AT90USB1286, виртуальный COM-порт Опции

[Visor]

Попробывал реализовать виртуальный COM-порт на AT90USB1286. За основу взял пример от Атмел (at90usb128-demo-cdc-1_0_3.zip). Подправил частоту (16МГц) и тупо загрузил, не пошло! Виндовс подключение устройства определяет, но тип устройства нет.
Может кто-то работал с этим примером, какие были проблемы (если были)?

[Visor]

Чип перестал работать, просто в один прекрасный день не завёлся и всё. Через ISP не отвечает. Проверил, на кварце нет генерации (16МГц). Заметил, что при отключении питания генерация на мгновение появляется при спаде питания ниже BOD. Что бы это значило?

[Xenia]

У меня появился новый животрепещущий вопрос по теме: как можно со стороны МК попросить хост сделать паузу в посылке данных? Те данные, которые уже пришли, МК готов безоговорочно принять, но хочет попросить хост, чтобы оставшиеся данные он пока не присылал, попридержав их у себя до тех пор, пока МК не будет к этому готов.

Рассмотрим конкретный пример, чтобы моя задача не казалась слишком абстрактной. Положим у нас имеется устройство не с USB-портом, а с обычным COM-портом (RS-232), которое работает "периодически": сначала набирает к себе в буфер данные, а затем что-то со всеми этими принятыми данными начинает делать, из-за чего нуждается в паузе, пока это дело не будет сделано. Сейчас не суть важно, что это за дело - может быть отправляет эти данные пакетом куда-то дальше, или записывет на диск, или отправляет по e-mail, - только приходится ждать, пока принятые данные не будут утилизированы, и лишь после этого устройство снова будет готово к приему новой порции данных. Причем подразумевается, что устройство не имеет в своем распоряжении столько памяти, чтобы сохранить весь поток данных, пришедшых во время исполнения дела.

Если это RS-232, то такая задача решается исключительно просто - данные передают с хэндшейкингом, используя линию DSR, как признак готовности к приёму данных. Тут устройство попросту устанавливает отрицательный уровень DSR, что является сигналом для хоста преостановить передачу данных. Когда устройство закончит "переваривать" принятые данные, оно снова установит на линии DSR положительную полярность, что побудит хост продолжать передачу с момента вынужденной остановки.

Но вот мы присоединили это устройство не к родному COM-порту компьютера, а через USB/COM-конвертор, выполненный на нашем МК. И вот видит наш МК, что устройство запросило паузу линией DSR, - что тогда ему делать? Собственная память у него есть, но ее не так много, чтобы сохранить все то, что отсылать устройству ему запрещено. Кроме того, он не знает точно, как долго продлится эта пауза. Единственным разумным выходом из этой ситуации было бы, в свою очередь, поступить аналогичным образом - тоже попросить USB-хост об отсрочке передачи.

Возможно ли такое в принципе, а если да, то каким образом делается? Ведь наш МК является ведомым, зависящим от посылок со стороны хоста. Как ему сигнализировать о том, что у него будет временный напряг с приемом?

DETACH снять я не могу - тогда USB-хост его попросту потеряет. FREEZE сделать? Но поймет ли хост? Что положено в этом случае делать?

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

[aesok]

Возможно ли такое в принципе, а если да, то каким образом делается? Ведь наш МК является ведомым, зависящим от посылок со стороны хоста. Как ему сигнализировать о том, что у него будет временный напряг с приемом?

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

8.5.2 Bulk Transactions
....
When the host is ready to transmit bulk data, it first issues an OUT token packet followed by a data packet
(or PING special token packet, see Section 8.5.1). If the data is received without error by the function, it
will return one of three (or four including NYET, for a device operating at high-speed) handshakes:
• ACK indicates that the data packet was received without errors and informs the host that it may send
the next packet in the sequence.
• NAK indicates that the data was received without error but that the host should resend the data because
the function was in a temporary condition preventing it from accepting the data (e.g., buffer full).
• If the endpoint was halted, STALL is returned to indicate that the host should not retry the transmission
because there is an error condition on the function.

Анатолий.