Выкладываю готовый тестовый проект USB CDC устройства для серии AT91. Среда - IAR EWB for ARM 5.40
Скорость передачи (по показаниям RealTerm 2.0.0.57) порядка 300 кБ/с.
Прерывания используются только для обработки setup-запросов.

Замечания приветствуются.

При каком бодрэйте?

При любом

а, думал данные потом через uart гонятся =)

А почему так строго с прерываниями?

А чего тут строгого? Просто приоритет setup-запросов, ИМХО, всегда выше чем обмен данными с приложением. Можно, конечно и без прерываний, как сделано в атмеловских апноутах - т.е. перед операцией ВВ выполняется проверка флагов прерываний.

А можно все делать по прерываниям и весь вопрос только в том, какой endpoint обрабатывается в прерывании первым (соответственно ep0 должен быть первым).

Безусловно. Все зависит от организации программы.

Смысл имеет по большому счету только при наличии OS. Что делать, если данные пришли, а места для них пока нет? Или наоборот - ушли, а новых еще нет.

Очень не хватает DMA атмеловскому UDP, так была бы полная автоматика.

1. Отслеживать эти события и принимать соотвествующие меры. Можно все это и без всякой OS сделать.
2. Если вы имеет Atmel ARM с кешами, то наличие DMA не сильно чего улучшит. Вам придется либо DMA буфера организовать в некешируемой области с последующим копированием по месту, либо обеспечить когерентность кеша за счет flush/invalidate. Учитывая, к тому же, специфические требования к выравниванием адресов для DMA обменов, все ооочень становится нетривиальным.

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


Во-первых, мы не имеем ARM с кэшами, поэтому страшилки про когерентность тут не к месту. А у того же PDC, например, нет каких-либо особо специфических требований к выравниванию.
С нормальным DMA как раз все стало бы очень просто и удобно: есть буферы для приема/передачи - DMA читает дескрипторы и гоняет данные; нет - хост получает NAK'и.

Мечтать не вредно. На практике ничего этого не наблюдается.




А мы имеем.



Топик про at91. В этом семействе полно процессоров с кешами. Я не оракул, чтобы знать про какие конкретно процессоры идет речь.

PDC имеет дело всегда со 32-х битными словами - уже ограничение. Если вы посмотрите на многочисленные примеры и errata, то там то сям надо выравниваниее DMA-буферов то на 256, то на 1024. Полная каша.




И что тут нормального. Ну "встал" входной поток данных, а кто "будить" то все это будет? А если вы пользуете USART с DMA? Какие там NACK'и? Нет, увы, единого подхода к решению этой проблемки.

У Атмела - да, не имелось. На SAM3 только прикрутили персональный DMA для USB.


А без оных еще больше.


Да ну? Вас кто-то обманул.


Казалось бы ответ должен быть очевиден. Будить будет IN или OUT токен от хоста. По нему DMA-автомат
проверит готовность буфера и осуществит транзакцию, если это возможно.


Вот только не надо валить все в одну кучу. Изначально мы говорили о DMA применительно к USB. И вдруг откуда-то
вылезли "страшные" кэши, 1024-байтные выравнивания, 32-х битный PDC и прочее не буду говорить что.

Да уж, в сердцах, сморозил. Виноват.

Да я и сам бываю... излишне эмоционален, не взыщите

У меня в Realterm почему-то скорость работы этого примера сильно зависит от машины, к которой подключаю устройство, самую большую скорость получил на ноутбуке, к которому из USB-устройств больше ничего не было подключено - 120 Кбайт/с, а так средняя 70 Кбайт/с и опускается вплоть до 20.

Как я понимаю такая разница из-за хоста и того, как он планирует bulk-транзакции....
Можно ли как-то заставить хост хормировать как можно больше bulk-транзакций в фрейме?

Еще заметил разницу в скорости приема данных в Realterm, если данные принимаются просто в консоль или же собираются в файл, то скорость при сборе данных в файл примерно в полтора раза выше, значит имеет значения как мы нагружаем хост?