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

[Visor]

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

[GDI]

Вы бы сам файл прикрепили, а то тут частенько просят эти примеры, а они, я так понял, даются только после регистрации на сайте атмела, что опять же будет неудобно желающим вам помочь...

[prottoss]

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

Обычно частоту камня делают кратной тактовой частоте USB, если ее можно назвать тактовой. Для LowSpeed это 1,5 МГц, для Full - 12 МГц. У ВАс не бъет ни для первой ни для второй - курите даташит.

[Visor]

Обычно частоту камня делают кратной тактовой частоте USB, если ее можно назвать тактовой. Для LowSpeed это 1,5 МГц, для Full - 12 МГц. У ВАс не бъет ни для первой ни для второй - курите даташит.

Спасибо, не курю, тем более даташиты.
А в нём как раз и сказано чистым англицким языком, что USB PLL умножитель имеет кратность х24 и предварительный делитель частоты XTAL до 2МГц с помощью PLL clock Prescaler, дабы получить необходимые 48МГц для тактирования USB интерфейса. И этот PLL clock Prescaler может быть только 4 или 8, т.е. для 8МГц и 16МГц клока соответственно.

[prottoss]

Спасибо, не курю, тем более даташиты.
А в нём как раз и сказано чистым англицким языком, что USB PLL умножитель имеет кратность х24 и предварительный делитель частоты XTAL до 2МГц с помощью PLL clock Prescaler, дабы получить необходимые 48МГц для тактирования USB интерфейса. И этот PLL clock Prescaler может быть только 4 или 8, т.е. для 8МГц и 16МГц клока соответственно.

Понятно. Я высказал лишь предположение, потому как с этим камнем не работал, но работал с USB. В таком случае отладчик Вам в помощь (или DBG_OUT :-))). Посмотрите в первую очередь, принимает ли чип пакеты - скорее всего в коде есть оброботчик прерывания для такого дела.

[Visor]

В таком случае отладчик Вам в помощь (или DBG_OUT :-))).

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

[prottoss]

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

Я же сказал - "... (или DBG_OUT :-)))." имея ввиду вывод в СОМ-порт. Если и СОМ-порта нет, то тогда есть еще одно хорошее средство - привинтить к свободной ноге(ногам) светодиод(ы), и , так скааать, визуально наблюдать скрытый процесс:-) У меня для AVR до сих пор тоже нет железного отладчика - пользуюсь именно выводом в USART или светодиодами.

[Visor]

Я же сказал - "... (или DBG_OUT :-)))." имея ввиду вывод в СОМ-порт. Если и СОМ-порта нет, то тогда есть еще одно хорошее средство - привинтить к свободной ноге(ногам) светодиод(ы), и , так скааать, визуально наблюдать скрытый процесс:-) У меня для AVR до сих пор тоже нет железного отладчика - пользуюсь именно выводом в USART или светодиодами.

Хех, идея хорошая, но плата уже готова, чип запаян, а навешивать "сопли" на чип в QFN64 дело неблагодарное.

[Visor]

Нашел ошибку в коде примера, неверный PLL clock Prescaler для частоты 16МГц, поправил.
Устройство стало определяться Виндовс, как "Контроллеры универсальной последовательной шины USB / Неизвестное устройство". Выходит, что устройство не возвращает сведений о себе.

[TinyQ]

а при установке драйвера at90usbxxx_cdc.inf указывали?

[Visor]

а при установке драйвера at90usbxxx_cdc.inf указывали?

Пробывал, но драйвера на "Неизвестное устройство" там не оказалось.

[TinyQ]

а VID_03EB&PID_2018 совпадают
у меня этот пример на at90usbkey работает

[Visor]

а VID_03EB&PID_2018 совпадают

Винда пишет Код экземпляра устройства: USB\VID_0000&PID_0000\5&13F82F15&0&2

[TinyQ]

Может проблема по плате?

[Visor]

Чип перестал работать, просто в один прекрасный день не завёлся и всё. Через ISP не отвечает. Проверил, на кварце нет генерации (16МГц). Заметил, что при отключении питания генерация на мгновение появляется при спаде питания ниже BOD. Что бы это значило?

[Xenia]

Нашел ошибку в коде примера, неверный PLL clock Prescaler для частоты 16МГц, поправил.
Устройство стало определяться Виндовс, как "Контроллеры универсальной последовательной шины USB / Неизвестное устройство".

Укажите, пожалуйста, где вы это исправили! У меня та же проблема, только я ошибки в упор не вижу.

В config.h переопределила на частоту 16 МГц:
#define FOSC 16000

В хидере pll_drv.h все написано совершено правильно:
#elif (FOSC==16000)
#define Pll_start_auto() Start_pll(PLLx03)
где PLLx03 определено выше как:
#define PLLx03 ( (1<<PLLP2) | (0<<PLLP1) | (1<<PLLP0) )

Так и быть должно согласно даташиту:
Табл. 6-13
XTAL=16 MHz
Clock Devision Factor=8
PLLP2=1
PLLP1=0
PLLP0=1

Где здесь ошибка?

Сообщение отредактировал Xenia - Apr 1 2008, 13:31

[Visor]

Укажите, пожалуйста, где вы это исправили! У меня та же проблема, только я ошибки в упор не вижу.

Ошибка оказалась в даташите, а не в софте.

Так и быть должно согласно даташиту:
Табл. 6-13
XTAL=16 MHz
Clock Devision Factor=8
PLLP2=1
PLLP1=0
PLLP0=1

Где здесь ошибка?

В даташите (в моём по крайней мере):
Table 6-13. PLL input prescaler configurations

Код

PLLP2 PLLP1 PLLP0     Clock Division Factor     External XTAL required for USB
                                                            operation (MHz)
  0     0      0            Reserved                            -
  0     0      1            Reserved                            -
  0     1      0            Reserved                            -
  0     1      1               4                                8
  1     0      0            Reserved                            -
  1     0      1            Reserved                            -
  1     1      0               8                               16
  1     1      1            Reserved                            -

[Xenia]

Ошибка оказалась в даташите, а не в софте.

А у вас какой МК?

Скачала последний даташит с сайта ATMEL:
[PDF] AT90USB1286, AT90USB1287, AT90USB646, AT90USB647 (455 pages, revision G, updated 03/08)

Действительно, в марте появились изменения. Однако вот что там сказано:

External XTAL required for USB operation (MHz) = 16
Clock Division Factor = 8

PLLP2=1, PLLP2=0, PLLP2=1 (1)
Note: 1. For AT90USB128x only. Do not use with AT90USB64x.

PLLP2=1, PLLP2=1, PLLP2=0 (2)
Note: 2. For AT90USB64x only. Do not use with AT90USB128x.

У меня AT90USB647, значит я и виновата, что использовала программу для AT90USB1287. Но ведь и в голову не могло придти, что в этом месте может быть расхождение!

Сообщение отредактировал Xenia - Apr 2 2008, 12:09

[Visor]

А у вас какой МК?

Скачала последний даташит с сайта ATMEL:
[PDF] AT90USB1286, AT90USB1287, AT90USB646, AT90USB647 (455 pages, revision G, updated 03/08)

Действительно, в марте появились изменения. Однако вот что там сказано:

External XTAL required for USB operation (MHz) = 16
Clock Division Factor = 8

PLLP2=1, PLLP2=0, PLLP2=1 (1)
Note: 1. For AT90USB128x only. Do not use with AT90USB64x.

PLLP2=1, PLLP2=1, PLLP2=0 (2)
Note: 2. For AT90USB64x only. Do not use with AT90USB128x.

У меня AT90USB647, значит я и виновата, что использовала программу для AT90USB1287. Но ведь и в голову не могло придти, что в этом месте может быть расхождение!

Я работаю с AT90USB1286 (в теме указан )
Использую даташит 7593D–AVR–07/06, т.е. ревизия D, когда я начинал была последняя.
Дак вы поправили, заработало?
У меня пример заработал, проблема была хардверная.

[Xenia]

Я работаю с AT90USB1286 (в теме указан )
Использую даташит 7593D–AVR–07/06, т.е. ревизия D, когда я начинал была последняя.

А я действовала по ревизии А (7593A-AVR-02/06) - там было 101. Вашу ревизию D я тоже нашла, и действительно в ней написаное иное - 110. Но ведь ревизия G (7593G-AVR-03/08) - последняя и только что вышла, и согласно ей для AT90USB128 права ревизия А, а для AT90USB64 права ревизия D.
Но ведь у вас AT90USB128 и по ревизии D у вас заработало. Выходит, что последнняя ревизия снова вернулась к первоначальному ошибочному утверждению относительно AT90USB128?

Дак вы поправили, заработало?

Да, заработало. Вам огромное спасибо!

Сообщение отредактировал Xenia - Apr 2 2008, 22:09

[Visor]

Но ведь у вас AT90USB128 и по ревизии D у вас заработало. Выходит, что последнняя ревизия снова вернулась к первоначальному ошибочному утверждению относительно AT90USB128?

Нет, у меня работает с 101.

Да, заработало. Вам огромное спасибо!

Я то причём.

[Xenia]

Нет, у меня работает с 101. Я то причём.

Если бы не ваш пост, я бы никогда не полезла искать последнюю ревизию даташита. А самой найти такую ошибку невозможно.

[Xenia]

На WinXP работает, а на Vista не загружается драйвер. Что делать?

В обеих случаях CDC использует фирменный драйвер от Microsoft под названием UsbSer.sys. При стандартной установке системы этот драйвер не ставится, но он имеется в базе driver.cab и оттуда при необходимости ставится в директорию System32\drivers\. Обычно этот драйвер используют многочисленные USB-модемы, для коих целей он и составлялся.
Проект at90usb128-demo-cdc-1_0_3.zip тоже базируется на этом драйвере, поэтому для его установки прилагается только inf-файл, который использует стандартный драйвер UsbSer.sys. Но вот беда - под Vista этот inf-файл не срабатывает.
Вот здесь - http://forums.microsoft.com/MSDN/showpost....51&siteid=1 - на микрософтовском форуме, народ ругается про то же самое. А кто-то составляет свои версии inf-файла - http://blog.bigreat.org/2007/11/25/at91sam...-windows-vista/ (правда не для AT90USB128, а для AT91SAM7).
Вопреки опасениям, UsbSer.sys в системе Vista имеется - его дата 02.11.2006 и он длинее на 2560 байт того, который поставляется с WinXP.

Отзовитесь, кому удалось запустить CDC-проект под Vista или помогите советом, где раздобыть подходящий inf-файл для этой цели.

===============
P.S.: Кажется в другом проекте at90usb162-cdc-1_0_1.zip есть inf-файл, в заголовке которого поминается Vista:

; Windows 2000, XP & Vista setup File for AT90USBxx2 demo

Пока не успела проверить заработает с ним или нет.

Сообщение отредактировал Xenia - Apr 4 2008, 11:16

[Visor]

На WinXP работает, а на Vista не загружается драйвер. Что делать?

Вы решили проблему? Интересует тот-же вопрос.

[Xenia]

Вы решили проблему? Интересует тот-же вопрос.

Проблема разрешилась тем способом, каким я и предполагала. INF-файл, взятый из проекта at90usb162-cdc-1_0_1.zip, способен работать под Vista со всеми МК типа AT90USB, а не только AT90USBxx2, как сказано в его заголовке.

Сообщение отредактировал Xenia - May 14 2008, 04:09

[Visor]

INF-файл, взятый из проекта at90usb162-cdc-1_0_1.zip, способен работать под Vista со всеми МК типа AT90USB, а не только AT90USBxx2, как сказано в его заголовке.

Спасибо!

[Visor]

Обнаружилось следующее:
Когда размер принимаемого либо отправляемого пакета данных кратен размеру ENDPOINT, он застревает в хосте. Пакет любой другой длины передаётся без проблем.
Подскажите в чём дело? И нужно хорошее описание по USB.

[prottoss]

Обнаружилось следующее:
Когда размер принимаемого либо отправляемого пакета данных кратен размеру ENDPOINT, он застревает в хосте. Пакет любой другой длины передаётся без проблем.
Подскажите в чём дело? И нужно хорошее описание по USB.

После такого пакета нужно посылать хосту пакет нулевой длины - это сигнал о завершении передачи

[galjoen]

После такого пакета нужно посылать хосту пакет нулевой длины - это сигнал о завершении передачи

Совершенно верно.
Но это происходит только в том случае если хост "не знает" длины передаваемых данных. Если длина известна хосту - передача завершается без посылки пакета 0й длины. В случае bulk передачи проблем нет - можно послать пакет 0й длины. А в случае передачи через контрольный канал (EP0) наличие в передатчике EP0 пакета 0й длины разрешённого для передачи, но незапрошенного хостом, может привести к сбою. Это если мы не успеем очистить передатчик EP0 после получения пакета OUT 0й длины с DATA1 (управляющая запись на эту транзакцию), а хост пошлёт следующий пакет SETUP (следующая транзакция) и сразу-же прочтет из передатчика EP0 пакет IN 0й длины (оставшийся) т.е. получится управляющее чтение (на следующую транзакцию). Я с такой ошибкой сталкивался. Пришлось слать пакет 0й длины по NAK-ам (если данные были кратны пакету EP). А заморочек с обработкой посылки NAK-ов хосту немало. Но я ничего лучше не придумал.
А вы как узнаёте, что нужно пакет 0й длины хосту слать? Без обработчика NAK-ов удаётся обойтись?

[prottoss]

Я не использовал AT90USBxxx, но по большому счету это относится ко всему, что работает по USB. Хост в любом случае не знает, сколько данных ему забирать, потому что он железяка. Так же не знает об этом и ПО, которое хостом управляет. ПО может только думать, ЧТО, если количество данных меньше, чем размер буфера конечной точки (EP), значит функция больше не будет передавать данные. Если количество принятых хостом данных равно размеру буфера ЕР, значит функция передала не все данные, и хост будет опрашивать функцию на предмет присутсвия пакета в ЕР. Чтобы сообщить хосту, что данных для передачи больше нет, мы пишем в ЕР нулевой пакет.

[Visor]

prottoss спасибо большое! Помогло!
Со стороны МК (USB Device) проблема решилась, но попался один РС (USB Host), который глючит по аналогичной причине, вплоть до потери устройства. Пришлось выкручиваться добавляя лишний байт, чтоб размер данных был не кратен размеру Endpoint.

[Xenia]

Два вопроса про питание AT90USB647 от порта

1. USB-коммуникация прекращает работать при понижении Vbus ниже 4.4 вольта. Это норма или патология?
Подробно моя проблема в следующем: устройство (АЦП с CDC-USB выходом) питается от Vbus и потребляет ток 200 мА, в то время как USB-порт столько ему не дает (по умолчанию должен давать 100 мА). В результате ограничения по току, напряжение падает до 4-х вольт, а на этом напряжении устройство не определяется компьютером, из-за чего не может попросить больше тока.
Это у всех так или я где-то напортачила? Схема соединения примитивная - все напряжения одним пучком Vbus+Uvcc+Avcc+Dvcc (Figure 21-3). Внутренний регулятор у меня включен.
По даташиту непонятно, должно ли работать при напряжении ниже 4.4 вольта. С одной стороны питание МК допустимо снижать до 3.4 вольта, а с другой стороны ничего не говорится про Ubus, который в то время отсоединен из пучка. Опять же сказано, что передающие линии D- и D+ имеют потенциал 1.4 вольта (если не в режиме хоста), а если так, то должно хватать.
И вообще, как мне быть, если у меня устройству нужно 200 мА, а начальное напряжение USB-порта при таком токе дает только 4 вольта?

2. Почему-то не хочет USB-порт добавлять ток, даже когда я его об этом вежливо прошу.
Устанавливаю:
#define CONF_ATTRIBUTES USB_CONFIG_BUSPOWERED
#define MAX_POWER 200 // 400 mA
USB_CONFIG_BUSPOWERED пробовала и 0x80 (как в апликэйшен), и 0x00 (как в книге Агурова), а толку чуть - какой был хилый ток, таким и остался. На разных компьютерах пробовала - результат неутешительный - сколько давал порт тока, столько и дает при любых MAX_POWER.
В чем тут может быть дело?

Сообщение отредактировал Xenia - Nov 5 2008, 10:39

[SKov]

Два вопроса про питание AT90USB647 от порта

2. Почему-то не хочет USB-порт добавлять ток, даже когда я его об этом вежливо прошу.
...
В чем тут может быть дело?

Говорят, что бывают такие умные материнские платы, которые действительно контролируют ток, потребялемый устройством от USB. На практике мне такое не встречалось. Типичная ситуация такова: операционка следит, чтобы суммарное потребление всех устройств на шине USB не превысило 0.5А. Если подключаемое устройство превышает эту грань, то оно не будет зарегистрировано операционнкой.
Так что все, что вы прописываете относительно потребления своего устройста, учитывается только на уровне "бухгалтерии', а не в виде реальных ограничений на ток на уровне железа.
На практике полно случаев "слабых" USB - портов или (у меня такой случай был) "слегка подгоревших", которые даже при 100мА садятся до 4-4.5V.
Для контроля такой ситуации пробуйте подключаться к разным компам или ставьте отдельную плату USB в свой комп.

[Xenia]

Говорят, что бывают такие умные материнские платы, которые действительно контролируют ток, потребляемый устройством от USB. На практике мне такое не встречалось. Типичная ситуация такова: операционка следит, чтобы суммарное потребление всех устройств на шине USB не превысило 0.5А. На практике полно случаев "слабых" USB - портов или (у меня такой случай был) "слегка подгоревших", которые даже при 100мА садятся до 4-4.5V.

Материнские платы действительно ограничивают ток USB. И это скорее всего не от большого ума, а необходимость защиты от внешнего короткого замыкания по USB-питанию.
USB-порты компьютеров, которые я испытывала, никак нельзя назвать слабыми, так как на них может работать внешний диск, потребляющий 0.8 А (из двух портов USB). Если бы порты и в самом деле были слабыми, то внешний диск бы не работал. Кроме того, модем (ZyXEL OMNI ADSL USB) тоже потребляет прилично - у него в конфигурации прописано 500 мА. А мое устройство потребляет куда меньше - 195 мА при напряжении 5.0 в.
Короче говоря, на чужие USB-устройства порты ток дают, а на мое нет. И вина в том, скорее всего ложится на драйвер. Я пробовала брать типовую прошивку, которую рекомендует Atmel, - "AT90USB128/64 CDC Device Virtual Com Port project". Исправляла в ней ток 100 мА на 500 мА (MAX_POWER = 0xFA) и получала тот же самый результат. И это не удивительно, т.к. все лабают с этого проекта, как и я.
В разных местах по этому поводу посылают читать "Refer to USB Feature Specification: Interface Power Management for details", но этого труда нигде достать не удается, хотя ссылок на него тьма тьмущая. В общем-то дело сводится к тому, что устройства USB 2.0 должны просить для себя электричество как-то иначе, чем это обычно делают устройства на USB 1.1.

When USB 2.0 was released, the document USB Feature Specification: Interface Power Management was under development. This document describes a protocol for managing power at the interface level instead of just the device level, to enable more precise and effective power conservation.

The 2.0 specification added an interface_power descriptor that enables power management at the interface level in addition to the device level. The document describing this descriptor's structure and use is USB Feature Specification: Interface Power Management.

И где мне искать описание этого загадочного "interface_power descriptor"а, если он даже в книге Агурова не упоминается?

P.S. С первым вопросом про питание я кажется сама разобралась - ниже 4.4 вольт зависал сам МК, т.к., согласно даташиту, питание при кварце 16 мГц должно быть не ниже 4.5 вольт. А на кварце 8 мГц тот же МК может работать даже начиная с 2.7 вольта. Придется теперь на вдвое медленный кварц переезжать.

Сообщение отредактировал Xenia - Nov 5 2008, 23:43

[SKov]

Материнские платы действительно ограничивают ток USB. И это скорее всего не от большого ума, а необходимость защиты от внешнего короткого замыкания по USB-питанию.

Возможно, не буду спорить. У моей материнки возраст меньше 3-х лет. Я умудрился спалить (по питанию) порт USB, который стоял на плате. Вытащил материнку из компа и к своему удивлению увидел обуглившийся проводник, подходивший к разъему USB. Припаивание проводочка поверх обуглившегося решило проблему - порт снова заработал и стал выдавать питание наружу. Читал про платы расширения USB, на которых стояли самовосстанвливающиеся предохранители. Про материнки, измеряющие и ограничивающие ток, не читал и не видел.
Я все-таки думаю, что вы только лишь уведомляете операционку, что хотите подключить устройство с таким-то питанием. А операционка просто суммирует эти числа для разных устройств на этой шине, сравнивает с максимально допустимой нагрузкой и либо регистрирует новое устройство в системе либо отказывает в регистрации по причине возможной перегрузки порта.

[Xenia]

Про материнки, измеряющие и ограничивающие ток, не читал и не видел.

Таких материнок, которые чтобы ограничить ток измеряют, действительно нет . Там принцип очень простой - на проходе ставят примитивный усилитель тока - транзистор, в цепи базы которого пускают калиброваный ток. Величина, получаемая умножением базового тока на коэффициент усиления по току для этого танзистора, и есть приблизительно ток отсечки. При достижении такого тока транзистор впадает в насыщение и больше чем эту величину пропустить тока через себя не может.
Конечно, это весьма грубый способ регулирования, т.к. внутреннее сопротивление самого транзистора при разных токах трудно учесть, а стало бы и падение напряжения на нем. Но, согласно описанию, дозирование тока производится ступенчато - шагами по 100 мА. А, значит, что там всего 5 ступенек, для которых подобрать резисторы для подходящего тока утечки можно экспериментально. Впрочем, похоже на то, что подбором фирмачи не занимаются, т.к. у меня, например, ограничение по току наступает не при 100 мА, а при 153 мА. Причем, на разных материнках по-разному. Но принцип регулирования тут у всех одинаковый.
Об этом я сама узнала случайно, когда у моего знакомого сгорел USB порт на старом ноутбуке из-за того, что он работал с внешним USB-диском, подключая только один USB-разъем. Ремонтровать пришлось у умельца, который все это рассказал. Я же за что купила, за то и продаю .

Сообщение отредактировал Xenia - Nov 6 2008, 09:33

[SKov]

Там принцип очень простой - на проходе ставят примитивный усилитель тока - транзистор, в цепи базы которого пускают калиброваный ток.
....
Но, согласно описанию, дозирование тока производится ступенчато - шагами по 100 мА.
.....
Ремонтровать пришлось у умельца, который все это рассказал. Я же за что купила, за то и продаю .

Сомневаюсь, что такая схема является общепринятой или стандартной. Хорошо бы взглянуть на описание, на которое Вы ссылаетесь. Всё-таки я остаюсь на своих позициях, пока не увижу бумагу, где написано обратное
Еще пара аргументов в пользу того, что ситуация именно такая, как я её представляю.
1) Если ваше устройство не работает (кварц не завелся), и операционка в принципе не в состоянии узнать, сколько вы хотите потреблять тока, то почему она в вашем случае ограничивает ток на уровне около 150ма? Вариант, что это величина ограничения по умолчанию, не проходит, иначе бы диски с питанием 0.8 А от двух USB не работали бы в принципе, ведь система не знает, с какого второго порта вы берете только питание. Вывод - ваш порт либо по жизни хилый либо подгорелый по питанию.
2) Несколько лет назад известная фирма Силабс начала выпускать свои преобразователи USB-Сом ср210х, к которым была приложена программа, с помощью которой можно было менять ток, запрашиваемый устройством. Эта информация хранилась в байте еепром в чипе преобразователя.
Содержимое байта (0..255) умножалось на 2 и передавалось операционке в качестве потребляемого тока. Некоторые разработчики сгоряча прописывали в этом байте максимально возможное число - 0xFF. Это число записывалось во внутреннюю еепром и соответствовало току 2* 255 - 510мА.
После этой операции чип можно было выбрасывать в урну, т.к. НИЧЕГО С НИМ НЕЛЬЗЯ БЫЛО СДЕЛАТЬ.
Чтобы перепрошить чип, надо было, чтобы его увидела система, а система (на уровне софта, а не харда!) отказывалась работать с устройством, которое требовало питание польше 500мА ! Помню, на силабовском форуме было бурное обсуждение, и наверное, сейчас программа прошивки уже поправлена Думаю, этот пример говорит тоже в пользу версии о софтверном смысле параметра потребления, не имеющим прямого отношения к харду, который может ограничивать ток лишь на уровне 0.5А, да и то не всегда, как было в случае с моей материнкой.

[TinyQ]

to Xenia

уточните вы пытаетесь подключать свое устройство только к ноутбукам или нет?

[Xenia]

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

Я вроде бы по-русски написала, что сослалась на слова умельца, который чинил сгоревший USB-порт. А для таких придир, как вы, я специально оговорила "за что купила, за то и продаю". Где вы прочли в моем посте, что я на описание ссылаюсь?
Если вы сомневаетесь, что там в качестве дискриминатора транзистор стоит, то что вам кажется менее сомнительным? Что там резистор что ли впаяли? Если бы это было так, то при достижении порогового значения наблюдалась бы не отсечка, а линейное уменьшение выдаваемого компьютером напряжения с ростом потребляемого тока на всем диапазоне. Однако такой эффект незамечен. До 100 мА порт исправно выдает свои 5 вольт (у меня 5.05 в) и лишь после преодоления порога ток начинает уменьшаться. Мой ноутбук при нагрузке на мое устройство (эквивалентное сопротивление 25 ом) понижает ток до 153-160 мА. Весьма возможно, что при коротком замыкании ток еще на сколько-то подрастет, но дискриминатор сгореть ноутбуку не даст.
Если же вы коряво выразились, и под словом схема имели ввиду не электрическую схему обеспечения напряжением, а логическую схему его блоковой раздачи, то здесь сослаться на описание я могу:
Павел Агуров, Интерфейс USB : практика использования и программирования, СПб, БХВ-Петербург, 2006. На странице 60 читаем:

Устройство указывает потребляемую мощность в дескрипторе конфигурации, который передается хосту при нумерации устройств на шине (см. разд. 10.2.2). Причем потребляемый от шины ток указывается с дискретностью 2 мА. Например, если устройство потребляет ток от USB-шины 100 мА, то в дескрипторе должна фигурировать цифра 50 (50 х 2 = 100 мА). Потребление тока устройством не должно превышать значения, указанного в процессе нумерации.
Потребляемая мощность, согласно спецификации USB, измеряется в блоках (unit). Один блок составляет 100 мА. Таким образом, устройства с малым потреблением используют 1 блок, а с большим потреблением - до 5 блоков.

Еще пара аргументов в пользу того, что ситуация именно такая, как я её представляю.
1) Если ваше устройство не работает (кварц не завелся), и операционка в принципе не в состоянии узнать, сколько вы хотите потреблять тока, то почему она в вашем случае ограничивает ток на уровне около 150ма?

Речь шла о случае, когда устройство "завелось", т.е. не только нормально определилось, но и выдает правильный текст на виртуальный COM-порт. Например, у моего ноутбука тока на это хватает (4.5 в, 153-160 мА), а у десктопа не хватает (4.0 в, 140 мА). Меня насторожил тот факт, что напряжение и токопотребление остаются одинаковыми, как в случае, когда устройство определилось (был инсталлирован драйвер), так и в том случае, когда оно не определилось (подключение без драйвера). Такое положение не нормально и свидетельствует о том, что просьба устройства о дополнительном электроснабжении была компьютером проигнорирована.
Кроме того, в моем устройстве предусмотрено подключение внешнего напряжения питания, благодаря чему я могу завести свое устройство даже на слаботочном USB-порте, а затем, отключив внешнюю подпитку, замерить, что дает порт.

Вывод - ваш порт либо по жизни хилый либо подгорелый по питанию.

У меня в ноутбуке не один USB-прт, а четыре. А на десктопе и подавно 6 портов. И все они ведут себя одинаково. Что ж, по-вашему они всего горелые? Если так, то отчего же те самые внешние USB-диски у меня на этих портах работают?

2) Несколько лет назад известная фирма Силабс начала выпускать свои преобразователи USB-Сом ср210х, к которым была приложена программа, с помощью которой можно было менять ток, запрашиваемый устройством. Эта информация хранилась в байте еепром в чипе преобразователя.
Содержимое байта (0..255) умножалось на 2 и передавалось операционке в качестве потребляемого тока. Некоторые разработчики сгоряча прописывали в этом байте максимально возможное число - 0xFF. Это число записывалось во внутреннюю еепром и соответствовало току 2* 255 - 510мА.
После этой операции чип можно было выбрасывать в урну, т.к. НИЧЕГО С НИМ НЕЛЬЗЯ БЫЛО СДЕЛАТЬ.
Чтобы перепрошить чип, надо было, чтобы его увидела система, а система (на уровне софта, а не харда!) отказывалась работать с устройством, которое требовало питание польше 500мА !

Это вы к чему? Какое отношение к теме имеют проблемы перепрошивки еепром у Силабса? У меня на AT90USB647 с прошивкой все нормально. Кроме того, я запрашиваю ток 400 мА (MAX_POWER=200). И этот запрос нормально виден на трассировщике USB канала.

уточните вы пытаетесь подключать свое устройство только к ноутбукам или нет?

Ответ на этот вопрос содержится в ответе для SKov.

[SKov]

Я вроде бы по-русски написала,
...
А для таких придир, как вы,
.....
Если же вы коряво выразились,
...
Это вы к чему?
...

Я просто хотел вам помочь.
Теперь уже не хочется.
Извините.

[ARV]

извините, что вмешиваюсь... мне казалось, что USB-хост выделяет по умолчанию 100 мА, и лишь по запросу больше. т.е. мне кажется, что девайс сначала должен держать всю свою периферию выключенной, чтобы не брать ток более 100 мА, потом запросить у системы свои реально необходимые 400 мА... а потом, по идее, уточнив, принят ли его запрос, подключать свою периферию...

или я путаю?

[Xenia]

мне казалось, что USB-хост выделяет по умолчанию 100 мА, и лишь по запросу больше. т.е. мне кажется, что девайс сначала должен держать всю свою периферию выключенной, чтобы не брать ток более 100 мА, потом запросить у системы свои реально необходимые 400 мА... а потом, по идее, уточнив, принят ли его запрос, подключать свою периферию...
или я путаю?

Вы ничего не путаете, именно так всё и есть. Только к моему большому сожалению, я мало что могу сделать, чтобы мое устройство вписалось в 100 мА. Погрузить в спячку микроконтроллер я не могу - в таком состоянии он неспособен будет общаться по USB. Оба АЦП (ADS1255) на борту питаются через через гальваноразвязки DC/DC (у каждого своя) - именно на них приходится наибольший расход тока, т.к. их КПД низок при данном токе (20% загрузки). Погружала оба АЦП в спячку, но это дало прибавку напряжения только на 0.05 в. Чтобы отключать DC/DC преобразователи на входе нужно было позаботиться заранее, при проектировании устройства. И это бы, несомненно, усложнило и удорожило конструкцию. А главное, что тогда я не могла знать, что у меня будет такой затык с USB-питанием, т.к. никогда раньше я программированием этой части не занималась. Да и про ограничение в 100 мА узнала только тогда, когда с этим непосредственно столкнулась.

Сообщение отредактировал Xenia - Nov 7 2008, 12:59

[GDI]

С первым вопросом про питание я кажется сама разобралась - ниже 4.4 вольт зависал сам МК, т.к., согласно даташиту, питание при кварце 16 мГц должно быть не ниже 4.5 вольт. А на кварце 8 мГц тот же МК может работать даже начиная с 2.7 вольта. Придется теперь на вдвое медленный кварц переезжать.

Вообще то для того чтобы не "переезжать", в устройствах ставят повышающий преобразователь и 7805, во всех USB сканерах так сделано, да и в некоторых переходниках для винчестеров.
P.S. Хотя для вас это, видимо , не подойдет раз плата уже готова.

[Dj.Shadow]

Xenia, а еще можно DC\DC подключить через мелкие полевички (например IRLML6401), чтоб питание им подавать после иницилизации, когда операционка разрешит. Всего то 1-2 вывода процессора оно займет.

[Xenia]

Заменила кварц 16 МГц на 8 МГц и ... ничего не изменилось. Снова всё та же история - как только напряжение становится ниже 4.4 вольта - МК виснет (обычно он у меня мигает раз в секунду светодиодиком).
Может быть у меня какой-нибудь не тот BODLEVEL в фузах прошит? И из-за этого МК на низком напряжении работать не хочет?
Подскажите пожалуйста, какие фузы для него надо устанавливать! Только все фузы разом, а не только те, которые понимаете. У меня внешний кварцевый резонатор на 8 МГц, и надо чтобы и МК работал на той же частоте. Хотелось бы, чтобы годилось питание в 4 вольта, а лучше - как можно более низкое.

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

[Petka]

Заменила кварц 16 МГц на 8 МГц и ... ничего не изменилось. Снова всё та же история - как только напряжение становится ниже 4.4 вольта - МК виснет (обычно он у меня мигает раз в секунду светодиодиком).
Может быть у меня какой-нибудь не тот BODLEVEL в фузах прошит? И из-за этого МК на низком напряжении работать не хочет?
Подскажите пожалуйста, какие фузы для него надо устанавливать! Только все фузы разом, а не только те, которые понимаете. У меня внешний кварцевый резонатор на 8 МГц, и надо чтобы и МК работал на той же частоте. Хотелось бы, чтобы годилось питание в 4 вольта, а лучше - как можно более низкое.

смотрю даташит:
Table 8-2. BODLEVEL Fuse Coding(1)

Код

BODLEVEL 2..0            V
111                  BOD Disabled
110                  2.0 V
101                  2.2 V
100                  2.4 V
011                  2.6 V
010                  3.4 V
001                  3.5 V
000                  4.3 V

в зависимости от установленных фузов BODLEVEL контроллер будет "уходить в reset" при разных напряжениях. выберите нужное вам напряжение и соответствующим образом прошейте фузы.

[Xenia]

смотрю даташит:
Table 8-2. BODLEVEL Fuse Coding(1)

Эту табличку я видела. Мои фузы такие (лог программатора Avreal32):

Код

Device connected, 90USB647 detected
Chip not locked
Fuses
  OSCCAL = 91
  CKDIV = 1
  CKOUT = 1
  SUT = 2
  CKSEL = E
  BLB1 = 3
  BLB0 = 3
  OCDEN = 1
  JTAGEN = 0
  WDTON = 1
  EESAVE = 1
  BOOTSZ = 1
  BOOTRST = 1
  HWBE = 0
  BODLEVEL = 7

Судя по BODLEVEL = 7, я пыталась отключить BOD совсем. Впрочем, не дожидаясь ответа, я перепробовала все BODLEVEL, но лучше от этого не стало.

Не подбросит ли кто-нибудь еще идеи, по какой причине AT90USB647 может зависать, при уменьшении питающего напряжения ниже 4.4 вольта?

Сообщение отредактировал Xenia - Nov 8 2008, 10:17

[Petka]

Судя по BODLEVEL = 7, я пыталась отключить BOD совсем. Впрочем, не дожидаясь ответа, я перепробовала все BODLEVEL, но лучше от этого не стало.

Не подбросит ли кто-нибудь еще идеи, по какой причине AT90USB647 может зависать, при уменьшении питающего напряжения ниже 4.4 вольта?

Как вы подключили пин UVCC?

[Xenia]

Как вы подключили пин UVCC?

На этот вопрос я уже отвечала:

Схема соединения примитивная - все напряжения одним пучком Vbus+Uvcc+Avcc+Dvcc (Figure 21-3). Внутренний регулятор у меня включен.

Криминала тут нет, поскольку согласно Figure 21-3 даташита, такая схема подключения функционирует вплоть до 3.4 в (ниже уже требуется подключаться напрямую к Ucap).
Кроме того, если бы я даже совсем обесточила UVCC, то у меня бы только перестал работать USB-канал, но процессор бы не завис. А у меня ниже 4.4 вольта перестает моргать светодиод на выводе порта, переключаемого из прерывания по таймеру T0. Т.е. у меня даже таймер останавливается! Впечатление такое, что кварц "заело".

Сообщение отредактировал Xenia - Nov 8 2008, 12:39

[Petka]

А у меня ниже 4.4 вольта перестает моргать светодиод на выводе порта, переключаемого из прерывания по таймеру T0. Т.е. у меня даже таймер останавливается! Впечатление такое, что кварц "заело".

1) а осцильчиком в кварц тыкнуть?
2) а если запитать схему не от USB а от регулируемого источника питания. (d+ и d- НЕ использовать). И тоже понижать напряжение. Схема тоже "остановится"?

[Xenia]

1) а осцильчиком в кварц тыкнуть?
2) а если запитать схему не от USB а от регулируемого источника питания. (d+ и d- НЕ использовать). И тоже понижать напряжение. Схема тоже "остановится"?

А чем питание от USB не кошерно? Я могу запретить, а точнее - вообще не инициализировать USB-сервис, используя чип, как обычный микропроцессор, а не как USB-контроллер. Тогда от USB-порта только одно питание и останется.

Если питать от внешнего источника, то происходит тоже самое - как только питание падает до 4.40-4.35 вольта - признаки жизни пропадают.

А ткнуть осцильчиком в кварц - моя мечта . К сожалению, я - программист, а не электронщик. Осциллографа у меня нет. Но надеюсь найти место, где мне удастся им воспользоваться.

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

[Petka]

Если питать от внешнего источника, то происходит тоже самое - как только питание падает до 4.40-4.35 вольта - признаки жизни пропадают.

А ткнуть осцильчиком в кварц - моя мечта . К сожалению, я - программист, а не электронщик. Осциллографа у меня нет. Но надеюсь найти место, где мне удастся им воспользоваться.

а есть возможность упротить программу например до:

Код

void main(void){
  led_on();
  delay_ms(250);
  led_off();
  delay_ms(250);
}

тоже будет "стопориться" при понижении питания?

[Xenia]

Проблема с напряжением на USB разрешилась совершенно неожиданным образом. Оказалось, что с программированием драйвера было всё в порядке, о чем свидетельствовало значение тока, которое можно посмотреть на вкладке Power устройства USB Hub в девайс-менеджере.
Проблема была ... в кабеле! Каждая жила которого имела сопротивление 2.6 ома. Итого в цепи питания (Ubus+Gnd) набиралось 2.6+2.6=5.2 ома, которые при токе 150 мА сажали на себя 5.2*0.15=0.78 вольта. В результате устройство имело для питания 5-0.78=4.22 вольта. Большего с этим кабелем получить было нельзя даже теоретически.
Кабель покупала на Буденовском рынке, был в полиэтиленовый мешочек запаян. Продавался как кабель типа A-B для USB 2.0, длина 1 метр (реально оказалось 90 см). Отчего у него такое высокое сопротивление не понимаю. Еще более удивительно, что сопротивление между внешними экранами разъемов достигает 20 ом! Мне и в голову не приходило, что такой короткий кабель может иметь такое большое сопротивление.
Кабель попал под подозрение тогда, когда я однажды забыла его отключить во время прошивки через LPT-порт. Еще не начав прошивку, а только лишь присоединив шлейф, я увидела, что мое устройство весело замигало лампочкой. Померив напряжение на МК, я обнаружила, что оно повысилось до 4.6 вольта, на которых устройство уже работало. Стала искать причину прибавки и сильно удивилась, не обнаружив на шлейфе никаких напряжений. Присоединяя все жилы шлейфа по очереди, удалось выследить, что напряжение возрастало в то момент, когда к устройству присоединяли ... землю! Вот тут-то уж померила напряжение между землями компьютера и устройства, которая оказалась как раз равна этой прибавке. В дальнейшем, выясняя ее происхождение, я неминуемо наткнулась на высокое сопротивление жил в соединительном кабеле.
Проклиная нехорошими словами злополучный кабель, а отодрала USB-кабель от принтера, с которым тот продавался в комплекте. Тот кабель был вдвое длиннее (2 метра), большего про него узнать не удалось. Принтер же определялся операционкой, как USB 1.1 девайс.
Измерив сопротивление принтерного кабеля, я с удовлетворением обнаружила, что оно составляет всего 0.2 ома на жилу, несмотря на то, что жилы в нем вдвое длиннее. Присоединив посредством этого кабеля свое устройство к компьютеру, я получила свои вожделенные 4.9-5.0 вольт, о которых мечтала.
Устройство равномерно подмигивало лампочкой, но ... компьютером не определялось. Вообще не видел компьютер моего устройства в упор. Подозреваю, что это потому, что этот кабель не был рассчитан на USB 2.0.
И вот сижу я теперь, перед этими двумя кабелями, как старуха у разбитого корыта. Один пропускает USB-сигналы, но пожирает напряжение питания, а другой пропускает напряжение питания, но пожирает USB-сигнал. На дворе воскресенье, магазины, где продают компьютерные прибамбасы, закрыты. А в понедельник куда мне идти, искать этот проклятый провод?
Может кто-нибудь в курсе, регламентируется ли где-нибудь омическое сопротивление USB-кабелей в расчете на один погонный метр? Или мне с авометром по магазинам ходить?
И еще один вопрос по теме - может ли AT90USB647/1286 работать по протоколу USB 1.1? Т.е. с меньшей скоростью, чем тот рассчитан? Если да, то что для этого нужно? В даташите на этот счет никакой информации не нашла.

Сообщение отредактировал Xenia - Nov 8 2008, 22:51

[aesok]

Принтер же определялся операционкой, как USB 1.1 девайс.
.....
Подозреваю, что это потому, что этот кабель не был рассчитан на USB 2.0.

USB 1.1 не синоним full(low)-speed, а USB 2.0 не синоним high-speed.

Может кто-нибудь в курсе, регламентируется ли где-нибудь омическое сопротивление USB-кабелей в расчете на один погонный метр? Или мне с авометром по магазинам ходить?

Universal Serial Bus Specification; Revision 2.0
Я надеюсь она у Вас есть.

Chapter 6 Mechanical;
6.6 Cable Mechanical Configuration and Material Requirements
6.6.3 Electrical Characteristics
Page 105; Table 6-6. Conductor Resistance

Chapter 7 Electrical
7.2 Power Distribution
7.2.2 Voltage Drop Budget
Page 175; Figure 7-47. Worst-case Voltage Drop Topology (Steady State)

И еще один вопрос по теме - может ли AT90USB647/1286 работать по протоколу USB 1.1? Т.е. с меньшей скоростью, чем тот рассчитан? Если да, то что для этого нужно? В даташите на этот счет никакой информации не нашла.

Первая страница даташита на AT90USB64/128:
• USB Full-speed/Low Speed Device Module with Interrupt on Transfer Completion

Анатолий.

Сообщение отредактировал aesok - Nov 9 2008, 01:34

[SKov]

...
Что там резистор что ли впаяли?
Если бы это было так, то при достижении порогового значения наблюдалась бы не отсечка, а линейное уменьшение выдаваемого компьютером напряжения с ростом потребляемого тока на всем диапазоне. Однако такой эффект незамечен. До 100 мА порт исправно выдает свои 5 вольт (у меня 5.05 в) и лишь после преодоления порога ток начинает уменьшаться.

Проблема была ... в кабеле! Каждая жила которого имела сопротивление 2.6 ома. Итого в цепи питания (Ubus+Gnd) набиралось 2.6+2.6=5.2 ома, которые при токе 150 мА сажали на себя 5.2*0.15=0.78 вольта. В результате устройство имело для питания 5-0.78=4.22 вольта. Большего с этим кабелем получить было нельзя даже теоретически.

[Xenia]

Разбралась в причине "зависания" МК при понижении напряжения питания ниже 4.4 вольта. Причина оказалась настолько же дебильной, как и сопротивление в соединительном кабеле. Даже признаваться неловко.
Начну по-порядку.
Осциллографом кварц замерила - ниже 4.4 вольта генерация наличествует. Предположение о том, что не тянет кварц, не оправдалось. Эх, зря я 16 Мгц на 8 Мгц сменяла!
Следуя данному мне здесь совету, написала самую простейшую программку типа:

Код

main()
{
  Lamp_on();   // включаю светодиод
  for(;;);    // бесконечный цикл
}

При напряжении ниже 4.4 вольта и эта программка, как и ожидалось, не сработала - светодиод не зажегся. Однако самым интересным оказалось то, что при понижении напряжения из работающего состояния в неработающее светодиод гас! Это означало, что МК не зависает, а ресетится!
Померила напряжение на ножке RESET - так оно и есть! Напряжение всего 0.4 вольта - при таком значении МК работать не может. Нашла в интернете даташит на микросхему супервизора (MCP100T-450), который формирует сигнал RESET. Так оно и есть - у него Vtrip = 4.5 вольта, а гистерезис от 4.25 в до 4.50 в (в среднем). Как у меня напряжение падало ниже этого уровня, он и вставлял ресет.
Судя про всему, быть мне великим электронщиком, когда я своё устройство усмирю!

Сообщение отредактировал Xenia - Nov 9 2008, 22:56

[Petka]

Разбралась в причине "зависания" МК при понижении напряжения питания ниже 4.4 вольта. Причина оказалась настолько же простой, как и сопротивление в соединительном кабеле.
.......
Нашла в интернете даташит на микросхему супервизора (MCP100T-450), который формирует сигнал RESET. Так оно и есть - у него Vtrip = 4.5 вольта, а гистерезис от 4.25 в до 4.50 в (в среднем). Как у меня напряжение падало ниже этого уровня, он и вставлял ресет.

Так BOD был внешним?
Одно из первых что проверяют после питания - ресет.

Судя про всему, быть мне великим электронщиком, когда я своё устройство усмирю!

Всё у Вас получится.

[Visor]

Нашла в интернете даташит на микросхему супервизора (MCP100T-450), который формирует сигнал RESET. Так оно и есть - у него Vtrip = 4.5 вольта, а гистерезис от 4.25 в до 4.50 в (в среднем). Как у меня напряжение падало ниже этого уровня, он и вставлял ресет.

А зачем она вам? AT90USB содержит встроенный BOD, параметрируемый и замечательно работающий.

[777777]

Небольшой оффтоп - Xenia, а где вы берете (планируете брать) Vendor ID и Device ID? Форум по этому вопросу я просмотрел, интересует ваш способ.

[Xenia]

Небольшой оффтоп - Xenia, а где вы берете (планируете брать) Vendor ID и Device ID? Форум по этому вопросу я просмотрел, интересует ваш способ.

Это не оффтоп, а вопрос как раз по теме.
За основу брала "USB библиотеку под AT90USBxxx" выложенную на Сахаре OlegPowerC:
http://caxapa.ru/128010.html
Затем я ее переписала под себя, вычистив замеченные ошибки:
http://caxapa.ru/136120.html
Vendor ID и Device ID остались от Atmel'я, примеры на сайте которого скорее всего послужили OlegPowerC прототипом.

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

[SKov]

Хорошая ссылка.
http://pdfserv.maxim-ic.com/en/an/AN3241.pdf
Особенно интересна последняя главка.
Здесь тоже кое-что есть по вашей теме.
http://www.usb.org/developers/whitepapers/...otherboards.pdf

[Xenia]

Хорошая ссылка.
http://pdfserv.maxim-ic.com/en/an/AN3241.pdf
Особенно интересна последняя главка.
Здесь тоже кое-что есть по вашей теме.
http://www.usb.org/developers/whitepapers/...otherboards.pdf

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

[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

[Visor]

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

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

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

[aesok]

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

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

Анатолий.

[Xenia]

Код

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))

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

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

[Visor]

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

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

[Xenia]

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

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

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

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

[Visor]

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

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

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

[aesok]

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


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

Анатолий.

Сообщение отредактировал aesok - Nov 21 2008, 16:03

[Xenia]

TXINI можно сбросить до, во время или после записи данных, но обязательно до сброса FIFOCON.
CONTROL-endpoint работают по другому. Вы про какой endpoint спрашиваете?

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


Visor

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

[Xenia]

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

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

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

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

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

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

Сообщение отредактировал Xenia - Jan 20 2009, 14:01

[aesok]

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

Я не знаю есть ли какой специальный механизм для этотго в CDC. Для Bulk ендпоинт это реализуеться посылкой NAK в ответ на OUT пакет.

8.5.2 Bulk Transactions
....
When the host is ready to transmit bulk data, it first issues an OUT token packet followed by a data packet
(or PING special token packet, see Section 8.5.1). If the data is received without error by the function, it
will return one of three (or four including NYET, for a device operating at high-speed) handshakes:
• ACK indicates that the data packet was received without errors and informs the host that it may send
the next packet in the sequence.
• NAK indicates that the data was received without error but that the host should resend the data because
the function was in a temporary condition preventing it from accepting the data (e.g., buffer full).
• If the endpoint was halted, STALL is returned to indicate that the host should not retry the transmission
because there is an error condition on the function.

Анатолий.

[tAmega]

Механизм есть. Он описан в спецификации CDC, там описаны запросы. Общая идея, есть запросы SET LINE CODING. Хост запрашивает скорость, число бит и т.д. в т.ч. тип управления потоком аппаратный или программный. Когда хост узнает, что управление потоком будет аппаратное, он запрашивает как именно будет управляться поток. Форматы запросов и ответов есть в спецификации на CDC.

Сообщение отредактировал tAmega - Jan 20 2009, 15:03

[Xenia]

Механизм есть. Он описан в спецификации CDC, там описаны запросы. Общая идея, есть запросы SET LINE CODING. Хост запрашивает скорость, число бит и т.д. в т.ч. тип управления потоком аппаратный или программный. Когда хост узнает, что управление потоком будет аппаратное, он запрашивает как именно будет управляться поток. Форматы запросов и ответов есть в спецификации на CDC.

SET_LINE_CODING передает от хоста в МК dwDTERate, bCharFormat, bParityType, bDataBits; т.е. скорость в бодах, формат, четность и число стоп-бит. Все это передается затем, чтобы МК повторил эти установки на своем RS-232-порту, т.к. для обмена по USB эти данные не нужны.
GET_LINE_CODING запрашивает эти же данные (обычно те же самые, что были раньше пререданы хостом командой SET_LINE_CODING).
Есть еще SET_CONTROL_LINE_STATE, посредством которого хост может выразить желание изменить уровни DSR и RTS. И это всё!
Никакого аппаратного хендшейкинга здесь нет!

Практика показывает, что все эти три команды подаются только при открытии USB-порта (виртуальный COM), а в процессе передачи никогда не подаются. Поэтому нет и никакой возможности подать сигнал о том, что линии изменили полярность в процессе передачи. Т.е. раз хост не спрашивает, то и ответить ему не представляется возможным.

====================================================================

Я не знаю есть ли какой специальный механизм для этотго в CDC. Для Bulk ендпоинт это реализуеться посылкой NAK в ответ на OUT пакет.

ACK'ом или NAK'ом можно отвечать на запросы от НУЛЕВОГО эндпоинта, на специфические ЗАПРОСЫ. Однако поток данных идет по эндпоинту RX_EP и не требует никаких ответных реплик. Там только бит FIFOCON устанавливают, чтобы показать, что буффер опустошен. Никаких посылок оттуда я посылать не могу, т.к. они не предусмотрены протоколом.
А в процессе передачи данных никаких запросов по нулевому эндпоинту нет вообще, а потому и отвечать не на что.

Сообщение отредактировал Xenia - Jan 20 2009, 16:26

[Rst7]

Никаких посылок оттуда я посылать не могу, т.к. они не предусмотрены протоколом.

И не надо. Просто не выгребаете данные из RX_EP и хост будет курить бамбук сколько надо. Это поддерживает сам USB-контроллер, посылая в ответ на пакеты хоста NAK, если нет места в приемном буфере. Хост, соответственно, будет перепосылать пакет, пока девайс не ответит ACK.

[aaarrr]

Там только бит FIFOCON устанавливают, чтобы показать, что буффер опустошен.

Механизм NAK'ов в USB работает на любых ендпоинтах. Не ставьте FIFOCON, железка будет посылать хосту NAK'и и поток затормозится.

Упс, опередили

[Xenia]

И не надо. Просто не выгребаете данные из RX_EP и хост будет курить бамбук сколько надо.

Вау! Так просто?! Т.е. забираю из буфера по мере использования, а заботиться о том, что он переполнится мне не надо? Так это же кайф!

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

[aesok]

ACK'ом или NAK'ом можно отвечать на запросы от НУЛЕВОГО эндпоинта, на специфические ЗАПРОСЫ. Однако поток данных идет по эндпоинту RX_EP и не требует никаких ответных реплик. Там только бит FIFOCON устанавливают, чтобы показать, что буффер опустошен. Никаких посылок оттуда я посылать не могу, т.к. они не предусмотрены протоколом.
А в процессе передачи данных никаких запросов по нулевому эндпоинту нет вообще, а потому и отвечать не на что.

Странно!!!!

На странице 221 "Universal Serial Bus Specification" параграфе "8.5.2 Bulk Transactions" написано и нарисованно что можно отвечать NAK для Bulk endpoint (также как и на Control/Interrupt endpoint). Это на Isochronous нет ACK/NAK/STALL. А откуда у вас информация что NAK работает только на controll endpoint?

Я так понимаю Вы работаете с Bulk ендпоинт. Тогда требуеться минимум действий. Расмотрим Bulk OUT endpoint, параграф "22.14 OUT endpoint management" даташита AT90USB64/128.

Когда приходит OUT пакет выставляться 2 бита:
RXOUTI - флаг прерывания по причине прихода пакета, который сразу можно сбросить и
FIFOCON - FIFO Control Bit - говорящий о том что буфер занят
пришедшим пакетом. Пока Вы не сбросите этот бит вы можете к какой угодно
скорость читать данные из этого буфура, при этом USB контроллер будет
отвечать NAK-ом на все попытки хоста передать следующий пакет. Как только Вы
полностью прочитаете буфер, Вы сбрасываете бит FIFOCON в 0. И теперь при
очередной попытке хоста передать пакет, контроллер запишет его в
освободившийся буфер, ответит хосту ACK, и выставит биты RXOUTI и FIFOCON.
И.т.д....

Другими словами сбрасывайте бит FIFOCON после того как полностью обработали пришедщий пакет, все остальное хост с USB контролером в mege все сделают сами.


Анатолий.

Сообщение отредактировал aesok - Jan 20 2009, 17:48

[Dx!]

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

Тоже думал уже сильно "переосмыслить" примеры, но, как всегда, велосипед уже изобретен.
http://www.fourwalledcubicle.com/LUFA.php
Куда как болие прямой USB стек от фанатов. Под WinAVR. C кучей DEMO. Понравился.

[Visor]

На WinXP работает, а на Vista не загружается драйвер. Что делать?

Ну вот, новая "радость" на наши головы - Windows 7.
Не работает под ней.

[manul78]

Ну вот, новая "радость" на наши головы - Windows 7.
Не работает под ней.

Да уж... только с XP разобрался, опять новые веяния... Благо "семерка" еще не доминирует... пока...

С "вистой" не работаю принципиально, т.к. о покойниках либо хорошо, либо никак... а вот в "семерке" должны быть
предусмотрены настройки для эмуляции более ранних ОС...

Давайте пробовать вместе. Я использую AT90USB162 и основательно мной "раскуроченные" на кирпичики Атмеловские
демки... Использую в основном HID, думаю "семерка" должна поддерживать без проблем со стороны МК, а вот со стороны
PC возможно уже другие драйвера для HID... Не знаю... Надо пробовать.

[Visor]

Использую в основном HID ...

С HID не знаю, не пробывал, здесь мы мучаем CDC.
Речь конкретно о at90usbxxx_cdc.inf .