Всем привет,
Я публикую здесь, потому что в последнее время работал над проектом, который включает в себя быстрый USB -серийный прием огромного количества данных (~ 150 КБ) на Maple Mini (Blue Pill).
@primateio выяснил, и я признал, что из -за некоторых проблем в текущей версии модуля USB CDCACM некоторые байты были потеряны.
См. Тема Связанный форум здесь, и на GitHub.

Теперь я разработал версию, которая преодолевает обнаруженные проблемы и, таким образом, обеспечивает скорость RX до ~ 600 Кбит / с, сильно влияя вовлеченный USB -хост (ПК) и его ежедневное настроение (по крайней мере, на моей машине Win10)... Тем не менее, кажется, что я больше не потерял байтов.
В качестве положительного побочного эффекта размер буфера RX был уменьшен (сейчас 256 байтов, ранее 512).

Кроме того, я также переработал сторону TX, потому что текущая версия не позволяет отправлять более 64 байтов одновременно. Он ждет, пока они не будут полностью отправлены, и только после того, как эти новые байты будут приняты, чтобы отправить, снова. Это довольно неэффективно и, следовательно, медленно.
Вместо этого я внедрил кольцевую трансмиссию, аналогичную части RX.
Размер буфера TX в настоящее время устанавливается на 256 байтов (сохраненные байты образуют деталь RX, поэтому в целом нет оперативной памяти). Это означает, что TX блокирует только в том случае, если вы очень быстро отправляете более 256 байтов.

Я протестировал новую версию (прикрепленную), до сих пор не обнаружено проблем.
Но все же, я хотел бы попросить некоторых из вас, кто заинтересован в этом, проверить часть RX и TX, как можно лучше.

Если вы думаете, что это стоит, мы могли бы даже отправиться в мастер -филиал.

Любое предложение/комментарий приветствуется.

ОБНОВЛЯТЬ
Я тоже переработал часть TX. На самом деле я могу достичь скорости ~ 300 Кбит / с для TX, независимо от размера буфера USB TX.
Что означает, что ограничение находится в коде пользователя.
Изменения можно найти здесь.

Похоже, это готово к большому времени

Вы можете отправить пиар ?

Привет, Роджер, пиар отправляется.

Спасибо

Я протестирую позже

@Stevestrong: Был бы у вас любой тестовый эскиз, доступный для тестирования производительности? Я хотел бы попробовать это и сравнить числа с текущим мастером и вашим патчем. Спасибо.

Какая скорость передачи вы предлагаете для максимальной выходной сигнала TX KB/SEC ?

Чтобы установить скорость передачи, на самом деле излишнее, поскольку USB -сериал будет толкать байты так быстро, насколько это возможно, независимо от настройки пользователя.

Я опубликую тестовый код вечером.

Обратите внимание, что скорость TX сильно ограничена кодом пользователя. В своем простом тесте я просто снова и снова нажимаю на USB -сериал USB.
Если вы попытаетесь загрузить данные, скажем, с SD -карты, то скорость USB TX быстро падает ниже ~ 60 кбит / с, ограниченная скоростью чтения из карты.

Хорошо, спасибо!

Я понимаю, что SD -карта ограничит производительность. В моем случае проблема, по -видимому, заключается в том, что с операцией TX будет блокировать (слишком долго), которые, кажется, влияют на другую часть программы.


Кстати: мне пришлось сделать одну небольшую модификацию, чтобы скомпилировать патч:

usb_serial.час

строка 68: size_t write (const uint8* uint32);

michael_l написал: Кстати: мне пришлось сделать одну небольшую модификацию, чтобы скомпилировать патч:
usb_serial.час
строка 68: size_t write (const uint8* uint32);

Спасибо, я просто смотрел на коммит, но не понял, что вы уже исправили.

Это мой код печати. Интересно, будет ли производительность лучше, если я создам температурный буфер, сначала заполняющий данные, и отправлю все это за один вызов в сериал.println ? Я думаю, да, потому что каждый байт отправляется в один USB -пакет. Я использую этот же код в ESP8266, и он, похоже, не заблокируется так же, как. Хорошо, это другой MCU, но все же...
void printMsg() { Serial.print(micros()); Serial.print(",ID: "); Serial.print(id, HEX); Serial.print(",Data: "); for(int i = 0; i