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

[harper]

На мой взгляд бесполезное занятие, разбирать код Атмеловских примеров с точки зрения железа. ......... А вот где нужно рыть это на уровне дескрипторов и обработки запросов хоста для устройств разных классов. .....

Уважаемый lepert! Наверное, Вы правы. Просто я дотошный и хочу это знать. И так как разработка ПО не моя профессия, а хобби, я не теряю на этом время, а развиваю мозги. Думаю, скоро дойду и до "обработки запросов хоста для устройств разных классов".
Код исследую в Proteus, в котором, вроде, очень неплохо работают примеры с USB. Хочу, для тех кому интересно, поправить мои предыдущие утверждения.
Я писал: " Так вот, в случае RXSTPI и RXOUTI сброс бита сразу отсылает ACK...". Получается, что это не так. SETUP request is always ACK’ed, как написано в Datasheet и это происходит без нашего участия, несмотря на сбивающую с толку фразу 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. Что здесь подразумевается под to acknowledge the packet не понятно.
То же самое происходит с ответом на OUT. Обнуление нами RXOUTI не приводит к мгновенной посылке ACK. Посылка ACK, по аналогии с TXINI для In Tocken, происходит только по приходу OUT Tocken от хоста.