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

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

Решения два:

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

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

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

С "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

Где копать?

на всякий случай исходникиНажмите для просмотра прикрепленного файла

#define TEST_DRIVER_SIZE

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

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

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

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

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

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

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

На 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.

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



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



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

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

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

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

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

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

Хорошо

Говорит Unknown device.


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

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

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

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

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

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

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

Это из usb-in-nutshell

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

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

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

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

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

Добрый день. Пытаюсь скомпилировать этот драйвер под 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
так вот - если закомментировать второе обращение, линкер функцию находит! Если закомментировать первое - то ошибка остается.

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

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

#ifdef __cplusplus
extern "C" {
#endif


...


#ifdef __cplusplus
}
#endif