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

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

[aleksey_g]

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

[osnwt]

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

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

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

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

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

[EWAVR]

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

[osnwt]

Гм... Скомпилировал 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]

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

[osnwt]

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

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

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

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

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

[EWAVR]

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

[osnwt]

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

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

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

[aleksey_g]

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

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

[EWAVR]

Гы! Скомпилировал 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]

Гы! Скомпилировал 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]

Ув. 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__ и т.п. Красивый фикс не получается. Менее красивый получается. Отправил автору патчи, может, он придумает что-то еще лучше.

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

[Proton]

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

[osnwt]

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

Последнее

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

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

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

[EWAVR]

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

Не компилируется в tiny - модели: Error[Pa043]: the keyword "__near" is not available with the current settings

[osnwt]

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

Не компилируется в tiny - модели: Error[Pa043]: the keyword "__near" is not available with the current settings

Это для меня сюрприз, придется обходить по другому. Я проверял на меге32, но в tiny. Не хочется переделывать асмовский код, хотя не столь и сложно.

AT90S2313? Версия IAR?

[EWAVR]

Да, at90s2313. IAR AVR 4.12A, есть для проверки 4.11A и 3.20D.

Сообщение отредактировал EWAVR - Mar 20 2006, 16:33

[osnwt]

Да, действительно для AT90S2313 __tiny недоступно даже в виде исключения (документировано), вот не ожидал от IAR такой диверсии. Почему, спрашивается...

Самый простой workaround - это вот такой:

usbdrv.h:

Код

//extern unsigned usbCrc16(uchar *data, uchar len);
extern unsigned usbCrc16(unsigned dptr, uchar len);

//extern unsigned usbCrc16Append(uchar *data, uchar len);
extern unsigned usbCrc16Append(unsigned dptr, uchar len);

usbdrv.c:

Код

//  usbCrc16Append(&usbTxBuf1[1], len);
    usbCrc16Append((unsigned)(&usbTxBuf1[1]), len);

//      usbCrc16Append(usbTxBuf + 1, len);
        usbCrc16Append((unsigned)(usbTxBuf + 1), len);

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

Решение не самое красивое, но работоспособное. Безусловно, оптимальнее переписать ассемблерные функции для решения проблемы, но автор едва ли согласится делать это в официальной версии. Потому пока прошу лишь проверить работоспособность. Во всяком случае, всегда есть возможность так и оставить для личных целей.

[EWAVR]

Спасибо, все заработало( все так просто, сам мог бы догадаться!).
Далее я попробовам перенести в IAR свой прект на tiny26. В нем использутся прерывание от АЦП, и линкер выдал следующее:

Error[e16]: Segment INTVEC (size: 0x18 align: 0x1) is too long for segment definition. At least
0x4 more bytes needed. The problem occurred while processing the segment placement
command "-Z(CODE)INTVEC=0-(_..X_INTVEC_SIZE-1)", where at the moment of placement
the available memory ranges were "CODE:0-1,CODE:4-17"
Reserved ranges relevant to this placement:
CODE:0-1 ?FILL1
CODE:2-3 Absolute code from usbdrvasm
CODE:4-17 ?FILL2

Ассемблерный код нагло залез в сегмент INTVEC.
Разборки с директивами ассемблера показали, что в файле usbdrvasm.S в месте

ASEG
ORG INT0_vect + IVT_BASE_ADDRESS
rjmp SIG_INTERRUPT0

нужно поменять ASEG на COMMON INTVEC, тогда линкуется без проблем.

P.S. При переходе с gcc на IAR в проекте на tiny26 я выиграл аж 10 байт, так что овчинка выделки не стоила. Но все равно спасибо за помошь:-}

Сообщение отредактировал EWAVR - Mar 20 2006, 22:56

[osnwt]

нужно поменять ASEG на COMMON INTVEC, тогда линкуется без проблем.

Да, я тоже предпочел бы использовать INTVEC, но сразу как-то не проэкспериментировал, напоровшись на проблемы с ORG. Однозначно, что предложенный подход более грамотный.

IVT_BASE_ADDRESS появилась ради размещения драйвера в boot area для создания загрузчиков. В варианте с INTVEC эта часть снова уходит в небытие.

P.S. При переходе с gcc на IAR в проекте на tiny26 я выиграл аж 10 байт, так что овчинка выделки не стоила. Но все равно спасибо за помошь:-}

Но если замыкаться на IAR, то смысл в этом есть - появляется возможность разместить определенный код в мЕньшем устройстве. Остается лишь проблема, как красиво с минимумом правок решить проблему с передачей указателя. Ну что стоило поддержать __near для всех CPU...

[aleksey_g]

Уважаемые EWAVR & OSNWT
Ну поделитесь же Вашими портами PowerSwitch для ИАР_а
Ато читаю Вашу переписку, слюни текут!
У самого опыта еще нету.

[Rst7]

P.S. При переходе с gcc на IAR в проекте на tiny26 я выиграл аж 10 байт, так что овчинка выделки не стоила. Но все равно спасибо за помошь:-}

Но если замыкаться на IAR, то смысл в этом есть - появляется возможность разместить определенный код в мЕньшем устройстве. Остается лишь проблема, как красиво с минимумом правок решить проблему с передачей указателя. Ну что стоило поддержать __near для всех CPU...

Ох, господа, не надеялся я бы так на T26. Недавно писал про глюки со старшим байтом X, так вот действительно:

If you use

LD r16,X

then you can use XH (r27) to something else, if you use

LD r16, X+

XL is incremented and XH is reset. I can see that the description in the instruction set is a bit unclear, but you have to
believe me in that this is how it is desgined to work ( I double checked with the IC-designers) and that it is not a bug.

Это я от Atmel'а ответ получил...

Особенно убивает последняя фраза про то, что так задумано, а в описании комманд - немного ошибочно

Мне пришлось из-за этого ПРИНУДИТЕЛЬНО включить для T26 режим near, точнее выбрать в опциях проекта не конкретно проц, а модель -v1.

[aleksey_g]

Все! Откомпилил PowerSwitch в ИАР_е под ATMEGA8535 , слепил драйвера в LIBUSB-WIN32,
проинсталил, подключил, есть в системе устройство-PowerSwitch.

Теперь не могу (не знаю чем) скомпилить commandline/powerswitch.c
любые попытки - море ошибок.

Вижу, Вы достаточно опытные спецы, не расскажете ли как с этим девайсом
пообщаться из-под DELPHI5?

C IgorPlug (USBtoRS232) имею некотрый опыт.

[EWAVR]

Никаких проблем с компиляцией, недостающие файлы usb.h и libusb.lib берутся в дистрибутиве libusb-win32. Компилировал Borland C++ 5.5 из командной строки:
bcc32.exe powerswitch.c libusb.lib

Сообщение отредактировал EWAVR - Mar 22 2006, 16:07

[aleksey_g]

Нашел ВС++ 5.2 Установил. Скомпилил. 2 WARNING:

C:\...werSwitch.2006-03-14\commandline>bcc32.exe powerswitch.c libusb.lib
Borland C++ 5.2 for Win32 Copyright © 1993, 1997 Borland International
powerSwitch.c:
Warning powerSwitch.c 127: 'handle' is assigned a value that is never used in function main
Turbo Link Version 2.0.68.0 Copyright © 1993,1997 Borland International
Warning: Extern '_usb_busses' was not qualified with __import in module powerSwitch.c

Получил екзешник 61440 байт.
Подключил устройство.
на строку "powerSwitch on 0 2.5" получаю:
powerSwitch.exe - обнаружена ошибка. Приложение будет закрыто. Приносим извинения за неудобства.
(WINXP SP1 rus)

[osnwt]

Ну поделитесь же Вашими портами PowerSwitch для ИАР_а

Алексей, отправить PM не удалось, какая-то ерунда с сервером. Пишу тут.

К сожалению, я не занимался попытками полноценно скомпилировать PowerSwitch под IAR. Я просто раскрутил, закомментировал вотчдоги и т.п., проверил, что собирается в tiny, и стер.

Как я понял, проблема уже решена.

Насчет командной строки то же самое: я уже писал на форуме, что варианты под libusb мне не интересны на данном этапе, и примеры приложений obdev я не компилировал. Я использовал для своих целей основу из Automator, и собирал ее под VisualStudio 6. Но собралось оно не сразу, а я вообще переписал приличный кусок.

Так что готовыми решениями стандартных примеров не порадую, увы. Да и интереснее самому разобраться. А, главное, полезнее.

Удачи!

[aleksey_g]

Олег!
Ерунда с сервером похоже есть!
ERROR
The requested URL could not be retrieved

--------------------------------------------------------------------------------

While trying to retrieve the URL: http://electronix.ru/forum/index.php?

The following error was encountered:

Zero Sized Reply
Squid did not receive any data for this request

Но ко мне письма пришли, надеюсь к Вам тоже.

[EWAVR]

Подключил устройство.
на строку "powerSwitch on 0 2.5" получаю:
powerSwitch.exe - обнаружена ошибка. Приложение будет закрыто. Приносим извинения за неудобства.

Есть маленькая хитрость: выравнивание данных нужно включить по границе байта (data align=byte, ключ компиляции -a1 или -a-). Сам чуть не поседел, пока нашел. А command-line-only BC++ 5.5 можно скачать с сайта Borland.

Сообщение отредактировал EWAVR - Mar 23 2006, 19:10

[osnwt]

EWAVR,

если есть возможность, прошу проверить работоспособность экспериментальной версии порта USBDRV на аппаратном tiny контроллере (tiny26, 90s2313 или т.п.). Ссылка на порт в PM. Это приватный билд, его нет смысла хранить (тем более, в нем есть кое-что неучтенное). Если будет все нормально, то будет официальная версия с поддержкой tiny.

У меня оно работает и в small, и в tiny на ATmega32 (код отличается на 101 байт на очень малой программе), но на маленьких контроллерах не тестировал.

Особенности: необходимость определения регистров работы с прерываниями для разных контроллеров (см. файл usbconfig-prototype.h в конце). К сожалению, #ifdef в IAR не работает для SFR, потому придется явно задать нужные регистры. Что можно задать - можно посмотреть в коде usbdrv.h, где возможность определения уже учтена.

Просьба не распространять эту версию - если с ней проблем не будет, то на следующей неделе будет официальная на сайте.

Прошу сообщить результат по мере возможности, или если такой возможности нет - то тоже сообщить, чтобы передать автору.

[KA_ru]

EWAVR,

если есть возможность, прошу проверить работоспособность экспериментальной версии порта USBDRV на аппаратном tiny контроллере (tiny26, 90s2313 или т.п.). Ссылка на порт в PM. Это приватный билд, его нет смысла хранить (тем более, в нем есть кое-что неучтенное). Если будет все нормально, то будет официальная версия с поддержкой tiny.

У меня оно работает и в small, и в tiny на ATmega32 (код отличается на 101 байт на очень малой программе), но на маленьких контроллерах не тестировал.

Особенности: необходимость определения регистров работы с прерываниями для разных контроллеров (см. файл usbconfig-prototype.h в конце). К сожалению, #ifdef в IAR не работает для SFR, потому придется явно задать нужные регистры. Что можно задать - можно посмотреть в коде usbdrv.h, где возможность определения уже учтена.

Просьба не распространять эту версию - если с ней проблем не будет, то на следующей неделе будет официальная на сайте.

Прошу сообщить результат по мере возможности, или если такой возможности нет - то тоже сообщить, чтобы передать автору.

Добрый день.

возможно ли получить AVR-USB порт(Proj) for IAR
распространять не собираюсь.
мне для сына. как учебное пособие.
чтоб мог с чем сравнивать.
заранее спасибо.
я его уже STK500 снарядил.
самому интересно что у него выйдем.
утонет или сможет плавать.

Андрей.

ka_ru2003@msn.com

[lazycamel]

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

[osnwt]

возможно ли получить AVR-USB порт(Proj) for IAR
распространять не собираюсь.

Я писал про экспериментальную версию до ее официального появления. Сейчас она уже не актуальна, так как все предложенное вошло в состав официальной. Получить ее можно непосредственно с сайта автора obdev.at - там в проекте PowerSwitch всегда присутствует самая свежая версия драйвера.

В новой версии от 26.03 добавлена (исправлена) поддержка tiny модели памяти для IAR, добавлены опции для выбора регистров, связанных с используемым прерыванием без изменения кода драйвера, а также исправлено размещение вектора прерывания через COMMON INTVEC вместо ASEG (все доработки - с подачи EWAVR, за что ему спасибо).

Обращаю внимание, что в варианте с ASEG (предыдущая версия) обнаружилась серьезная проблема с размещением векторов при использовании дополнительных прерываний - вся таблица "съезжала". Потому настоятельно рекомендуется обновиться до текущей версии.

Насчет замены if на switch: вероятнее всего, это вполне возможно. Есть еще ряд мест, где можно было бы сэкономить. Я верю, что можно минимизировать размер кода драйвера до степени GCC, если не более. Но этим нужно заниматься. Для себя это сделать можно, но знаю точно, что особая оптимизация размера кода для IAR автора не беспокоит, и официальных изменений в этом направлении ждать почти бесполезно. Он вообще недоумевает, почему наши люди не используют бесплатный компилятор gcc...

Если же задаться целью существенно оптимизировать код драйвера, то самое оптимальное - это просто переписать часть C на ассемблер. Тогда бы можно было уложиться килобайта в 1.1-1.2, я думаю. Это было бы совсем хорошо, но я лично не готов этим заниматься. Тем более, что потом возникнет вопрос поддержки и обновления при внесении изменений в оригинал.

Сообщение отредактировал osnwt - Mar 29 2006, 07:03

[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]

EWAVR, опять глюки zero sized reply
PM получил?

[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 подкупает!

[aleksey_g]

Закончил управление Powerswitch_em на Дельфи.
http://www.obdev.at/products/avrusb/powerswitch.html
Для любителей. Может кому-то будет в пользу.
Реализовано все, что может авторский commandline.с
Необходим драйвер USBIO http://www.thesycon.de
Там в комплекте инсталятор драйвера на usb-устройства.
Исходники и откомпилированный проект.
DELPHI5.
Проверено на WINXPSP1_RUS
Из багов: Иногда долго закрывается. Причин не знаю. Может из-за демовости драйвера?

 DELPHI_SOURCE.zip ( 3.7 килобайт ) Кол-во скачиваний: 254

 exefile.zip ( 194.17 килобайт ) Кол-во скачиваний: 213

[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

[aleksey_g]

После некоторых танцев с бубном, удалось запустить проект http://www.xs4all.nl/~ynlmns/ ,
В котором реализована возможность работы через фришные libusb-win32-bin-0.1.8.0
http://prdownloads.sourceforge.net/libusb-...tar.gz?download

В самом проекте определяем тип type PByte=^byte;
После этого компилируется в IDE (WINAVR).
Берем сгенерированый инф-визардом из libusb-win32-device-bin-0.1.10.1 http://prdownloads.sourceforge.net/libusb-...tar.gz?download
INF-файл, в котором меняем все libusb0.sys на libusbfl.sys, прикладываем в этот же каталог
libusb0.dll и libusbfl.sys от версии libusb-win32-bin-0.1.8.0 и получаем пакет установки драйверов.
С этими драйверами уже работает USBTEST.EXE от http://www.xs4all.nl/~ynlmns/
Проблема была только в версии драйверов.
Теперь любители дельфей смогут свободно работать с Powerswitch_ем.

Вот готовые драйвера:  libusb_win32_bin_0.1.8.0.rar ( 28.16 килобайт ) Кол-во скачиваний: 277

[aleksey_g]

А вот и сама рулилка Powerswitch_ем. С исходниками под дельфи5.
Драйвера в прошлой мессаге.


 PROJEKT.zip ( 208.17 килобайт ) Кол-во скачиваний: 268

[aleksey_g]

Продолжаем "мучить Powerswitch"!

Теперь он может (на меге8535) измерять напряжение по 8 каналам.
Выполняет команду 4(вернуть напряжение) с параметром data(номер опрашиваемого канала 0..7)
Возврвщаемые данные (Code) (диапазон 0-1023) пропорциональны напряжению, приложенному
к входам ADC0-ADC7 микроконтроллера (см. дельфийский проект)
Опорным для ацп выбрано внешнее AREF.

Прилагается проект под ИАР[attachment=5124:attachment]
И проект под Дельфи5(в исходниках) [attachment=5126:attachment]

За оптимальность и "красоту" просьба ногами не пинать!
Драйвера выше.
Испытано на WINXPSP1_rus

[aleksey_g]

Продолжаем "мучить Powerswitch"!

Теперь он может (на меге8535) измерять напряжение по 8 каналам.
Выполняет команду 4(вернуть напряжение) с параметром data(номер опрашиваемого канала 0..7)
Возврвщаемые данные (Code) (диапазон 0-1023) пропорциональны напряжению, приложенному
к входам ADC0-ADC7 микроконтроллера (см. дельфийский проект)
Опорным для ацп выбрано внешнее AREF.

Прилагается проект под ИАР[attachment=5124:attachment]
И проект под Дельфи5(в исходниках) [attachment=5126:attachment]

За оптимальность и "красоту" просьба ногами не пинать!
Драйвера выше.
Испытано на WINXPSP1_rus


Извиняюсь за дубль (выше).
Опять глюки сервера (Zero Sized Reply)

Прилагается проект под ИАР  POWERSWITCH.rar ( 109.2 килобайт ) Кол-во скачиваний: 305

И проект под Дельфи5(в исходниках)  POWERSWITCHLIBUSB.rar ( 180.31 килобайт ) Кол-во скачиваний: 265

[aleksey_g]

При перекомпиляции Powerswitcha IAR_ом под мегу48 компилятор ругается:
Error[e16]: Segment TINY_Z (size: 0x16 align: 0) is too long for segment definition. At least 0x15 more bytes
needed. The problem occurred while processing the segment placement command
"-Z(DATA)TINY_I,TINY_Z,TINY_N=_..X_SRAM_BASE-_..X_SRAM_TEND", where at the moment of placement the available
memory ranges were "DATA:100-100"
Reserved ranges relevant to this placement:
DATA:100-100 TINY_I

Описание из iarcompat.h:
#ifndef USB_BUFFER_SECTION
# define USB_BUFFER_SECTION "TINY_Z" /* if user has not selected a named section */
#endif

При чем avr-gcc использует описание сегмента .dss и работает правильно.
Цитата из usbconfig-prototype.h
/* #define USB_BUFFER_SECTION ".bss" */
/* The USB receive buffer (variable "usbRxBuf") with a length of 22 bytes
* MUST NOT cross a 256 byte boundary. We have introduced this configuration
* option to allow you to change the data segment where this buffer is
* allocated. If you have problems with the default segment (start of .bss),
* you may change this setting. See the comment in usbdrv.h for details.
* On IAR C, the default is the TINY_Z segment (first 256 bytes). You must
* change this default for devices which don't have RAM below 0x100.
*/

Вопрос- Как описать этот сегмент, чтобы иар не ругался?

[osnwt]

Описание из iarcompat.h:
#ifndef USB_BUFFER_SECTION
# define USB_BUFFER_SECTION "TINY_Z" /* if user has not selected a named section */
#endif

Вопрос- Как описать этот сегмент, чтобы иар не ругался?

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

В ряде контроллеров RAM находится, начиная с адреса 0x100 (то есть, там TINY области, как таковой, нет вообще). Очевидно, что невозможно разместить буфер в области нулевой длины.

Решения два:

Поставить #define USB_BUFFER_SECTION "NEAR_Z" где-нибудь в usbconfig.h, чтобы явно заказать размещение в одном из существующих стандартных сегментов достаточной длины. При этом важно после линковки убедиться, что весь указанный буфер полностью размещен так, чтобы не пересекать и даже не касаться границы 256-байтной области, например, полностью лежать в пределах 0x100-0x1fe включительно (1ff уже не допустим, так как при инкременте будет изменен старший байт адреса).

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

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

[aleksey_g]

Решения два:

Поставить #define USB_BUFFER_SECTION "NEAR_Z" где-нибудь в usbconfig.h, чтобы явно заказать

явно описать свой собственный сегмент с явно заданными границами адресов, удовлетворяющими

С "NEAR_Z" не работает!
Мой вариант тоже.
Устройство через 5 раз определяется виндой, но работать отказывается.

Может не правильно понял?
скопировал lnkm48s.xcl в директорию проекта.
в нем описал свой сегмент -Z(DATA).bss=100-116 (с запвсом!)
.bss для совместимости с avr-gcc.
project/options/linker/config установил галку Override default.
Указал путь к своему lnkm48s.xcl
ИАР_ом компилируеися, но не работает. avr-gcc компилирует и устройство нормально работает.
Проект привел в такой вид, чтобы он мог компилироваться и иаром и avr-gcc

Где копать?

на всякий случай исходники  m48.rar ( 25.01 килобайт ) Кол-во скачиваний: 150

[osnwt]

#define TEST_DRIVER_SIZE

определенное в коде - это так и задумано? Так и работает? Чудеса...

В первом приближении причин не увидел. Попробуй пообщаться с EWAVR - у него проект в tiny под IAR заработал.

[aleksey_g]

#define TEST_DRIVER_SIZE

определенное в коде - это так и задумано? Так и работает? Чудеса...

Именно!
В авторском варианте при этом не компилится usbFunctionSetup с функциями, а только usbPoll();
я же туда добавил ECHO.
И работает!

[aleksey_g]

Для скачавших Powerswitchlibusb.rar, рекомендуется заменить в UNIT1.PAS строку
buffer:array[0..2] of byte; на buffer:array[0..1] of byte;
[0..2]-это излишество, да и работает более медленно.

[Георгий]

На базе драйвера разработал USB вольтметр (USB драйвер и сама программа свои, включено автоопределение подключения-отключения устройства), все прекрасно работает на компах с USB 1.1, но не работает на компах с USB2, устройство вообще не определяется компом? В чем могут быть грабли?

[Spider]

Ребят а не поможете создать джойстик? Я вот сижу и пытаюсь разобраться с HID. И не могу прикинуть как же всётаки объяснить сколько скнопок и прочего на джойстике.

[prottoss]

На базе драйвера разработал USB вольтметр (USB драйвер и сама программа свои, включено автоопределение подключения-отключения устройства), все прекрасно работает на компах с USB 1.1, но не работает на компах с USB2, устройство вообще не определяется компом? В чем могут быть грабли?

В смысле не определяет? вообще не видит, или говорит Unknown device? У меня прекрасно видится на любых версиях портов - пробовал на разных платах. ОСи пробовал 98/МЕ/2000/ХР

[osnwt]

Ребят а не поможете создать джойстик? Я вот сижу и пытаюсь разобраться с HID. И не могу прикинуть как же всётаки объяснить сколько скнопок и прочего на джойстике.

На 100% однозначно этого нигде нет - есть только документ с www.usb.org, описывающий структуру HID Report Descriptor (крайне поверхностно), а также утилита для генерации этих самых дескрипторов (лежит там же).

Самый простой вариант - найти дескриптор устройства, похожий на тот, что хочется сделать. И начать экспериментировать с ним.

Еще вариант - посмотреть, например, на проекты на странице http://obdev.at/products/avrusb/projects.html, реализующие SNES/NES gamepad to USB adapter и PPM RC to USB Interface на базе этого драйвера. Последний названный - это мой проект, реализующий просто джойстик и джойстик с кнопками для авиамодельных симуляторов. Наряду с декодером PPM сигнала в нем предусмотрено использование АЦП ATmega8 для реализации джойстика с 8-ю осями. Кнопки в версии с кнопками просто дублируют аналоговые каналы. После публикации оказалось, что этот вариант бесполезен, поскольку кнопки мешают калибровке осей в силу своей реализации. Но если их формировать не так, как там сделано, а путем чтения физических пинов портов, то все будет нормально.

Есть и другие подобные проекты в интернете, где можно подсмотреть структуру HID Report Descriptor.

[prottoss]

На 100% однозначно этого нигде нет - есть только документ с www.usb.org, описывающий структуру HID Report Descriptor (крайне поверхностно), а также утилита для генерации этих самых дескрипторов (лежит там же).

Кстати, по поводу дескрипторов и драйверов, раз уж встретились



Хотелось бы узнать про вот такую строчку в драйвере, при использовании устройства как USB CDC ACM class - что то она мне не внушает доверия, может поясните:

Код

if(intr3Status != 0 && usbInterruptIsReady3())
{
      static UCHAR serialStateNotification[10] = {0xa1, 0x20, 0, 0, 0, 0, 2, 0, 3, 0};
      if(intr3Status == 2)
             usbSetInterrupt3(serialStateNotification, 8);
      else
             usbSetInterrupt3(serialStateNotification+8, 2);
       intr3Status--;
}

Это отправляется на запрос SET_CONTROL_LINE_STATE... По идее (вернее по спецификации на USB CDC), устройство должно ответить нулевым пакетом...

[osnwt]

Кстати, по поводу дескрипторов и драйверов, раз уж встретились
Хотелось бы узнать про вот такую строчку в драйвере, при использовании устройства как USB CDC ACM class

Если вопрос ко мне, то увы, не подскажу. Я не игрался (пока?) с CDC. Потому вопросов, с этим связанных, не изучал. Может, кто-то другой подскажет чего.

[prottoss]

Кстати, по поводу дескрипторов и драйверов, раз уж встретились
Хотелось бы узнать про вот такую строчку в драйвере, при использовании устройства как USB CDC ACM class

Если вопрос ко мне, то увы, не подскажу. Я не игрался (пока?) с CDC. Потому вопросов, с этим связанных, не изучал. Может, кто-то другой подскажет чего.

Да не лично к Вам, конечно, НО, раз уж вы лично переписываетесь с автором такого замечательного драйвера, то могли бы ему сказать о данном вопросе. Я, честно говоря, не придавал значения этим строчкам, пока не стал отлаживать более "серъезный" USB девайс, тоже прикидывающий ся CDC ACM. SET_CONTROL_LINE_STATE не требует ответа...

Это описанно в файле usbcdc11.pdf стр.69. 6.2.14.SetControlLineState

[osnwt]

Да не лично к Вам, конечно, НО, раз уж вы лично переписываетесь с автором такого замечательного драйвера, то могли бы ему сказать о данном вопросе.

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

Автор без проблем общается со всеми. Кроме того, с недавних пор на его сайте запущена phpBB, где есть форум по AVR USB драйверу и проектам на его основе. Автор там регулярно отвечает на вопросы. Я полагаю, что самое оптимальное - это задать вопрос там.

[prottoss]

Да не лично к Вам, конечно, НО, раз уж вы лично переписываетесь с автором такого замечательного драйвера, то могли бы ему сказать о данном вопросе.

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

Автор без проблем общается со всеми. Кроме того, с недавних пор на его сайте запущена phpBB, где есть форум по AVR USB драйверу и проектам на его основе. Автор там регулярно отвечает на вопросы. Я полагаю, что самое оптимальное - это задать вопрос там.

Хорошо

[Георгий]

На базе драйвера разработал USB вольтметр (USB драйвер и сама программа свои, включено автоопределение подключения-отключения устройства), все прекрасно работает на компах с USB 1.1, но не работает на компах с USB2, устройство вообще не определяется компом? В чем могут быть грабли?

В смысле не определяет? вообще не видит, или говорит Unknown device? У меня прекрасно видится на любых версиях портов - пробовал на разных платах. ОСи пробовал 98/МЕ/2000/ХР

Говорит Unknown device.

Ребят а не поможете создать джойстик? Я вот сижу и пытаюсь разобраться с HID. И не могу прикинуть как же всётаки объяснить сколько скнопок и прочего на джойстике.

В инете был прекрасный проект джойстика на Мега8 с HID устройством MJoy. Я по нему в свое время разбирался с хидами, он на асме, но комментировано достаточно хорошо было, понять все можно. Я хиды бросил, достаточно один раз написать драйвер USB, потом уже по аналогии за 5 минут драйвер пишется. А возможностей гораздо больше, чем с обезличенным ХИД устройством.

[prottoss]

На базе драйвера разработал USB вольтметр (USB драйвер и сама программа свои, включено автоопределение подключения-отключения устройства), все прекрасно работает на компах с USB 1.1, но не работает на компах с USB2, устройство вообще не определяется компом? В чем могут быть грабли?

В смысле не определяет? вообще не видит, или говорит Unknown device? У меня прекрасно видится на любых версиях портов - пробовал на разных платах. ОСи пробовал 98/МЕ/2000/ХР

Говорит Unknown device.

Скорее всего, что то "не совсем правильно" с дескрипторами. Я бы попробовал отследить протокол общения с помощью вот этой программульки. Только не спрашивайте, как с ней работать , раз с драйвером AVR разобрались, с ней и подавно. После каждой транзакции слева показывает код ошибки - если отличен от нуля - устройство сушит весла

Прикрепленные файлы

 SnoopyPro_0.22.zip ( 291.41 килобайт ) Кол-во скачиваний: 203

 

[Георгий]

Скорее всего, что то "не совсем правильно" с дескрипторами. Я бы попробовал отследить протокол общения с помощью вот этой программульки. Только не спрашивайте, как с ней работать , раз с драйвером AVR разобрались, с ней и подавно. После каждой транзакции слева показывает код ошибки - если отличен от нуля - устройство сушит весла

С дескрипторами вряд ли, ассемблерный вариант с этими дескрипторами работает на всех машинах.
За программульку спасибо, вечерком попробую.

[Георгий]

Попробовал программульку на работе, удобная штучка, разбираться там особо не с чем, это обычный драйвер-фильтр, врезаемый в стэк драйверов. Тут только два вопроса - где взять расшифровку кодов ошибок и самое главное, программа снифит уже установленные устройства. А если мое устройство не определяется, то соответственно не загрузится и драйвер. Что же будет снифиться в этом случае?

[prottoss]

Попробовал программульку на работе, удобная штучка, разбираться там особо не с чем, это обычный драйвер-фильтр, врезаемый в стэк драйверов. Тут только два вопроса - где взять расшифровку кодов ошибок и самое главное, программа снифит уже установленные устройства. А если мое устройство не определяется, то соответственно не загрузится и драйвер. Что же будет снифиться в этом случае?

Про расшифровку кодов я не знаю, может Билли Гей тс знает , bus драйвер егошний))), а по поводу что же будет сниффить - то и будет, что появится... VID и PID вам же известен? В списке устройств (в программе, которую я положил выше) Ваш девайс же есть? так на него и тыкайте

[Георгий]

Насколько я помню, вид и пид с устройства не брались вообще, т.е. до считывания дескрипторов дело не доходило в принципе.
Если драйвер дяди Билла, то скорей всего коды ошибок стандартные виндусовские, надо будет сравнить.

Сообщение отредактировал Георгий - Jan 22 2007, 12:47

[prottoss]

Насколько я помню, вид и пид с устройства не брались вообще, т.е. до считывания дескрипторов дело не доходило в принципе.
Если драйвер дяди Билла, то скорей всего коды ошибок стандартные виндусовские, надо будет сравнить.

Как так? В любом случае, как только устройство определилось на шине, начинается считывание дескриптора устройства, привожу последовательность, стандартную для ОС Windows 98/ME/2000/XP etc:

A common Windows enumeration involves the following steps,
1. The host or hub detects the connection of a new device via the device's pull up resistors on the
data pair. The host waits for at least 100ms allowing for the plug to be inserted fully and for power
to stabilise on the device.
2. Host issues a reset placing the device is the default state. The device may now respond to the
default address zero.
3. The MS Windows host asks for the first 64 bytes of the Device Descriptor.
4. After receiving the first 8 bytes of the Device Descriptor, it immediately issues another bus reset.
5. The host now issues a Set Address command, placing the device in the addressed state.
6. The host asks for the entire 18 bytes of the Device Descriptor.
7. It then asks for 9 bytes of the Configuration Descriptor to determine the overall size.
8. The host asks for 255 bytes of the Configuration Descriptor.
9. Host asks for any String Descriptors if they were specified.

Это из usb-in-nutshell

[Георгий]

Если просто прицепить резистор 1,5 ком между D- b питанием получим тот же эффект. Вся сложность в том и состоит, что до получения конфигурации дело не доходит.
Мне больше грешится на несоблюдение времени первоначального сброса, возможно у USB1.1 оно менее критично, чем у USB2.0.

[prottoss]

Если просто прицепить резистор 1,5 ком между D- b питанием получим тот же эффект. Вся сложность в том и состоит, что до получения конфигурации дело не доходит.
Мне больше грешится на несоблюдение времени первоначального сброса, возможно у USB1.1 оно менее критично, чем у USB2.0.

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

[Георгий]

Так меня и интересует, в каком месте он может грешить при USB2.0 и быть невинным при USB1.1. Проверял на 4 компах. На асмовском варианте (типа Igor Cesko) такого не было.

[prottoss]

Так меня и интересует, в каком месте он может грешить при USB2.0 и быть невинным при USB1.1. Проверял на 4 компах. На асмовском варианте (типа Igor Cesko) такого не было.

Кстати, а можно увидеть входные цепи USB? Я имею ввиду схему подключения МК к хосту...

И еще, я бы рекомендовал пользоваться отладочными сообщениями через USART - хотя бы было бы видно чего хост шлет девайсу. Даже если просто прицепить резистор к хосту, хост обязан послать запрос дескриптора девайса устройству

[BSVi]

Добрый день. Пытаюсь скомпилировать этот драйвер под IAR. Получаю ошибку.

Error[e46]: Undefined external "usbCrc16Append(unsigned int, unsigned char)" referred in usbdrv ( F:\BSVi\_projects\MalleusInter2\iar\Debug\Obj\usbdrv.r90 )

Борюсь с ней уже почти день, никак не могу победить. К этой функции есть два обращения, оба в usbdrv.c
Одно на строке 240 в функции usbGenericSetInterrupt
второе на строке 536 в функции usbCrc16Append
так вот - если закомментировать второе обращение, линкер функцию находит! Если закомментировать первое - то ошибка остается.

Может есть какие-нибуть идеи на этот счет.

Сообщение отредактировал BSVi - Oct 27 2009, 21:37

[BSVi]

Проблема решена установкой в каждом .h файле макросов

#ifdef __cplusplus
extern "C" {
#endif


...


#ifdef __cplusplus
}
#endif