WCH-LinkE (CH32V305FBP6) USB2.0 HS.

[pvvx]

Кто может объяснить данное явление:

Как обычно закатал в WCH-LinkE сильно переделанную программу примера ch32v307\EVT\EXAM\USB\USBHS\DEVICE\SimulateCDC.
В ней исправил всё связанное с инициализацией PLL-ей, т.к. кварц на WCH-LinkE на 12 МГц, а не 8 МГц как во всех примерах от WCH.
Временно отключил UART (он всего там до 9 Мбит в сек, а мне надо десятки Мегабит), заменив на "Эхо" (что отсылается в USB то и приходит обратно) чтобы протестировать скорость USB на разных размерах передаваемых-принимаемых блоков в CDC (USB-COM).
Протестировал старым своим питоно-скриптом.

>python3 DevEchoCDCTstTxRx.py -p COM21 -c 10000 8120 8120
USB Echo Utility version 20.10.19
Start 10000 cycles Tx 8120 -> Rx 8120
------------------------------------------
  Time: 6.081 sec
Cycles: 10000 (transactions)
Writes: 81200000 Bytes (13039.033 KBytes/s)
Reads: 81200000 Bytes (13039.033 KBytes/s)
OldBlk: 55 aa 1fb8 270f ..
------------------------------------------
IO Speed: 26078.066 KBytes/s

~ 25.5 MBytes/s

Скрипт передает фиксированный размер блока в COM и ждет приема ответа аналогичного переданному и так повторяет указное кол-во раз. Данные в блоке изменяются по номеру счетчика транзакции и сверяются...

В итого, как всегда:

Нарывается на предельный размер в 8120 байт, где далее идет падение скорости(!?).

Если тестируемый WCH-LinkE всунуть в другой порт USB, то вылезают и другие ограничения:
- в некоторых портах или через разные USB хабы (USB2.0...USB3.1...) вообще происходят сбои при блоке более чем 4095 байт.
Замеры скоростей передачи до этих ограничений примерно одинаковы...

Но от куда данные ограничения и провалы?

Ранее где-то мелькала информация о не полной скорости USB2.0 на драйвере или самом USB у AMD процов, проявляющуюся в редких тормозах... Например об этом писалось в Saleae при работе с Cypress CY7C68013A, так же у NRF в PowerProfiler II (хотя там всего USB2.0 FS) . Так и не исправили... Решается методом перебора и тыка в другой порт или через USB-Хаб.

Кто видел решение данной проблемы?

 

[pvvx]

Добавление в Питоне serialPort.set_buffer_size(rx_size = 65536, tx_size = 65536) никак не помогло.

Изменение алгоритма – прием-передача по одному блоку для EP USB (до 512 байт) с ожиданием, т.е. всё по очереди, тоже не принесло успехов. При более 8КБ типа теряется пакет… а скорость просела до 15 Мегабайт в сек. Надо глядеть ослом шину USB на 480 Mbit …

 

[pvvx]

Увеличение частот CPU и вся, так-же не помогло. Была надежда, что что-то не успевает в прерывании...
(И нечего смотреть позорные видео о том, что незя поставить частоту CPU на 144MHz, когда используется USB. У USB свой PLL на 48MHz, обычно перемножающий частоту кварца деленного на 2.)
log старта:

Simulate USB-CDC Device running on USBHS Controller
ChipID: 30520518
SYSCLK: 144000000
HCLK:   144000000
PCLK1:  144000000
PCLK2:  144000000
ADCCLK: 72000000

 

[pvvx]

Почти полностью переписал пример USB CDC от WCH.

Скорость потока возросла к 30 Мбайт в сек, т.к. пошел частичный дуплекс - прием с передачей и выкинуты лишние наляпанные в коде передачи ...

Теперь имеется четкое ограничение в виде непрерывно считываемых по USB блоков компом. Более 36 штук аппаратных фреймов в тестируемый USB3.1 по протоколу USB2.0HS не лезет, толи в чипсет, толи кривые дрова USB-CDC у Windows... Не считывает дальнейшие блоки после 36-го из EP USB и выходит по таймауту. Очередная халтура.

CDC работает тупо, но имеет синхронизацию-разбивку потока на фреймы. Т.е. если послан блок максимального размера FIFO USB (в данном случае я выставил 512 байт), то если это конец фрейма, тогда передается блок с длиной “0”, как завершающий. В других случаях передача блока с меньшей длиной, чем максимальная является концом фрейма.

Пример: надо передать единый блок в 1222 байта. Это будет 3 посылки 512+512+198 байт.

Но если надо передать 1536 байт, тогда это будет: 512+512+512+0, т.е. 4-ре передачи, с завершение передачи блоком с длиной 0.

Дык вот комп не жрет в USB2.0HS фрейм более 18432 байт

Надо пробовать иногда, через N полных блоков, давать нулевой блок... Но это убьет всю разбивку на фреймы.... В чипсете не нашлось транзисторов для буфера в мегабайты?

 

[pvvx]

Т.е. подсказать никто ничего не может...
Оставлю пока так, как вышло:

До 18 килобайт фрейма в USB-CDC да в Питоне работает, с буферизацией в 4 килобайта выдает за 30 Мегабайт в секунду чистых перекачанных байт на финтифлюшке WCH-LinkE.
Для Ардуинщиков нужна UART на 300 Мегабит Но в чипе есть всего 1Мbps 12 бит ADC....

 

[nikolz]

Кто может объяснить данное явление:
Если тестируемый WCH-LinkE всунуть в другой порт USB, то вылезают и другие ограничения:
- в некоторых портах или через разные USB хабы (USB2.0...USB3.1...) вообще происходят сбои при блоке более чем 4095 байт.
Замеры скоростей передачи до этих ограничений примерно одинаковы...
Но от куда данные ограничения и провалы?

Может быть 4К связано с размером страницы. Переход на новую требует дополнительных затрат времени, которого нет.

 

[pvvx]

Может быть 4К связано с размером страницы. Переход на новую требует дополнительных затрат времени, которого нет.

В Wireshark в Windows данные от устройства поступают блоками по 4 кило. Но это никак не связано с сегментами проца. Скорее всего с win-дровами USB-CDC. 4 блока по 4 и потом всё. Wireshark уже на уровне API...
Ещё ограничение может быть связано с API Питона.
Мне пока фреймы более 8 кило не нужны... Но...

 

[pvvx]

В самом чипе CH32V30X нет много RAM и большие фреймы не требуются. Только если задача конвертации/шифрования проходящего потока. И то зачем там CDC (COM-порт)?
А на малых фреймах в 4 кило всё будет хорошо - уже достигается максимальная производительность USB2.0 HS.

 

[pvvx]

У Modbus фрейм вообще до 254 байта. И при использовании USB-CDC блочная синхронизация соблюдается.
Гнать SD карточку через USB-COM нет смысла - там свой USB драйвер.
Но если хотим передать файл (пусть c SD карточки) - тогда придется городить свою систему блочной синхронизации потока, т.к. в CDC сидит описанная бяка-баг, которая не дает это сделать штатными средствами.

 

[pvvx]

А вставка своей системы блочной синхронизации = уменьшение пропускной способности шины. Будут лишние синхро чтения уже на уровне USB, не считая лишние байты в потоке для разметки фреймов.
Ардуинщикам и программерам (не системным) это безразлично - от этого и имеем баги такого типа в самом корне систем.

 

[pvvx]

Вообще про всё это нормальных описаний в инет не найти уже много лет. Есть только вякания неких в коментах к вопросам по данным темам. А глубоко изучать спецификацию USB в здравом состоянии никто не будет.

Микрософт описывает некоторые части, но со своем уклоном При этом приводит детские игрушки (на древних чипах) в качестве средств для отладки системных драйверов, а не нормальное проф. оборудование. Видимо по этому такой уровень дров и есть в Windows.

 

[pvvx]

Итог очередного баловства с USB-COM + ADC:

Осел на 923 ksps 12 бит в эксплорере... На вход ADC CH32V305 подключена качающаяся частота 1..10 кГц (пила).

 

[pvvx]

Возможно и два канала, т.к. в чипе ADC две шутки по до 1Mbps. При 12 бит и расширении до 16 бит это всего 32 Мегабита в сек, а USB 2.0 HS дает за 20 Мегабайт в сек. Это всего займет до 25 % пропускной способности, но справиться ли Java (JS) в эксплорере (?)...

 

[pvvx]

И по шумам достойно (- не ESP32 ) , при работе от USB без всякой фильтрации питания и соединении китайскими железными проводами и разъемами к генератору:

20 мВ p-p 1 кГц (меньше ген не выдает). Масштабирование в 100 раз (полная шкала 33 мВ).

 

[pvvx]

Тест скинут на github