[SKov 0]

Хорошая ссылка.

http://pdfserv.maxim-ic.com/en/an/AN3241.pdf

Особенно интересна последняя главка.

Здесь тоже кое-что есть по вашей теме.

http://www.usb.org/developers/whitepapers/...otherboards.pdf

[Xenia 38]

Хорошая ссылка.

http://pdfserv.maxim-ic.com/en/an/AN3241.pdf

Особенно интересна последняя главка.

Здесь тоже кое-что есть по вашей теме.

http://www.usb.org/developers/whitepapers/...otherboards.pdf

 

Так вы на меня больше не сердитесь? :)

[Xenia 38]

Народ! Кто-нибудь из вас пробовал писать прошивку для 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.

Изменено 21 ноября, 2008 пользователем Xenia

[aesok 0]

А то есть у меня вопрос про отсылку пакетов - никак не пойму из описания, как положено 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 38]

Если Вы спрашиваете про дескрипторы, то они отправляються по 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 до заполнения буфера данными или можно после?

Изменено 21 ноября, 2008 пользователем Xenia

[Visor 0]

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

Я на базе этого проекта написал свой, функции конечно подправил, но идеология осталась. Проблем не встретил.

Вот посылка:

do
  {
    if (!Is_usb_write_enabled()) { Usb_send_in(); } // If Endpoint full -> flush
    while (!Is_usb_write_enabled());                // Wait Endpoint ready
    Usb_write_byte(usb_data[buff_pointer++]);
  } while (--tx_counter);

[Xenia 38]

Я на базе этого проекта написал свой, функции конечно подправил, но идеология осталась. Проблем не встретил.

 

А может быть вы в нем сильно не разбирались - работает и ладно, а на TXINI и FIFOCON начхать? :)

Вы на меня, пожалуйста, не обижайтесь, но меня совершенно не устраивает фукция передачи, которая заставляет меня ждать в цикле while, пока не закончится передача. Мне нужно, как и в случае USART - отсылка по прерыванию опустошения передатчика. Т.е. здесь - по прерыванию освободившегося FIFO-буфера. У меня АЦПы очень быстро передают, и если я стану отправки ждать, то не смогу их вовремя обслуживать. Потому меня и волнует вопрос отправки буфера.

[aesok 0]

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

 

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

 

Анатолий.

[Xenia 38]

do
  {
    if (!Is_usb_write_enabled()) { Usb_send_in(); } // If Endpoint full -> flush
    while (!Is_usb_write_enabled());                // Wait Endpoint ready
    Usb_write_byte(usb_data[buff_pointer++]);
  } while (--tx_counter);

 

Ваш Usb_send_in() - это и есть мой FIFOCON:

#define Usb_send_in() (UEINTX &= ~(1<<FIFOCON))

 

То, что вы делаете - ужасно! Каждый байт оправляете отдельным пакетом.

Изменено 21 ноября, 2008 пользователем Xenia

[Visor 0]

То, что вы делаете - ужасно! Каждый байт оправляете отдельным пакетом.

Ошибаетесь, отсылка идёт при заполнении ендпоинта.

[Xenia 38]

Ошибаетесь, отсылка идёт при заполнении ендпоинта.

 

Мда... Тут не мудрено и запутаться.

 

А TXINI вы где сбрасываете? По-вашему это будет Usb_send_control_in().

Изменено 21 ноября, 2008 пользователем Xenia

[Visor 0]

Мда... Тут не мудрено и запутаться.

 

А TXINI вы где сбрасываете? По-вашему это будет Usb_send_control_in().

Отсылка происходит по Usb_send_in(), т.е. сбросом FIFOCON.

[aesok 0]

В даташите же ясно написанно и нарисованно, для IN-endpoint вначале надо сбросить TXINI и только после того как в буфер помещенны все необходимые данные сбросить FIFOCON.

TXINI можно сбросить до, во время или после записи данных, но обязательно до сброса FIFOCON.

 

 

CONTROL-endpoint работают по другому. Вы про какой endpoint спрашиваете?

 

Анатолий.

Изменено 21 ноября, 2008 пользователем aesok

[Xenia 38]

TXINI можно сбросить до, во время или после записи данных, но обязательно до сброса FIFOCON.

CONTROL-endpoint работают по другому. Вы про какой endpoint спрашиваете?

 

Да-да, именно про это я и спрашивала. Только диаграммы в этом смысле бывают не совсем понятны, т.к. из них не всегда ясна причина, отчего тот или иной сигнал изменил уровень. Например, до того, как вы объяснили, мне было неясно: падает ли TXINI на диаграмме сам (аппаратно) из-за того, что в буфер стали пихать байты, или же его сбросили программно перед запихиванием первого байта. Теперь ситуация проснилась, за что вам от меня большое спасибо :).

 

 

Visor

 

Вообще-то сочиненный мною код подобен вашему, только я писала в буфер не по признаку Is_usb_write_enabled(), а просто заталкивала туда столько, каков был его размер, т.е. чисто по штукам. Из-за того, что это было в прерывании из-за пустоты буфера, то я могла быть уверенной, что он пуст и, стало быть, в него можно записать на полную катушку.

Однако я, хотя и пишу на Си, однако прямо на регистрах, а не этими мнемоническими функциями, которые никак не могу запомнить.

[Xenia 38]

У меня появился новый животрепещущий вопрос по теме: как можно со стороны МК попросить хост сделать паузу в посылке данных? Те данные, которые уже пришли, МК готов безоговорочно принять, но хочет попросить хост, чтобы оставшиеся данные он пока не присылал, попридержав их у себя до тех пор, пока МК не будет к этому готов.

 

Рассмотрим конкретный пример, чтобы моя задача не казалась слишком абстрактной. Положим у нас имеется устройство не с USB-портом, а с обычным COM-портом (RS-232), которое работает "периодически": сначала набирает к себе в буфер данные, а затем что-то со всеми этими принятыми данными начинает делать, из-за чего нуждается в паузе, пока это дело не будет сделано. Сейчас не суть важно, что это за дело - может быть отправляет эти данные пакетом куда-то дальше, или записывет на диск, или отправляет по e-mail, - только приходится ждать, пока принятые данные не будут утилизированы, и лишь после этого устройство снова будет готово к приему новой порции данных. Причем подразумевается, что устройство не имеет в своем распоряжении столько памяти, чтобы сохранить весь поток данных, пришедшых во время исполнения дела.

 

Если это RS-232, то такая задача решается исключительно просто - данные передают с хэндшейкингом, используя линию DSR, как признак готовности к приёму данных. Тут устройство попросту устанавливает отрицательный уровень DSR, что является сигналом для хоста преостановить передачу данных. Когда устройство закончит "переваривать" принятые данные, оно снова установит на линии DSR положительную полярность, что побудит хост продолжать передачу с момента вынужденной остановки.

 

Но вот мы присоединили это устройство не к родному COM-порту компьютера, а через USB/COM-конвертор, выполненный на нашем МК. И вот видит наш МК, что устройство запросило паузу линией DSR, - что тогда ему делать? Собственная память у него есть, но ее не так много, чтобы сохранить все то, что отсылать устройству ему запрещено. Кроме того, он не знает точно, как долго продлится эта пауза. Единственным разумным выходом из этой ситуации было бы, в свою очередь, поступить аналогичным образом - тоже попросить USB-хост об отсрочке передачи.

 

Возможно ли такое в принципе, а если да, то каким образом делается? Ведь наш МК является ведомым, зависящим от посылок со стороны хоста. Как ему сигнализировать о том, что у него будет временный напряг с приемом?

 

DETACH снять я не могу - тогда USB-хост его попросту потеряет. FREEZE сделать? Но поймет ли хост? Что положено в этом случае делать?

Изменено 20 января, 2009 пользователем Xenia