Вышла очередная версия AVR-USB драйвера от Objective Development, Исправлена пара серьезных багов, рекомендуется обновиться Опции

[osnwt]

Вышла версия программного USB драйвера для большинства AVR контроллеров.
См сайт автора.

Самая последняя версия всегда находится в составе reference-проекта PowerSwitch.

Изменения в текущей версии:

* Release 2006-03-14

- Added IAR compiler compatibility to USB driver (not the PowerSwitch project).
Thanks to Oleg Semyonov for contributing this port!
- Major Bugfixes in the low level parts of the USB driver. See the driver's
Changelog for details.

Changelog:

- Give a compiler warning when compiling with debugging turned on.
- Added Oleg Semyonov's changes for IAR-cc compatibility.
- Added new (optional) functions usbDeviceConnect() and usbDeviceDisconnect()
(also thanks to Oleg!).
- Rearranged tests in usbPoll() to save a couple of instructions in the most
likely case that no actions are pending.
- We need a delay between the SET ADDRESS request until the new address
becomes active. This delay was handled in usbPoll() until now. Since the
spec says that the delay must not exceed 2ms, previous versions required
aggressive polling during the enumeration phase. We have now moved the
handling of the delay into the interrupt routine.
- We must not reply with NAK to a SETUP transaction. We can only achieve this
by making sure that the rx buffer is empty when SETUP tokens are expected.
We therefore don't pass zero sized data packets from the status phase of
a transfer to usbPoll(). This change MAY cause troubles if you rely on
receiving a less than 8 bytes long packet in usbFunctionWrite() to
identify the end of a transfer. usbFunctionWrite() will NEVER be called
with a zero length.

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

[733259]

Насколько я понял - это было сделано из-за того что GCC case всегда как "int" обрабатывает, но ИАР case"ы весьма эффективно раскручивает.

Так было в gcc 3 версии, 4.0.3 у меня case нормально обрабатывает.

Он вообще недоумевает, почему наши люди не используют бесплатный компилятор gcc...

Аналогично, тоже недомеваю.

Сообщение отредактировал 733259 - Mar 29 2006, 09:08

[osnwt]

Так было в gcc 3 версии, 4.0.3 у меня case нормально обрабатывает

Там написано, что версия драйвера оптимизимрована под gcc 3. Последующие могут быть оптимизированы под 4.

А насчет использования IAR я уже писал: код лоадера от Atmel компилируется в 1400 байтов под gcc 3 (4 не проверял), и в 1000-1050 - под IAR. Для ATmega128 не критично, для 2313 или т.п. - очень даже. Да и привычка русского человека....

[aleksey_g]

 TestPowerswitch.rar ( 153.94 килобайт ) Кол-во скачиваний: 270
Все! Сделал управление Powerswitch_ем из-под Дельфи через USBIO от http://www.thesycon.de
Осталось найти свежую не демо версию драйвера.
Ато дает поработать только 4 часа

[lazycamel]

 TestPowerswitch.rar ( 153.94 килобайт ) Кол-во скачиваний: 270
Все! Сделал управление Powerswitch_ем из-под Дельфи через USBIO от http://www.thesycon.de
Осталось найти свежую не демо версию драйвера.
Ато дает поработать только 4 часа

НАФИГА ? Чем тебя LibUSB-win32 не устроила ? Халявная кстати.

[aleksey_g]

НАФИГА ? Чем тебя LibUSB-win32 не устроила ? Халявная кстати.

Тут ключевое слово - Дельфи.
Ну тяжел для меня С. А по поводу LibUSB-win32, так Паскаль с ним работать не будет!
Так сказали разработчики.http://libusb-win32 .sourceforge.net
Правда, здесь мне подсказали лежит одно извращение, чтобы заставить работать под
Паскалем именно LibUSB, но оно оказалось не рабочим.http://www.xs4all.nl/~ynlmns/
Может дело в версиях драйверов?, не знаю.
Просто хочется использовать более знакомый инструментарий.
Если под силу, выясните причину неработоспособности. Там acces violation под дебагом.
Да, Lazycamel, не вы ли где-то здесь говорили, что адаптировали USB Игоря Ческо под С да еще
на меге48-24? Сможете USBDRV от http://www.obdev.at/products/avrusb/index.html
переписать на мегу48-24 для ИАР_а? 24MHZ подкупает!

[lazycamel]

Да, Lazycamel, не вы ли где-то здесь говорили, что адаптировали USB Игоря Ческо под С да еще
на меге48-24? Сможете USBDRV от http://www.obdev.at/products/avrusb/index.html
переписать на мегу48-24 для ИАР_а? 24MHZ подкупает!

Было дело, но по сравнению с Objective Development мой вариант выглядит поделкой студента первокурсника :-( Я по их коду теперь практически учусь правильному написанию исходника с прицелом на кастомизацию да пытаюсь безуспешно счаз въехать в ИАР-совместимость.

А по поводу 24 Мгц есть две заковыки.
1) Атмел понизил скорость Мег до 20МГц. Слишком много они жрут в 24 Мгц режиме и с флешем что-то не то на такой частоте проиходило.
2) по результатам профилирования - выигрыша по сути в движке нет, только уровень приложения ускоряется.

Я по поводу драйвера, я давно уже всем советую - делайте обычное HID устройство только с 0 конечной точкой и 8 байтным фьючерепортом. В результате получаете бесплатный враппер в тоже самое стандартными драйверами виндоуз, начиная с 2000. И операции ReadFile/WriteFile.

[osnwt]

Я по их коду теперь практически учусь правильному написанию исходника с прицелом на кастомизацию да пытаюсь безуспешно счаз въехать в ИАР-совместимость.

По поводу IAR-совместимости готов ответить на конкретные вопросы, поскольку это - моих рук дело. Правда, мои мысли и патчи Кристиан выразил просто блестяще, переписав это в своем стиле.

2) по результатам профилирования - выигрыша по сути в движке нет, только уровень приложения ускоряется.

Есть возможность спросить автора, не получится ли при этом добавить проверку CRC "на лету". Как известно, сейчас этого не делается при приеме вообще. Хотя, если официально 24 MHz версий уже нет, то заниматься этим он не станет.

Я по поводу драйвера, я давно уже всем советую - делайте обычное HID устройство только с 0 конечной точкой и 8 байтным фьючерепортом. В результате получаете бесплатный враппер в тоже самое стандартными драйверами виндоуз, начиная с 2000. И операции ReadFile/WriteFile.

Есть информация, что HID без Interrupt In работает не со всеми Windows (а с ней работает, в том числе, с Win98SE). Причем, можно не реализовывать код для обработки этой самой точки (не описывать INPUT в Report Descriptor). Дотаточно того, что она просто есть. А обмен информацией организовывать через Feature Reports (фиче, кстати, а не фьюче). Только с ним ReadFile/WriteFile не работают - это для Input/Output. Для работы с Feature используются API функции GetFeature/SetFeature.

[lazycamel]

Я по их коду теперь практически учусь правильному написанию исходника с прицелом на кастомизацию да пытаюсь безуспешно счаз въехать в ИАР-совместимость.

По поводу IAR-совместимости готов ответить на конкретные вопросы, поскольку это - моих рук дело. Правда, мои мысли и патчи Кристиан выразил просто блестяще, переписав это в своем стиле.

Ок, спасибо.

2) по результатам профилирования - выигрыша по сути в движке нет, только уровень приложения ускоряется.

Есть возможность спросить автора, не получится ли при этом добавить проверку CRC "на лету". Как известно, сейчас этого не делается при приеме вообще. Хотя, если официально 24 MHz версий уже нет, то заниматься этим он не станет.

Там в том то и проблема, что в месте где в движке лимитирована производителность сейчаз свободно толи 5 толи 8 тактов, при переводе на 24 высвободиться еше порядка 40. В эти полсотню тактов CRC все равно не впихнуть ИМХО. Т.е. получается что вроде и есть ресурсы, но ни для чего серьезного их просто не хватает.

Я по поводу драйвера, я давно уже всем советую - делайте обычное HID устройство только с 0 конечной точкой и 8 байтным фьючерепортом. В результате получаете бесплатный враппер в тоже самое стандартными драйверами виндоуз, начиная с 2000. И операции ReadFile/WriteFile.

Есть информация, что HID без Interrupt In работает не со всеми Windows (а с ней работает, в том числе, с Win98SE). Причем, можно не реализовывать код для обработки этой самой точки (не описывать INPUT в Report Descriptor). Дотаточно того, что она просто есть. А обмен информацией организовывать через Feature Reports (фиче, кстати, а не фьюче). Только с ним ReadFile/WriteFile не работают - это для Input/Output. Для работы с Feature используются API функции GetFeature/SetFeature.

Ну не будем к словам придираться. :-)
Тем не менее Features Report только с Win XP начали читаться через HidD_GetFeature/HidD_SetFeature, а до этого использовался обычный Read/Write.

[osnwt]

Есть возможность спросить автора, не получится ли при этом добавить проверку CRC "на лету". Как известно, сейчас этого не делается при приеме вообще. Хотя, если официально 24 MHz версий уже нет, то заниматься этим он не станет.

Там в том то и проблема, что в месте где в движке лимитирована производителность сейчаз свободно толи 5 толи 8 тактов, при переводе на 24 высвободиться еше порядка 40. В эти полсотню тактов CRC все равно не впихнуть ИМХО. Т.е. получается что вроде и есть ресурсы, но ни для чего серьезного их просто не хватает.

Ответ неверный.

Рекомендую почитать замечательную статью на сайте автора avr-usb о том, как оптимизировался код.

В двух словах: код avr-usb от obdev писался с нуля, а не по мотивам других ассемблерных реализаций. Его особенностью является то, что весь прием usb пакетов выполняется в реальном времени, в том числе, bit stuffing, - в отличие от ассемблерного драйвера, сначала принимающего, а потом декодирующего. Этим выигрывается как время, так и объем.

Нетрудно подсчитать (что и сделано в той статье), что при скорости low-speed девайса 1.5MBit и тактовой контроллера 12MHz мы получаем 8 машинных циклов на принимаемый бит, которыми нужно распорядиться и для манипуляций битами, и для продвижения указателя, и для подсчета принятого количества бит. И ровно 8 циклов использовано в алгоритме. Как к этому шел автор - тоже приведено в статье на уровне исходного кода с комментариями. Отсюда намного лучшая производительность этого драйвера, его предсказуемость и документированность.

Удвоение тактовой добавит всего 8 (свободных) тактов, совсем не 40. Хватит ли их на CRC calculation - надо смотреть. Но это уже другой вопрос.

Тем не менее Features Report только с Win XP начали читаться через HidD_GetFeature/HidD_SetFeature, а до этого использовался обычный Read/Write.

Факт, взятый с широкоизвестного HID FAQ, подтверждаемого также MSDN. Цитата:

How can an application send a report using a control transfer?

Under Windows 98 Gold (original version), WriteFile sends Output reports using control transfers with Set_Report requests. Under later Windows editions, WriteFile uses control transfers if the HID interface doesn't have an interrupt OUT endpoint. Otherwise, WriteFile uses interrupt transfers for Output reports. Beginning with Windows XP, you can use HidD_SetInputReport to send an Output report with a control transfer and a Set_Report request. Under all Windows editions, HidD_SetFeature sends a Feature report using a control transfer with a Set_Report request.

Похоже, в ранее приведенном Вашем утверждении были перепутаны Feature и Output reports. Такая совместимость для Feature, кстати, очень удобна для всяких загрузчиков и т.п. дел.

Сообщение отредактировал osnwt - Apr 13 2006, 09:01

[lazycamel]

Ответ неверный.
Рекомендую почитать замечательную статью на сайте автора avr-usb о том, как оптимизировался код.

В двух словах: код avr-usb от obdev писался с нуля, а не по мотивам других ассемблерных реализаций. Его особенностью является то, что весь прием usb пакетов выполняется в реальном времени, в том числе, bit stuffing, - в отличие от ассемблерного драйвера, сначала принимающего, а потом декодирующего. Этим выигрывается как время, так и объем.

Ась ? У нас по-моему некоторое взаимонепонимание. Я говорю про ту часть которая разбирает адрес и формат пакета (от метки se0) , а не про SIE (получение последовательности битов) и превращение их в байты.

Похоже, в ранее приведенном Вашем утверждении были перепутаны Feature и Output reports. Такая совместимость для Feature, кстати, очень удобна для всяких загрузчиков и т.п. дел.

Крайне на это похоже. Точнее я попутал вот с этим:

"HidD_GetFeature requests a Feature report using a control transfer with a Get_Report request. Beginning with Windows XP, you can use HidD_GetInputReport to request an Input report with a control transfer and a Get_Report request."

Чтож и на старуху бывает проруха. Спасибо.

Сообщение отредактировал lazycamel - Apr 13 2006, 09:47