Простейший код HID. Везде только слова, мыши и джойстики...

Кто нибудь может привести простейший код HID для CodeVision. Перелопатил кучу информации, но реализовать так и не смог. Все статьи по HID делятся на 2 типа:
1. Джойстик, мышь, клавиатура (это классика, перепечатываемая по 100 раз).
2. Термометр и т.д. (без исх. кодов или хрен пойми как реализованные)

Запустить это тоже не получилось. Откомпилировал код http://microsin.ru/Download.cnt/avr/avr-usb-russian.rar (avr-usb-russian\examples\hid-custom-rq\firmware). Прочитал "разработка устройства USB - как начать работу с библиотекой AVR USB" от microsin. Собрал схему (как рекомендуют)

Proteus. Через 4 секунды работы - ошибка. Одна. Не показывает какая и останавливается. Примеры из папки Samples Протеуса (работа с USB HID) работают. Устройство определяется. Видно в Диспетчере устройств. И управляется программой (.ехе файл). Светодиоды зажигаются. Но там контроллер уже с USB, впрочем как и в книге Агурова - читал, мне не помогло.

Помогите разобраться пожалуйсто. Только не надо ссылок (я там везде был). Везде одно и то же. Ругани тоже не надо.

Задача проста: Устройство. Подключаем к компьютеру (USB). Оно определилось как HID. Готово к работе. На компьютере программа с 1 кнопкой. (вкл/выкл). Т.е. (как я понимаю), нашли наше устройство по ID и т.д. отправили какой нибудь байт. Если пришел этот байт - включить светодиод, пришел ещё раз выключить. Всё. Вместо диода потом будет подключена схема управления нагрузкой 220 В.

Везде только общие слова. Типа воспользуемся этим и т.д. Может кто то может привести КОД простейшего HID? Или объяснить поподробней. Буду очень признателен.

Код:: PROGMEM char usbHidReportDescriptor[22] = { /* дескриптор репорта USB */ 0x06, 0x00, 0xff, // USAGE_PAGE (Generic Desktop) 0x09, 0x01, // USAGE (Vendor Usage 1) 0xa1, 0x01, // COLLECTION (Application) 0x15, 0x00, // LOGICAL_MINIMUM (0) 0x26, 0xff, 0x00, // LOGICAL_MAXIMUM (255) 0x75, 0x08, // REPORT_SIZE (8) 0x95, 0x80, // REPORT_COUNT (128) 0x09, 0x00, // USAGE (Undefined) 0xb2, 0x02, 0x01, // FEATURE (Data,Var,Abs,Buf) 0xc0 // END_COLLECTION }; /* Поскольку мы задали только один feature-репорт, мы не используем идентификаторы * report-ID (которые должны быть в первом байте репорта). Весь репорт состоит из 128 * opaque байт данных. */

0x75, 0x08, // REPORT_SIZE ( 8 )
0x95, 0x80, // REPORT_COUNT (128)

Я так понимаю мне надо:
Размер элемента данных 1
Число элементов 1

0x75, 0x01, // REPORT_SIZE (1)
0x95, 0x01, // REPORT_COUNT (1)

А что такое 0х75 и 0х95 ?

В голове просто каша.

Причем если просто подключаю usbconfig.h и ещё куча всего к CodeVision - не компилируется. Я думаю это из-за того что не настоены порты, не определен контроллер при компиляции. Это же всё в так называемом make файле, а как всё это CodeVision задать не соображу.

P.S. не ругайте строго, просто очень хочется чтобы заработало то что задумал. Пусть даже до конца код не пойму.

тема оч заинтересовала. к сожалению помочь не могу, сам в этом не силен. будет интересно почитать ответы.
спсибо за тему,mr_smit

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

протеус тебе не дает 100% гарантию работы
тем более с таким наслоением, как усб
у меня вон в юарт выводит мусор, а ты хочеш усб

собери реальный девайс

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

Просто удивительно, неужели мне первому в голову пришла такая идея??? Не верю. Встроенный USB интерфейс это конечно хорошо, но все его возможности не используются на 100% (для HID). Просто смотришь на это http://radiokot.ru/circuit/digital/pcmod/16/ и диву даёшься. Элементарный контроллер. Каким образом автор компилировал проект??? Из его описания и исходников это вообще не ясно. Ну ладно, раз никто не знает.

на CodeVision это дело не скомпилишь никак, т. к. основной код работы с USB на асьме, а как это дело цеплять к CodeVision - x3. Раньше сам пользовал CV, но очень много мороки с переводом исходников avrstudio и IAR. Как компилил? чтото не вкурю а в чем вопрос?[/b]

Автор не приводит в исходниках hex файл для контроллера. То что он предлагает скачать - там есть папка cdcmega, в ней cdcmega.hex, но насколько я понимаю из названия это cdc, а не HID, да и размер 12 КВ, извините, но у нас в распоряжении только 4 КВ (ATTiny45). Как то это настораживает.

Наверное плохо искал:
http://www.obdev.at/products/vusb/projects.html

тут этих клав с джойстиками и термометрами завались.
Пробывал, получалось. Единственное что не понял, как передать данные этому HID устройству (клава, допустим, умеет принимать данные для инициализации и всякого рода засвечивания светодиодов). Там об этом ни слова. Только выход. А жаль.

По протеусу сразу скажу - даже не пытайся. Элемент "USB" заточен только под ПИК и только с аппаратным USB. Проверено.

Правильно подсказывают - собери и будет работать.
Хотя, возьми проект USB программатора на АВР, для тех-же АВР , может легче разбираться будет. :))

mr_smit писал(а):1. Просто удивительно, неужели мне первому в голову пришла такая идея??? Не верю.

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

mr_smit писал(а):Встроенный USB интерфейс это конечно хорошо, но все его возможности не используются на 100%

А контроллеры существуют вовсе не для того, чтобы использовать их на сколько-то процентов, как правило, задачи формулируются совершенно иначе. И, кстати, ограничения на затраченное время занимают в постановке задачи не последнее место. Я потому так и спросил: сотворение протокола на коленке - это самоцель или нет?

Прошу заметить ! Если вы хотите эксперементировать с USB - по тои схеме как у вас: то Proteus в данном случае - враг !

Не совсем конечно, но всёже...
Поясняю - сделаная вами схема - ни что иное - как Програмный USB - а этого не предусмотрено. Proteus может работать с USB только через железную симуляцию в контроллере! Т.е. в контроллере железное USB = эмулированное USB устроиство в ПК... С параметрами что вы записываете в регистры контролеера отвечающие за тот самый USB.
Proteus не делает анализа временых диаграм дергания ног контроллера и подстановку их под стандарт USB или хотябы анализ диаграмы, вделения из этого USB пакета и внесения его в виртуальное устр-во. Всего этого НЕТ! И врятли будет :))

Вывод - берём макетку - и всё на неё ! Всё работает как надо ! Если хотите углубится - берём USB sniffer - анализатор / перехватчик пакетов приходящих на USB ПК , помогает для изучения, анализа и поиска ошибок.
С уважением Pe3...

сотворение протокола на коленке - это самоцель или нет?

Самоцель это сделать устройство. Учитывая что судя по всему это возможно (таким способом). На выходных посижу, постараюсь спаять. Единственное не купил кварц на 16 МГц. Зашел сегодня в ВольтМастер - кварцев вообще нет. Вот думаю поставить на 8 МГц (у меня есть). Надеюсь заработает.

mr_smit писал(а):Автор не приводит в исходниках hex файл для контроллера. То что он предлагает скачать - там есть папка cdcmega, в ней cdcmega.hex, но насколько я понимаю из названия это cdc, а не HID

Вы ошибаетесь! название cdcmega.hex осталось от тестов и отладки на меге, т.к. за основу я взял проект cdc и примеры avrusb. Сами посудите, если все работает, зачем что-то менять? (это насчет названий файлов)

да и размер 12 КВ, извините, но у нас в распоряжении только 4 КВ (ATTiny45). Как то это настораживает.

Размер hex файла и размер памяти - разные вещи! Эта прошива нормально влезает в tiny45, у меня же поместилась!

mr_smit писал(а):Самоцель это сделать устройство.

Я так и думал - в большинстве случаев всё же именно так и есть.

Тогда позволю себе предложить такие рассуждения:
1. USB шина - не резиновая, 128 устройств всего, а на "морде лица" компа (ну, не только на морде

) количество разъемов и того меньше. Поэтому врядли имеет смысл к каждому выключателю (ведь именно о нем шла речь?) цеплять свой интерфейс к USB-гнезду компа, на мой взгляд, разумнее прицепить к компу м/к'шный контроллер (вот он - по USB!) а уж от него разводить управление к тинькам, которые "обжигают горшки" - включают/выключают нагрузку, что-то измеряют, куда-то сообщают и так далее. И если так, то контроллер можно коннектить с ПК с помощью моста USB/UART (FTDI, CP) - это и быстрее (ничего не нужно программировать в м/к), и ресурсы м/к не затрагивает, и наконец (в случае legacy устройств) - позволяет не менять софт, если таковой к ним существовал в COM-инкарнации. Скажем, так делали USB-редакции программаторов - в ПК'шной софтине просто выбирали виртуальный COM-порт, а дальше все работало также, как и до перехода с COM на USB.

Я и не собирался на один USB сажать 1 выключатель. Лучше уж подключать всё к контроллеру, а уже контроллер к ПК через USB.

Что бы это могло означать:

mr_smit писал(а):Я и не собирался на один USB сажать 1 выключатель.

Ну, как ты написал, так я и понял

:

mr_smit писал(а):Устройство. Подключаем к компьютеру (USB). Оно определилось как HID. ... потом будет подключена схема управления нагрузкой 220 В.

mr_smit писал(а):... подключать всё к контроллеру, а уже контроллер к ПК через USB.

Да, только я бы предпочел возложить задачу отработки протокола на мост USB/UART по причинам уже изложенным выше.

Собрал простой программатор:

И проект, чтобы его протестировать:

WinAVR не хочет прошивать, CodeVision тоже. Что не так?

Убрал галочку Check Signature, нажал Yes

Не работает. :cry:

И WinAVR и CodeVision пишут что то про сигнатуру. Это что такое?

UniProF

Главное при запуске не ругается и распознает контроллер. (если отключить от LPT, то ругается)

А при прошивке питание нужно подавать на контроллер? Я делаю так: подключаю к LPT -> пытаюсь прошить. Отключаю. Подключаю питание (5 В взял с USB)

Yellow Tiger писал(а):И если так, то контроллер можно коннектить с ПК с помощью моста USB/UART (FTDI, CP) - это и быстрее (ничего не нужно программировать в м/к), и ресурсы м/к не затрагивает, и наконец (в случае legacy устройств) - позволяет не менять софт, если таковой к ним существовал в COM-инкарнации. Скажем, так делали USB-редакции программаторов - в ПК'шной софтине просто выбирали виртуальный COM-порт, а дальше все работало также, как и до перехода с COM на USB.

Оно так, но в масштабах рынка - кому нужны эти программаторы?
И CP и FTDI требуют установки драйверов. Если нужно взять от USB 300-400мА тока а коммуникация вторична, то альтернативе HID не видно. Софт, если он нужен (для обновления прошивки, например) написать иногда проще с нуля для HID и забить на любое legacy, учитывая удешевление hardware и, главное, отсутствие драйверов для конечного юзера.
Аппаратных удобных мостов для HID я не знаю.

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

Советую взять удлинитель LPT и уже от него 10-15см шнурок до МК.