AT90USB128* enumeration, Знатоки, помогите, пожалуйста разобраться Опции

[harper]

Изучаю AT90USB1286, застрял на enumeration. Примеры от Atmel работают, но хотелось бы разобраться, как?

Datasheet на ATmega32U6/AT90USB64/128, 22.12.2 Control Read: на рисунке TXINI обнуляют в фазе Setup. Firmware от Atmel тоже не проверяет наличие IN Tocken от хоста. Набрало в буфер байтов и сразу обнуляет TXINI. Обнуление TXINI - есть посылка пакета. А вдруг IN Tocken от хоста еще не пришел (а по вышеупомянутому рисунку в Datasheet он точно не пришел).
Или обнуление TXINI - это не посылка пакета, как написано в Datasheet, а складывание его в какой-нибудь буфер передатчика и контроллер хардварно определяет приход IN Tocken и после этого посылает пакет из буфера?
То же самое для Control Write в примере Atmel, например, для Set Address. Контроллер считал адрес, ответил на Setup отсылкой ACK и сразу следующей строчкой кода посылает Zero Length Packet. А где запрос от хоста?

Спасибо.

[harper]

Или обнуление TXINI - это не посылка пакета, как написано в Datasheet, а складывание его в какой-нибудь буфер передатчика и контроллер хардварно определяет приход IN Tocken и после этого посылает пакет из буфера?

Извините, что сам с собой, но раз пока никого нет.
Еще рассматривал картинки для Control Write и Control Read в Datasheet. По ним получается, что я прав
в своем утверждении. Аппаратное обеспечение устанавливает TXINI сразу после приема In Tocken от хоста, значит именно в этот момент EP0 посылает пакет и освобождается.
А мы, сбрасывая TXINI, не отправляем пакет, а показываем аппаратному обеспечению, что пакет готов и может быть отправлен.
Я прав или я прав?

[galjoen]

Тоже собираюсь занятся AT90USB...

Извините, что сам с собой, но раз пока никого нет.
Еще рассматривал картинки для Control Write и Control Read в Datasheet. По ним получается, что я прав
в своем утверждении. Аппаратное обеспечение устанавливает TXINI сразу после приема In Tocken от хоста, значит именно в этот момент EP0 посылает пакет и освобождается.

Я понял так, что TXINI устанавливается после ПЕРЕДАЧИ ПАКЕТА ДАННЫХ ХОСТУ в ответ на его маркер IN. Т.е. показывает, что буфер передачи свободен.

А мы, сбрасывая TXINI, не отправляем пакет, а показываем аппаратному обеспечению, что пакет готов и может быть отправлен.
Я прав или я прав?

Пока TXINI установлен - в ответ на маркер IN от хоста будет слаться NAK. Перед сбросом TXINI нужно записать в буфер передачи данные (если не планируется передача пакета данных 0й длины - контрольное чтение). После сброса TXINI в ответ на IN от хоста ему будет послан пакет данных и установлен TXINI.

А причём здесь енумерация?

[harper]

Спасибо, Вы написали то же самое, что и я, укрепив мою уверенность, что я все правильно понял.
А сбивает с толку Atmel в пункте22.12 CONTROL endpoint management, описывая биты RXSTPI, RXOUTI и TXINI одинаковой фразой "It shall be cleared by firmware to acknowledge the packet (to send the packet )...." Так вот, в случае RXSTPI и RXOUTI сброс бита сразу отсылает ACK, а в случае с TXINI вот так все немного сложнее оказывается.

А причём здесь енумерация?

Потому что я пытаюсь досконально разобрать код атмеловских примеров и пока сижу в энумерации. Не знаю, может быть у TXINI для In и Out точек появятся какие -то ньюансы. Поэтому, пишу о том, что успел рассмотреть.

[lepert]

Спасибо, Вы написали то же самое, что и я, укрепив мою уверенность, что я все правильно понял.
А сбивает с толку Atmel в пункте22.12 CONTROL endpoint management, описывая биты RXSTPI, RXOUTI и TXINI одинаковой фразой "It shall be cleared by firmware to acknowledge the packet (to send the packet )...." Так вот, в случае RXSTPI и RXOUTI сброс бита сразу отсылает ACK, а в случае с TXINI вот так все немного сложнее оказывается.
Потому что я пытаюсь досконально разобрать код атмеловских примеров и пока сижу в энумерации. Не знаю, может быть у TXINI для In и Out точек появятся какие -то ньюансы. Поэтому, пишу о том, что успел рассмотреть.

На мой взгляд бесполезное занятие, разбирать код Атмеловских примеров с точки зрения железа. Потому что они железо и софт для него в любом случае привязаны к USB спецификации. Т.е. USB спецификация первична, а Атмел вторична. И разбор железа практически ничего не даст, потому что основные затыки как раз не на уровне железа, тут они все вылизали, и код для железа создали в примерах именно такой, который работает с любым USB оборудованием. И он будет неизменен для любого Вашего приложения. Вы просто не сможете что либо изменить, если
собираетесь сделать совместимое с остальным миром устройство. А вот где нужно рыть это на уровне дескрипторов и обработки запросов хоста для устройств разных классов. Здесь как раз просто немеряно неисследованных даже Атмелом вопросов, и именно здесь будут основные затыки у Вас.

Сообщение отредактировал lepert - Jan 25 2009, 17:33