[EmbedElektrik 0]

Для передачи данных с ацп в комп использую пример VCP из StdLib, выбросил все лишнее и работаю напрямую с эндпоинтами. Раз в 8 мс отправляю с контроллера в комп вот так: DCD_EP_Tx (&USB_OTG_dev, CDC_IN_EP, (uint8_t*)APP_Rx_Buffer, 1008); Т.е. скорость примерно 126 кб/сек. Обычно все работает нормально, но если комп начинает свопить то теряются данные. Почитал UM1021, но так и не понял как контролировать опустошение буфера IN эндпоинта?

[jcxz 184]

Никак не надо контролировать, надо отправлять правильно. Если необходим непрерывный поток данных с фикс. скоростью, то нужно использовать изохронную точку.

И как понять "отправляете"? Отправлять device сам, по своей инициативе, никак не может. Только в ответ на запросы host-а.

[EmbedElektrik 0]

надо отправлять правильно.

вообще то я об этом и прошу совета

Если необходим непрерывный поток данных с фикс. скоростью, то нужно использовать изохронную точку.

Изохронная передача не гарантирует доставки. Да и нужная мне скорость значительно ниже максимальной пропускной способности USB, bulk с запасом должен справляться.

И как понять "отправляете"? Отправлять device сам, по своей инициативе, никак не может. Только в ответ на запросы host-а.

Я же указал функцию отправки. Подразумевается запись в точку IN откуда хост забирает пакет.

[jcxz 184]

Изохронная передача не гарантирует доставки. Да и нужная мне скорость значительно ниже максимальной пропускной способности USB, bulk с запасом должен справляться.

И зачем Вам гарантированная доставка? У Вас вокруг такие помехи, что данные искажают???

Поймите элементарную вещь - гарантированная доставка в USB реализована за счёт повторов повреждённых пакетов, следовательно - в эндпоинтах которые её обеспечивают ни о каком реалтайм-потоке говорить нельзя.

У Вас выбор - или реалтайм-поток или гарантированная доставка.

И кроме того - bulk совершенно не гарантирует время доставки пакета, может 1мс, а может и 100мс (если а соседний разъём воткнули флеху и начали на неё писать файл). Используете bulk - забываете о любом реалтайме.

А для реалтайм-потоков самой спецификацией USB и заложен изохронный режим. Читайте доки.

Если Вы себя считаете умнее разработчиков USB - флаг Вам в руки в изобретении своего велосипеда с квадратными колёсами.

 

Я же указал функцию отправки. Подразумевается запись в точку IN откуда хост забирает пакет.

"Отправка" подразумевает запись в регистры буфера передатчика USB-периферии, а не в какой-то программный буфер, откуда ещё неизвестно когда и кем отправится и отправится-ли вообще.

[EmbedElektrik 0]

И зачем Вам гарантированная доставка? У Вас вокруг такие помехи, что данные искажают???

...

Если Вы себя считаете умнее разработчиков USB - флаг Вам в руки в изобретении своего велосипеда с квадратными колёсами.

 

 

"Отправка" подразумевает запись в регистры буфера передатчика USB-периферии, а не в какой-то программный буфер, откуда ещё неизвестно когда и кем отправится и отправится-ли вообще.

 

Да ё-моё, ну вопрос же конкретный звучал - можно ли контролировать завершение отправки или нет. Вот к чему эти Ваши догадки о нужности мне гарантированной доставки, помехах и флешках в соседних гнездах? Я Вас услышал, спасибо за Ваше мнение.

[esaulenka 5]

Можно контролировать, конечно.

Только для этого надо читать не описание "библиотеки", а reference manual.

 

OTG_FS device endpoint-x interrupt register (OTG_FS_DIEPINTx)

 

Bit 7 TXFE: Transmit FIFO empty

This interrupt is asserted when the TxFIFO for this endpoint is either half or completely empty. The half or completely empty status is determined by the TxFIFO Empty Level bit in the OTG_FS_GAHBCFG register (TXFELVL bit in OTG_FS_GAHBCFG).

 

Только вот DCD_EP_Tx() - это ниразу не "работаю напрямую". Это "передать первую часть буфера в FIFO, включить прерывание TX Empty, чтоб потом передать остаток".

Там, скорее, надо копаться в кишках этого кода, вроде б, в счётчиках структуры USB_OTG_EP.

[EmbedElektrik 0]

Можно контролировать, конечно.

Только для этого надо читать не описание "библиотеки", а reference manual.

 

Ок, большое спасибо. Пока решил проблему выставив на компе высокий приоритет потоку приема. Но это, конечно, костыль, хоть и стабильно работающий. Теперь ясно куда копать. С НГ!

[jcxz 184]

Ок, большое спасибо. Пока решил проблему выставив на компе высокий приоритет потоку приема. Но это, конечно, костыль, хоть и стабильно работающий. Теперь ясно куда копать. С НГ!

А где гарантия, что Ваши данные переданные USB-драйверу для передачи этим высокоприоритетным потоком, далее, внутри драйвера, не обрабатываются низкоприоритетным потоком? ;)

Была у меня такая фигня с CyUSB под WinXP. Никакое повышение хоть до самого наивысшего приоритета потоку не помогало, когда в момент передачи на экране происходило сворачивание/разворачивание какого-либо окна. Разворачивание окна - это была самая убойная вещь - задержки происходили до неск. сот мсек. Под следующими версиями виндов эффект не проявлялся.