[aesok 0]

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

 

Я не знаю есть ли какой специальный механизм для этотго в 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.

 

Анатолий.

[tAmega 0]

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

Изменено 20 января, 2009 пользователем tAmega

[Xenia 40]

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

 

SET_LINE_CODING передает от хоста в МК dwDTERate, bCharFormat, bParityType, bDataBits; т.е. скорость в бодах, формат, четность и число стоп-бит. Все это передается затем, чтобы МК повторил эти установки на своем RS-232-порту, т.к. для обмена по USB эти данные не нужны.

GET_LINE_CODING запрашивает эти же данные (обычно те же самые, что были раньше пререданы хостом командой SET_LINE_CODING).

Есть еще SET_CONTROL_LINE_STATE, посредством которого хост может выразить желание изменить уровни DSR и RTS. И это всё!

Никакого аппаратного хендшейкинга здесь нет!

 

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

 

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

 

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

 

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

А в процессе передачи данных никаких запросов по нулевому эндпоинту нет вообще, а потому и отвечать не на что.

Изменено 20 января, 2009 пользователем Xenia

[Rst7 5]

Никаких посылок оттуда я посылать не могу, т.к. они не предусмотрены протоколом.

 

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

[aaarrr 69]

Там только бит FIFOCON устанавливают, чтобы показать, что буффер опустошен.

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

 

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

[Xenia 40]

И не надо. Просто не выгребаете данные из RX_EP и хост будет курить бамбук сколько надо.

 

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

 

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

[aesok 0]

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

А в процессе передачи данных никаких запросов по нулевому эндпоинту нет вообще, а потому и отвечать не на что.

 

Странно!!!!

 

На странице 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 все сделают сами.

 

 

Анатолий.

Изменено 20 января, 2009 пользователем aesok

[Dx! 0]

Народ! Кто-нибудь из вас пробовал писать прошивку для USB САМОСТОЯТЕЛЬНО? А то от демонстрационного проекта буквально уши вянут.

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

http://www.fourwalledcubicle.com/LUFA.php

Куда как болие прямой USB стек от фанатов. Под WinAVR. C кучей DEMO. Понравился.

[Visor 0]

На WinXP работает, а на Vista не загружается драйвер. Что делать?

Ну вот, новая "радость" на наши головы - Windows 7. :smile3046:

Не работает под ней.

[manul78 4]

Ну вот, новая "радость" на наши головы - Windows 7. :smile3046:

Не работает под ней.

 

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

 

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

предусмотрены настройки для эмуляции более ранних ОС...

 

Давайте пробовать вместе. Я использую AT90USB162 и основательно мной "раскуроченные" на кирпичики Атмеловские

демки... Использую в основном HID, думаю "семерка" должна поддерживать без проблем со стороны МК, а вот со стороны

PC возможно уже другие драйвера для HID... Не знаю... Надо пробовать. :)

[Visor 0]

Использую в основном HID ...

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

Речь конкретно о at90usbxxx_cdc.inf .