Search in topic

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

Права не нарушаются, и код опубликован не будет. А нездоровое качание прав может привести только к бану на форуме.

Позиция странная, но понятная мне - ведь на этом форуме запрещенны обсуждения использования нелицензионного ПО.

Копия лицензии (или хотя бы ссылка на нее) должна быть в ДИСТРИБУТИВЕ, а не на каком-то сайте. В конечном счете можно просто не заметить, то что человек хотел выпустить в общий доступ свое творение, а просто взять и пренебречь этим.

а не на каком-то сайте сайт также является произведение АВТОРА и все то что он выкладывает туда подпадает под действие GPL - и он сообщает об этом.

А вообще мне непонятна Ваша позиция - что так скрывать эти исходники? Раз уж Вы выложили все схемы. Я лишь интересуюсь ими по одной простой причине - мне хотелось бы добавить туда поддержку обработки PCM протокола.

Народ, чего бодаетесь? Сказано-же было, вылизаная версия будет идти как коммерческий продукт. Авторам совсем не улыбается дать шанс комуто вылизать и коммерциализировать свое детище.
Исходников хочется - у чехов посмотреть можно. Отличие в номере порта и лишней кнопке. Ну это не суть критично. Разберетесь.
ссылка на проект чехов на 1ой или 2ой странице.

Кстати, а если кому нужно еще и каналы переназначать прямо из винды - то вот посмотрите на это www.cattopasto.com - правда схема на PIC16 зато с готовым USB.

Я лишь интересуюсь ими по одной простой причине - мне хотелось бы добавить туда поддержку обработки PCM протокола.

Настоятельно не рекомендую с этим связываться. Программная реализация USB отжирает практически все ресурсы контроллера. Параллельная работа обработчика USB и декодера РСМ может просто оказаться невозможной.

Настоятельно не рекомендую с этим связываться. Параллельная работа обработчика USB и декодера РСМ может просто оказаться невозможной.

Так вот и хотелось бы это проверить. Мы по-моему все здесь собрались для того чтобы эксперементировать, не так ли? 😊 Есть еще несколько идей которые хотелось бы реализовать. А Вы к сожалению лишаете такой возможности. 😕

Так вот и хотелось бы это проверить. Мы по-моему все здесь собрались для того чтобы эксперементировать, не так ли? 😊 Есть еще несколько идей которые хотелось бы реализовать. А Вы к сожалению лишаете такой возможности. 😕

Экспериментируйте на здоровье. У Вас есть исходники прототипов. Если у Вас достаточно квалификации, чтобы написать декодер РСМ и заставить его работать одновременно с обработчиком USB, то привинтить одно к другому Вы сможете без труда. Декодеры РРМ и РСМ никак между собой не связаны и отсутствие у Вас наших исходников никоим образом не является препятствием в таком эксперименте.

Вопрос с исходниками закрыт.

Так вот и хотелось бы это проверить.

Так в чем проблема-то? Ссылка на оригинальный проект есть. Берете, делаете. Если вы в состоянии реализовать декодер pcm, то довести до нужного состояния оригинальный исходник - пара пустяков…

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

Я так понимаю они собираются еще это использовать в коммерческих целях - вообще ужас.

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

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

Так Вы все же признаете, что с лицензированием у Вас не все чисто?

Так Вы все же признаете, что с лицензированием у Вас не все чисто?

Извините, но это у Вас в голове не все чисто. Не надо путать авторские права и GPL. GPL и коммерческое использование не связаны НИКАК.
Все права на прототипы принадлежат их авторам и коммерческое использование запрещено авторами. Коммерческое использование нашего устройства также запрещено. Решение о публикации исходников мы вправе принимать любое, т.к. прототипы не подпадают под условия GPL. Если Вы с этим не согласны - жалуйтесь в FSF, но рекомендую предварительно еще раз изучить документ, на к-рый я ранее указал.

В последний раз прошу Вас прекратить крючкотворство. Лучше сделайте что-нибудь сами и опубликуйте.

Извините, но это у Вас в голове не все чисто
…
Не надо путать авторские права и GPL.
Можно узнать где я спутал два этих понятия?

прототипы не подпадают под условия GPL
Как раз в условия попадают, а значит и на все, что созданно на их основе.
“0. Настоящее Соглашение распространияет свое действие на любую программу или другое произведение, которое содержит данное правообладателем уведомление о том, что ее (его) использование осуществляется на основании Открытого лицензионного соглашения GNU.”

жалуйтесь в FSF
Может еще в спортлото отошлете - там уж я точно правду найду.

В последний раз прошу Вас прекратить крючкотворство
“Крючкотворством” занимаетесь Вы - выдумывая способы обойти Лицензию.

Я очень симпатизирую сообществу OpenSource и поэтому Ваши “шаманства” с лицензированием вызывают во мне искренее недовольство.

alkot, его вы добиваетесь-то? текстов программ вы все равно не получите. 😃 скорее vad64 спишется с автором и получит от него “эксклюзивные права”, а именно разрешение не давать вам лично никаких своих исходников. 😃 а позаимствованный из оригинального проекта код - да сколько угодно! 😁

Я очень симпатизирую сообществу OpenSource и поэтому Ваши “шаманства” с лицензированием вызывают во мне искренее недовольство.

Бесплатный сыр только в мышеловке. И достается он _второй_ мышке. Вы тянете пока тоьлко на первую. На ту самую, которой вместо сыра достанется по горбушке.
Умейте ценить чужую собственность и права на неё. Будьте благодарны за представленный готовый продукт. Хочется большего - родите свое. Захотите поделится плодами своего труда - честь вам и хвала. Кстати, тот-же Миндаугас не торопится выкладывать исходники на MJoy16. готовую прошивку, схему - велком, а вот исходники - увольте. Может, сначала там покачаете сомнительные права?
Все, заканчиваем флуд и оффтопик. Хочется потрещать неочем - есть для этого официальная сральня - www.udaff.com

Мы по-моему все здесь собрались для того чтобы эксперементировать, не так ли?.. А Вы к сожалению лишаете такой возможности. 😕

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

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

Исходник версии на меге8 последнего доступен и открыт (хотя проект получил развитие на меге16 с уже закрытыми исходниками в сторону расширения числа линий ввода-вывода - используется пилотами “взрослых” самолетных симуляторов). Текст прекрасно прокомментирован, поддержка USB и HID вынесена отдельно и сопровождается инструкциями автора по модификации дескрипторов (для изменения параметров обнаруживаемого устройства по части кнопок, хаток и ручек). Заменить фрагмент чтения АЦП на чтение значений таймера через Input Capture - элементарная задача пары часов для того, кто способен заняться более-менее серьезными экспериментами с кодом (не считаю таковыми правку имени устройства или Vendor ID).

Так что я лично не пойму предмета разговора. Если это - вопросы сугубо копирайта - то их стоит обсуждать не в этом форуме. Если это - невозможность провести эксперименты, то это не так. Все ссылки есть, и дописано в конкретной прошивке по отношению к первоисточникам, в принципе, совсем немного: маппинг каналов в NVRAM. Так что никто не мешает экспериментировать. Например, перенести код в небольшой 8-ножный чип (2 ноги - питание, 2 кварц, 2 USB, 1 вход PPM/PCM, 1 выход на светодиод, например, как индикатор наличия сигнала с передатчика при подключенном устройстве.

Это было бы более рациональным применением усилий, IMHO 😃

PS. Сам вчера завел литовский джойстик, сегодня займусь модификациями прошивки для своих задач.

(не считаю таковыми правку имени устройства или Vendor ID).

Подскажите чайнику где в Atmega8 эти самые имя и Vendor ID?

Подскажите чайнику где в Atmega8 эти самые имя и Vendor ID?

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

Они не в атмеге, а в исходных текстах USB-драйвера.

Что-то вы путаете. Все эти параметры сообщает само устройство в дескрипторах. Драйвер USB лишь расшифровывает дескрипторы. Если мы говорим о джойстиках (тем более о том, про который статья), то все это - устройства HID, которые сами о себе все сообщают. С другими USB девайсами ситуация может быть другой.

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

Если не находят, то или ставят стандартный для HID (если устройство сделано под HID), или просят указать, где брать драйвер.

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

Что-то вы путаете. Все эти параметры сообщает само устройство в дескрипторах. Драйвер 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-устройств. Почему так сделали - не знаю.

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

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