Activity

Если проблемы с топливом наверное есть смысл взять вертолёт 30-го класса, потом его можно будет переделать в 50-ку.

Да, видимо, так. Проблем с топливом, как таковых, особо нет. Просто второе такое увлечение (в дополнение к парапланам с постоянными разъездами по летным местам) бюджет уже вытянет с трудом 😃 Потому хотелось понять, есть ли смысл и возможность тут сэкономить. Потому что на всем остальном (аппаратура, мотор и т.п.) экономить явно нельзя - слишком велика цена отказа.

Стабильность подкупила или - мощность ?

Мощность тоже, но в первую очередь - стабильность при отличной управляемости.

Я как-то ранее (пол годика назад примерно) написал тут, что JK и на ТиРексике летает дай дорогу.

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

Подержав в руках управление 50-м Раптором (после 36-й Валкеры, за что огромная благодарность уважаемому Nadaske), начал всерьез подумывать о ДВС-ном верте.

Вопрос такой: реально ли и насколько целесообразно пытаться поставить бензиновый двигатель на вертолет 50-го (60-го, 90-го) класса? Идея такая: поучиться в более спокойном полете на бензине, а потом перейти на калилку. Смысл: пока без 3д, особой мощности не нужно, а нужен налет. Бензин может (а может и нет?) выйти экономнее.

Какие соображения? Буду рад услышать мнение опытных товарищей. Ставят ли вообще бензиновые движки на верты класса ниже 90-го? Сколько стоят?

При прочих равных условиях насколько целесообразнее (если так) брать, скажем, 60-ку, а не 30-ку или 50-ку? Или большой разницы в поведении не будет на стадии обучения? Цель же - пилотаж. От петель и до… докуда денег хватит на ремонты 😃

Блин, было бы неплохо помечать в имени файла где сорсы, а где бинарники ибо описалово читать долго, а в поисках альтернативной опенсорс прошивки накачал архивов, в хесов там нету. А где есть, так вроде ниже написано, что она нерабочая.

К сожалению, если “описалово читать долго”, то помочь мало чем могу.
Ибо, в описалове было написано, что скомпилированная прошивка (а то и несколько в разных вариантах) находится в каждом архиве с исходниками, в подкаталоге Release/EXE. Файл *.a90 - это обычный hex. Его можно переименовать, а можно шить и прямо так. Отдельного файла только с hex не публиковалось с момента выкладывания первого исходника, так как размер и так смешной, а первой целью было выкладывание именно исходников для экспериментов и модификаций заинтересованными людьми, и только потом - собственно, прошивки. А если исходники не нужны, то есть оригинальная прошивка, которая вполне работоспособна.

А подскажите в чем проблема - не убрать газ полностью, 3-й канал. WinXP. Раньше со шнурком на COM порт таких проблем не было, а теперь никак не остановиться. А в остальном все нормально. При калибровке все нормально показывает - столбик от нуля до полного заполнения.

Если столбик от нуля до 100%, то, возможно, есть смысл проверить калибровку в самом симуляторе. У меня была подобная проблема (которая отложила публикацию на довольно большой срок): не работала пара каналов в AFPD. В джойстике все нормально, а в симе по нулям. Но я им не пользовался и поставил только для проверки работы устройства. Сваливал на дескрипторы и т.п. Но так как было не слишком нужно - не возился. И только потом дошло, что в нем есть своя калибровка. И тогда неработающие каналы нашлись и заработали. Возможно, это поможет.

Я так понял, что полярность сигнала по барабану? у меня на входе транзистора нет просто рез на 10к стоит.

Да.

Не понял. PIC18F2550 стоит в розницу $5,74, итого себестоимость комплектухи со всей обвязкой - $10-15. В каком месте ужасаться?

ATMEGA8-16AU 1.376 $ (MT-System, СПб, розница от 1 шт.).

Ужасаться, может, и не стоит. Но разница - цена аппаратного USB, который, конечно, вещь приятная, но насколько оно потребно в данном применении - вопрос субъективный.

Последнюю прошивку залил вполне нормально работает, только когда ручками шевелишь почемуто кнопки мигают (когда в виндах смотришь)

Так и быть должно, поскольку кнопки просто дублируют состояния каналов. Если канал меньше 50%, то кнопка выключена (погашена). Если больше 50%, то включена (светится).

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

По поводу независимых от каналов кнопок (был такой вопрос): сделать их управление от клавиатуры проблематично, так как это повлечет за собой свой драйвер на Windows. А вот сделать их зависимыми от кнопок, подключенных к Mega8 - это очень просто. Достаточно один раз при инициализации прошивки включить pull-up резисторы на соответствующих пинах (куда подключить кнопки), а потом читать состояние этих битов, укладывать их в байт и вставлять его при формировании HID Report вместо сравнения каналов с 50%. Это легко сделать самому - на то и открытые исходники.

EMS-ом из Венгрии

Поправка: авиапочтой. Но суть в том, что при этом стоимость доставки таможней учтена не была, хотя посылка была вскрыта, просмотрена и опечатана их лентой с надписью о досмотре со вскрытием. Видимо, для авиапочты это катит. А вот DHL с таможней мне все нервы вымотала со своей оценкой стоимости доставки по нашим ценам (в 2.9 раза выше реально заплаченного). Напомню, что по украинским правилам стоимость доставки входит в таможенную стоимость груза, а пошлина+НДС берутся не с суммы превышения 200 евро, а с полной. То есть, 199 евро - без пошлины. 201 евро - с полной стоимости.

Не факт, что в следующий раз прокатит и таможня не увидит. Говорят, что не более 200 евро, но интересно бы глянуть на сам документ, подтверждающий это.

Будучи украинским дилером бразильской компании по производству парапланерного снаряжения, пришлось столкнуться с этим вопросом. Поднял документы любимого правительства. Там конкретно указано, что для неделимых грузов (про делимые не написано) таможенная стоимость, не облагаемая налогом, составляет для физических лиц 200 евро. Но при одном условии: доставка почтой, авиапочтой или ускоренной почтой (EMS). Все прочие экспресс-службы доставки облагаются даже при оценке в 1 доллар (что и пришлось в полной мере огрести при получении посылки с запчастями к верту из Китая, отправленной fedex-ом). Важное дополнение: в таможенную стоимость входит стоимость доставки! Если она не указана в инвойсе, то будет предоставлена экспресс-службой, и при этом может отличаться в направлении “оттуда” и “туда” в 2-3 раза при оплате с той стороны или с нашей. Правда, я получал товар EMS-ом из Венгрии, отправленный как подарок, с суммой оценки 215 долларов (без доставки) - получил на почте без проблем.

компайлера нет а ссылка в доку на демо качает полную версию.

Это не совсем демо - это на самом деле полная eva*luation версия, отличающаяся от retail только отсутствием исходников библиотек. Если ее скачивать через сайт после регистрации (ни к чему не обязывающей), то на указанный email присылают 30-дневную лицензию, позволяющую протестировать пакет без каких-либо ограничений. Если скачать ее по прямой ссылке, то без лицензии запустить продукт не получится, но в определенном смысле эта проблема решаема. Например, путем покупки лицензии. Ну, или поиска в интернете, или т.п.

Что касаемо вертолетного девайса из соседнего поста : в задаче два-три уровня напряжения, которые надо мерить относительно друг друга с точностью 0,01-0,02 В. АЦП потянет?

В AVR 10-битный АЦП. При внешнем смещении уровня операционниками вполне реально.

А проблесковый девайс для оценки состояния аккумулятора был сделан лет десять назад, когда это было актуально для ДВС-ных вертолетов с механическим гироскопом.

Никто не претендует на оригинальность. Просто решение из разряда недорогих. А народ до сих пор механические мекшеры кое-где обсуждает 😃

У меня на Торе стоит регулятор ЖВСный с отсечкой на 5(?)вольт. Под никель в общем. Когда ставлю на неё литиевый, летаю с опаской и ограничиваюсь по времени. Акк. конечно используется не полностью. 😦

Смотри соседнюю тему 😃 Я как раз на этот случай сделал только что девайс. Отсечку он не обеспечивает (рассчитан на установку на вертолете, где цена неожиданного отключения выше), но визуально показывает статус батареи.

По сути, если выкинуть входы управления, то запросто повеситься на балансирный разъем и мерять все три банки (или даже 4, если выкинуть также один из светодиодов). Только вот эксперименты что-то проводить ломает.

А я такой путь ещё ни разу в жизни не прошёл - из новостей на ентом пути - только покупка струйника R220 способного лоток для CD заглатывать, а у него размеры вполне подходящие/достойные.
Но однако - ещё идти и идти, одно изучение проги разводки чего стоит…

В моем варианте достаточно любого струйника или лазерника. Я печатал на каком-то Epson. При печати на пленке не нужно способности печатать на твердом листе (CD). Хотя в последнем варианте можно попробовать прямую печать на фольгу без фоторезиста (если пигментные чернила).

А насчет программы разводки - мне не хотелось морочиться с PCAD/ORCAD и т.п. монстрами для данной платы (я долго вообще думал, сделать ее на макетке или все же развести). Потом взял любимый многими SprintLayout4… Это примитивная программа, рассчитанная на ручную разводку, но с готовыми примитивами типа площадок, инструмента прокладки дорожек и библиотеки корпусов. Ее изучение у меня заняло вместе с разводкой несколько часов параллельно с переключением на основную работу. Рекомендую для простых вещей.

А печать на пленке, вырезание платки, наклейка при свете неонки пленочного фоторезиста, экспонирование, проявка, травление и пайка с проверкой заняли еще часа 4, из которых больше всего неприятного времени ушло на вырезание платки из стеклотекстолита ввиду малости ее размеров. Так что в этом процессе, по моему, главное - это иметь негативный пленочный (не аэрозоль) фоторезист (я использовал Riston-215 от Du-Pont) и правильный проявитель к нему (Na2CO3 0.85% раствор - пробовал другим подручным материалом - результаты намного хуже)

Ниже прицеплено описание моего самого первого опыта изготовления платы - сразу с шагом 0.5мм и толщиной дорожек 0.3мм. Многие вещи подтверждены - надо прикатывать пленку утюгом и использовать нормальный проявитель. Не претендую на правильность технологии - это лишь описание первой попытки. Но, может, кому-то будет интересно. Во всяком случае, даже для такой мелкой платки из SMD компонентов изготовление PCB уже оправдывает себя. И в руках держать приятнее, и сопли проводами разводить не нужно.

Изготовление PCB - описание первой попытки:

DataSheet на негативный пленочный фоторезист Rison-215:

Плата в SprintLayout под резисторы 0805 - мелочь, а приятно 😃

Вот схема автомобильного амперметра “без шунта”. Собрал, поставил на машину - работает.

Принцип понятен вполне (шунтом является кусок провода). Более того, у многих AVR есть режим дифференциального входа АЦП с программируемым усилителем. Так что вполне реально это все померять. Надо просто экспериментировать.

Видел где-то такое решение - измеряется разность напряжений на “положительном” проводе питания регулятора

Решение нормальное, есть только два минуса:

1. сопротивление этого участка нужно точно измерять, чтобы потом откалибровать измеритель (или калибровать по фактическим токам).
2. сопротивление проводов стараются сделать как можно меньше, чтобы снизить потери на проводах. При правильном проводе там будет такое малое падение, что измерить его будет уже сложнее.

Более красивое решение - специальные датчики тока на эффекте Холла или что-то подобное. Но они не слишком дешевые.

Реализовано все это (пока в виртуальном виде - надо платку спаять) на одном контроллере AVR

А вот и реальное решение, выполненное на скорую руку (SprintLayout -> негатив на струйнике -> фоторезист -> плата):

Позволю себе продублировать пару/тройку скачанных из Инета разрядных графиков для лития - места много не займёт…

Спасибо, картинки действительно интересные. Хорошо видно, что 11 вольт, пожалуй, многовато для начала моргания - 10 будет ближе к истине, а вот насколько хватит после того - зависит от многих факторов, включая разрядный ток и тип батареи.

Интеллект делать в таком устройстве не хочется, так как чтобы мерять такие разрадные токи… Вообще говоря, есть мысли интегрировать эту функциональность в контроллер двигателя - там ток все равно меряется, и статистика разряда может быть накоплена. Но пока сойдет и так, как есть. Только пределы подобрать надо под конкретный экземпляр батареи. Вчера собрал на макетике - симулятор не подвел, работает, как доктор прописал 😃 Буду ставить на верт и на летающее крыло. Последнее - прикольная летающая тарелка будет в свете луны в динамике у Черного моря 😉

Только что написал на скорую руку прикольный прибамбас на ATtiny15L для своего вертика Walkera #36 (точнее, написал прошивку и проверил в работе на симуляторе, а железо еще не собрал).

Мигалка на двух сверхярких светодиодах с углом обзора 120 градусов (сверху и снизу вертолета), выполняющая роль монитора батареи и бортовых огней.

Основная функция: как только напряжение упадет ниже определенного порога (например, до 11 вольт при 12.6 исходно), оба светодиода начинают синхронно вспыхивать. Частота вспышек увеличивается до почти непрерывного горения при дальнейшем падении напряжения до другого предела (скажем, 9 вольт - уже критический порог). При снижении до третьего предела (скажем, 8.5) устройство все гасит и уходит в режим powerdown, потребляя микроамперы (чтобы не убить батарею, если забыли выключить).

При обдумывании, чем занять устройство во время полета, и при воспоминании о свободном 5-м канале приемника на #36 и тумблере на пульте захотелось задействовать его. Так появилась вторая функция той же схемы - режим моргающих поочередно (как на самолетах) навигационных огней. С передатчика можно переключать режим “включено-выключено”. При включенном идут поочередные вспышки по принципу “верх-пауза-низ-пауза”. Если же свободного канала передатчика нет, то можно принудительно включить этот режим, поставив перемычку на схеме.

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

Реализовано все это (пока в виртуальном виде - надо платку спаять) на одном контроллере AVR ATtiny15L (8 ног корпус), стабилизаторе 5v (если всегда использовать с управлением от приемника, то питать можно от него) и двух светодиодах, управляемых ключами на полевых транзисторах (мои светодиоды кушают по 40 mA штатно, зато их видно отлично даже днем).

Мне интерес представляло написать софт для этого контроллера, не имеющего оперативной памяти и не поддерживаемого поэтому большинством компиляторов C. На ассемблере бы можно было написать все несколько быстрее, но мне было интересно опробовать компилятор ImageСraft ICCtiny, рассчитанный как раз на контроллеры AVR без SRAM. Энное время ушло на то, чтобы уяснить пару особенностей компилятора для написания более эффективного кода (путем изучения кода генерируемого) и нахождение бага компилятора. Зато эксперимент удался, и в симуляторе Proteus данная схема работает в реальном масштабе времени.

Собственно, вопрос: какие есть смысл установить параметры питания батареи для 3-cell LiPo батареи? В макете поставил пока так:

// Battery voltage levels
#define BATTERY_RECOVERY			11.2	// battery recovery level
#define BATTERY_LOW				 11.0	// battery discharge level
#define BATTERY_CRYTICAL			9.0	 // crytical battery level
#define BATTERY_POWERDOWN		   8.5	 // powerdown level

Может, кто-то подскажет по своему опыту, как лучше подстроить эти пределы?

1. 2006.07.13 - работает но почти все каналы дергаются

By design. Это уже обсуждали. Хотя у некоторых работает без дрыгов, но это просто удачный USB хост. Причина выявлена. Считать прошивку устаревшей.

2. 2006.07.20 - не работает (и в игровых устройствах ее нет)

То, что нет в устройствах - странно. Должно просто не работать (у большинства) чтение PPM сигнала. Считать прошивку нерабочей.

3. 2006.08.09 - работает очень хорошо

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

4. 2006.08.11 - работает очень хорошо (разницы с предыдущей не увидел)

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

И еще попутно вопрос, а что биты конфигурации все должны быть в Off,
там только SUT0 - сам ставится в On, а то ведь в прошивках которые были выложены
здесь раньше было - CKOPT-On и SPIEN-On?

Судя по часто появляющемуся тут вопросу о битах конфигурации: я вообще не указывал того, какие биты должны быть прошиты. Должны быть прошиты точно те же самые биты, что и для оригинальной прошивки, поскольку аппаратно устройства идентичны. И отсутствие прошитого бита SPIEN вообще сделает контроллер неперешивающимся по SPI. Поскольку прошивка задумывалась, как drop-in replacement для оригинальной (бросил на место оригинальной и забыл), то акцента на установке битов не делалось.

Кабель у меня собран на Atmega8-16PI который питается от 3.3 вольт.

Если оно работает с оригиналом, то будет работать и с альтернативной версией. Спор по поводу питания от 3.3 вольт кристаллов, работающих на 12 MHz, уже был в соответствующей ветке. Как правило, все работает. Я предпочел питать контроллер от 5 вольт, но выбор этот более-менее произвольный.

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

Самое интересное - проверить на 98 и ME. 98-я, по имеющейся информации, иначе работает с HID джойстиками. Она требует положительных значений передаваемых данных (это условие у меня соблюдается изначально) и не использует USB interrupt для опроса устройства (у меня реализовано оба варианта: как система запросит - так мы ей и ответим).

В любом случае спасибо за информацию всем ответившим. По крайней мере понятно, что хоть у кого-то оно заработало. Хотелось бы еще в том же ряду увидеть сравнение с оригинальной версией, чтобы для себя уяснить, а имело ли смысл все это мероприятие? Я писал для себя, но спустя полгода что-то стукнуло выложить сюда. Может, и зря. Но раз выложил, то хотелось хотя бы понять, имело ли все это смысл…

Первым я на данный момент и воспользовался. Если приспичит, попробую 3-ий.

Если первого достаточно, то зачем тогда остальные? 😃

FMS->Control->Analog control->Joystic interface->Mapping/Calibration - и там все есть.

Пока проверил в FMS, к риалфлайту компакт не мог найти после переезда, вещи разгребу все, - найдется.

Там тоже все есть.

Жаль. А на сколько закрытый? Полностью или можно как-нить стать тестером?

Пока полностью. А дальше время покажет. Сроков никаких нет, поскольку проект, как некоммерческий, идет по остаточному принципу, а времени на все не хватает.

С любым не RC. ИЛ-2, например.

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

Предположим, что канал руля высоты поступает с пульта по счету 3. Его симулятор хочет увидеть как ось Y стандартного джойстика. Тогда нужно поставить в дескрипторе 0x09, 0x31, // USAGE (Y) на 3-е место, считая сверху (в данном случае - вместо 0x09, 0x32, // USAGE (Z)), а последнее - соответственно, на второе. И эти два канала поменяются местами.

Иначе говоря, следует понять, в какой последовательности идут каналы с передатчика (например, 1 - газ, соответствующий в симуляторе оси Z, 2 - элероны, соответствующие в симуляторе оси X, 3 - руль высоты, соответствующий в симуляторе оси Y, и так далее). И поменять последовательность в дескрипторе в этом порядке, то есть

0x09, 0x30, // USAGE (X)
0x09, 0x31, // USAGE (Y)
0x95, 0x02, // REPORT_COUNT (2)
0x81, 0x82, // INPUT (Data,Var,Abs,Vol)
0xc0, // END_COLLECTION
0xa1, 0x00, // COLLECTION (Physical)
0x09, 0x32, // USAGE (Z)

поменять на

0x09, 0x32, // USAGE (Z) - 1 канал передатчика
0x09, 0x30, // USAGE (X) - 2 канал передатчика
0x95, 0x02, // REPORT_COUNT (2)
0x81, 0x82, // INPUT (Data,Var,Abs,Vol)
0xc0, // END_COLLECTION
0xa1, 0x00, // COLLECTION (Physical)
0x09, 0x31, // USAGE (Y) - 3 канал передатчика

Способ не вполне очевидный, но я не рассчитывал на подобные применения. Однако, любые изменения с точки зрения HID джойстика можно сделать, правильно сформировав этот дескриптор. В принципе, можно сформировать некий набор настроек прошивки, чтобы делать это более удобно. Пусть будет ToDo для очередной версии прошивки, если таковая когда-либо появится. Если нет, то можно переписать ее под себя, сделав указанные выше изменения.

каналы на джойстике все попутаны получились

Да, это особенность прошивки. Я не старался тут сохранять совместимость с оригиналом, поскольку не увидел в этом большого смысла.

Как только начнете работу регульятора для бесколлекторника на PWM3, сообщите, плиз, в личку.

Работа над ним уже идет, и довольно успешно. Но проект будет закрытым.

подскажите как поменять каналы.

Варианта 3:

1. (рекомендуемый): в любом известном мне симуляторе назначение каналов может программироваться внутри самого симулятора. В том числе, это относится к FMS, Aerofly Pro Deluxe, RealFlight G3 и Reflex XTR. Там же есть калибровка расходов каналов. Потому я не увидел смысла менять что-то в прошивке и не знаю точно, зачем это сделано в оригинале (вероятно, для общности или совместимости по умолчанию с неким конкретным симулятором).

2. (частичное решение не для всех симуляторов): назначение каналов задается в USB дескрипторе строками:

PROGMEM char usbHidReportDescriptor[USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH] =
{
0x05, 0x01, // USAGE_PAGE (Generic Desktop)
0x15, 0x00, // LOGICAL_MINIMUM (0)
0x26, 0xff, 0x00, // LOGICAL_MAXIMUM (255)
0x75, 0x08, // REPORT_SIZE (8)
0x09, 0x04, // USAGE (Joystick)
0xa1, 0x01, // COLLECTION (Application)
0x09, 0x01, // USAGE (Pointer)
0xa1, 0x00, // COLLECTION (Physical)
0x09, 0x30, // USAGE (X)
0x09, 0x31, // USAGE (Y)
​ 0x95, 0x02, // REPORT_COUNT (2)
0x81, 0x82, // INPUT (Data,Var,Abs,Vol)
0xc0, // END_COLLECTION
0xa1, 0x00, // COLLECTION (Physical)
0x09, 0x32, // USAGE (Z)
0x09, 0x33, // USAGE (Rx)
​ 0x95, 0x02, // REPORT_COUNT (2)
0x81, 0x82, // INPUT (Data,Var,Abs,Vol)
0xc0, // END_COLLECTION
0x09, 0x34, // USAGE (Ry)
0x09, 0x35, // USAGE (Rz)
0x09, 0x36, // USAGE (Slider)
0x09, 0x37, // USAGE (Dial)
​ 0x95, 0x04, // REPORT_COUNT (4)
0x81, 0x82, // INPUT (Data,Var,Abs,Vol)
0xc0 // END_COLLECTION
};

В таком порядке видятся с 1-го по 8-й каналы компьютеру. Назначение их применительно к джойстику очевидно из названий (оси X,Y,Z, вращение по осям Rx, Ry, Rz, ползунок, колесико). Для симулятора эти назначения могут приниматься или не приниматься в расчет (зависит от решения автора симулятора). Можно без особых проблем переставить местами эти обозначения, сохранив их места. Но это будет иметь значение только для джойстика и симуляторов, где стандартные назначения берутся в расчет (думаю, что нигде 😃).

3. (реальная перестановка, но решение надо писать самому): нужно вводить таблицу перекодировки или просто переписать формирование последовательности каналов в функции usbBuildReport(). В каком порядке будут положены значения из channelData[] в usbReport[] - в таком и будут видны каналы в симуляторе.

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

А с каким симулятором реально проблема?

Версия от 11.08.2006.
rcu_20060811.rar
По отношению к предыдущей сделаны следующие изменения:

• Изменена версия компилятора. Теперь компилировать следует IAR 4.20. Из особенностей компилятора использовано новое ключевое слово __nested для глобального разрешения прерываний сразу по входу в процедуру обработки прерывания. Это более корректно, чем sei после сохранения регистров.
  • Обновлена версия USB драйвера до 2006-07-18. Новые возможности, например, динамические дескрипторы, в проекте пока не использованы, но они в принципе дают возможность сделать универсальную прошивку под разные виды интерфейсов.
  • Добавлен опциональный режим серво-тестера. Идея в том, чтобы при входном PPM сигнале выдать один из каналов на отдельный выход контроллера. Использовать его можно для проверки серв или регуляторов двигателей. Естественно, что питать их надо не от USB. Я использовал этот режим для отладки контроллера бесколлекторного двигателя. Опция работает только при выборе драйвера in_ppm_adv, поскольку добавлялась как побочный эффект, а не самоцель.
• Добавлен альтернативный выходной драйвер out_joystick_btn, аналогичный обычному out_joystick, но дублирующий 8 аналоговых каналов на 8 дискретных (кнопки). Если входной канальный импульс <1.5мс, то соответствующая кнопка не нажата, и наоборот. Минусом этого варианта является снижение в 2 раза периода опроса USB джойстика (ограничение программного USB как low-speed device). Плюсом же - пример того, как можно делать USB HID дескрипторы, состоящие из более чем одного репорта. Несмотря на кажущуюся избыточность кода, IAR крайне эффективно сливает его в один фрагмент, так что ручная оптимизация была принесена в жертву очевидности кода.
• Многие аппаратные опции перенесены из *.c файлов в options.h, что, надеюсь, снизит вероятность подсунуть в очередной раз неработающую прошивку из за того, что какой-то из портов не был исправлен.
• В архиве лежат две скомпилированные версии - с кнопками и без оных. Обе поддерживают режим серво-тестера, выводя на вывод PB1 (OC1A) сигнал 3-го канала передатчика (не проверено на ATmega8).
• Обе версии проверены на оригинальном железе и выглядят работоспособными.

Одним словом, только что заливал ради интереса в шнурок обе по очереди - с виду работают одинаково ХОРОШО.

Это случайно. Первая формально работать не должна (CMOS - не TTL).

По сравнению с первой от 13/07 случайно реверс элеронов не поменялся ?

Логика не менялась, так что не должен был.

Расходов не хватает - но енто уже точно по причине не сделанной мною калибровки в AFPD и винде.

Расходы сделаны с запасом на разную аппаратуру. Калибровать крайне рекомендуется или в Windows, или в симуляторе. Желающие могут поправить коэффициенты в исходнике и лучше использовать разряды байтовых переменных. Еще оптимальнее было бы переписать out_joystick_btn так, чтобы передавать не 8-ми, а 10-ти битные значения каналов. Тогда полное использование разрядов не имело бы такого смысла. Но при этом из за усложнения упаковки данных пропала бы наглядность. Кто идею понял - сам сможет переписать эту часть.

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

Это работает, если прерывание гарантированно вызвалось. А если случился захват при запрещенном прерывании, которое позже разрешили, то таймер убежит на непредсказуемую величину. В случае USB драйвера это работать не будет, поскольку драйвер может запрещать прерывания на время до 100 мкс и даже более, что внесет существенную погрешность в измерение PPM сигнала (порядка 10%, что и наблюдалось в версии с in_ppm декодером).

Единственное, что еще хотелось быувидеть в данной версии - продублировать пару каналов кнопками, как это было во 2 й и 3ей оригинальных прошивках

Как было в оригинальных - не знаю, так как их не смотрел. Но опционально сделал вариант с продублированными всеми 8-ю каналами в виде кнопок. Оба варианта прошивок есть в архиве.

А почему бы ей не работать? Привязка к порту и биту в последнем декодере актуальна только для pull-up резистора.

Все, наверное, пользуются и радостно молчат. Если бы не работало - засЫпали бы жалобами.

😃 Похоже, что ты прав. Работать не обязано, но в каких-то случаях может и работать. Может, и так.

Я понял: чтобы получить фидбэк, надо выложить заведомо неработоспособный, но ОЧЕНЬ ИНТЕРЕСНЫЙ софт, а потом, после получения огромного фидбэка начать его доводить до рабочего состояния (почти по Microsoft) 😃

У меня она нормально работала…

Нормально работала версия от 13.07.06 с простым PPM декодером.
Версия от 20.07.06, в которой полностью переписан PPM декодер с целью вообще исключить какие-либо дерганья, работать на меге8 не могла в принципе, поскольку там вместо бита порта D6 (ICP1 на ATmega8) стоял B0 (ICP1 на ATmega32).

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

Ну не верится мне, что из 60-ти скачавших никто не смог выбрать 5 минут и проверить ее. Речь не о тех, кто собрался делать адаптер с нуля - речь о тех, у кого эта штука лежит на столе рядом с компом (а иначе и быть не может, так как адаптер без компа не имеет смысла).

Ну да ладно…

Буду рад услышать отзывы о ее работе, в том числе, в сравнении с предыдущей. Желательно также указывать, с какой аппаратурой и на какой версии Windows выполнялась проверка. Интересно проверить работу на Windows 98 и ME.

К моему огромному сожалению, за почти 3 недели ни один (!) из 60-ти скачавших эту прошивку, не сообщил, что она неработоспособна, несмотря на мои явно выраженные просьбы. Только случайно я узнал об этом, попробовав ее на исходной схеме. Причина, как всегда, оказалась предельно простой: переходя с ATmega32 на ATmega8, я забыл поправить нужный бит и порт для захвата таймера в новом модуле входного интерфейса.

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

К сожалению, в связи с полным отсутствием обратной связи от скачавших прошивку я пришел к выводу, что подобные проекты с открытым исходным кодом никого не интересуют. Поэтому данная прошивка - это первая и последняя моя публикация такого рода. Следующим проектом готовился к публикации контроллер бесколлекторного двигателя на AT90PWM3 с использованием всех возможностей данного специализированного кристалла (ЦАП для аппаратной программируемой токовой защиты, аппаратный высокочастотный PWM для полумостов, встроенные компараторы для ZCD), множеством функций и настроек, различными режимами управления двигателем (например, говернором по задаваемой пользователм кривой) и вдобавок - с возможностью конфигурирования всего этого добра по USB, используя шнур с 4-мя проводами без каких-либо деталей в нем, подключаемый непосредственно к контроллеру (и он же, используемый для перешивки контроллера). Но по названной причине я решил закрыть этот проект, не успев открыть. Нет ничего хуже для разработчика, чем полное отсутствие реакции тех, для кого проекты предназначены. Это на корню убивает какое-либо желание что-либо выкладывать. Во всяком случае, у меня.

В общем, идей набралось достаточно - пора писать новый вариант декодера 😃

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

1. Добавлен новый вариант входного драйвера - альтернативный PPM декодер. Старый оставлен для совместимости. Новый же переписан с учетом всех прозвучавших предложений и замечаний. Дальнейшие описания относятся именно к нему.

2. Точность декодирования повышена путем изменения режима работы таймера. Он теперь не сбрасывается, а бегает в свободном режиме. Длительность импульсов вычисляется как разница между двумя соседними захватами. Полярность входного сигнала не имеет значения для корректно сформированного PPM сигнала. Частота тактирования таймера понижена в 8 раз, чтобы обеспечить обнаружение паузы для малоканальных передатчиков. Максимальная длительность импульса (или паузы) - около 21 миллисекунды, при большем значении будет переполнение при вычислениях. Этого достаточно для стандартного PPM сигнала с большим запасом.

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

3. В случае, если хост слишком долго держит CPU в USB прерывании, отдельные пакеты PPM сигнала могут быть вообще испорчены (пропущены). К сожалению, с программным USB это не лечится (хотя при хосте, соответствующем спецификациям, этого не должно происходить, но не все хосты им соответствуют). Потому единственным выходом видится проверка пакетов на корректность различными способами. В декодере реализовано три опции для такой проверки, описанные ниже. Допустимо использование только одной из опций. При выборе нескольких поддержана будет первая выбранная. При отключении всех опций дополнительных проверок производится не будет, и будут передаваться все обнаруженные каналы до MAX_CHANNELS включительно. Выбор опций - в файле options.h.

// If this option is set to non-zero then ONLY first N_CHANNELS_ONLY channels
// will be read and made available for output. This option may be useful for
// Walkera transmitters which have some PCM data after standard PPM stream.
#define IN_PPM_ADV_N_CHANNELS_ONLY	  0   // range is 0 or [1..MAX_CHANNELS]

При указании ненулевого значения декодер всегда будет устанавливать только первые N каналов (где N - заданное значение). Это может быть полезным для передатчиков типа Walkera, где после нормального PPM может идти дополнительный код с произвольным количеством импульсов. НЕ ТЕСТИРОВАЛОСЬ, но должно работать, как задумано.

// If this option is set to non-zero then input PPM stream will be checked to
// see if it consists of exactly N_CHANNELS_EXACT channels. Any deviation will
// result in refusal of whole PPM data packet.
#define IN_PPM_ADV_N_CHANNELS_EXACT	 0   // range is 0 or [1..MAX_CHANNELS]

При указании ненулевого значения каждый PPM пакет будет проверяться на то, что он содержит РОВНО указанное количество каналов. Если количество каналов не совпадает (что возможно, например, при потере импульса из за задержки в USB прерывании), то данный пакет будет целиком проигнорирован и возвращен будет предыдущий (выходной драйвер не будет перестраивать репорт). Опция работает хорошо, но привязана к количеству каналов. Использовать не рекомендуется. При тестировании с 4-х канальным передатчиком ESKY опция должна быть установлена в 5 (а не 4), поскольку с передатчика идет именно 5 каналов.

// If this option is set to non-zero then input PPM stream vill be eva*luated
// to find the number of PPM channels. If last N_CHANNELS_AUTO PPM packets
// consist of equal number of pulses, then PPM data packet will be treated
// as valid. Otherwise it will be rejected. This is the recomended option
// with number of packets to check 2-10.
#define IN_PPM_ADV_N_CHANNELS_AUTO	  4   // range is 2-10

При указании ненулевого значения будет выполняться проверка серии последовательных PPM пакетов на предмет равного количества каналов в них. Длина серии равна заданному значению. Опция эквивалентна предыдущей, но количество каналов считается автоматически. Например, если значение установлено в 4, то необходимо, чтобы 4 последовательных пакета содержали равное количество каналов. В этом случае данные будут переданы выходному интерфейсу. Если только количество каналов изменилось, то данные не будут обновляться, пока не будет получено 4-х пакетов с равным количеством каналов в них. Это рекомендуемая опция, если без нее наблюдается дерганье нескольких каналов в определенных положениях ручек. Скомпилированная версия прошивки собрана именно с таким значением.

Новая версия тут.

В подкаталоге Release/Exe находится собранная прошивка (это обычный HEX формат).

Буду рад услышать отзывы о ее работе, в том числе, в сравнении с предыдущей. Желательно также указывать, с какой аппаратурой и на какой версии Windows выполнялась проверка. Интересно проверить работу на Windows 98 и ME.

Если из 10 пачек импульсов не менее чем в 9 из них - X каналов, то считать пачку с Y каналами ошибочной. Если волшебным образом передатчик во время работы превратился в восьмиканальный, то через 1 пропущенную пачку следующие 9 пройдут “без проверки” и дальше будет действовать новая накопленная статичстика (что-то типа fifo-буфера).

Именно так я и предлагал выше. Проблема будет только с нестандартными передатчиками от Валкеры. У них в конце пачки, как я понял, идет что-то вроде PCM. А они могут (и будут) восприниматься как произвольное количество импульсов (потому что посылки 1010 или 1111 дадут разное число импульсов). Тогда эта схема работать не будет. Но, поскольку ситуация не вполне типичная, а исходники открыты, то думаю, условная компиляция для таких случаев (опция для валкеры, опция для статистического контроля количества, опция для строгого задания количества) будет вполне приемлемым решением, а кому надо - соберет себе то, что ему нужно. Делать гибкую конфигурацию для такой поделки, мне кажется, будет перебором.

В общем, идей набралось достаточно - пора писать новый вариант декодера 😃

При входе в любое прерывание все прерывания запрещаются. Если в это время возникает событие таймера, его сброс оттягивется на некоторое время.

Конечно, всё так. Просто в ряде случаев возможно глобальное разрешение прерываний сразу после входа в ISR, и тогда более приоритетное всё равно сможет случиться. Что касается таймера, то задержка на несколько циклов при отсчете длительности PPM не очень критична, она никак не даст скачков на единицы (десятки) процентов. Потому ей можно пренебречь (хотя в целом это, конечно же, неправильно). Но вот задержка внутри USB - это серьезная проблема.

Это понизит вероятность дрыганий, но, возможно, не устранит их окончательно. Если есть вероятность пропуска произвольного количества событий РРМ, то будет ненулевая вероятность принятия ошибочного решения о “корректности” пачки. Так что в идеале нужна либо аппаратная поддержка USB, либо более продвинутая система регистрации событий РРМ, исключающая пропуски.

Возможно, не устранит, но вероятность значительно снизить должно, как мне кажется (поскольку мы просто будем ждать паузы - не верится, что в USB мы можем проторчать 3 миллисекунды, например). Ну, а с выводом я согласен - остается только придумать, как это реализовать наиболее простыми средствами 😃

при измерении времени в таймер вообще лучше ничего не писАть. Если его обнулять или писАть в него, всегда будет потеря его фазы и временная ошибка.

Это так, но есть одна проблема: я использую его переполнение выше TOP для поиска синхропаузы между пачками. Потому эта логика нарушится, если не трогать таймер. Хотя, безусловно, можно поменять логику: при измерении интервала просто сравнивать вычисленное значение с величиной TOP и в случае превышения считать, что имело место переполнение (пауза). Одной ISR станет меньше, а точность поднимется.

Когда есть прерывания

Посторонние (более приоритетные) прерывания (как USB в данном случае).

Также нет необходимости обрабатывать оба фронта входного сигнала - достаточно настроиться на любой. Полярность значения не имеет.

Посмотрел еще раз на PPM сигнал - да, действительно можно добавлять паузу 0.3 хоть до, хоть после импульса: результат будет одним и тем же, а код упростится.

Что касается дрыганий - у меня причина в том, что наблюдается повторный вход в прерывание TIMER_CAPT. Т.е. обработка прерывания USB иногда длится более 0.9 мс. Наверное, это как-то можно победить, но я, честно говоря, не напрягался.

Скорее, не повторный вход, а потеря одного из запросов. Да, именно оно видится реальной причиной дрыгания: потеря одного из импульсов приводит к “увеличению” длительности предыдущего на величину последующего, а все остальные сдвигаются на один. В итоге резко скачут все.

В документации на AVR-USB сказано, что драйвер может находиться в прерывании до 100 микросекунд, если хост соответствует стандартам. Реально далеко не все хосты им соответствуют. Далее, количество дрыганий, предположительно, может также зависеть от количества low-speed устройств на USB шине, так как драйвер обслуживает каждую транзакцию, даже если она не адресована нам. Потому можно просто попробовать выключить лишние устройства для подтверждения версии о причине дерготни, но это будет баловство. Думаю, что тут надо подходить иным путем. Я тоже пока напрягаться не планирую, но если возникнет идея, как перестать терять посылки - попробую реализовать. При этом самым простым (но не лучшим) решением видится отбрасывание пачки при неверном количестве импульсов (которое нужно получать автоматически). Для большинства аппаратов это должно работать удовлетворительно.

а винда не исключено что раздельно для разных джоев хранит калибровочные сведения.

Именно так - раздельно. Для нее это совершенно разные устройства.

Ну и второй (эффект) обнаружился - при некоторых положениях рукояток (что-то в центре, а одна-две (руль высоты/элероны) - в край, думаю что в минимум) начинается жёсткая дрыготня всех каналов (мотор и хвост тоже) на 50% от хода

Было бы, конечно, интересно найти причину такого поведения. Я наблюдал подобные эффекты с пультом от Валкеры 36. Там, как известно, не совсем честный PPM - после него идет несколько байтов дополнительной информации, сбивающей с толку декодер. Потому для этого пульта я делал специальную версию, ограничивая количество принимаемых каналов 6-ю. Тогда дрыганье исчезало. Выход кривой, но при отсутствии четкого представления, что там идет дальше, трудно сделать выводы о том, как с этим бороться. Я, во всяком случае, не стал.

не исключено что тоже от отсутствия WIN калибровки - сигналы выходят за объявленные/обнаруженные минимумы/максимумы и принудительно центрятся самой виндой ?

Маловероятно. По умолчанию (и здравому смыслу) при отсутствии калибровки винда должна воспринимать граничными те значения, которые прописаны в дескрипторе - а это 0…255, другого не дано. Что бы не принималось на входе - есть коррекция значений при формировании блока данных для отправки. Если только принимается совсем ерунда - тогда да, но это надо проверять.

Хотя почему при ентом дрыгаются все каналы, а не только тот, который в край ?

Возможно, идет потеря синхронизации по паузе - может, надо поиграться с ее определением, или увеличить ее ожидаемую длительность.

Надо второй шнурок забабахать и подцепить его к аналоговым выходам от пульта DF 5#4.
Снабдить его USB так сказать - будет отдельный симуляторный пультик.

Я так и делал, повесившись на потенциометры подобного пульта.

Кроме того - сразу будет понятно - кто виноват в дрыготне - PPM кодер или USB конвертер - потому как тут всё в одном флаконе станет.

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

СТОП! Действительно, возможна ситуация, когда мы попадаем как раз на момент, когда таймер-то захватили, но в 0 его не прописали (обслуживая более приоритетное прерывание от USB-). Потом мы его все же обнулим, но позже, и длительность следующего импульса будет посчитана неправильно (он получится короче реального). И тогда будет то самое дерганье.

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

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

Похоже, что именно это и наблюдается в описанном случае: конкретный хост долго держит устройство в прерывании. По этой причине конец короткого импульса (“минимум”) теряется, и вместо этого захватывается суммарная длительность этого и последующего импульсов (то, что “в центре”). И получаем дрыготню на величину этого самого центра - те самые “50%”. Вот это хуже всего, надо думать, как идентифицировать такую пачку, чтобы ее вообще отбрасывать, если нет возможности ее принять правильно (что тоже надо обдумать).

Идеи-то есть. Например, если точно известно количество импульсов в пачке, то при меньшем их количестве вообще пачку отбрасывать. Минус: теряется универсальность. Идея два: набирать статистику по конкретному передатчику. Скажем, ловим 10 пачек и смотрим, сколько импульсов там. Если, по большей части, их там будет 8, а когда-то - лишь 7 или меньше, значит все пачки, где меньше 8 импульсов, надо игнорировать. Но тоже минус: не будут работать пульты типа валкеры с дополнительными посылками в конце. Ну, что же - это плата за дешивизну программной реализации USB. Хотя надо думать - может, можно что-то и с этим поделать 😃

Жаль, что АЦП опрашивается, а не синхронен какому-либо таймерному прерыванию.

Не видел смысла, так как других задач нет. Да и писалось на скорую руку, так что есть поле для экспериментов.

Ну и усреднять - станет постабильнее.

Не думаю, что это критично - АЦП 10-битный, а выход в данной реализации - 8-ми. Так что дрожание младших битов не может дать 20% столбика. Тут что-то другое.

Хотя - вот для ентого и нужны исходники, что-бы пытаться их ковырять для самоудовлетворения/образования.

Вот потому я и выложил - чтобы кто-то улучшил или дописал своё. А при обсуждении возникают новые мысли (как вот та ошибка с длительностью - в USB драйвере управление может находиться довольно долго - и тем самым ломать работу декодера).

К слову говоря: появилась новая авторская версия USB драйвера (пока у меня, но после тестирования появится на сайте автора), где поддержано динамическое управление всеми USB дескрипторами, которые могут быть статическими или генерироваться на лету во время выполнения. Как частный случай, это дает возможность штатно сделать устройство с переключаемыми интерфейсами (например, по кнопке), а не одним жестко скомпилированным. А код драйвера стал еще более оптимизированным по объему (а казалось бы - куда ещё)…

Вполне готов проверить, высылай прошивку.

Выложена в этой ветке. Используйте версию rcu_20060713.rar.

Не знаю, хватит ли производительности. Попробую. Ведь для ЮСБ жесткие временные рамки… Выкладывай исходники. А я попробую включить их.

Включить так просто не получится, поскольку использованный вариант USB поддержан только для двух компиляторов - gcc (WinAVR) и IAR. Портировать его под другие компиляторы может быть непростой задачей, так как там есть ассемблерный модуль, и очень активно используется препроцессор, который у указанных компиляторов доступен и для ассемблерного текста, и совместим (точнее, тот же самый) с сишным.

Тем не менее, я исходники rcu_20060713_source.rar под IAR компилятор выложил на общее обозрение в той же ветке. Я бы предложил кодер переписать в более структурированном виде. Когда сделаю железку, то и сам займусь таким вопросом, а пока могу лишь предлагать.

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

ВО! Эта работает, причем очень хорошо, каналы отрабатываются ровно и без поддергиваний.

Спасибо, поскольку еще один человек мне писал, что с оригиналом есть проблемы со стабильностью. А с чем оно проверялось (версия Windows, передатчик)?

Итак, как и обещал, принимайте исходные тексты и файлы проекта под компилятор IAR (www.iar.com, доступна полнофункциональная ознакомительная 30-дневная версия):

Готов ответить на любые конкретные вопросы по тексту (кроме единственного, уже отвеченного непосредственно там). И ещё сразу говорю: портировать под gcc (WinAVR) или другие среды разработки у меня нет ни времени, ни желания. Но поскольку там не использовано никаких особенностей компилятора, это сделать достаточно просто самостоятельно.

Имея оригинальное железо, я за 5 минут бы выяснил причину неработоспособности его, так как она кроется не в системе, а что-то перепутано с пинами (напомню, что у меня железа такого нет).

Итак, всё оказалось почти так, как я и предполагал. От большого ума и желания красиво оформить исходные тексты. Я использовал условную компиляцию выбора пинов под свое железо и железо по схеме с сайта. Только в одном месте проверка варианта оказалась раньше, чем ее определение. Потому компилировалось совсем не то, что предполагалось.

Вот новая версия прошивки. Прошу проверить, а также проверить работу ее PPM с приведенными в исходном сообщении оговорками.

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

Виталий, спасибо за заботу 😃 Вероятно, кто-то чего-то действительно недопонял.

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

2. Если заглянуть на страницу проектов, то там видно, что одним из проектов является мой крипто-загрузчик. Из этого следует, что я, как минимум, знаю о существовании этого продукта и, скорее всего, не стал бы изобретать велосипед.

Crypto-Boot - an USB Boot Loader

3. И я действительно знаю об этом драйвере, так как если заглянуть внутрь его readme, то там в ряде файлов видно упоминание автора о том, что он благодарен мне за порт драйвера под IAR компилятор. Кроме того, в процессе работы над тем портом была найдена пара серьезных багов в логике работы, которые были исправлены в тесном сотрудничестве с Кристианом, а также добавлено несколько расширений, полезных на тот момент мне, но включенных в официальный порт.

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

Пробовал, все равно устройство не опознано пишет

Значит, завтра буду брать собранную схему и пробовать на ней.

PS. Неужели ни один человек больше не попробовал?
PPS. Куда-то делся линк на скачку. Ставлю еще раз в таком виде.
PPPS. Да, когда выше шла речь о “Если кто может помочь с готовой платой на разумных условиях” платы на меге128 для передатчика, то имелась в виду голая печатка, без деталей, ессно.

Вынь ХР проф, со всеми обновлениями, не в ней дело

Да, дело явно не в ней. Скорее всего, что-то с пинами. Да вроде все правильно:

#define USB_CFG_IOPORTNAME	  D
/* This is the port where the USB bus is connected. When you configure it to
 * "B", the registers PORTB, PINB and DDRB will be used.
 */
#define USB_CFG_DMINUS_BIT	  0
/* This is the bit number in USB_CFG_IOPORT where the USB D- line is connected.
 * This may be any bit in the port.
 */
#define USB_CFG_DPLUS_BIT	   1
/* This is the bit number in USB_CFG_IOPORT where the USB D+ line is connected.
 * This may be any bit in the port. Please note that D+ must also be connected
 * to interrupt pin INT0!
 */

старая прошивка работает на ура, мега от 5 вольт запитана, USB придушен стабилитронами до 3.3в

У меня все то же самое от версии винды до схемотехники, за одним исключением - пины другие и PPM проверялся на меге32, но в макетную плату на меге8 я свою прошивку шил (с другими пинами), и оно виделось как USB устройство.

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

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

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

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

Предлагаю попробовать такой вариант.

Общему вниманию предлагается альтернативная open-source прошивка для USB-адаптера передатчика, собранного на ATmega8 по схеме с http://rcdesign.ru. Код написан на C и будет опубликован после подтверждения ее работоспособности с парой популярных передатчиков. У меня нет ни нормальной аппаратуры (кроме валкеры да еская), ни в точности той схемы, потому хотелось бы убедиться, что декодирование PPM работает так, как задумано.

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

Цели ее опубликования:

• показать, что писать код под программный USB для AVR вовсе не так сложно, если использовать не ассемблерный вариант интерфейса (предположительно, использованный в оригинальной прошивке, судя по ее ограничениям), а открытый USB драйвер для AVR, написанный большей частью на C и отлично документированный;
• помочь начинающим сделать свои варианты входных интерфейсов (например, чтение встроенного ADC контроллера - этот модуль также присутствует в составе исходного текста, или декодера различных вариантов PCM по аналогии с декодером PPM, дописав соответствующий модуль);
• помочь начинающим сделать свои варианты выходных интерфейсов с кнопками, дополнительными каналами и др.;
• показать вариант интеграции функциональности USB-адаптера в самодельный кодер передатчика, обсуждаемый вот в этой ветке. Дальнейшее развитие этого направления вижу в интеграции функций USB загрузчика в тот самый кодер (дает возможность смены прошивок без программатора - по тому же USB-). И в возможности настройки кодера и/или моделей через тот же USB интерфейс. Сам готов подключиться к этим задачам, как только соберу ту схему (делать плату руками или паять на макетке нет времени, так как я по работе не связан с изготовлением железа. Если кто может помочь с готовой платой на разумных условиях - с радостью бы воспользовался предложением);
• выполнение требование лицензии на использованный open-source программный USB драйвер (публикация исходных текстов проектов, написанных с его использованием без приобретения коммерческой лицензии).

Прошивка для проверки (пока без исходников):

Краткое описание предложенной версии

Вход: PPM до 8 каналов, полярность не имеет значения.
Выход: HID джойстик на 8 аналоговых каналов.

В данной прошивке не выполняется маппинг каналов в соответствии с их назначением прямо или через NVRAM. Соответствие каналов жестко записано следующее (оно не соответствует маппингу по умолчанию в оригинальной прошивке):

1 - X
2 - Y
3 - Z
4 - Rx
5 - Ry
6 - Rz
7 - Slider
8 - Dial

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

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

У меня эта прошивка вообще не запустилась 😦 пишет “устройство не опознано”

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

Что значит “стандартно PPM поддерживает 8 каналов”?
А что, существует PPM поддерживающий более чем 8 каналов?

Откуда-то же они берутся…

Как уже писали, большое количество выходных каналов (джойстика) получают дублированием 8 входных каналов сигнала PPM, и только.

К сожалению, я не видел этой информации. Но и не вижу смысла в таком дублировании. Раскидать аналоговый канал на N дискретных - это понятно (хотя я не знаю алгоритмов, использованных в различной аппаратуре). А вот просто дублировать…

Лучше наверное в раздел программ/схем.

OK. Перевел тему сюда.

Думаю, что на выходных выложу что-то, раз уж проанонсировал.

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

Краткое описание

Вход: PPM до 8 каналов, полярность не имеет значения.
Выход: HID джойстик на 8 аналоговых каналов.

В данной прошивке не выполняется маппинг каналов в соответствии с их назначением прямо или через NVRAM. Соответствие каналов жестко записано следующее (оно не соответствует маппингу по умолчанию в оригинальной прошивке - проверяется не соответствие один в один):

1 - X
2 - Y
3 - Z
4 - Rx
5 - Ry
6 - Rz
7 - Slider
8 - Dial

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

После получения положительных (а как же иначе) отзывов опубликую в виде open-source свои исходники на C.

PS. К авторам оригинальной статьи: если вы считаете, что мой постинг тут неуместен по каким-либо причинам - прошу сообщить. Без проблем переползу в любую другую тему/форум/сайт.

Я прошил мегу8 один раз, а на второй она мне поазала комбинаци из трех пальцев. Решил адаптер джостика собрать.

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

Вроде как просто ищется синхропауза, без привязки к периоду следования пакетов 20 мСек. Если каналов более 8, то период следования пакетов будет просто увеличиваться. Однако работать должно.

Мой PPM декодер является управляемым по прерыванию и также нечувствителен к полярности и количеству импульсов - сколько есть, столько и принимает, но не более, чем максимально заданная константа. Можно попробовать увеличить эту цифру с 8 до 9.

Потом по просьбе Тохи он их вроде как задублировал с сигналом от каналов 4-9 - если сигнал в канале более 50% - кнопка ВКЛ, если менее - кнопка ВЫКЛ, что-то вроде того.

Отличная идея, я чего-то об этом не подумал. Это на самом деле может быть полезным.

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

Но это займет некоторое время, так как я до выходных занят. Думаю, что на выходных выложу что-то, раз уж проанонсировал.

И кстати - недавно InterSema.Ch порадовала меня 3 мя штуками ms5543b датчиков абс давления/температуры +16 бит дельта-сигма АЦП в одном флаконе.
Один могу уступить для опытов в хорошие руки - маленький, легкий, точный, мало кушающий модуль с i2c интерфейсом.

Ох ты, и где же такое чудо берется и сколько денег стоит?
Полтора года назад, когда делал себе вариометр (для полетов в потоках на параплане, ибо являюсь парапланеристом), все перерыл, но ничего такого не нашел (с АЦП на борту): или точность никакая (а моя связка MPX4115+ADS1240/AD7705 дает цену деления 15 см по высоте), или цена безбашенная. Поскольку эта часть - самая дорогая в таком приборе, то очень интересно бы узнать, где такое можно найти. Лучше в ЛС, ибо не по теме тут.