Использую libopencm3. За основу взят вот этот
пример CDC.
Размер фрейма для нашего ендпойнта настроен 64.
Написал простеньку логику: МК принимает фрейм, смотрит первый элемент и высылает назад статик массив размером, указанным в принятом байте.
Таким образом, я в терминале посылаю число и в ответ получаю заказанное кол-во байт.
Код:
Код
static void cdcacm_data_rx_cb(usbd_device *usbd_dev, uint8_t ep)
{
(void)ep;
int len = usbd_ep_read_packet(usbd_dev, 0x01, USBio.buffer, 64);
сdcacm_data_tx((uint8_t *)textBuf, USBio.buffer[0]);
}
Посылаю число 0х20 - получаю 32 байта данных.
Посылаю число 0х3F - gjkexf. 63 байта в ответ.
Посылаю 0x40 - тишина. Еще раз - тишина. Теперь внимание! Посылаю 0х01 - получаю 129 байт.
Т.е. пришли все запрошенные за прошлые 3 раза данные.
Выходит, что если МК посылает кол-во байт, совпадающее с размером фрейма - данные где-то зависают.Начал копать: посылает ли МК? Поставил коллбек по окончанию передачи, виду, что передача проходит.
Принимает ли ПК? К сообщению прикреплен скриншот USB сниффера.
Данные действительно где-то зависают. Буфер драйвера? Буфер USB контроллера?
Кто сталкивался?
UPD: нащел аналогичный
вопрос на форуме СТ. Он там остался без ответа)
UPD2:
Вот тут пояснили, что передача длиной равной размеру кадра должна дополняться передачей нулевой длины. Однако, такая логика не согласуется с логикой разрабов libopencm3, которые используют следующую логику для проверки занятости ендпойнта в функции отправки:
Код
while(usbd_ep_write_packet(usbd_dev, 0x82, buf, len) == 0);
Функция возвращает 0, если идет передача, таким образом происходит ожидание освобождения ендпойнта. Посылка длиной 0 байт приведет к зависанию и вообще не похоже, что такая вещь предусмотрена разрабами
Сообщение отредактировал drozel - Oct 19 2015, 10:46
STM4 USB CDC. Интересное поведение
Oct 19 2015, 10:35
