Дешифратор MULTI канала прошивки VCoder

Раздел для обсуждения и разработки дешифратора MULTI канала прошивки VCoder

О МULTI канале:

В прошивке VCoder заложен программный механизм уплотнения 4х любых каналов аппаратуры (напомню что всего их 16) в один канал передаваемый на приемник. Это уплотненный канал был назван MULTI каналом, по названию режима Фильтра настройки канала.
Таким образом со стороны передатчика 4 канала упаковываются в один и передаются на приемник.
Это позволяет увеличить количество каналов передаваемых на приемник, например на стандартном 8ми канальном приемнике мы можем получить следующие каналы:
1,2,3,4,5,6,7 - обычные каналы аппаратуры
8 - MULTI канал - через который передаются еще 4 (!) канала
итого общее количество каналов которые можно использовать в модели достигает 11
Технических ограничений на использование нескольких MULTI каналов нет, то есть вы можете использовать так же и два MULTI канала, в этом случае на 8ми канальном приемнике вы получаете:
1,2,3,4,5,6 - обычные каналы аппаратуры
7 - MULTI канал, через который передаются 4 канала
8 - MULTI канала, через который передаются еще 4 канала
итого, общее количество каналов передаваемых на модель 14

Для того чтобы MULTI каналы можно было использовать в модели нам необходим

ДЕШИФРАТОР MULTI КАНАЛА

Это небольшое устройство которое включается в один из каналов приемника и на выходе формирует 4 стандартных канала управления, к которым можно напрямую подключать исполнительные механизмы в виде Серв или иные устройства управляющиеся стандартным PWM импульсом

ФОРМАТ ПЕРЕДАЧИ MULTI КАНАЛА

Формат до безобразия прост 😃
Первым передается маркер мульти канала, его длительность 750 мкс.
Далее идут последовательно импульсы 4х каналов
Далее опять передается маркер мульти канала и опять 4 канала… и т.д.

Нужно отметить что формат сигнала PPM при этом не меняется, то есть приемник получает стандартные пачки PPM сигнала длительностью 20 мс
просто в первой пачке на месте импульса МУЛЬТИ канала будет идти маркер, во второй пачке импульсов - данные первого канала, в третьей - второго канала, в четвертой - третьего канала, в пятой - четвертого канала (везде в этом предложении по номером канала имеется в виду канал уплотненный в МУЛЬТИ канал, номер канала для уплотнения указывается в настройках фильтров каналов)

Таким образом быстродействие (скорость изменения) уплотненного канала будет равна 1\5 от быстродействия обычных, не уплотненных каналов, то есть около 10 гц.

Таким образом уплотненные мульти каналы нельзя использовать для управления рулями самолета - для этого нужно использовать обычные каналы, но для управления такими механизмами как камера, различные открывашки люков, зажигатели БАНО и прочих - данные каналы подходят как нельзя лучше !

Comments

Формат сигнала MULTI канала, здесь показаны только первая пачка с маркером размером в 750 мкс и две последующие пачки первого и второго мульти канала… после них еще две пачки мультиканалов(устал это рисовать!) и потом опять передается маркер и следующее состояние 4х каналов…

Дешифратор в настоящее время реализован на отладочной плате PinBoard v1.1 (подробнее о плате здесь -> shop.easyelectronics.ru/index.php?productID=147 внимание, это не реклама !!! можно сделать и на коленке !)

Схема соединений для тех кто возьмется повторить для экспериментов:

PORTB - алфавитно цифровой дисплей, в реальном устройстве его не будет, но его наличие на этапе разработки реально очень помогает!
по пинам сигналы дисплея подключены следующим образом (в скобках номер физического вывода для АТМЕГА16 в корпусе DIP40)

Подключение дисплея:
E - PORTB.0 (1)
RW - PORTB.1 (2)
RS - PORTB.2 (3)
D4-D7 - PORTB.4 (5)-PORTB.7 (8)
вывод PORTB.3 - свободный и не используется

Еще раз повторюсь - дисплей используется со стандартным интерфейсом для алфавитно цифровых HD44780

Кварц на 16 МГц подключен к выводам 12, 13 меги, стандартно кварц и пара кондеров

Сигнальный выход приемника подключен на ножку INT1/PD3 (17), какой из выводов у приемника является сигнальным читать здесь -> rcopen.com/blogs/50021/9292

Сигнал для серв снимается с выводов PA0-PA3 (40, 39, 38, 37)

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

Было бы здорово если бы кто нить смог нарисовать схему в чем нить графическом… а то я пока пачки PPM в ворде нарисовал - чуть не офигел! 😃

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

Теперь ПРОГРАММНАЯ ЧАСТЬ ДЕШИФРАТОРА

Программа написана на языке ассемблер, с одной стороны сделал это для того чтобы получить максимум быстродействия, с другой AVRStudio - это бесплатное свободно распространяемое средство разработки ПО…

Исходники проекта с поддержкой алфавитно-цифрового дисплея -> MULTI_D.RAR.html

Обращаю еще раз внимание, исходники под ATMEGA16, с кварцем 16 Мгц !

Как организован код дешифратора:

Старт, он у нас самый что ни на есть обыкновенный 😃

;------------------------------------------------------------------------------------------
;
; СТАРТОВЫЕ ПРОЦЕДУРЫ
;
;------------------------------------------------------------------------------------------
START:
                        CLI                                    ; запретим прерывания

                        LDI        R16        , low (RAMEND)        ; инициализируем стек
                        OUT        SPL        , R16
                        LDI        R16        , high(RAMEND)
                        OUT        SPH        , R16

                        LDI        R16        , 0xFF            ; конфигурируем младший полубайт
                        OUT        DDRA    , R16            ; порта A на выход - выходы каналов
                        LDI        R16        , 0b00000000    ;
                        OUT        PORTA    , R16


                ; конфигурируем прерывание по bit 3 PORT_D
                        LDI        R16        , 0x00        ; конфигурируем порт полностью на вход
                        OUT        DDRD    , R16        ; для работы с прерываниями int_1

                        LDI        R16        , 0b00000000    ; выключим резисторы подтяжки к шине +5В
                        OUT        PORTD    , R16            ;

                        LDI        R16        , 0b00001000     ; режим генерации прерывания по int_1
                        OUT        MCUCR    , R16            ; 0b0000xx00
                                                        ;        00 - низкий уровень прерывание
                                                        ;        01 - любое изменение уровня
                                                        ;        10 - падение уровня
                                                        ;        11 - установка уровня

                        LDI        R16        , 1<<INT1         ; разрешение прерываний по int_1
                        OUT        GICR    , R16            ;

                        LDI        R16        , 0                ; фаза 0 - ждем падения импульса
                        STS        IRQ_PH    , R16            ;
                        STS        CHNUM    , R16            ; номер канала для сохранения

                    ; настройка таймера Т1
                        LDI        R16        , 0                ; сбросим счетчик таймера
                        OUT        TCNT1H    , R16            ;
                        OUT        TCNT1L    , R16            ;

                        LDI        R16        , 1<<CS11        ; предделитель таймера 8 (010)
                        OUT        TCCR1B    , R16            ; частота счета 16МГц/8=2 МГц

                        LDI        ZL        , low(CH21)        ; инициализация значений выходных
                        LDI        ZH        , high(CH21)    ; каналов на 1500 мкс
                        LDI        R16        , low (3000)    ; у нас частота 16 мгц - поэтому
                        LDI        R17        , high(3000)    ; значение выходного импульса нужно
                        ST        Z+        , R16            ; умножать на два чтобы получить
                        ST        Z+        , R17            ; правильную длительность при счете
                        ST        Z+        , R16
                        ST        Z+        , R17
                        ST        Z+        , R16
                        ST        Z+        , R17
                        ST        Z+        , R16
                        ST        Z+        , R17


                        SEI                                ; разрешаем все прерывания

К слову, об алгоритме,

Выше приведены диаграммы сигналов PPM которые передатчик отправляет на приемник,
приемник получает сигнал PPM и раскидывает сведения о каждом канале на соответствующий выход по каналам, при этом на выходе каждого канала мы получаем так называемый PWM сигнал, с одним импульсом длинной от 1 до 2 мс и паузой 20мс-<длина импульса>

     ------
_____|    |_____________________________________________

здесь импульс длинной в 1 мс и пауза длинной в 19 мс

я долго ломал голову как совместить несовмещаемое 😃 и придумал следующее решение:
сигнал с приемника мы захватываем с вывода внешнего прерывания INT1
при этом в зависимости от переменной IRQ_PH мы выполняем следующие действия:
IRQ_PH=1 - мы ожидаем фронт импульса PWM, смотрите на рисунок выше!
после того как мы получили прерывание по фронту (нарастанию импульса), а проще говоря мы регистрируем начало импульса:

мы сбрасываем значение счетчика T1
в переменную IRQ_PH записываем ноль (это маркер того что теперь ждем спад импульса)
в регистр MCUCR - записываем режим ожидания спада импульса (проще говоря указываем что ждем пока импульс закончиться)

и выходим из прерывания !

Маленькая справка:
Счетчик T1 у нас 16ти битный, мы его настроили на счет с частотой 2 Мгц… после того как мы его сбросили (это команды TCNT1H=0, TCNT1L=0) он немедленно начал считать !!!

Ну так вот, ждем пока на вывод INT1 придет очередное прерывание, причем после выставления MCUCR это будет прерывания по спаду импульса
Получили прерывание,
смотрим IRQ_PH, если он равен нулю - то значит импульс закончился !
значит в счетчике T1 (а конкретно в регистрах TCNT1H и TCNT1L) находиться длительность импульса (кстати длительность считается так TCNT1H*256+TCNT1L)

Теперь эту длительность мы проверяем, не маркер ли это ?
Проверить очень просто,
мы знаем что маркер это сигнал с длительностью около 750 мкс…
разделим целочисленно 750\128=5 - это значение старшего регистра счета (TCNT1H) для T1.
если значение больше - то значит у нас передано значение канала,
если равно - значит это маркер
но у нас система передачи-приема сигналов аналоговая, поэтому в качестве значения для проверки я взял значение 7
если TCNT1H>7 - то значит у нас замерен канальный импульс, и его нужно сохранить для выдачи
если TCNT1H<7 - то значит у нас замерен маркер

все что описано выше в коде выглядит так:
от того что я написал только одно маленькое отличие - как только мы попадаем в прерывание, мы тут же сохраняем значение счетчика в переменной T1 (чтобы оно не успело исказиться (увеличиться) до того как мы решим что с ним делать), и сбрасываем его в ноль
гм…зря наверное переменную назвал T1 (таймер то у нас тоже Т1…) - но пусть вас успокаивает то что мы использовали только один таймер и только одну переменную 😃

;-------------------------------------------------------------------------------------------
;
;  ЧТЕНИЕ С MULTI КАНАЛА ЗНАЧЕНИЙ КАНАЛОВ
;
;-------------------------------------------------------------------------------------------

IRQ1REQ:                ; прерывание по EXT IRQ 1 (PD3)
                        PUSH    R16                    ; coхраним SREG и R16
                        IN        R16        , SREG
                        PUSH    R16
                        PUSH    R17
                        PUSH    ZL
                        PUSH    ZH
                        PUSH    YL
                        PUSH    YH

                        IN        R16        , TCNT1L    ; сохраним показания таймера
                        STS        T1        , R16
                        IN        R16        , TCNT1H
                        STS        T1+1    , R16

                        LDI        R17        , 0            ; сбросим счетчик
                        OUT        TCNT1H    , R17        ;
                        OUT        TCNT1L    , R17        ;

                        LDS        R16        , IRQ_PH    ; фаза ожидания сигнала
                        CPI        R16        , 0            ; ожидаем падение уровня ?
                        BRNE    IRQ1REQ_UP1            ; иначе ожидали фронт уровня - идем туда!

                        ; регистрируем падение уровня
                        LDS        R16        , T1+1        ; прочитаем старший байт таймера

                        CPI        R16        , 7            ; старший байт <7 - это управляющий импульс
                        BRCC    IRQ1REQ_GETCH

Чувствуете как просто ! помоему объяснял как работает дольше чем писал программный код !

Итак, продолжаем,

после того как проверили старший байт счетчика на маркер (сравнили с 7)
если наш старший байт >7 то вызываем процедуру IRQ1REQ_GETCH - это процедура сохранения считанной длительности канального импульса
в CHNUM у нас номер канала который мы сохраняем,
берем адрес переменной (это CH1, CH2, CH3, CH4) и сохраняем туда значение канала
потом увеличим CHNUM на единицу (чтобы в следующий раз сохранить следующий канал) и ограничим CHNUM значениями 0…3 (то есть после значения 3 будет идти значение 0 (ноль))

IRQ1REQ_GETCH:
                        LDS        R16        , CHNUM        ; прочитаем номер канала для ожидания
                        LDI        ZL        , low (CH1)
                        LDI        ZH        , high(CH1)
                        CLR        R17
                        ADD        R16        , R16        ; *2
                        ADD        ZL        , R16        ; СH1 + R16*2
                        ADC        ZH        , R17
                        ; здесь в Z у нас адрес переменной для сохранения канала

                        LDS        R16        , T1         ; сохраним значение счетчика
                        ST        Z+        , R16
                        LDS        R16        , T1+1
                        ST        Z        , R16

                        LDS        R16        , CHNUM            ; увеличим номер канала
                        INC        R16                        ; для сохранения
                        ANDI    R16        , 0b00000011
                        STS        CHNUM    , R16

Теперь второй случай,

старший байт счетчика < 7

Вот тут начинается интересное, если мы получили маркер, то нам в первую очередь нужно убедиться что мы получили все 4 канала перед ним (4 канала после предыдущего маркера)
для этого мы смотрим значение переменной CHNUM - и если она равна нулю - то значит были получены либо ноль каналов (такое вряд ли возможно и мы не обрабатываем это специально) либо все 4 канала, и значение CHNUM изменялось так 0, 1, 2, 3, 0
так вот если значение CHNUM=0 то мы копируем содержимое переменных CH1, CH2, CH3, CH4 в переменные СH11, CH12, CH13, CH14 - это переменные с подтвержденной длительностью канальных импульсов… в них данные попадают если маркер пришел вовремя и мы можем предполагать что вся серия из 5 пачек получена верно
если CHNUM не равно нулю - то значит мы не проводим копирование, где то был сбой, и фиг его знает что мы там получили…

в коде все выглядит так

                        LDS        R16        , CHNUM        ; берем CHNUM

                        CPI        R16        , 0            ; если CHNUM=0 то копируем каналы
                        BRNE    IRQ1REQ_NOCOPY
                        LDI        ZL        , low(CH1)
                        CLR        ZH
                        LDI        YL        , low(CH11)
                        CLR        YH
                        LDI        R17        , 4
IRQ1REQ_COPY:
                        PUSH    R17
                        LD        R16        , Z+        ; взяли значение канала
                        LD        R17        , Z+

                        ANDI    R16        , 0b11111110 ; отбросим младший 1 бит

                        ST        Y+        , R16        ; cохраним значение канала
                        ST        Y+        , R17
                        POP        R17
                        DEC        R17
                        BRNE    IRQ1REQ_COPY
IRQ1REQ_NOCOPY:

                        LDI        R16        , 0
                        STS        CHNUM    , R16        ; начнем читать каналы сначала !
                        RJMP    IRQ1REQ_DN_E        ; выйдем из процедуры импульса

Надеюсь что вы еще со мной и не потерялись в непонятках в недрах того алгоритма что я вам пытаюсь донести 😃

В принципе тот алгоритм что я вам объяснил работоспособен и будет успешно захватывать данные с MULTI канала и запоминать их в переменных T11 T12 T13 T14
Немного дописав код на вывод цифр на дисплей мы получим возможность просматривать импульсы какой длинны получены и дешифрованы
В проекте этот код уже написан, правда для вывода я использую другие переменные (об этом ниже расскажу) но если вам принципиально то можете смело менять например T21 на T11 и будете просматривать какие значения дешифратор получил с приемника и подтвердил их верность

                        INIT_LCD        ; инициализация дисплея

                        LCDCLR            ; очистка дисплея
LOOP:
                        LCD_COORD    0 , 0            ; печатаем мульти канал-1
                        LDI        R17        , 1
                        CALL     PRN_HEX8_L4
                        LDI        R17        , '-'
                        CALL    LCD_CHAR
                        LDS        R16        , CH21
                        LDS        R17        , CH21+1
                        CALL    PRINT_CH

                        LCD_COORD    8 , 0            ; печатаем мульти канал-2
                        LDI        R17        , 2
                        CALL     PRN_HEX8_L4
                        LDI        R17        , '-'
                        CALL    LCD_CHAR
                        LDS        R16        , CH22
                        LDS        R17        , CH22+1
                        CALL    PRINT_CH

                        LCD_COORD    0 , 1            ; печатаем мульти канал-3
                        LDI        R17        , 3
                        CALL     PRN_HEX8_L4
                        LDI        R17        , '-'
                        CALL    LCD_CHAR
                        LDS        R16        , CH23
                        LDS        R17        , CH23+1
                        CALL    PRINT_CH

                        LCD_COORD    8 , 1            ; печатаем мульти канал-4
                        LDI        R17        , 4
                        CALL     PRN_HEX8_L4
                        LDI        R17        , '-'
                        CALL    LCD_CHAR
                        LDS        R16        , CH24
                        LDS        R17        , CH24+1
                        CALL    PRINT_CH

                        RJMP    LOOP

PRINT_CH:
                        CLC                            ; разделим частоту на 2
                        ROR        R17                    ; так как частота кварца 16 МГц
                        ROR        R16                    ;
                        LDI        R23        , 4            ; количество выводимых цифр
                        CALL    PRN_BCD16
                        RET

На фото именно это и запечатлено (кликабельное фото почему то не получилось, но в принципе даже так видно что на экране):

вот ссылка на большое изображение ->radikal.ru/F/…/87910288daab.jpg.html

Теперь шаг 2 - нам по захваченным значениям каналов нужно сделать генерацию на 4 выхода (4 отдельных канала)

я сначала думал “мудрить” с каким то еще счетчиком, но прикол в том что 16ти битный счетчик у АТМЕГА16 только один и следовательно отмерять временные интервалы “за один раз” больше не на чем…

решение пришло такое
вспомним картинку импульса PWM который мы дешифруем с приемника:

     ------
_____|    |_____________________________________________

C момента начала импульса и до начала следующего у нас 20 мс…
сам импульс имеет максимальную длительность в 2 мс
почему бы на оставшееся время (а это без малого как минимум 20-2=18 мс) - не использовать таймер T1 для отмера интервалов импульсов каналов ?!
прикинь математику:
максимальная длина канального импульса 2 мс… у нас их 4 то есть всего нам нужно 8 мс… добавим небольшую паузу между ними, пусть в 1 мс = получим 12 мс !!! то есть мы успеем сгенерировать канальные импульсы и еще останеться 18-12=6 мс до прихода очередного импульса с приемника !!

В какой момент это все делать ?
правильно ! после того как обработали маркер или сохранили очередной канальный импульс !
в коде этот код начинается с метки IRQ1REQ_DN_E

Что мы там делаем:
Мы готовим к запуску наш таймер Т1 для генерации импульсов,
для этого мы делаем им небольшую паузу

                        LDS        R16        , T1
                        LDS        R17        , T1+1
                        LDI        YL        , low (65535-5000)
                        LDI        YH        , high(65535-5000)
                        ADD        YL        , R16
                        ADC        YH        , R17
                        ; в Y длительность паузы

                        OUT        TCNT1H    , YH        ; делаем паузу для выравнивания импульсов
                        OUT        TCNT1L    , YL        ;

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

                        LDI        R16        , 1<<TOIE1        ; включим прерывание по переполнению
                        OUT        TIMSK    , R16            ; таймера

                        LDI        R16        , 0            ; номер канала для выдачи
                        STS        CHOUT    , R16        ;
                        STS        OUT_PH    , R16        ; фаза выдачи

Тут наверное нужно пояснение,

у счетчиков есть регистры в которых содержится текущее значение счетчика… у 8ми битных счетчиков это один регистр, у 16-ти битных счетчиков два регистра…
так же счетчик может вызывать прерывание при переходе счетчика через ноль… то есть считает например 16-ти битный счетчик 65534, 65535, - следующее значение при 16-ти битном счете 0 (ноль!) - вот в этот момент и возникает прерывание ! то есть процессор перейдет на процедуру которая обрабатывает переполнение счетчика
в нашем коде мы задали следующее значение счетчика для паузы:
(смотрите это я уже приводил чуть выше!)
LDS R16 , T1
LDS R17 , T1+1
LDI YL , low (65535-5000)
LDI YH , high(65535-5000)
ADD YL , R16
ADC YH , R17
; в Y длительность паузы

То есть счетчик будет равен 65535-5000=60535 + значение последнего импульса с приемника в переменной T1
таким образом у нас пауза всегда будет обеспечивать чтобы генерация импульсов на выходные каналы начиналась примерно через 2,5 мс после начала импульса приходящего с приемника…
фактически остальная работа делается в прерывании по переполнению счетчика T1

Процедуру передачи захваченных значений пока описывать не буду по следующей причине:

уже 2 дня эксперементирую с генерацией канальных импульсов… сервы откликаются и двигаются…
причем если стиком двигать быстро - то сервы точно встают в нужное положение, а вот если со средней скоростью - то в движениях наблюдаются небольшие рывки…
как бы понятно почему - частота обновления у нас уменьшилась в 5 раз… но все равно как то не по феншую…
сейчас, и в этом варианте выложены исходники выше, я сделал программное замедление серв - то есть значение канального импульса для их управление меняется постепенно, причем это замедление сделано на уровне дешифратора (на передатчике ничего крутить не нужно)
в принципе введение замедления - сделало движение серв более плавными (рывки почти полностью ушли) - но одновременно сервы стали двигаться медленнее… если раньше на перекладку из одного положения в другое уходило около полусекунды то сейчас это занимает секунды 3…
в принципе так управлять например камерой думаю было бы даже удобнее - не пролетишь нужное положение 😃 но поскольку думаю я не только о камере- то копаю дальше…

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

вотс !!

кстати, сегодня попробую купить в магазине attiny2313 и сделать дешифратор на ней…
в связи с этим вопрос - а кто и где покупает контроллеры для своих проектов ? а то частенько вижу обсуждения что мол тинька стоит 50 рублей… а вот где ее можно купить за 50 рублей никто не пишет 😦

Посмотри на goodluckbuy.com от от 10ти штук какраз в районе $1.5 за корпус получаеться
А не моглибы вы одним файлом скетч под atmega 8 выложить? Судя по фрагментам для задачи много памяти не требуеться и производительности на 8 МГц (от внутреннего генератора) должно хватить.

targetorsk;bt63195

Посмотри на goodluckbuy.com от от 10ти штук какраз в районе $1.5 за корпус получаеться

гм. то ли я искать не умею 😦 то ли не туда зашел… но атмег я там не нашел… очень много PICов всяких… а авр’ок всего штук 5 было во всем списке…

targetorsk;bt63195

А не моглибы вы одним файлом скетч под atmega 8 выложить? Судя по фрагментам для задачи много памяти не требуеться и производительности на 8 МГц (от внутреннего генератора) должно хватить.

Угу… чуть позже… я вообще планирую в тиньку2313 все засунуть… там кода на килобайт не набереться…

кстати, вчера зашел в местным торгашам… гм… купил атмега8 за 260(!) рублей (для экспериментов нужно уже сейчас) я в шоке… в Москве я 128ую мегу брал помоему за 360 рублей… а тут восьмая !

Для поиска электронных компонентов используй сайт www.efind.ru

Я всю жизнь не понимал, что народ в этих мегах находит. Сплошной изврат. При програмной реализации счетчиков и ШИМ через прерывания В ЛЮБОМ СЛУЧАЕ БУДУТ присутствовать дрожание и выпадение сигнала. Подобные вещи я уже проходил. От наложений прерываний и совпадений сигналов избавиться невозможно.

Виталий! посмотри процессор PIC18F25K22. При стоимости 70 руб. имеет 5 аппаратных выходов ШИМ, 7 таймеров, захват длительности входных импульсов, АЦП, ЦАП и еще кучу всего. Позволяет непосредственно на выходы вешать приличные нагрузки до 25 мА.
Самое главное - работает на частоте 64 МГц от встроенного генератора!!!
Подключил питание и вся схема собрана! Никаких монтажных плат не требует, максимум панельку можно поставить.
Процессор доступен в корпусах DIP, SOIC и более мелких при тех же ценах.

Давай на этом проце проект замутим. Программа получается всего несколько байт. Считал значение с захвата длительности, записал его в регистр ШИМ и все. Все выполняется аппаратно, глюки, дрожания длительности гарантировано исключены.
Среда программирования абсолютно бесплатна. Есть С компилятор, могу подкинуть. Думаю для таких проектов памяти 64 кБ выше крыши будет.
Что скажешь?

вот atmrga8 - $12 за 10 шт с доставкой
www.ebay.com/itm/ws/eBayISAPI.dll?ViewItem=&item=2…
атмега 644 брал на elitan.ru по 188 руб за штуку, при заказе можете ввети ноер моей карты 0000086467675380 получите скидку сразу, потом можно будет себе карте заказать.

Если будет время и желание скомпелить на Atmega8 то могу вам задарить (передать через маршрутку) данную микруху в DIP корпусе для тестирования.

Эхх… в общем в пятницу я сделал контроллер, и он даже достаточно успешно работал… а вот в субботу я ошибся при разводке питания на плате - и спалил мегу нафиг 😦

сегодня закажу новую (как то не радует меня перспектива покупать за 260 рублей 😃)) и как придет реализую, отфотаю, выложу…

по поводу PIC - фиг его знает, с мегами у меня уже есть накопленный опыт, начинать заново на PIC как то не хочется… да и купили же уже отладочную плату под AVR (реально очень помогает в разработке !)…
Поэтому сейчас перейти на чтото другое не готов…
по поводу дрожания серв и так далее - это проблема не контроллера а двойного преобразования Кодер-передатчик - приемник - дешифратор… как минимум кодер-передатчик и приемник-дешифратор преобразовывают сигнал… вот и погрешности

Кстати сейчас реализован следующий функционал дешифратора:
вход:

3 линии задания скорости изменения значений в выходных каналах
выход:
4 пропорциональных канала передаваемых в мультиканале
4 линии по каналам, лог. “1” при длительности канала >1500 мкс (для каждого канала в мультиканале)
4 линии по каналам, лог. “1” при длительности канала <1500 мкс (для каждого канала в мультиканале)
1 пропорциональный канал - замедленный входной (для использования дешифратора как канального замедлителя)

Так что в принципе с дешифратора можно будет снимать и пропорциональный сигнал, и обычный логический уровень для включения например БАНО или еще чего нить (когда PWM не требуется)

Платка получилась вот такая: narod.ru/disk/30746428001/vcoder_dm.lay.html

Самый левый резистор (внизу, под входящим разъемом) - 10 кОм - подтяжка линии RESET, в принципе можно не ставить работает и без него, но во избежании проблем - лучше запаять

Внизу между разъемами - кондерсатор на 0,1 мкф - защита от помех при работе серв… у меня работало стабильно и без него, но думаю что не помешает…

справа-вверху - резистор 500 ом + светодиод - цепь индикации преобразования мультиканала - если индикация не нужна то можно не ставить 😃

Разъемы слева на право сверху вниз,
группа из 4х трехконтактных разъемов - выходы 4х пропорциональных дешифрованных мультиканалов, сигнальный вывод помечен “S” на плате,
один трехконтактный разъем- замедленный входящий канал (при мультиканале- маркер мультиканала)

группа из 4х двухконтактных разъемов - логические выходы каналов при значении каналов > 1500 принимает значение лог. “1” (+5 в)

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

слева на право ниже микрухи:
4х контактный разъем - входящая цепь задания скорости изменения каналов, участвуют 3 левыx линии, 8 значений задержки (двоичное задание скорости)
правый нижний разъем, 4 линии справа налево - выход логического значения при длительности каналов <1500 +5в
два левых ряда этого разъема пока не используются (еще думаю что туда засунуть 😃

ВитГо;bt63438

Платка получилась вот такая:

Эм, а где кварц (на 12-13 ножках, из первого поста)? Или в данном варианте он не нужен (работает внутренний генератор)? Это уже под АтМега 8, как я понимаю?

Кварц не нужен, используется внутренний на 8 мгц… там получилось что его за глаза… контроллер АТМега8, в корпусе DIP
в принципе как соберу - проведу натурные испытания дрейфа меги (на балконе сейчас очень холодно 😃 - и решу нужен он или нет…

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

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

угу… правда завтра-послезавтра меня здесь не будет (сегодня в ночь уезжаю в коммандировку в Самару)…

Столько логических каналов нужно не часто,отсюда вопрос возможно сделать 2-ю прошивку (сразу на 8 мутиплексированных каналов 2 входа) и распределить каналы примерно так:

3 линии задания скорости изменения значений в выходных каналах
выход:
4 пропорциональных канала передаваемых в мультиканале
4 пропорциональных канала передаваемых в мультиканале (второй выход+1 вых реконфигурить на вх.)
1 линия по каналам, лог. “1” при длительности канала >1500 мкс (2 канал во 2 мультиканале)
1 линия по каналам, лог. “1” при длительности канала <1500 мкс (3 канал во 2 мультиканале)
1 Проблесковый маячек (для последнего канала во 2 мультиканале) с частотой мигания
1000- лог 0
1200-1500 - 1 Гц
1600-2000 - 5 Гц (или - … )
1 пропорциональный канал - замедленный входной (для использования дешифратора как канального замедлителя)

И еще подумав можно сделать 3-ю 4 шим выхода 8+1 дискретных (для запуска пиротехники) т.е. для того чтобы случайно не запустить бабах, одельным тумблером подаем “1” на доп. линию (готовность) повесив на нее замыкатель земли, а оставшиеся 8 после этого запаливают сами устройства + замедленную

Вопрос Виталию: каким образом дешифратор будет детектить фейлсейф? Тут ведь возможны 3 варианта:
1 - собственно, фейлсейфа нет, при потере связи PWM не генерируется (родные приемники Турниги). Тут все просто - нет сигнала, выставляем заданные значения на выходах.
2 - фейлсейфа нет, но приемник при потере связи сохраняет последнее принятое значение (FrSky, если фейлсейф не запрограммирован). Как ловить Ф/С в этом случае? Пока на ум приходит только длительное отсутствие изменений канальных импульсов…
3 - при потере связи приемник выставляет заранее установленное значение. Тут тоже все понятно, но нужно иметь возможность это самое значение фейлсейфа запомнить в дешифраторе.

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

p.s. Сборка собственного экземпляра пока откладывается. В местном радиомаге контроллеров нет вообще никаких. Теперь надежда только на то, что в скорости удастся выбраться в Ижевск.

И может стоит реализовать программирование начальной установки Мульти-устройства при вкл. ему питания без наличия сигналов от приемника!

Привет Всем !!

Я снова в коммандировке, на этот раз в Тарко-Сале (попробуйте найти на карте!)
буду в Оренбурге только после 20го декабря…
так что пока эксперименты с дешифратором пришлось прекратить (отладочную плату то я с собой взял, а вот аппаратуру взять не получилось, итак две хороших сумки пришлось брать 😃))

По поводу ваших вопросов:

пока дешифратор будет 1->4… то есть из одного входящего канала делаем 4…
для подавляющего большинства этого достаточно, тем более что используя два дешифратора вы получите желаемые 2->8

по поводу кодирования сигнала при уплотнении с аппаратуры на дешифратор - наверное еще раз поменяю формат…
причина достаточно интересна: приемник при получении сигнала с передатчика может запросто пропустить например один пакет (!) и поэтому по каналам повторяет последние полученные верные данные…(! 😦 )
если при этом вспомнить что дешифратор после маркера (700 мкс) считает 4 посылки - посылками канала - то становиться совсем не приятно - так как фактически первый мультиканал может быть передан например дважды ! - дешифратор возьмет его и в качестве первого и потом второго, потом сразу пойдет третий канал (и тоже например дважды!)…
вот такие вот дела…
не зря я задумывался о цифровом осциллографе - как одним местом чувствовал что где то связка передатчик-приемник подкинут проблем 😃

но тем не менее - как решить эту задачку я уже придумал ! (не зря в поезде 4 суток ехал!) - так что обещаю что дешифратор все равно закончу и он будет работать ! 😃)))

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

при всем выше написанном я не ожидаю изменений в печатной плате… изменения будут касаться фактически только кода… так что если кто начал делать плату и покупать детали - можете не переживать - все будет в силе !

lexash;bt63696

Вопрос Виталию: каким образом дешифратор будет детектить фейлсейф?

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

lexash;bt63696

Тут ведь возможны 3 варианта:
1 - собственно, фейлсейфа нет, при потере связи PWM не генерируется (родные приемники Турниги). Тут все просто - нет сигнала, выставляем заданные значения на выходах.
2 - фейлсейфа нет, но приемник при потере связи сохраняет последнее принятое значение (FrSky, если фейлсейф не запрограммирован). Как ловить Ф/С в этом случае? Пока на ум приходит только длительное отсутствие изменений канальных импульсов…
3 - при потере связи приемник выставляет заранее установленное значение. Тут тоже все понятно, но нужно иметь возможность это самое значение фейлсейфа запомнить в дешифраторе.

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

lexash;bt63696

p.s. Сборка собственного экземпляра пока откладывается. В местном радиомаге контроллеров нет вообще никаких. Теперь надежда только на то, что в скорости удастся выбраться в Ижевск.

вот и у меня в городе примерно такая же фигня… а те что были - стоили не нормальные деньги 😃

targetorsk;bt63603

Столько логических каналов нужно не часто,отсюда вопрос возможно сделать 2-ю прошивку (сразу на 8 мутиплексированных каналов 2 входа) и распределить каналы примерно так:

я не делаю более 4х каналов из за того что уже сейчас заметны потери в быстродействии… если каналов внутри мультиканала будет еще больше - то боюсь что это будут логические а не пропорциональные каналы 😦
в любом случае - сейчас на VCoder’e обкатаем дешифратор на 1->4 а потом бум думать как навернуть во втором…

targetorsk;bt63603

И еще подумав можно сделать 3-ю 4 шим выхода 8+1 дискретных (для запуска пиротехники) т.е. для того чтобы случайно не запустить бабах, отдельным тумблером подаем “1” на доп. линию (готовность) повесив на нее замыкатель земли, а оставшиеся 8 после этого запаливают сами устройства + замедленную

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

На новый год пришла ко мне посылка с чипстера, так что пора наверное вернуться к теме дешифратора мульти-канала.
плату решил сделать на tiny2313 - она меньше восьмой меги…
из дискретки останутся только уровни единицы когда значение канала больше середины
сейчас уже нарисовал печатку, завтра отутюжу… собирать наверное буду позже, завтра у меня небольшой праздник намечается…

Это готовая плата дешифратора на 8-й меге.

красиво… сейчас буду заливать свой 😃

(утром спаял…)

09.01.2012 16:24 ??? Сейчас уже 02.04.2012 , а утро то было???

ViktorDoma;bt67066

Это готовая плата дешифратора на 8-й меге.

А не поделитесь схемой и прошивкой?

ВитГо;bt64249

по поводу кодирования сигнала при уплотнении с аппаратуры на дешифратор - наверное еще раз поменяю формат…
причина достаточно интересна: приемник при получении сигнала с передатчика может запросто пропустить например один пакет (!) и поэтому по каналам повторяет последние полученные верные данные…(! 😦 )

А что если кординально поменять протокол?
Мое предложение: задействовать еще 1 канал для передачи в явном виде (не то чтобы совсем в явном, но в виде ШИМ, конечно) номера текущей последовательности. Это, само собой, минус канал, но что получаем?

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

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

Сетап для примера: 4 канала на органы самолета(без мульти), еще 2 на поворотку камеры, и еще пару тем, которые не должны работать сильно медленно (мультиканал и счетчик 1…4), и остальные 8 каналов вешаем на оставшиеся 2 (мультиканал и счетчик 1…8. Такими каналами вполне можно менять настройки/режимы автопилота, крутить закрылки/шасси, открывать щитки, створки, и т.д. и т.п.).

Наиболее подходящим будет вариант с масштабированием точности.
Т.е. если в исходном сигнале длительность 0-25% - переносим ее в первый выходной канал 0-100%.
Соотв 25-50% во второй выходной канал и т.д.
Если подумать, то и небольшие защитные интервалы на границах можно поставить.
Получается мы гарантированно защищаемся от разных сбоев передачи. Упадет точность, да бог с ней. На доп каналы вряд ли будут вешать критичные рулевые поверхности.

Не думаю, что это наиболее подходящий. Просто один из вариантов. Под разные задачи будет подходить разное. Точность это и так параметр меняющийся от расстояния и качества передачи, если его еще понижать, каналы начнут попросту самопроизвольно “плавать”. Скажем, тот же поворот камеры на “плавающий” канал я б вешать не стал, усугубляет головокружение 😃 Хотя опять же все зависит от уплотнения, если пару канало запихнуть в 1, то наверно это будет даже не заметно, но без канала-счетчика эта величина будет константой, и врядле равной 2 😃

я тоже пришел к варианту с масштабированием точности
от 1000 до 1200 - 1ый канал
от 1250 до 1450 - 2ой канал
от 1500 до 1700 - 3ий канал
от 1750 до 1950 - 3ий канал

Ну раз решили, значит решили. Только в качестве некоторого увеличения точности надо взять пошире диапазон. Хотябы 800-2200, или еще больше, до максимального. Сервам этот диапазон отрабатывать все равно не придется.

ну можно и по шире, но сильно точность от этого не вырастит…