Search in topic

usb-адаптер для передатчика

Путаница в терминологии. Вы называете это “драйвером”, хотя это по сути библиотека.

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

Драйверы Windows к этому отношение имеют лишь косвенное. Там понятие драйвера трактуется слишком широко. Драйвером называют даже простейший inf файл, который не является таковым, а служит для управления работой некоего системного драйвера.

А библиотека - это метод организации кода в многократно используемую единицу в разных проектах. Тем более, что то, в каком виде оно присутствует, библиотекой назвать язык не поворачивается. Не структурировано, не документировано, практически, не подлежит сопровождению. Но, правда, работает 😃

Я так понял, что вы говорите о драйверах со стороны хоста.

Я тоже так понял, что вы так поняли 😃 Отсюда и оговорка первой строчкой ответа о том, что имелись в виду драйверы со стороны контроллера.

Да, это так. Но только если они, по мнению windows, оба подходят.

Именно так.

Название самого устройства (в частности, если это именно HID) тоже присутствует. Следовательно, если мы говорим о HID, то все что надо там есть.

Но не все так просто. HID устройство (да и не HID тоже) при первом подключении говорит о себе, как оно называется, может сообщить производителя, серийный номер и т.п. Но после установки стандартного драйвера HID со стороны Windows эта информация скрывается, и ее можно увидеть лишь в свойствах. Например, размещение - Remote Controller. Но в панели стоит не Remote Controller, а HID-совместимое устройство. Если это джойстик, то будет вторая строка - стандартный игровой манипулятор (или что-то в том духе - точно не помню, под рукой нет). В панели игровых манипуляторов при этом будет или MJoy (на Windows Server 2003), или просто “игровой джойстик с X осями и Y кнопками” (на XP). Более того, Windows кеширует эту фигню. Найдя один раз джойстик с 8 осями и 24 кнопками, винда запоминает это (показывая в панели игровых манипуляторов), и потом без смены vid/pid поменять это не удается. Делаешь 2 оси, включаешь - в панели джойстиков по прежнему будет 8, хотя нажатие на него для проверки или калибровки показывает фактическое количество осей. Удалить его из панели джойстиков невозможно (используйте Device Manager). Удалить из последнего можно, потом устройство будет находиться заново. Но в панели игровых устройств оно по прежнему предстанет как 8-осевое. Удалить кэш из реестра тоже не получается - эта область защищена.

В общем, есть где повеселиться. При всем этом предоставление inf-файла, подобного рефлексовскому, реально переименовывает устройство в Device Manager. Теперь это уже не HID-совместимое устройство, а конкретно названное. Вот цитата на эту тему из еще одной статьи:

Менеджер устройств ОС Windows использует .inf файлы, чтобы решить, какой драйвер назначить найденному устройству. HID устройство может использовать встроенный в OS .inf файл для HID (hiddev.inf для Windfows 98 и input.inf для Windows 2000), альтернативно, Вы можете использовать свой собственный .inf файл, в котором находятся ваши VID и PID. Преимущество собственного .inf файла состоит в том, что Вы можете включить в файл описание устройства и имя изготовителя, которые появятся на Панели Управления вместо общего термина “Стандартное Устройство”.

Впрочем, ничто не мешает нам написать свой драйвер, который будет сообщать другое имя (или подставлять его, вместо пустого). Равно как и драйвер, который будет вообще полностью эмулировать девайс.

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

Я не спорил, я лишь попытался уточнить.

Да я, собственно, тоже 😛

Удалить его из панели джойстиков невозможно (используйте Device Manager). Удалить из последнего можно, потом устройство будет находиться заново. Но в панели игровых устройств оно по прежнему предстанет как 8-осевое. Удалить кэш из реестра тоже не получается - эта область защищена.

Достаточно в регедите удалить ключ HKLM\SYSTEM\CurrentControlSet\Enum\USB\Vid_xxxx&Pid_xxxx
Если ругается, то нужно просто в меню “Разрешения” задать полный доступ к разделу USB и его подразделам. А то при отладке замучаешься VIDы PIDы менять.

Да, я тоже так подумал, что надо просто вместо regedit пользовать regedt32 для установки разрешений, но сильно не доставало, и пока оставил эту тему.

Обычно когда я что-то пишу, или отлаживаю, или изучаю чужой код в познавательных целях 😃, я делаю это внутри виртуальных машин VMware, где можно за пару секунд откатить состояние системы назад. Для USB это тоже работает, но не очень удобно. Потому плюнул на это и стал ставить на основную машину. Менять пиды-виды для устновки - не только задолбает, но и систему загадит 😊

А с виртуалками стало совсем удобно после того, как NuMega SoftICE стал поддерживать экранный драйвер виртуальной машины. Можно делать двухмашинные конфигурации с программой в одном месте, интерфейсом отладчика в другом. И все это - не затрагивая хоста. Очень неплохо. Связь между машинами - или по tcp/ip, или через виртуальные комы. Но это уже совсем другая тема.

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

Суть драйвера - модульность. То есть возможность работы с разными устройствами по стандартному интерфейсу без перекомпиляции самого приложения. В нашем конкретном случае все компилируется в единый и неделимый модуль. С таким же успехом можно называть функции вывода на экран “драйвером ЖКИ”, функции генерации писков разной тональности пищалки “звуковым драйвером” и так далее. 😃

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

Не имеет значения как это показывается в виндах. Важно лишь то, что получает приложение которое работает с этим устройством через setupapi и hidapi. Через hidapi оно получает именно то, что сообщает о себе само устройство.

Суть драйвера - модульность. То есть возможность работы с разными устройствами по стандартному интерфейсу без перекомпиляции самого приложения.

Слова “без перекомпиляции самого приложения”, пожалуй, лишние, хотя часто это именно так. Возможно, это многим не авторитет, но смотрим в Wiki:

Операционная система управляет некоторым «виртуальным устройством», которое понимает стандартный набор команд. Драйвер переводит эти команды в команды, которые понимает непосредственно устройство. Эта идеология называется «абстрагирование от аппаратного обеспечения».

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

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

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

В нашем конкретном случае все компилируется в единый и неделимый модуль.

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

С таким же успехом можно называть функции вывода на экран “драйвером ЖКИ”

Можно посмеяться, но ведь так это и называется у разработчиков embedded устройств. Стоит взять любую библиотечку функций, например, бесплатную avrlib, в которой смотрим:

/*! \file ata.c \brief IDE-ATA hard disk interface driver. */

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

/*! \file lcd.c \brief Character LCD driver for HD44780/SED1278 displays. */
/*! \file ks0108.c \brief Graphic LCD driver for HD61202/KS0108 displays. */

А в коммерческой аналогичной библиотеке исходники строятся по принципу: один файл с интерфейсом, и десяток файлов с конкретными (да-да) драйверами разных типов контроллеров LCD.

Самое интересное: неужели действительно кто-то полагает, что файлы lcd.c и ks0108.c буду присутствовать в одной системе? Скорее, там будет или символьный дисплей, или графический. И это будет единым неделимым модулем в составе прошивки. Лишает ли это права называть набор функций управления конкретным типом дисплея, абстрагирующим основной код от аппаратуры, драйвером? Вероятно, нет.

функции генерации писков разной тональности пищалки “звуковым драйвером” и так далее. 😃

/*! \file uart.c \brief UART driver with buffer support. */

Тут также может быть вариант без буфера с тем же интерфейсом. И в коде будет или тот, или иной, но не оба вместе.

Если это не разбросанные по всему коду приложения функции, а собранные в одном месте, связанные друг с другом по смыслу, управляющие одним аппаратным устройством, то почему бы и не назвать? Тем более, что все так и называют 😃

Заблуждение в том, что если похожих по назначению устройств и работающих с ними кусков кода много, то это будут драйверы (особенно, если они загружаются, а не собраны в единую неделимую прошивку). А вот если такое же устройство (пока?) всего одно, то точно тому же куску почему-то отказано в праве называться драйвером. Как-то не очень логично.

Разговор перешел на идеологическую тему 😃. Это, может, и интересно, только времени отнимает немеряно. Так что я согласен, пусть я даже буду неправ 😃. В конце концов, как не назови этот кусок кода - он все равно будет выполнять свои функции.

Не имеет значения как это показывается в виндах. Важно лишь то, что получает приложение которое работает с этим устройством через setupapi и hidapi. Через hidapi оно получает именно то, что сообщает о себе само устройство.

Смотря к чему. Если это сказано к вопросу о том, можно ли в принципе приложению прочитать название устройства - то да, можно. Если к тому, о чем шла речь - как это устройство показывается в Windows для обычного пользователя, а не девелопера, со стандартными HID драйверами - то тогда нельзя. Может, стандартный драйвер не использует какие-либо доступные функции - не знаю. Но вот некоторым известным симуляторам, к примеру, использующим стандартный HID-драйвер Windows для своих адаптеров, и не использующих никаких DirectInput API или HID API, совершенно пофигу, какие там функции стандартный виндовый драйвер использует. Они видят устройство по VID/PID, и работают с ними на уровне ReadFile, читая байты репорта, но даже не заглядывая в ReportDescriptor (зная, что там заведомо лежит). Ну, а пользователь без установки inf-файла про это даже не подозревает, но видит “стандартное устройство”. А для красоты можно поставить .inf и увидеть, что это супер-пупер-мега-девайс 😃

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

Они видят устройство по VID/PID, и работают с ними на уровне ReadFile, читая байты репорта, но даже не заглядывая в ReportDescriptor (зная, что там заведомо лежит).

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

ps: Хотите называть драйвером - называйте. Но тогда поясняйте какой “драйвер USB” вы имеете в виду, их как минимум два по вашей терминологии. Я лично предпочитаю называть драйвером компоненты какой бы то ни было операционной стстемы. Считаете прошивку операционной системой? Ваше право.

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

Говорим о разном. Я о том, что видно в Windows без драйверов про HID-устройство, и можно ли как-то добиться отображения собственного названия без написания .inf. Ну а Вы - о чем-то ином.

ps: Хотите называть драйвером - называйте. Но тогда поясняйте какой “драйвер USB” вы имеете в виду, их как минимум два по вашей терминологии.

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

Я лично предпочитаю называть драйвером компоненты какой бы то ни было операционной стстемы.

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

Если бы Вы были ембеддерщиком, то Ваше понимание драйверов бы соответстовало моему. У меня же оно таково, поскольку я начинал работать с компьютерами, которые занимали целый зал, и там была очень тесная связь с аппаратным обеспечением. По сути, это было близко к современным embedded системам. О динамическом подключении устройств типа нынешнего USB тогда даже и не мечтали. Это просто классическое понимаение драйвера.

Считаете прошивку операционной системой? Ваше право.

Я всего лишь привел цитату из онлайновой энциклопедии, которую не имел права править или дополнять. Не всякую прошивку можно считать операционной системой. Но неоспоримым фактом является то, что во многих прошивках используются т.н. RTOS - Real-Time Operating Systems, операционные системы реального времени. В том числе и на AVR таких существует больше десятка. То, что данные RTOS работают в составе единого неделимого кода прошивки, опять же не лишает их права называться RTOS. Или Вы и в этом готовы усомниться (утверждая, что операционных систем внутри прошивок не существует, поскольку это неделимый код)? Ссылки приводить, или не нужно? Впрочем, вот первый же поиск дал такую ссылку. На деле их крайне много, несколько десятков. Вот еще одна… Я использую в своих устройствах третью… И т.д.

PS. Вы - не embedded system programmer, не так ли?

Господа!
Я конечно сильно извиняюсь, но с обсуждением статьи о USB-Aдаптере Ваше мерянье у кого кунфу круче и партбилет краснее имхо ничего общего уже не имеет.

С уважением

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

Программистам нравится слово “драйвер”. “Я написал аудиодрайвер” звучит гораздо солиднее чем “я написал библиотечку для пищалки”.

Предлагаю вынести наши сообщения из этой темы в отдельную тему в курилке.

PS. Вы - не embedded system programmer, не так ли?

Я не занимаюсь программированием embedded систем в настоящее время. Я не занимался этим давно.

Я могу считать себя embedded system programmer’ом, потому что я в свое время делал embedded систему на vxWorks. Для радиолокации. Успешно, работает. Всякую мелочь вроде программирования контроллеров для нужд rc не рассматриваем.

Предлагаю вынести наши сообщения из этой темы в отдельную тему в курилке.

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

К АВТОРАМ!
Спасибо за разработку!!!
Все завелось с пол-оборота.
Только стабилизатор применил LP2951 SOIC-
Выставил 3.3 V -и ура , опозналось сразу как VJoy.
Потом поменял местами каналы 1и2 в EEPROM и успешно летаю-
а то руль высоты и элероны были наоборот( может
задумка такая?)-прошил версию USB_PPM_V3.
Передатчик JR8103 - поставил резистор 62 ком от источника
+5В на базу транзистора входного формирователя как указывалось
выше в сообщ №98.
Программировал STK-200- изготовил и использую давно.
С уважением.

Про предметную благодарность авторам.
Не так давно мой знакомец содеял между городами такую штуку.
Ему надо было передать 200 рублей за рег код из города в город.
В одном городе в море киосков покупается телефонная карточка какого-либо
Транснационального Сотового Гиганта, и активируется на телефон (Вад64 в данном случае)
того же Транснационального Сотового Гиганта в другом городе.
При небольших объемах денег - пользователям мелочь, а автору приятно.
Ну или в ЛС автору код карты высылать - главное знать, какую карту купить.
Вад64 - как на счет продвинутой версии прошивки лично мне ?
Вот думаю просто кабелёк такой спаять …

Привет всем,в электронике разбираюсь фигово,но руки растут из правильного места. Есть несколько вопросов. Пока ещё ничего не приобрёл,но первым хочу преобрести передатчик, чтобы подключать к симу поначалу. Таквот, 1)схема,приведённая в статье является окончательным вариантом?(я видел на форуме высказывания,что что-то куда-то нужно добавлять,чтобы всё работало) 2)Куда именно подключать эти 2 входа,которые Tx ppm, Tx gnd.? 3) Что такое DA1? 4)и кто-нибудь уже нарисовал печатку ? 5)На картинке vkb.sukhoi.ru/elektron/mjoy/avrisp.gif всего 5 контактов выхода. А на х2 6 😃 На картинке есть земля,и на х2 есть земля, куда какую подключать,и куда подевался ещё 1 контакт?(vcc) 😃 заранее спасибо.

1)схема рабочая.
2)подключать эти 2 входа,которые Tx ppm, Tx gnd - к тренерскому разъему передатчика.
3) Что такое DA1 - лень смотреть схему, но наверно стабилизатор на 3.3 вольта
4)и кто-нибудь уже нарисовал печатку ? - где-то тут пробегала, но зачем она? Все на макетке собирается, обвязки то по сути нет…
5)На картинке vkb.sukhoi.ru/elektron/mjoy/avrisp.gif всего 5 контактов выхода. А на х2 6 😃 На картинке есть земля,и на х2 есть земля, куда какую подключать,и куда подевался ещё 1 контакт?(vcc) 😃

• 1контакт- это питание. в приведенной картинке его никуда подключать не надо, просто воткни усб шнур в комп и он от него питаться будет.

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

существует ли технология управления передатчиком от компа,через USB,тоесть сигналы должны поступать с компа(USB-) на передатчик а уже от него по радиоканалу на автомодель.

За автомодель не скажу, так как мало какие автомодельные передатчики имеют разъем тренер-ученик. Вообще, такие есть? Чтобы был не только выход на симулятор, но и вход с ученического передатчика?

С практической точки зрения, это малоприменимо. Управлять моделью с компа занятие довольно сомнительное. Но в теории, это возможно.

C авиа проще. Для этого надо сделать “кабель наоборот”. То есть программа на компьютере записывает в USB устройство данные. Это USB устройство формирует ppm-посылку и отправляет в передатчик через тот же разъем тренер-ученик, только комп в данном случае выступает не как “тренер” а как “ученик”. На некоторых передатчиках придется при этом держать все время нажатой кнопку “тренер”.

На практике, я не слышал, чтобы кто-то занимался подобной фигней.

[team Пахомов]

Поверь мне таких изврашенцев много)уже есть примеры управления через сом порт.
И не обязательно иметь на передатчике разъём тренер - ученик.Почему бы всё это дело к микросхеме сразу не подвести)Тока надо знать чё куда припаивать)

Вопрос не совсем по теме статьи. Продолжите пожалуйста в более подходящем разделе.

Вопрос не совсем по теме статьи. Продолжите пожалуйста в более подходящем разделе.

а в каком это разделе обсуждают? 😒

Приветствую!
❓ Возникли проблемы с работой устройства.
Собрал,прошил yаap-ом,при включении адаптера к usb появляется девайс vjoy.
Когда включаю аппаратуру, то почти все оси в свойствах джоя скачут как ненормальные, т.е о калибровке не может быть и речи. В симе соответственно тоже. Аппаратура Sanwa VG 6000, операционка XP, симулятор G2. Если кто сталкивался с подобной проблемой,прошу подсказать как поправить это досадное положение. 😕

Аппаратуру в PPM режим переключите.