STM32 USB CDC некоторые данные потеряны с Win 10

#usb #stm32 #cdc #virtual-serial-port #stm32cubemx

Вопрос:

Я использую USB — устройство-плату разработки STMicroelectronics. Используйте встроенное ПО, поддерживающее USB-оборудование. Он работает как последовательный порт USB.

На хост-ПК (win10 21H1) я использую последовательный терминал («Tera Term») для получения данных с моего устройства. Я использую стандартный драйвер Windows usbserial.

Мое устройство отправляет данные. Если поток данных невелик (1-2-5 кБайт/с) — все работает нормально. Но если я ускоряюсь (поток около 100 Кбайт/с или более) — я вижу потерю данных.

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

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

В полученных данных я увидел потерянные 64 или 128… кратно 64 байтам. 64 байта — размер конечной точки в моем случае. Дополнительные сведения см. в разделе Связанные данные.

Я создаю проект USB_test в CubeMX. И добавьте простой код для отправки данных на ПК. Передача данных цикла, если предыдущая передача CDC завершена. Добавление задержек недопустимо: во-первых, это не 100% устранение потерь; во-вторых, это плохо сказывается на пропускной способности канала.

 //in main() function 

uint8_t is_transmit = 0;

HAL_Delay(5000);
uint8_t Buf[2048];
uint8_t k = 48;
// fill the array with printable characters
for(uint16_t i=0; i<sizeof(Buf)-2; i  ){
    if(k > 100) {
        k = 48;
    }
    Buf[i] = k  ;
}
// array - is a one string line
Buf[sizeof(Buf)-2] = 'r';
Buf[sizeof(Buf)-1] = 'n';
        
    
while (1)
{
    if(is_transmit == 0){
        is_transmit = 1;
        //HAL_Delay(1); // add delay on 1 ms reduces the likelihood of losses by an order of magnitude
        CDC_Transmit_FS(Buf, sizeof(Buf));
    }
}
 

В CDC_TransmitCplt_FS() я мигаю is_transmit.

 static int8_t CDC_TransmitCplt_FS(uint8_t *Buf, uint32_t *Len, uint8_t epnum)
{
    ---
    extern uint8_t is_transmit;
    is_transmit = 0;
    ---

  return resu<
}
 

Информация из файла журнала связи службы поддержки ST и USB — анализатора.
https://drive.google.com/drive/folders/1CvTPfaFGmcFxD4V5zTvsVE6U26DNwG2v?usp=sharing

Как я устраняю эту проблему? Мне нужен поток данных с устройства для размещения 500 кБ/с или более.

С наилучшими пожеланиями, Андрей.

Комментарии:

1. Стек драйверов последовательного порта Windows, по-видимому, содержит много кода, который управляет скоростью передачи. Вероятно, это имеет смысл для последовательного порта в его первоначальном воплощении, но мешает современной связи на основе USB с более высокой скоростью. Попробуйте увеличить скорость передачи данных в бодах (хотя теоретически это не имеет значения). В качестве альтернативы, откажитесь от CDC и используйте USB-устройство конкретного производителя.

2. 1. Скорость связи не влияет. 2. Откажитесь от CDC в устройстве stm32 и используйте CP210x или FTDI — нет, мне нужна синхронизация с другим USB (по пакету SOF). CP210x не предлагает этого. Спасибо вам за решения.

3. Я не предлагаю использовать чип CP210x или FTDI. Вместо этого я предлагаю использовать USB-порт STM32, реализующий одну или две массовые конечные точки с дескриптором устройства, который не объявляет устройство виртуальным последовательным устройством (USB CDC ACM). На стороне Windows вам понадобится WinUSB вместо API последовательного порта. И что вы подразумеваете под «Скорость связи не влияет»?

4. Спасибо, я посмотрю, что такое WinUSB (теперь наше программное обеспечение работает с последовательным портом). Я имел в виду настройку скорости передачи данных портов.

5. Я понимаю насчет winusb. Работа с winusb потребует некоторой работы как со стороны устройства, так и со стороны хоста. Но самое страшное — это отладка и тестирование, тестирование, тестирование …. И поддержка на протяжении всего жизненного цикла устройства. Я бы очень хотел оставаться в пределах функциональности последовательного порта. Это большая нагрузка для нашей команды. Это крайне нежелательно. Но мы рассмотрим эту возможность среди потенциальных результатов.