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

[Visor]

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

[Xenia]

Народ! Кто-нибудь из вас пробовал писать прошивку для USB САМОСТОЯТЕЛЬНО? А то от демонстрационного проекта буквально уши вянут. Или на крайний случай, хотя бы пытался разобраться что там к чему?
А то есть у меня вопрос про отсылку пакетов - никак не пойму из описания, как положено FIFO-буфер отсылать - стиранием флага TXINI или FIFOCON? Из описания вроде бы надо через FIFOCON, но в демо-проекте все дескрипторы отсылаются без использования FIFOCON.
Вот что писано по этому поводу в даташите:

1) TXINI is set when the bank is ready to accept a new IN packet. It shall be cleared by firmware to send the packet and to clear the endpoint bank.

2) The data are written by the CPU, following the next flow:
• When the bank is empty, an endpoint interrupt (EPINTx) is triggered, if enabled (TXINE set) and TXINI is set. The CPU can also poll TXINI or FIFOCON, depending the software
architecture choice,
• The CPU acknowledges the interrupt by clearing TXINI,
• The CPU can write the data into the current bank (write in UEDATX),
• The CPU can free the bank by clearing FIFOCON when all the data are written, that is:
• after ”N” write into UEDATX
• as soon as RWAL is cleared by hardware.

3) • 0 - TXINI - Transmitter Ready Interrupt Flag
Set by hardware to signal that the current bank is free and can be filled. An interrupt (EPINTx) is triggered (if enabled).
Shall be cleared by software to handshake the interrupt. Setting by software has no effect.

Сообщение отредактировал Xenia - Nov 21 2008, 11:26

[aesok]

А то есть у меня вопрос про отсылку пакетов - никак не пойму из описания, как положено FIFO-буфер отсылать - стиранием флага TXINI или FIFOCON? Из описания вроде бы надо через FIFOCON, но в демо-проекте все дескрипторы отсылаются без использования FIFOCON.

Если Вы спрашиваете про дескрипторы, то они отправляються по CONTROL endpoint, как с ней работать нарисанно в параграфе 22.12 CONTROL endpoint management:

A SETUP request is always ACK’ed. When a new setup packet is received, the RXSTPI interrupt
is triggered (if enabled). The RXOUTI interrupt is not triggered.
The FIFOCON and RWAL fields are irrelevant with CONTROL endpoints. The firmware shall
thus never use them on that endpoints. When read, their value is always 0.
CONTROL endpoints are managed by the following bits:
• RXSTPI is set when a new SETUP is received. It shall be cleared by firmware to
acknowledge the packet and to clear the endpoint bank.
• RXOUTI is set when a new OUT data is received. It shall be cleared by firmware to
acknowledge the packet and to clear the endpoint bank.
• TXINI is set when the bank is ready to accept a new IN packet. It shall be cleared by firmware
to send the packet and to clear the endpoint bank.

Та цитата что привели Вы относиться к IN endpoint.

Анатллий.

[Xenia]

Если Вы спрашиваете про дескрипторы, то они отправляються по CONTROL endpoint, как с ней работать нарисанно в параграфе 22.12 CONTROL endpoint management: ...
Та цитата что привели Вы относиться к IN endpoint.

Здесь разница только в номере конечной точки: запрос дескрипторов идет по нулевой, а передача и прием данных - по 1-ой и 2-ой. Неужели эти два случая разняться настолько, что в первом случае FIFOCON не нужен, а в двух других он необходим?
Или вот пустой пакет (ZLP) когда отправляют, то FIFOCON'ом не пользуются. Вроде как только дрыгнут TXINI и пакет отправился. Почему же тогда при отправлении блока данных я должна использовать помимо TXINI еще и FIFOCON? Ведь TXINI формально относится к передаче данных, хотя CONTROL отправляет с его помощью дескрипторы. А FIFOCON тот и вовсе ничейный.

Почему же, когда в даташите демонстрируют примитивное отправление байта по USART, которое и так каждому понятно, то приводят пример кода, который это делает. А USB во сто крат сложнее, а примерчика нету. Или может бы знаете где найти такой примерчик? Только не отсылайте меня к тому дурацкому проекту, в котором разобраться невозможно. И книжка Агурова не в помощь, т.к. на его процессоре FIFOCON'а нет, а все флаги в регистрах вывернуты наоборот. Хотелось бы все-таки из первых рук получить инфу, а не от индийских программистов , которые тот проект написали.

P.S. Тот параграф, что вы указали, я посмотрела, но из той диаграммы не поняла, который из сигналов все-таки отправляет FIFO-буфер на линию. Мне бы чего по-проще - последовательность ШАГОВ, как отправить FIFO-буфер с данными наружу. Натолкала я в него байтов, а потом чего? Обязательно ли TXINI и FIFOCON друг за дружкой, или достаточно одного? Опять же скидывать TXINI до заполнения буфера данными или можно после?

Сообщение отредактировал Xenia - Nov 21 2008, 13:46

[aesok]

Здесь разница только в номере конечной точки: запрос дескрипторов идет по нулевой, а передача и прием данных - по 1-ой и 2-ой. Неужели эти два случая разняться настолько, что в первом случае FIFOCON не нужен, а в двух других он необходим?

Нет! Hулевой (control) endpoin двухнаправленный, по нему передаются пакеты и от хоста к устройства и от устройства к хосту, все же остальные endpoin-ты одноноправленные (IN или OUT), так что ничего удивительного в том что они управляються по разному нет.

Анатолий.