[osnwt 0]

Вышла версия программного 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.

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

[aleksey_gregul 0]

Олег, было бы совсем прекрасно, если бы Вы PowerSwitch или Automator

предложили в версии для IAR_a

[osnwt 0]

Олег, было бы совсем прекрасно, если бы Вы PowerSwitch или Automator

предложили в версии для IAR_a

У меня нет соответствующего железа для полноценной проверки. Просто сделать, чтобы скомпилировалось? Думаю, что это не столь сложно. Но неужели это столь сложно, что не сделает кто-то самостоятельно (тавтология умышленная) :)? Ведь все аналогии есть в исходниках usbdrv, там прямо написано, что на что поменять.

 

На самом деле переделать PowerSwitch - дело минут 10-20, я думаю. Добавить туда файлы Workspace и Project и рекомендации по настройке IAR проекта. Последнее из названного я писал в readme для IAR, но автор не стал включать в релиз, так как больше ориентируется на бесплатный gcc.

 

Честно говоря, даже не пробовал компилировать готовые названные проекты в IAR. Проблем там быть не должно, максимум - это замена хедеров и функций работы с watchdog'ом, так как готовых макросов запуска последнего с заданным периодом в IAR, насколько мне кажется, нет. Да и libusb я ставить не хочу на свою машину, ограничившись пока HID-устройствами со стандартным Windows-драйвером.

 

Если это вообще кому-то сильно нужно, я могу написать свои рекомендации по портированию. Но половину я уже сказал, собственно. Осталось еще чуть-чуть по имеющим место warnings компилятора (автор предпочел их не душить pargma-ми) и особенностям порта для IAR касательно выбора сегмента для приемного буфера.

[EWAVR 0]

Гм... Скомпилировал c грехом пополам PowerSwitch IAR'ом, залил... не работает (устройство USB не опознано). С приложенной прошивкой - все ОК. А в исходниках копаться - мне проще с gcc разобраться (что я и делаю).

[osnwt 0]

Гм... Скомпилировал c грехом пополам PowerSwitch IAR'ом, залил... не работает (устройство USB не опознано). С приложенной прошивкой - все ОК.

Не получилось вчера (уже сегодня) ничего написать, а потому просто вопрос: с какой моделью памяти компилировалось? С моделью по умолчанию (tiny) работать не будет в принципе, хотя скомпилируется без замечаний. Об этом сказано в документации на USB драйвер. Я имел в виду: напишу то, чего нет в авторском описании.

 

DEVELOPMENT SYSTEM

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

This driver has been developed and optimized for the GNU compiler version 3

(gcc 3). It does work well with gcc 4 and future versions will probably be

optimized for gcc 4. We recommend that you use the GNU compiler suite because

it is freely available. AVR-USB has also been ported to the IAR compiler and

assembler. It has been tested with IAR 4.10B/W32 and 4.12A/W32 on an ATmega8

with the "small" memory model. The "tiny" memory is not supported. Please

note that gcc is more efficient for usbdrv.c because this module has been

deliberately optimized for gcc.

Что касается разборки с gcc: это тоже вариант. Хотя IAR заметно эффективней на "обычных" исходниках, не оптимизированных под конкретный компилятор. Как я уже где-то писал, проигрыш в 200 байтов на 700-байтном коде usbdrv.c (оптимизированном под gcc) окупается на первом же 1000-байтном коде (не подо что не оптимизированным) выигрышем в 400 байтов.

[EWAVR 0]

Компилировалось и заливалось в AT90S2313, для которой единственно возможная модель памяти "tiny". Меня интересовало, какой выигрыш в размере кода дает переход с gcc на IAR-есть уже изготовленный девайс на Tiny26, забитый кодом до последнего байта, а хотелось бы еще байт 100-150...

[osnwt 0]

Компилировалось и заливалось в AT90S2313, для которой единственно возможная модель памяти "tiny".

Это объясняет причину неработоспособности кода (модель не поддерживается), хотя не объясняет причин этого. Мне вообще не удалось заставить IAR порт драйвера работать, будучи cкомпилированным под tiny. Но я и не особенно изучал этот вопрос, так как мне это было не слишком актуально.

 

Меня интересовало, какой выигрыш в размере кода дает переход с gcc на IAR-есть уже изготовленный девайс на Tiny26, забитый кодом до последнего байта, а хотелось бы еще байт 100-150...

Один частный результат я уже приводил. Всё зависит от соотношения объемов оптимизированного под компилятор кода и неоптимизированного. В моем случае проигрыш в 200 байтов на usbdrv.c окупился на втором же файле в два раза. Я тоже хотел выиграть, но в обратную сторону. Увы, для "просто кода" IAR оказался эффективнее.

 

Но, на самом деле, драйвер же компилируется и линкуется в tiny? Раз так - почему бы не собрать приложение иаром и сравнить размер? Ну, а если овчинка будет стоить выделки, то тогда будет вполне реальный стимул изучить, можно ли заставить usbdrv работать в tiny. Вполне полезная и интересная задача. Может, я бы и поизучал этот вопрос, если бы кто-то привел реальные цифры выигрыша (если таковой будет - мой опыт пока обратный).

[EWAVR 0]

Скомпилировал PowerSwitch (at90s2313) - IAR проигрывает gcc при наилучшем раскладе 20 байт при общем рамере около 1900 байт. Если же выбросить из проекта все, кроме самого драйвера USB, то IAR проигрывает 50 байт при общем размере около 1500 байт.

[osnwt 0]

Скомпилировал PowerSwitch (at90s2313) - IAR проигрывает gcc при наилучшем раскладе 20 байт при общем рамере около 1900 байт. Если же выбросить из проекта все, кроме самого драйвера USB, то IAR проигрывает 50 байт при общем размере около 1500 байт.

Это, вероятно, в tiny (и неработающее)? Потому что у меня разница байтов в 150-160 и получалась при смене модели с tiny на small. В принципе, можно попробовать разобраться, что не так с tiny. Если будет время - посмотрю. Если будут какие-то идеи - было бы интересно услышать. Вероятно, фокус в размерах каких-то указателей, используемых и ассемблерной, и сишной частями. Больше-то быть нечему.

 

Интересно также, что получается у gcc, если он всегда (всегда?) дает столь же эффективный код, как IAR только в tiny модели? Хотя его заморочки с доступом к const переменным во flash (как мне говорили) вполне могут быть той самой ценой вопроса.

[aleksey_gregul 0]

Если это вообще кому-то сильно нужно, я могу написать свои рекомендации по портированию. Но половину я уже сказал, собственно. Осталось еще чуть-чуть по имеющим место warnings компилятора (автор предпочел их не душить pargma-ми) и особенностям порта для IAR касательно выбора сегмента для приемного буфера.

 

Очень нужно! На примере порта PowerSwitch.

[EWAVR 0]

Гы! Скомпилировал PowerSwitch для 90s2313 IAR'ом в small модели памяти - заработало! Но размер кода - 1700 против 1500 у gcc (только драйвер USB). Ув. osnwt, нельзя ли адаптировать исходники usbdrv и для tiny модели памяти? Там, как я понял, нужно править ассемблерный текст на предмет корректной передачи параметров-указателей (один байт вместо двух)? И еще: в файле usbdrv.h есть такое место:

 

#if defined GIMSK

# define USB_INTR_ENABLE GIMSK

#elif defined EIMSK

# define USB_INTR_ENABLE EIMSK

#else

# define USB_INTR_ENABLE GICR

#endif

 

На выходе имеем #define USB_INTR_ENABLE GICR и ошибку компидяции(GICR не определен), хотя в io2313.h есть GIMSK и нет никакого GICR. По-моему, констукции типа #if defined GIMSK в IAR не работают для имен SFR'ов.

[osnwt 0]

Гы! Скомпилировал PowerSwitch для 90s2313 IAR'ом в small модели памяти - заработало! Но размер кода - 1700 против 1500 у gcc (только драйвер USB).

Верно, точно тот же результат я и получал. Просто в моем случае для криптозагрузчика на следующем же файле я получил выигрыш IAR против gcc в 400 байтов, а так как мне не была актуальна модель tiny (загрузчик работает в бутовой области и со всем application flash area), я не стал возиться.

 

Ув. osnwt, нельзя ли адаптировать исходники usbdrv и для tiny модели памяти? Там, как я понял, нужно править ассемблерный текст на предмет корректной передачи параметров-указателей (один байт вместо двух)?

Вероятнее всего, дело в чем-то подобном - я не изучал этот вопрос пока. С радостью это готов поправить. Если можно, было бы полезным указать конкретное место (места), где это проявляется. Если нет - придется искать самому, но я не знаю, когда выберу момент для исследования.

 

По-моему, констукции типа #if defined GIMSK в IAR не работают для имен SFR'ов.

Я сам напоролся на такую беду применительно к другому месту, но там было связано не с SFR. А эти места сами по себе проблемные при переносе. Вариант типа (SFR-1) вызывает предупреждение при компиляции, из за чего пришлось поменять в паре мест #define на = при объявлении адресов портов. Надо будет придумывать красивый workaround. Но уже ясно, что искать.

 

Я постараюсь поправить эти места в ближайшем будущем (но см. выше насчет указателей).

 

Спасибо за достаточно точный bug report. Хоть я не являюсь maintainer'ом IAR порта, но раз уж взялся...

[osnwt 0]

Ув. osnwt, нельзя ли адаптировать исходники usbdrv и для tiny модели памяти?

Дошел ход посмотреть. Вот фикс для этого дела. У меня заработало, но с пристрастием не тестировал (время суток не располагает), прошу проверить (минус убрать, плюс добавить):

 

usbdrv.h:

-extern unsigned usbCrc16(uchar *data, uchar len);
+extern unsigned usbCrc16(uchar __near *data, uchar len);

-extern unsigned usbCrc16Append(unsigned char *data, unsigned char len);
+extern unsigned usbCrc16Append(uchar __near *data, uchar len);

 

И еще: в файле usbdrv.h есть такое место:

 

#if defined GIMSK

С этим так просто не поделать ничего. Сам Atmel использует #ifdef __IOM32__ и т.п. Красивый фикс не получается. Менее красивый получается. Отправил автору патчи, может, он придумает что-то еще лучше.

 

(на работу опять проспать придется, что за фигня эти выходные :cranky:)

[Proton 1]

Посмотрел на сайте проект PowerSwitch, а там почему то нет исходников драйвера под виндовс. В описании что-то сказано про библиотеку libusb-win32, однако это не может быть полноценным драйвером. А посему вопрос: драйвер под устройство нужно писать самому (WinDDK), или всё-же он где-то есть, а я плохо искал?

[osnwt 0]

А посему вопрос: драйвер под устройство нужно писать самому (WinDDK), или всё-же он где-то есть, а я плохо искал?

Последнее :)

 

libusb - это не только библиотека, но также inf-wizard и пара файлов драйвера под Windows (в windows-порте библиотеки libusb0.dll, libusb0.sys ). Драйвер, как я понимаю (сам не ставил) может работать с любым устройством. Остается только написать для этого устройства inf.

 

В этом и есть удобство использования libusb: драйвер не пишется самостоятельно, а используется достаточно стабильный и многократно проверенный из состава библиотеки.

 

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