Search in topic

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

Что-то вы путаете. Все эти параметры сообщает само устройство в дескрипторах. Драйвер USB лишь расшифровывает дескрипторы.

Уточню на всякий случай, что я рассматриваю устройство, собранное на ATmegaXX не как черный ящик, а как микроконтроллер, работающий по своей программе. Соответственно, с этой стороны тоже имеет место USB драйвер (программно реализующий поддержку интерфейса, так как аппаратного там на самом деле нет), и приложение, управляющее работой этого драйвера. И дескрипторы (см. ниже).

Следовательно и все что к usb относится находится в прошивке, включая самый низкий уровень взаимодействия с usb хостом и более высокие уровни, включая самый верхний - hid.

Собственно, я это почти дословно и сказал: что VID находится не в меге (как железке), а в “исходных текстах USB-драйвера”, который после компиляции, конечно же, находится внутри меги, но более конкретно - это часть ее прошивки, а не принадлежность кристалла.

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

Чтобы устройство опозналось как HID оно обязано сообщить о себе “я устройство HID”, передав соответствующие HID-дескрипторы. Просто абстрактное USB устройство никогда не опознается драйвером HID.

Похоже, моя фраза была прочитана не очень внимательно. Читаем еще раз вместе:

vid/pid… сообщаются виндам при подключении, и те уже потом ищут в своей базе подходящий драйвер. Если не находят, то или ставят стандартный для HID (если устройство сделано под HID), или просят указать, где брать драйвер.

Имелось в виду следующее:

1. при подключении устройство определяется как USB устройство, сообщает свои vid/pid и прочую информацию (это написано).
2. по vid/pid Windows ищут в базе драйвер конкретного устройства, если таковой присутствует в системе. Если он найден, то он будет использован (это тоже написано).
3. если специфического драйвера для конкретного устройства с заданным vid/pid в системе нет, то Windows пытается установить универсальный драйвер для класса устройств, к которому отнесло себя устройство в своем дескрипторе. Это может быть HID (Human Interface Devices), это может быть MSD (Mass Storage Device - пресловутые USB-диски, например), и т.п.
4. Если устройство не относится к стандартным классам, то тогда будет востребован драйвер производителя.

Если прочитать выделенное мною сейчас, то понятно, что речи не шло об абстрактном устройстве с драйверами Windows под HID. Речь шла о HID устройстве (о чем говорит замечание в скобках). А еще о том, что при наличии драйвера конкретного (vid/pid) устройства он всегда имеет более высокий приоритет, чем драйвер универсальный. Приходилось получать от Windwos сообщение типа “Найден более подходящий драйвер для данного устройства”? Вот это оно и есть.

Говоря же о приоритете установки драйверов, приведу пример адаптера из Reflex. Это HID устройство, которое ставится в Windows и работает прекрасно, как стандартный HID, и пишется про него как HID-совместимый USB девайс. Но если поставить драйвер из состава симулятора (правда, в частном случае это всего лишь способ переименовать устройство в панели управления), то стандартное устройство будет использовать в данном случае название - REFLEX RC USB Device, а в общем оно может использовать свой специфический драйвер вместо предоставленного Windows. А может работать поверх предоставленного Windows, подставляя свои фильтры. И т.п. Вариантов множество.

Отвечая, я не ставил задачи излагать взаимодействие устройств максимально подробно и максимально формально - это не форум разработчиков USB девайсов, потому такие беседы лучше вести в другом месте. Но поверьте: я прекрасно представляю взаимодействие всех уровней обмена со всех сторон, так как электроникой и системным программированием под embedded системы занимаюсь уже лет 20. И прежде, чем получить свой работоспособный вариант подобного устройства, кстати, на 70% написанный на C (ассемблерные только time-critical участки, весь application layer, включая десприпторы - C), я перечитал не одну спецификацию c usb.org, включая HID1_11.pdf, Hut1_12.pdf, hidpar.pdf, pid1_01.pdf (не считая популярных книжек типа usb-in-a-nutshell.pdf). А потому представляю, для чего нужен каждый байт кода (исключая только самый нижний уровень, так как это уже отлаженная часть, которая поменяется только вместе со стандартом). Просто нужно ли все это тут? Место ли этому здесь?

В общем, спорить не стану (особенно с членом группы модераторов 😃 ). Мой девайс прекрасно работает, и делался он не с наскока, а с пониманием. Править байтики и гадать, от чего не работает - я так не умею. Да и никому не советую. RTFM полезен. Да и не то место тут - обсуждать особенности реализации USB. Тут народ летает большей частью, чем firmware пишет 😉

Соответственно, с этой стороны тоже имеет место USB драйвер (программно реализующий поддержку интерфейса, так как аппаратного там на самом деле нет), и приложение, управляющее работой этого драйвера.

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

А еще о том, что при наличии драйвера конкретного (vid/pid) устройства он всегда имеет более высокий приоритет, чем драйвер универсальный.

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

Это HID устройство, которое ставится в Windows и работает прекрасно, как стандартный HID, и пишется про него как HID-совместимый USB девайс.

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

В общем, спорить не стану (особенно с членом группы модераторов 😃

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

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

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

Драйверы 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 Пахомов]

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

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

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

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