Я не знаю есть ли какой специальный механизм для этотго в CDC. Для Bulk ендпоинт это реализуеться посылкой NAK в ответ на OUT пакет.



Анатолий.

Механизм есть. Он описан в спецификации CDC, там описаны запросы. Общая идея, есть запросы SET LINE CODING. Хост запрашивает скорость, число бит и т.д. в т.ч. тип управления потоком аппаратный или программный. Когда хост узнает, что управление потоком будет аппаратное, он запрашивает как именно будет управляться поток. Форматы запросов и ответов есть в спецификации на CDC.

Сообщение отредактировал tAmega - Jan 20 2009, 15:03

SET_LINE_CODING передает от хоста в МК dwDTERate, bCharFormat, bParityType, bDataBits; т.е. скорость в бодах, формат, четность и число стоп-бит. Все это передается затем, чтобы МК повторил эти установки на своем RS-232-порту, т.к. для обмена по USB эти данные не нужны.
GET_LINE_CODING запрашивает эти же данные (обычно те же самые, что были раньше пререданы хостом командой SET_LINE_CODING).
Есть еще SET_CONTROL_LINE_STATE, посредством которого хост может выразить желание изменить уровни DSR и RTS. И это всё!
Никакого аппаратного хендшейкинга здесь нет!

Практика показывает, что все эти три команды подаются только при открытии USB-порта (виртуальный COM), а в процессе передачи никогда не подаются. Поэтому нет и никакой возможности подать сигнал о том, что линии изменили полярность в процессе передачи. Т.е. раз хост не спрашивает, то и ответить ему не представляется возможным.

====================================================================



ACK'ом или NAK'ом можно отвечать на запросы от НУЛЕВОГО эндпоинта, на специфические ЗАПРОСЫ. Однако поток данных идет по эндпоинту RX_EP и не требует никаких ответных реплик. Там только бит FIFOCON устанавливают, чтобы показать, что буффер опустошен. Никаких посылок оттуда я посылать не могу, т.к. они не предусмотрены протоколом.
А в процессе передачи данных никаких запросов по нулевому эндпоинту нет вообще, а потому и отвечать не на что.

Сообщение отредактировал Xenia - Jan 20 2009, 16:26

И не надо. Просто не выгребаете данные из RX_EP и хост будет курить бамбук сколько надо. Это поддерживает сам USB-контроллер, посылая в ответ на пакеты хоста NAK, если нет места в приемном буфере. Хост, соответственно, будет перепосылать пакет, пока девайс не ответит ACK.

Механизм NAK'ов в USB работает на любых ендпоинтах. Не ставьте FIFOCON, железка будет посылать хосту NAK'и и поток затормозится.

Упс, опередили

Вау! Так просто?! Т.е. забираю из буфера по мере использования, а заботиться о том, что он переполнится мне не надо? Так это же кайф!

А то я приметила что флэшка (виртуальный диск) тоже начинает внезапно томозить, когда в нее закачиваешь длинный файл. Я еще сильно удивлялась, как ей удается сопротивляться внешнему накачиванию данными. Ведь у нее скорость записи медленнее, чем скорость передачи по USB2.0.

Странно!!!!

На странице 221 "Universal Serial Bus Specification" параграфе "8.5.2 Bulk Transactions" написано и нарисованно что можно отвечать NAK для Bulk endpoint (также как и на Control/Interrupt endpoint). Это на Isochronous нет ACK/NAK/STALL. А откуда у вас информация что NAK работает только на controll endpoint?

Я так понимаю Вы работаете с Bulk ендпоинт. Тогда требуеться минимум действий. Расмотрим Bulk OUT endpoint, параграф "22.14 OUT endpoint management" даташита AT90USB64/128.

Когда приходит OUT пакет выставляться 2 бита:
RXOUTI - флаг прерывания по причине прихода пакета, который сразу можно сбросить и
FIFOCON - FIFO Control Bit - говорящий о том что буфер занят
пришедшим пакетом. Пока Вы не сбросите этот бит вы можете к какой угодно
скорость читать данные из этого буфура, при этом USB контроллер будет
отвечать NAK-ом на все попытки хоста передать следующий пакет. Как только Вы
полностью прочитаете буфер, Вы сбрасываете бит FIFOCON в 0. И теперь при
очередной попытке хоста передать пакет, контроллер запишет его в
освободившийся буфер, ответит хосту ACK, и выставит биты RXOUTI и FIFOCON.
И.т.д....

Другими словами сбрасывайте бит FIFOCON после того как полностью обработали пришедщий пакет, все остальное хост с USB контролером в mege все сделают сами.


Анатолий.

Сообщение отредактировал aesok - Jan 20 2009, 17:48

Тоже думал уже сильно "переосмыслить" примеры, но, как всегда, велосипед уже изобретен.
http://www.fourwalledcubicle.com/LUFA.php
Куда как болие прямой USB стек от фанатов. Под WinAVR. C кучей DEMO. Понравился.

Ну вот, новая "радость" на наши головы - Windows 7.
Не работает под ней.

Да уж... только с XP разобрался, опять новые веяния... Благо "семерка" еще не доминирует... пока...

С "вистой" не работаю принципиально, т.к. о покойниках либо хорошо, либо никак... а вот в "семерке" должны быть
предусмотрены настройки для эмуляции более ранних ОС...

Давайте пробовать вместе. Я использую AT90USB162 и основательно мной "раскуроченные" на кирпичики Атмеловские
демки... Использую в основном HID, думаю "семерка" должна поддерживать без проблем со стороны МК, а вот со стороны
PC возможно уже другие драйвера для HID... Не знаю... Надо пробовать.

С HID не знаю, не пробывал, здесь мы мучаем CDC.
Речь конкретно о at90usbxxx_cdc.inf .