Receive double buffering for STM32F1xx #456

makarenya · 2019-02-24T19:31:01Z

Receive double buffering for STM32F103 and others. Milestone 1

Affected devices:

STM32F103x6
STM32F103xB
STM32F103xG
STM32F103xE
STM32F102x6
STM32F102xB

Transmission double buffering not tested yet.

Reception works. It achieve maximum CDC speed, available for this devices.
It also contains a set of fixes and improvements.

fpistm

I will review it deeply later.
Just a first request changes:
Remove the .idea (you can also use .gitignore to ensure not add it after)

makarenya · 2019-02-25T08:52:03Z

Ok. .idea removed.
All my changes are splitted by a set of commits. Many of them very small and and evident.

makarenya · 2019-02-25T09:22:15Z

And... You can review it later... but maybe you can test it? Speed on bluepill. And communication errors?

fpistm · 2019-02-25T09:26:06Z

Yes I will test it. ;)

fpistm · 2019-02-26T16:57:46Z

Board: BluePill F103C8
Test: Benchmark_USB_Receive_Standard from PJRC.
- Without this PR:
  - Linux: Average bytes per second = 288175
  - Windows: Average bytes per second = 296861
- With This PR:
  - Linux: Average bytes per second = 1251652
  - Windows: errors transmitting data

On Windows, AnalogReadSerial is functional only the benchmark test return an issue.
Data integrity will need to be tested.

FYI, benchmark code returning the issue:

		for (sent = 0; sent < 50000; sent += size) {
			n = transmit_bytes(port, buffer, size);
			if (n != size) die("errors transmitting data\n");
		}

makarenya · 2019-03-05T20:27:43Z

It was hard. Very hard, so hard, that i must say any bad word: poop. Ok, i'm better. But i tested receiving on my mac and linux, and it works in many cases. I done it without interrupt disabling... Please, test it

fpistm · 2019-03-06T14:31:59Z

Thanks @makarenya
I've started to debug but I had to switch to some other task. I will test it as soon as possible.

makarenya · 2019-03-06T17:30:11Z

And some interactive rebasing...

Old review

- Transmit endpoint over receive endpoint in both branches (style correction). - Initialize receive buffer for the double-buffered endpoint (as single buffered already have) - In double buffering transmission, set EP to valid, and set DTOG-s to the same buffer for NAK-ing After activation, all endpoint would NAK-ing for any host attempt to receive anything,

it is impossible to determine exactly how large the allocated buffer should be. To achieve double-buffering acceleration, the PCD_FreeUserBuffer call must occur before the HAL_PCD_DataOutStageCallback call. But the real data buffer can be allocated only in this callback. It turns out that the approach itself needs to be changed - always allocate maximum allowable endpoint buffer size (it's already happends in USB_ActivateEndpoint). At the same time we need to check the size of the data received. This check be done at the time of data receipt. During reception confirmation, it may be that there is no allocated buffer at all. In this case, we will have to leave the filled PMA intact and not complete its release. In this case, this operation will be repeated in HAL_PCD_EP_ReceiveData.

fpistm

Only one questions around double buffering.
Else seems nice. I will need to test deeply.

cores/arduino/stm32/usb/cdc/usbd_cdc.h

cores/arduino/stm32/usb/usbd_conf.c

fpistm · 2019-03-07T16:26:01Z

Argh, just retry with BP the speed test... and got old results ⁉️

Average bytes per second = 253013

makarenya · 2019-03-07T16:31:45Z

I test BluePill on the two platforms: OpenWRT MT7688 Linux host and on my MacBook Pro 2017... And i get about 760 000 bps on first and 720 000 on second.

makarenya · 2019-03-07T16:33:27Z

Moreover, I cannot get a speed greater than 760,000 under any circumstances at all, even if I do nothing in response to the IRQ, but simply say that the buffer is free and the hardware can work further.

makarenya · 2019-03-07T17:03:19Z

I just dust off my windows PC and repeat all tests with the BluePill
With PR:

System	Before PR	With PR
OpenWRT on MT7688	730 000	760 000
MacBook Pro 2017	540 000	709 000
My old PC with i7 1-st gen	510 000	940 000

As you can see, on windows system speed is close to theoretical maximum

fpistm · 2019-03-07T19:23:09Z

~~Strange, I will check that tomorrow. 😞~~
So, still the same issue.
Have you fix the resistor for USB of your BP ?
Anyway tested on Maple with the same result 😣
Reverting clean buffer allows to get speed higher on Linux but test failed on Windows. But clean is required.

makarenya · 2019-03-08T10:13:13Z

No, i'm using original chinese BP. Two BP-s. First - connected to my MacBook via micro usb cable, second one connected to OpenWRT via two 68 Ohm resistors (resistors connects A11 and A12 pins of the BP board to the USB- and USB+ pins of OpenWRT board)

makarenya · 2019-03-08T10:25:28Z

It seems to me, that there are reasons, that doesn't allow your host to speed up greater than 250 000 bps... Maybe some isochronous device connected to it... USB speakers or mic...

fpistm · 2019-03-08T14:34:47Z

Well, seems my host USB stack was corrupted.... Fresh restart and it's work.
I've made several iterations and never seen issue.
Speed is now correct and seen no data corruption.

…ring_for_f1 Receive double buffering for STM32F1xx

fpistm self-requested a review February 25, 2019 07:59

fpistm previously requested changes Feb 25, 2019

View reviewed changes

makarenya force-pushed the receive_double_buffering_for_f1 branch 3 times, most recently from c1e5b09 to 2e88dba Compare February 25, 2019 08:36

fpistm self-requested a review February 25, 2019 08:38

makarenya force-pushed the receive_double_buffering_for_f1 branch 2 times, most recently from c9309c1 to 7b09ae3 Compare February 25, 2019 08:48

makarenya force-pushed the receive_double_buffering_for_f1 branch from a6f600e to ffb44b5 Compare March 5, 2019 20:21

makarenya force-pushed the receive_double_buffering_for_f1 branch 2 times, most recently from b872823 to 0cd04d8 Compare March 6, 2019 17:26

makarenya changed the title ~~Receive double buffering for f1~~ Receive double buffering for STM32F1xx Mar 6, 2019

makarenya force-pushed the receive_double_buffering_for_f1 branch 2 times, most recently from 051ad2b to 1cd5b35 Compare March 6, 2019 19:04

fpistm added enhancement New feature or request review on going labels Mar 7, 2019

makarenya force-pushed the receive_double_buffering_for_f1 branch from 3065501 to f3fdfe3 Compare March 7, 2019 13:48

makarenya added 5 commits March 7, 2019 16:52

Maxpacket not really used in the code, it's const, not variable

f337aa5

Variables total_length and rem_length moved into device specific context

9d71bad

Removed unused variable

8885e01

Unnecessary PMA write removed.

8b9cb4d

makarenya added 5 commits March 7, 2019 16:52

Small rewrite, will be used in future.

b195fda

Save cpu cycles...

e5b25f8

Move receiving to double buffering on STM32F10x

bd21778

Small simplification

2bdb516

makarenya force-pushed the receive_double_buffering_for_f1 branch from 126c341 to 2bdb516 Compare March 7, 2019 13:55

fpistm reviewed Mar 7, 2019

View reviewed changes

cores/arduino/stm32/usb/cdc/usbd_cdc.h Show resolved Hide resolved

cores/arduino/stm32/usb/cdc/usbd_cdc.h Show resolved Hide resolved

cores/arduino/stm32/usb/usbd_conf.c Show resolved Hide resolved

fpistm approved these changes Mar 8, 2019

View reviewed changes

fpistm removed the review on going label Mar 8, 2019

fpistm added this to the 1.5.1/1.6.0 milestone Mar 8, 2019

fpistm merged commit c7dffcd into stm32duino:master Mar 8, 2019

makarenya deleted the receive_double_buffering_for_f1 branch March 8, 2019 18:21

fpistm mentioned this pull request Mar 24, 2019

USBSerial loosing characters on Linux #478

Closed

benwaffle pushed a commit to benwaffle/Arduino_Core_STM32 that referenced this pull request Apr 10, 2019

Merge pull request stm32duino#456 from makarenya/receive_double_buffe…

fb75eaa

…ring_for_f1 Receive double buffering for STM32F1xx

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Receive double buffering for STM32F1xx #456

Receive double buffering for STM32F1xx #456

makarenya commented Feb 24, 2019 •

edited

Loading

fpistm left a comment

makarenya commented Feb 25, 2019

makarenya commented Feb 25, 2019

fpistm commented Feb 25, 2019

fpistm commented Feb 26, 2019 •

edited

Loading

makarenya commented Mar 5, 2019

fpistm commented Mar 6, 2019

makarenya commented Mar 6, 2019

fpistm left a comment

fpistm commented Mar 7, 2019

makarenya commented Mar 7, 2019

makarenya commented Mar 7, 2019

makarenya commented Mar 7, 2019

fpistm commented Mar 7, 2019 •

edited

Loading

makarenya commented Mar 8, 2019

makarenya commented Mar 8, 2019

fpistm commented Mar 8, 2019

Receive double buffering for STM32F1xx #456

Receive double buffering for STM32F1xx #456

Conversation

makarenya commented Feb 24, 2019 • edited Loading

Receive double buffering for STM32F103 and others. Milestone 1

fpistm left a comment

Choose a reason for hiding this comment

makarenya commented Feb 25, 2019

makarenya commented Feb 25, 2019

fpistm commented Feb 25, 2019

fpistm commented Feb 26, 2019 • edited Loading

makarenya commented Mar 5, 2019

fpistm commented Mar 6, 2019

makarenya commented Mar 6, 2019

fpistm left a comment

Choose a reason for hiding this comment

fpistm commented Mar 7, 2019

makarenya commented Mar 7, 2019

makarenya commented Mar 7, 2019

makarenya commented Mar 7, 2019

fpistm commented Mar 7, 2019 • edited Loading

makarenya commented Mar 8, 2019

makarenya commented Mar 8, 2019

fpistm commented Mar 8, 2019

makarenya commented Feb 24, 2019 •

edited

Loading

fpistm commented Feb 26, 2019 •

edited

Loading

fpistm commented Mar 7, 2019 •

edited

Loading