Делаем AVR USB (software) правильно, уровень схемы Опции

[MAXvaLL]

При реализации софтварного USB на AVR возникают вопросы. Как сделать правильно?

Видел варианты:

1. МК питается 5В от шины. D+ и D- напрямую к МК через резисторы ~ 200 Ом. D- подтянута на +5В через резистор ~10кОм.
Проблемы: по спецификации USB макс. допустимый уровень сигнала относительно земли 4.6В (или даже меньше) Смотрим USB2.0 Spec. Figure 7-2. Maximum Input Waveforms for USB Signaling
Можно спалить порт.

2. То же что и 1. , но дополнительно на D+ и D- поставлены стабилитроны на 3.6В (на землю), а вместо резисторов на 200 Ом стоят по 68 Ом.
Проблема: емкость стабилитронов - искажение формы сигнала. И всеравно будут выбросы.

3. МК питается от 3.3-3.6В от шины через стабилизатор или 2 диода. Подтяжка D- 1.5 кОм. На D+ и D- стоят резисторы по 68 Ом или вообще без резисторов.
Проблема: Минимальная необходимая частота 12 Мгц, а при использовании внутреннего генератора 16.5 Мгц. Насколько корректно гонять МК на такихз частотах при таком питании? В даташите как-то туманно про это написано: на титульной странице одно, на графиках другое, и ничего конкретного я так и не нашел.


Лично я использовал вариант 3. МК ATmega8 при кварце 12МГц. Работает.
Интересует заведется ли Tiny25 на 16.5 Мгц при питании 3.5-3.6В ?

Еще: атмел советует не гонять встроенный ацп быстрее 1 МГц (тактирование)
Я запустил при 3х Мгц. Работает. Насколько это корректно? (Полученная точность устраивает)

[Xenia]

Кто знает, отчего берутся USB-запросы (CDC Class Requests):
SEND_ENCAPSULATED_COMMAND
GET_ENCAPSULATED_RESPONSE
?
Обычно их не обрабатывают, но любопытно, для чего они нужны. Короче говоря, мой вопрос формулируется так: "Какую команду из Windows-API должно подать приложение, чтобы моя AVRка получила один из этих реквайстов?" И в частности, если у меня на USB организован виртуальный COM-порт. Как вызвать все остальные реквайсты я знаю, остались непонятными только эти. В книгах и исходниках эти два реквайста всегда упоминаются, однако ни слова не нашла про то, в связи с каким событием такие запросы посылаются. Драйвер, конечно, может послать любой реквайст, но остается неясным, как побудить драйвер к этому (я использую стандартный драйвер виртуального порта usbser.sys, встроенный в Windows).

Сообщение отредактировал Xenia - Jun 21 2009, 00:45

[Genadi Zawidowsk...]

Кто знает, отчего берутся USB-запросы (CDC Class Requests):
SEND_ENCAPSULATED_COMMAND
GET_ENCAPSULATED_RESPONSE
?
Обычно их не обрабатывают, но любопытно, для чего они нужны. Короче говоря, мой вопрос формулируется так: "Какую команду из Windows-API должно подать приложение, чтобы моя AVRка получила один из этих реквайстов?" И в частности, если у меня на USB организован виртуальный COM-порт. Как вызвать все остальные реквайсты я знаю, остались непонятными только эти. В книгах и исходниках эти два реквайста всегда упоминаются, однако ни слова не нашла про то, в связи с каким событием такие запросы посылаются. Драйвер, конечно, может послать любой реквайст, но остается неясным, как побудить драйвер к этому (я использую стандартный драйвер виртуального порта usbser.sys, встроенный в Windows).

Попробуйте применить TransmitCommChar - может, оно вызовет SEND_ENCAPSULATED_COMMAND ?

хотя, почитал первый попавшийся даташит - и показалось, что это - рлддержка для DeviceIoControl

Сообщение отредактировал Genadi Zawidowski - Jun 21 2009, 07:47

[Xenia]

Попробуйте применить TransmitCommChar - может, оно вызовет SEND_ENCAPSULATED_COMMAND ?

Уже думала про это, но лениво было проверять .

хотя, почитал первый попавшийся даташит - и показалось, что это - поддержка для DeviceIoControl

А вот это как раз меня больше всего интересует! К сожалению, константы DeviceIoControl для СОМ-порта не описаны.
Любопытно, что функция

BOOL EscapeCommFunction(
HANDLE hFile, // handle to communications device
DWORD dwFunc // extended function to perform
);

очень похожа на DeviceIoControl, поскольку значение dwFunc очень похожа по смыслу на констанды DeviceIoControl:
dwFunc value:
CLRDTR Clears the DTR (data-terminal-ready) signal.
CLRRTS Clears the RTS (request-to-send) signal.
SETDTR Sends the DTR (data-terminal-ready) signal.
SETRTS Sends the RTS (request-to-send) signal.
SETXOFF Causes transmission to act as if an XOFF character has been received.
SETXON Causes transmission to act as if an XON character has been received.
SETBREAK Suspends character transmission and places the transmission line in a break state until the ClearCommBreak function is called.
CLRBREAK Restores character transmission and places the transmission line in a nonbreak state.

К сожалению, нмчего похожего на SEND_ENCAPSULATED_COMMAND и GET_ENCAPSULATED_RESPONSE тут нет.