usb-адаптер передатчика - альтернативная open-source прошивка
при измерении времени в таймер вообще лучше ничего не писАть. Если его обнулять или писАть в него, всегда будет потеря его фазы и временная ошибка.
Это так, но есть одна проблема: я использую его переполнение выше TOP для поиска синхропаузы между пачками. Потому эта логика нарушится, если не трогать таймер. Хотя, безусловно, можно поменять логику: при измерении интервала просто сравнивать вычисленное значение с величиной TOP и в случае превышения считать, что имело место переполнение (пауза). Одной ISR станет меньше, а точность поднимется.
Когда есть прерывания
Посторонние (более приоритетные) прерывания (как USB в данном случае).
Также нет необходимости обрабатывать оба фронта входного сигнала - достаточно настроиться на любой. Полярность значения не имеет.
Посмотрел еще раз на PPM сигнал - да, действительно можно добавлять паузу 0.3 хоть до, хоть после импульса: результат будет одним и тем же, а код упростится.
Что касается дрыганий - у меня причина в том, что наблюдается повторный вход в прерывание TIMER_CAPT. Т.е. обработка прерывания USB иногда длится более 0.9 мс. Наверное, это как-то можно победить, но я, честно говоря, не напрягался.
Скорее, не повторный вход, а потеря одного из запросов. Да, именно оно видится реальной причиной дрыгания: потеря одного из импульсов приводит к “увеличению” длительности предыдущего на величину последующего, а все остальные сдвигаются на один. В итоге резко скачут все.
В документации на AVR-USB сказано, что драйвер может находиться в прерывании до 100 микросекунд, если хост соответствует стандартам. Реально далеко не все хосты им соответствуют. Далее, количество дрыганий, предположительно, может также зависеть от количества low-speed устройств на USB шине, так как драйвер обслуживает каждую транзакцию, даже если она не адресована нам. Потому можно просто попробовать выключить лишние устройства для подтверждения версии о причине дерготни, но это будет баловство. Думаю, что тут надо подходить иным путем. Я тоже пока напрягаться не планирую, но если возникнет идея, как перестать терять посылки - попробую реализовать. При этом самым простым (но не лучшим) решением видится отбрасывание пачки при неверном количестве импульсов (которое нужно получать автоматически). Для большинства аппаратов это должно работать удовлетворительно.
> Посторонние (более приоритетные) прерывания (как USB в данном случае).
Да любые, не обязательно более приоритетные. При входе в любое прерывание все прерывания запрещаются. Если в это время возникает событие таймера, его сброс оттягивется на некоторое время. И даже если других прерываний нет, время реакции на прерывание таймера зависит от текущей выполняемой команды. Так что модификация таймера при измерении интервалов в общем случае - неудачная идея.
> Скорее, не повторный вход, а потеря одного из запросов.
Естественно, потеря. Просто я наблюдал повторный вход. А означал он, что прерывание таймера еще не окончило свою обработку, было прервано прерыванием USB и в USB просидело достаточно, чтобы выскочил новый запрос таймера (возможно даже не один).
> При этом самым простым (но не лучшим) решением видится отбрасывание пачки при неверном количестве импульсов
Это понизит вероятность дрыганий, но, возможно, не устранит их окончательно. Если есть вероятность пропуска произвольного количества событий РРМ, то будет ненулевая вероятность принятия ошибочного решения о “корректности” пачки. Так что в идеале нужна либо аппаратная поддержка USB, либо более продвинутая система регистрации событий РРМ, исключающая пропуски.
При входе в любое прерывание все прерывания запрещаются. Если в это время возникает событие таймера, его сброс оттягивется на некоторое время.
Конечно, всё так. Просто в ряде случаев возможно глобальное разрешение прерываний сразу после входа в ISR, и тогда более приоритетное всё равно сможет случиться. Что касается таймера, то задержка на несколько циклов при отсчете длительности PPM не очень критична, она никак не даст скачков на единицы (десятки) процентов. Потому ей можно пренебречь (хотя в целом это, конечно же, неправильно). Но вот задержка внутри USB - это серьезная проблема.
Это понизит вероятность дрыганий, но, возможно, не устранит их окончательно. Если есть вероятность пропуска произвольного количества событий РРМ, то будет ненулевая вероятность принятия ошибочного решения о “корректности” пачки. Так что в идеале нужна либо аппаратная поддержка USB, либо более продвинутая система регистрации событий РРМ, исключающая пропуски.
Возможно, не устранит, но вероятность значительно снизить должно, как мне кажется (поскольку мы просто будем ждать паузы - не верится, что в USB мы можем проторчать 3 миллисекунды, например). Ну, а с выводом я согласен - остается только придумать, как это реализовать наиболее простыми средствами 😃
Если из 10 пачек импульсов не менее чем в 9 из них - X каналов, то считать пачку с Y каналами ошибочной. Если волшебным образом передатчик во время работы превратился в восьмиканальный, то через 1 пропущенную пачку следующие 9 пройдут “без проверки” и дальше будет действовать новая накопленная статистика (что-то типа fifo-буфера).
Если из 10 пачек импульсов не менее чем в 9 из них - X каналов, то считать пачку с Y каналами ошибочной. Если волшебным образом передатчик во время работы превратился в восьмиканальный, то через 1 пропущенную пачку следующие 9 пройдут “без проверки” и дальше будет действовать новая накопленная статичстика (что-то типа fifo-буфера).
Именно так я и предлагал выше. Проблема будет только с нестандартными передатчиками от Валкеры. У них в конце пачки, как я понял, идет что-то вроде PCM. А они могут (и будут) восприниматься как произвольное количество импульсов (потому что посылки 1010 или 1111 дадут разное число импульсов). Тогда эта схема работать не будет. Но, поскольку ситуация не вполне типичная, а исходники открыты, то думаю, условная компиляция для таких случаев (опция для валкеры, опция для статистического контроля количества, опция для строгого задания количества) будет вполне приемлемым решением, а кому надо - соберет себе то, что ему нужно. Делать гибкую конфигурацию для такой поделки, мне кажется, будет перебором.
В общем, идей набралось достаточно - пора писать новый вариант декодера 😃
В общем, идей набралось достаточно - пора писать новый вариант декодера 😃
Вот очередная версия прошивки вместе с исходными текстами. Проверена, как водится, на другом железе, но надеюсь, что в этот раз проблем на оригинале быть не должно. Изменения по отношению к предыдущей версии:
-
Добавлен новый вариант входного драйвера - альтернативный PPM декодер. Старый оставлен для совместимости. Новый же переписан с учетом всех прозвучавших предложений и замечаний. Дальнейшие описания относятся именно к нему.
-
Точность декодирования повышена путем изменения режима работы таймера. Он теперь не сбрасывается, а бегает в свободном режиме. Длительность импульсов вычисляется как разница между двумя соседними захватами. Полярность входного сигнала не имеет значения для корректно сформированного PPM сигнала. Частота тактирования таймера понижена в 8 раз, чтобы обеспечить обнаружение паузы для малоканальных передатчиков. Максимальная длительность импульса (или паузы) - около 21 миллисекунды, при большем значении будет переполнение при вычислениях. Этого достаточно для стандартного PPM сигнала с большим запасом.
Данные изменения уже заметно снижают дребезг каналов (на моем пульте и компьютере дребезг, практически, отсутствует по сравнению с предыдущей версией прошивки).
- В случае, если хост слишком долго держит 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.
Собрал схемку… залил прошивку джостик нормально определилися но нет сигнала с передатчика точнее нет ни какого отклика в настройках… передатчик Walkera WK-0701… помоните настроить…
Собрал схемку… залил прошивку джостик нормально определилися но нет сигнала с передатчика точнее нет ни какого отклика в настройках… передатчик Walkera WK-0701… помоните настроить…
Первое, что пришло в голову - поменяй местами провода идущие к тренерскому разъему передатчика. Прошивке то всеравно, 1 это пауза, или импульс, а вот транзистору полярность не пофигу… 😃
Еще появилась информация… этот пульт сделан на Atmega128! Чуть позже будут фото внутренностей…
Моежт еще эта ссылка чего даст Здесь
Еще появилась информация… этот пульт сделан на Atmega128!
Упсс ошибся Atmega88-20au…
Помогите…
Вот еще осцилограмма снятая компом через звуковую карту… тока амплидуда получается гдето около ~2.5 вольта
Буду рад услышать отзывы о ее работе, в том числе, в сравнении с предыдущей. Желательно также указывать, с какой аппаратурой и на какой версии Windows выполнялась проверка. Интересно проверить работу на Windows 98 и ME.
К моему огромному сожалению, за почти 3 недели ни один (!) из 60-ти скачавших эту прошивку, не сообщил, что она неработоспособна, несмотря на мои явно выраженные просьбы. Только случайно я узнал об этом, попробовав ее на исходной схеме. Причина, как всегда, оказалась предельно простой: переходя с ATmega32 на ATmega8, я забыл поправить нужный бит и порт для захвата таймера в новом модуле входного интерфейса.
Ниже выложена исправленная версия прошивки с исходными текстами. Попутно добавлена опция инверсии входного PPM сигнала (на случай теоретически возможного неправильного источника канальных импульсов). В общем случае эта опция не имеет значения. Предыдущую версию, как содержащую ошибку, я удаляю.
К сожалению, в связи с полным отсутствием обратной связи от скачавших прошивку я пришел к выводу, что подобные проекты с открытым исходным кодом никого не интересуют. Поэтому данная прошивка - это первая и последняя моя публикация такого рода. Следующим проектом готовился к публикации контроллер бесколлекторного двигателя на AT90PWM3 с использованием всех возможностей данного специализированного кристалла (ЦАП для аппаратной программируемой токовой защиты, аппаратный высокочастотный PWM для полумостов, встроенные компараторы для ZCD), множеством функций и настроек, различными режимами управления двигателем (например, говернором по задаваемой пользователм кривой) и вдобавок - с возможностью конфигурирования всего этого добра по USB, используя шнур с 4-мя проводами без каких-либо деталей в нем, подключаемый непосредственно к контроллеру (и он же, используемый для перешивки контроллера). Но по названной причине я решил закрыть этот проект, не успев открыть. Нет ничего хуже для разработчика, чем полное отсутствие реакции тех, для кого проекты предназначены. Это на корню убивает какое-либо желание что-либо выкладывать. Во всяком случае, у меня.
У меня она нормально работала…
К сожалению, в связи с полным отсутствием обратной связи от скачавших прошивку я пришел к выводу, что подобные проекты с открытым исходным кодом никого не интересуют. Поэтому данная прошивка - это первая и последняя моя публикация такого рода. Следующим проектом готовился к публикации контроллер бесколлекторного двигателя на AT90PWM3 с использованием всех возможностей данного специализированного кристалла (ЦАП для аппаратной программируемой токовой защиты, аппаратный высокочастотный PWM для полумостов, встроенные компараторы для ZCD), множеством функций и настроек, различными режимами управления двигателем (например, говернором по задаваемой пользователм кривой) и вдобавок - с возможностью конфигурирования всего этого добра по USB, используя шнур с 4-мя проводами без каких-либо деталей в нем, подключаемый непосредственно к контроллеру (и он же, используемый для перешивки контроллера). Но по названной причине я решил закрыть этот проект, не успев открыть. Нет ничего хуже для разработчика, чем полное отсутствие реакции тех, для кого проекты предназначены. Это на корню убивает какое-либо желание что-либо выкладывать. Во всяком случае, у меня.
Зря Вы так !
Вот я например прошивку скачал но в связи с нехваткой свободного времени даже залить ее не успел
Тут полетать то вырваться не всегда получается не говоря уже о паяльнике с программатором
сейчас имхо не совсем то время для занятия данными вещями июль - август сезон отпусков (в это время реально по Москве на авто хоть ездить мона 😲 )
очень много дел всякие дачи, стройки итд 😦
Я думаю что осенью больше народа подтянется да и время дождливыми вечерами коротать както придется . Для паяния - вояния ,симуляторов и постройки летательных аппаратов самое время !!!
Лично от меня БОЛЬШОЕ СПАСИБО !!! за проделанную Вами работу 😃
Хочется надеиться что Вы измените свое мнение и продолжите свои нужные для народа проекты! 😃
С уважением ,Павел
У меня она нормально работала…
Нормально работала версия от 13.07.06 с простым PPM декодером.
Версия от 20.07.06, в которой полностью переписан PPM декодер с целью вообще исключить какие-либо дерганья, работать на меге8 не могла в принципе, поскольку там вместо бита порта D6 (ICP1 на ATmega8) стоял B0 (ICP1 на ATmega32).
Вот я например прошивку скачал но в связи с нехваткой свободного времени даже залить ее не успел
Ну не верится мне, что из 60-ти скачавших никто не смог выбрать 5 минут и проверить ее. Речь не о тех, кто собрался делать адаптер с нуля - речь о тех, у кого эта штука лежит на столе рядом с компом (а иначе и быть не может, так как адаптер без компа не имеет смысла).
Ну да ладно…
Нормально работала версия от 13.07.06 с простым PPM декодером.
Версия от 20.07.06, в которой полностью переписан PPM декодер с целью вообще исключить какие-либо дерганья, работать на меге8 не могла в принципе, поскольку там вместо бита порта D6 (ICP1 на ATmega8) стоял B0 (ICP1 на ATmega32).
Ну не верится мне, что из 60-ти скачавших никто не смог выбрать 5 минут и проверить ее. Речь не о тех, кто собрался делать адаптер с нуля - речь о тех, у кого эта штука лежит на столе рядом с компом (а иначе и быть не может, так как адаптер без компа не имеет смысла).Ну да ладно…
Может и не могла, но работала. Я серьезно!
А ведь и правда времени нет. Да и необходимости - тоже. У кого работает и его устраивала старая версия - вовсе не обязательно зальют новую… У меня шнурок на Ti сделан, и второй вроде и не нужен. Твою прошивку хотел на шнурке друга посмотреть, но уже 2 месяца с ним увидеться не могу, и что?
Выкладывать что-то или нет - дело твое. ! А обижаться на всех подряд - не стоит!
Версия от 20.07.06, в которой полностью переписан PPM декодер с целью вообще исключить какие-либо дерганья, работать на меге8 не могла в принципе, поскольку там вместо бита порта D6 (ICP1 на ATmega8) стоял B0 (ICP1 на ATmega32).
А почему бы ей не работать? Привязка к порту и биту в последнем декодере актуальна только для pull-up резистора.
Все, наверное, пользуются и радостно молчат. Если бы не работало - засЫпали бы жалобами.
А почему бы ей не работать? Привязка к порту и биту в последнем декодере актуальна только для pull-up резистора.
Все, наверное, пользуются и радостно молчат. Если бы не работало - засЫпали бы жалобами.
😃 Похоже, что ты прав. Работать не обязано, но в каких-то случаях может и работать. Может, и так.
Я понял: чтобы получить фидбэк, надо выложить заведомо неработоспособный, но ОЧЕНЬ ИНТЕРЕСНЫЙ софт, а потом, после получения огромного фидбэка начать его доводить до рабочего состояния (почти по Microsoft) 😃
Я понял: чтобы получить фидбэк, надо выложить заведомо неработоспособный, но ОЧЕНЬ ИНТЕРЕСНЫЙ софт, а потом, после получения огромного фидбэка начать его доводить до рабочего состояния (почти по Microsoft) 😃
Ну, надо же учитывать и объем кода, всё ж таки 😃
И, главное, количество кодировщиков + их неадекватное понимание одних и тех же спецификаций интерфейсов 😁
Зря Вы обижаетесь - поверьте на слово! Вы сделали прекрасную вещь, сопровождаете её - честь Вам и хвала! (я сам - лицо незаинтересованное, прошивки не качал и не ставил, но слежу за этой дискуссией со стороны с большим интересом). Когда-то раньше я и сам писал софт и очень хорошо Вас понимаю. Немного посмотрел Ваши исходники - это работа мастера высокого класса, я и сам так работал 😃
Удачи Вам во всех делах! 😃
А я погряз в отладке/полировке прицепленного к 18 пику 44780 отладочного LCD.
Ну уже практически всё сделал, что хотелось, теперь прицепил аппаратно/обдумываю план проги обмена пакетами для dp1205 на том же 18 пике.
Новую Прошиву Шнурка видел, скачивал, но на симе за енто время ни разу не летал. Сегодня первый раз на верте-сооснике повисячил за месяц с лишним. Однако вину осознаю, и в компенсацию пойду пыльцу с фотика сдувать - заснять свою “печатную плату” с “разъёмом внутрисхемного программирования” :
Имелось ввиду исправление с варианта от 20/07
// Capture port settings
#define ICP_PORT_DD DDRD // timer input capture ports
#define ICP_PORT_IN PIND
#define ICP_PORT_OUT PORTD
#define ICP_BIT 6 // timer input capture pin
на вариант от 20/08 ?
// Capture port settings
#define ICP_PORT_DD DDRB // timer input capture ports
#define ICP_PORT_IN PINB
#define ICP_PORT_OUT PORTB
#define ICP_BIT 0 // timer input capture pin
Одним словом, только что заливал ради интереса в шнурок обе по очереди - с виду работают одинаково ХОРОШО.
По сравнению с первой от 13/07 случайно реверс элеронов не поменялся ?
Потому как я на сохранённом профиле джоя в AFPD не смог взлететь, перенастраивать не стал - только дрыготню глядел.
Расходов не хватает - но енто уже точно по причине не сделанной мною калибровки в AFPD и винде.
Дрыганье теперь однозначно меньше чем у прошивки Вада, хотя справедливости ради надо всё-таки откалибровать в винде и AFPD как положено.
Периодические Редкие но амплитудные дрыги прошивки 13/07 отсутствуют вовсе, так же как и жёсткая дрыготня всех каналов при ручках в минимуме.
Теперь при высота/элерон в минимуме происходит смещение полосок на пиксел, не более. А при центральном положении - полоски в AFPD вообще стоят как влитые. Так что - прогресс явно на лицо, высказанные идеи не пропали даром.
98 СЕ винду пока не грузил - она на ентом компе, с которого я мессагу набивал. Да и так почти 2 часа провозился - где уж мне за 5 минут всё протестить - я только пульт со шнурком с полки 5 минут доставал …
Кстати, между присвоением значения таймеру в прерывании и его свободным бегом есть компромисс - Увеличение таймера (в прерывании по переполнению ентого таймера) на требуемую коррекцию - применял в своём прошлом учебном проектике - тоже работает.
Ну и прилагаю фотку ЛСД 20х4, над которым корпел.
Производительность чуть более 1000 строк/секунду что по 4 что по 8 битам. Ну и в каждой строке по паре 16 бит БЦД преобразований делается при ентом выводе. 10 МИПСов - трать/не хочу. Однако с прогой фонового обмена буферами через радиоканал посредством 1205 - ну туго пока что, сложно всё чего-то, пока только общие черты обдумал. Однако - кто знает, быть может и состряпаю.