После некоторых танцев с бубном, удалось запустить проект 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

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


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

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

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

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

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

Продолжаем "мучить 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

При перекомпиляции 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.
*/

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

Буфер для приема данных должен быть размещен так, чтобы не пересекать границу 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

Где копать?

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

#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), устройство должно ответить нулевым пакетом...