Изучаю 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. А где запрос от хоста?

Спасибо.

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

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

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

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

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

Спасибо, Вы написали то же самое, что и я, укрепив мою уверенность, что я все правильно понял.
А сбивает с толку 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! Наверное, Вы правы. Просто я дотошный и хочу это знать. И так как разработка ПО не моя профессия, а хобби, я не теряю на этом время, а развиваю мозги. Думаю, скоро дойду и до "обработки запросов хоста для устройств разных классов".
Код исследую в 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 от хоста.

Уважаемый harper, я написал не к тому, чтобы Вас отлучить от любимых примеров, поверьте. Если Вы хотите досконально изучить USB на аппаратном уровне, то по хорошему нужно взять просто микроконтроллер, без встроенного USB, и написать свою программу, которая
сама дергает ноги процессора, заведенные на DP и DM. И спаять плату, реальную, а не в Proteus, подключить ее к компьютеру,
и заставить общаться с компом по USB. Есть полно примеров в интернете и здесь на форуме где контроллер работает с USB непосредственно, например программатор от Protoss. Он там работает с USB непосредственно, без всякого аппаратного уровня, как это сделано на AT1286. И поскольку Вы работаете не с железом, а с Proteus, у Вас получается моделирование второго уровня Т.е. AT1286 работает с USB так, как это придумала Atmel. А Вы моделируя ее через Proteus, работаете с USB так как моделирует Proteus то, как придумала Атмел, как работает At1286 с USB. Короче дом который построил Джек. И таким образом Ваши знания на самом деле ни на грамм не приблизятся к пониманию что же на самом деле происходит на аппаратном уровне USB.
Но это только как совет. Не хотите, дело такое. Каждый имеет право заморачиваться на своих хомячках©

Нет. Самое важное - именно изучение железа. Примеры от атмеля я лично даже и смотреть не собираюсь...
Меня у AT90USB напрягает как-раз слишком жёсткая привязка железа к спецификации USB (см. далее). Хотя, конечно, только вчера изучать начал.
А код, совместимый с остальным миром, я собираюсь как-нибудь сам написать... И опыт показывает, что самописный код получше будет. Если с железом и протоколами хорошо разобраться конечно.
Пример: Если компьютер по кнопке усыпить и снова разбудить, то все фирменные USB устройства принтеры, сканеры и т.д (кроме мыши и клавы) пропадут. Для того, чтобы ими пользоваться начать - придётся их переткнуть. А вот мои самописные USB девайсы в таких условиях не теряются.

Теперь касательно TXINI. Судя по описанию данный бит нардварно установится после получения ACK от хоста в ответ на посланный ему (хосту) пакет данных. Если пакет данных был хосту отправлен, а ответ от него ACK от хоста не получен (то-ли пакет по пути к хосту разрушен, то-ли ACK от хоста к нам не дошёл), то эта ситуация никакими битами не отражается (так мне кажется), а хотелось бы. Или я не прав? И как-то это узнать можно?

А насчёт посылки дескрипторов хосту и обработки запросов от него - я пока только 2 варианта знаю:
1. По контрольному каналу. Там всегда один механизм. Его в любом случае реализовывать нужно.
2. Через бульки (устройства типа MassStorage). Там подругому. Но один раз реализовав этот механизм дальше просто пользуешься.
А м.б. вы к.л. запросы ещё знаете? Откуда возьмётся немерянное кол-во неисследованных вопросов?

ЗЫ
У меня тут интернет не работал - поэтому м.б. несинхронно ответил.




+1 Я тоже дотошный.
И AT90USBxx мне интересен. У него в отличие от многих других EP 0 буфер на 64 байта имеет. Это решающее преимущество (особенно в случае HID через контрольный канал). Хотя и недостатки имеются. Например, нельзя номер EP изменять. Но так у всех современных девайсов... И вообще, чем устройство новее, тем меньше простора для фирмваря, всё аппаратно в нём делается и изменить ничего не можешь.

Тут видимо подразумевается, что от хоста 2 (или больше) SETUP-а подряд прийти может (это нормально, так бывает если SETUP-ы без фазы данных). Т.к. NAK-овать на SETUP нельзя, то обычно аппаратное FIFO SETUP-ов организуется (хотя-бы 2 уровня). Прочли вы первый SETUP (8 байт данных), бит сбросили, и у вас уже следующий SETUP в буфере. Хотя физически он уже давно принят был (и ACK в ответ на него хосту послан). Без этого SETUP-ы терятся будут (если их своевременно прочесть не получилось - процессор другим занят был).

Совершенно верно. ACK шлётся только В ОТВЕТ на OUT1/0 с данными (м.б. и 0 байт) от хоста. Ведущий всегда хост.

Я пока, к сожалению, другими делами на работе занят и много времени посвятить AT90USB не могу. Но вот освобожусь и активно к вам присоединюсь. Но вопросы возникают уже. Вот кстати - не могли-бы вы проверить на протеусе как поведёт себя девайс при приёме 2-х SETUP-ов подряд (см. выше).

Я так понимаю, что TXINI дословно по datasheet устанавливается после опустошения банка, , а не "после получения ACK от хоста". В противном случае в ситуации с Вашим вопросом бит TXINI не устанавливался бы (т.е. ситуация отражалась бы битом TXINI). Косвенно это подтверждает код Atmel, который ждет установки TXINI в цикле while, и завис бы навсегда в случае неустановки TXINI из-за неприхода ACK от хоста.
Я так понимаю, что если мы не получили ACK от хоста, это ничего не меняет. Каждый (девайс и хост) продолжает заниматься своим делом. На самом деле, вообще не совсем понятно, зачем придуман ACK от хоста. Если же к хосту не дошел наш пакет, то это будет ошибкой и, наверное, хост начнет транзакцию заново с самого начала.

Не совсем понимаю про два и более Setup-a. После каждого Setup-a без данных все равно есть Status stage, в котором хост будет ждать подтверждения от девайса и не завалит его новыми запросами, пока не дождется.

Транзакция считается завершённой (и банк пустым) после получения ACK от хоста. А зависание в цикле на совести атмела. Этим и плохи примеры...

Прежде чем разбираться, рекомендую прочитать описание (с usb.org). Могу дать перевод. Только он не очень... Кстати я его уже неоднократно выкладывал.

Нет. Хост просто перепошлёт маркер IN. И на него нужно перепослать ТОТ-ЖЕ пакет данных, с ТЕМ-ЖЕ маркером пакета (DATA1 или DATA0). DATA2 это high speed.

Если ACK, посланный устройством, будет повреждён, то хост сразу-же пошлёт новый пакет SETUP.
Так-же это может получится при рассинхронизации, когда ACK от хоста (завершающий предыдущую транзакцию) разрушен по пути к девайсу. И хост с девайсом расходятся в вопросе о том, завершена транзакция или нет. Вобщем-то вопрос и был в том, нужно-ли делать програмную защиту от такого случая. Или всё сделано аппаратно?


Вобщем настоятельно рекомендую прочитать 8-ю главу описания. Ещё понадобится 9-я. Но уже после 8й. Остальные главы читать необязательно. И не читайте то, что относится к high speed, это в случае AT90USB не имеет значения. А вообще многое в вашем непонимании работы AT90USB от незнания собственно протокола USB.

Не ради спора, а, может быть, действительно из-за моего незнания, но:

Цитата из Datasheet:
• 0 - TXINI - Transmitter Ready Interrupt Flag
Set by hardware to signal that the current bank is free and can be filled.
Про ACK от хоста ничего не говорится. Может быть у Atmel своя аппаратная реализация, ведь главное с хостом общаться правильно, а как сделано со стороны девайса, это же личное дело девайса? Насчет примеров Atmel: сомнительно, чтобы там работали такие простые ребята с легко зависающими примерами.

Спасибо, прочитал. Узнал, что, хост делает еще две попытки при неудачном приеме данных, а девайс при неполучении ACK от хоста на следующий IN пошлет ему тот же пакет. В итоге, если и эти две попытки хоста закончатся неудачей, он остановит конечную точку. А вот когда и из каких соображений он ее запустит вновь, все облазил - не нашел.

В Datasheet об этом нет ни слова. В программе тоже ничего не происходит. Я так понял по USB спецификации, что если мы потеряем Setup, это в конечном счете может привести к RESET и все заново? Нехорошо.
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.
Т.е. по аналогии с RXOUTI и TXINI мы должны его сбрасывать (RXSTPI), чтобы был ACK на следующий Setup. А я раньше писал, что ACK на Setup происходит без нашего участия. Получается, мы разрешение дать должны. Я в программе для эксперимента оставил его установленным, так у меня даже TXINI перестал сбрасываться программно (надеюсь, не глюк Proteus).
Так вот Atmel в программе (Вы бы уже ознакомились что-ли, мне кажется с нуля на основе Datasheeta трудновато самому написать будет) пока считывает Setup Date держит RXSTPI установленным (иначе считать не сможет) и в это время на новый Setup ответить не может.

Хотя по диаграмме для In endpoint -a после ACK. Atmel путает постоянно.

Всётаки TXINI устанавливается после приёма ACK от хоста. Иначе никакая аппаратная реализация не поможет. Не будет девайс с хостом правильно общаться. По протоколу хост у девайса ТЕ-ЖЕ данные в случае ошибки запрашивает (это же не изохронная передач). А откуда девайс их возьмёт если он current bank is free сделает. Да ещё мы ему туда новых данных напихаем. И ведь нет у нас в распоряжении никаких других битов чтобы такой случай проверить (у некоторых USB девайсов такие флаги имеются, в смысле и такие и такие).
А насчёт примеров, так они примеры и есть. Для ознакомления только подходят. Делать так как в примерах нельзя ни в коем случае.

Ну в винде хост вновь запускает после общего сброса с новой энумерацией.

Самый неприятный случай, это когда теряется ACK девайса, подтверждающий получение SETUP с установкой адреса (энумерацией). Девайс считает, что успешно SETUP принял и переходит в status stage (да ещё изменение адреса заряжает), а хост считает, что девайс SETUP не принял и этот SETUP перепосылает. И там программу вылизывать приходится т.к. установка адреса должна происходить без ошибок. Некоторые биосы так написаны (не соответствуют описанию USB), что в результате ошибки (одиночной) при установке адреса (при работе под биосом - загрузке) компьютер вообще зависает (не загружается). Т.е. если в комп воткнут USB девайс - он не загружается. Никогда такого не встречали? Я встречал.

Ознакомлюсь. Но к.л. выводы на основании того, как работает эта программа, делать нельзя (см. выше). А начинающих эти примеры только с толку сбивают. По себе сужу.