OSD на ATmega1281
доброжелателей с Новым годом!
И Вам того же.
новые трудовые подвиги…
Эта завсегда.
Великого народного праздника, дописал-таки вчерне софт
О, на это и надежда, праздники длинные.
принимает PPM, приемник выдает PWM по своим каналам и передает по UART для АП/ОСД.
а как насчет параллельного обратного TX канала через RFM22?
АП/OSD уже принимает (и понимает) значения приемника по UART. Особенно понравилось, что теперь “палки” качества сигнала показывают не абстрактных попугаев, а вполне конкретные dbm (пока от -70 до -20 с шагом 10)
А ну с палками ИМХО актуальнее диапазон от -100dBm что бы не прозевать момент когда вырубят, да и задача OSD вернуть на базу.
Вот так вот мотивируем а когда ознакомиться поближе сможем:)
Обратный канал пока не планирую. Летать по приборам не интересно, да и 100мвт линк вряд-ли обеспечит надежную связь на вменяемых расстояниях. Правда приемник при потери канала периодически включается на передачу, для поиска gmrs рацией (режим - “маяк”).
актуальнее диапазон от -100dBm
Сейчас много по работе приходится заниматься установкой WiFi подобных систем на 2.4 и 5.8. Практика показывает, что при уровнях меньше -75…-80 даже со стационарными антеннами вне крупных населенных пунктов ни о какой надежности канала говорить не приходится. 433 имхо несравнимо более шумный диапазон, поэтому -70 выбрал нижней границей именно
что бы не прозевать момент когда вырубят
. Практические испытания покажут куда скорректировать эти границы.
Выложу все hexы/исходники тоже после полевых испытаний, те. не раньше весны (если будет положительный результат конечно…).
Сейчас надо дописать еще режим бинда приемника, а то пока приходится конфигурацию вливать по uart и в передатчик и приемник.
полевых испытаний, те. не раньше весны (если будет положительный результат конечно…).
А весна это когда (это когда выборы)? А как мы подготовимся к встрече кода, нужно жеж железо подготовить😒
Я тут чьи-то уши прожужал по поводу propagation losses. Получается по грубым
прикидкам на 10 км -129.5dB а энергетика канала при front end 30dBm - 165dB
и антеннах по 8dBi остается в запасе 35dB вполне может хватить и на 100мвт и приличный SNR.
WiFi подобных систем на 2.4 и 5.8
А что ставим? Cisco?
2 msv возможно ли ваш проект использовать в сокращенном виде?
собственно очень интересует осд система для Ardupilot и ArdupilotMega, кто то заметит что осд для нее уже придумали и она скоро будет в продаже, но она основана на схеме ремзиби, у нее три существенных недостатка
1 очень дорогая микруха видечипа
2 прожорливая по току эта микруха по тактильным ощущениям не меньше ампера
3 закрытый программный код - ни продебажить ни понять чего он от тебя хочет.
За прошедшие полгода я спаял и протестировал “вдоль и поперек” плату сенсоров которая ardupilot imu v2 flat (это типа 6DOF ) 3D гиро + 3D аксель, вход жпс, возможность подключения компаса с отлаженным кодом их обработки, есть библиотеки под баро, на выходе по сериалу устройство выдает результат в простом и понятном виде. логично было бы его применить вместо пиродатчиков. Кстати себестоимость деталей вполне сносная - около 1500р
лично моя потребность это осд система без дорогих и прожорливых по току деталей, в которую по сериалу можно передать данные о горизонте и вывести в определенное место на экране показания датчиков телеметрии (возможно также по сериалу передавать координаты начала строки и желаемый текст)
а функции стабилизации и навигации от дать на откуп ардупилоту, такое решение упростило бы код за счет что не надо учитывать кучу прерываний - один процессор - одна функция - ОСД, но надежная и универсальная.
поскольку задача не такая уж и простая, позвольте несколько вопросов
- я особо в с++ и тем более в ассемблерных вставках не кумекаю, возможно ли это реализовать в среде более всокого уровня, на Arduino?
- какой чип следует выбрать? обязательно 1281 или потянет 328 / 1280 / 2560? (эти чипы поддерживает ардуино )
если вам интересена тема заменить пиродатчики на ardupilot imu v2 flat
я бы мог посодействовать бесплатно выслав заводскую печатную плату (я заказывал в резоните для себя, но при заказе одной ценник 2000р а 20шт стоят 2500, вот я и заказал с запасом)
2 all
в теме было еще обсуждение, про 10 герцовые жпс, и утилиту MiniGps 1.4
я в последнее время активно пробиваю тему поиска надежного и точного приемника, попутно нарыл последнюю версию, 1.7 - в ней особо нового не прибавилось, но опция 10 герц есть, я пробовал один из своих модулей, реально вываливает десяток строк с одной секундной меткой при записи в лог,
если кому надо качнуть можно тут: hobby.msdatabase.ru/…/ardupilot-gps
для отображения вкладок setup нажмите Ctrl + Alt + S
какой чип следует выбрать? обязательно 1281 или потянет 328 / 1280 / 2560?
Ардуино, точнее, GCC, допускает ассемблерные вставки, но там настолько все мутно, что не стоит связываться.
Без ассемблера при скорости атмеги 16 МГц возможно делать только унылые текстовые ОСД с огромными буквами.
Выбор чипа при одинаковой тактовой определяется его объемом SRAM - это напрямую связано с тем, что нужно выводить на экран. Если это более-менее пристойная графика, то нужно делать экранный буфер на весь экран (ширина*высота). При разрешении 128х128 пикселей это 2 кБ памяти только под буфер. 240х240 (практически максимум для атмеги по разрешению) - это 7.2кБ. 8 кБ памяти имеют 1280, 2560, 1281…
Если тупо 4 строки по 20-40 знаков, то подойдет любая атмега, т.к. буфер только символьный 160 байт, а шрифт берется из flash.
Для примера, как все работает, в т.ч. ассемблерные вставки, посмотрите MegaPirate OSD - перешитый Hobbyking E-OSD, исходники открыты, автор йа. Там и графика, и текст, а чип - всего лишm atmega88. Видео по сети тоже валяются.
спасибо огромное за ликбез!
и за код и за выкладку по ттх чипов.
сразу возникла гипотеза- вопрос как к автору что если к примеру не весь экран держать в рам, а поделить на несколько зон,
и к примеру если брать за раскладку сабжевое осд - есть средняя зона в которой искусственный горизонт - его черточки можно высчитать и на лету в на верхнюю и нижнюю части для вывода текста затратить рам?
или держать в рам не весь экран а подготавливать процессу выводящему биты несколько строк налету?
Собственно, так и сделано в мегапирате 😃 В центре панель 64х64 точки, индикатор крена, тангажа и указатель “домой”.
Сверху и снизу по 2 строки по 40 символов + одна статусная строка с мигающими символами всяких аварий, 5 символов.
Центральная панель держится целиком в памяти, а вот строки - это один массив в 160 байт, в котором только ASCII-коды символов. В строчном прерывании знакогенератор (программный) подставляет соответствующие символы из шрифта.
В принципе, можете повторить (или даже купить - $12) схему Е-ОСД, там кроме резисторов, пары кондеров, atmega88 и одного транзистора ничего нет. Кварц там на 24МГц: разогнали чип. Распространения переделка не получила, т.к. для получения ком-порта нужно паяться к ноге микрухи в корпусе 5х5мм 😃
У меня на ютубе есть несколько роликов с megapirate osd
www.youtube.com/user/syberian1980?feature=mhee
Если есть какие-то еще вопросы, пишите в личку, не будем тему Сергея засорять.
Да я не против… 😃 А то мои монологи уже всем надоели…
2 msv
вовсе нет, очень интересно, даже неудобно лишний раз спросить…
в обсуждении была картинка с алгоритмом автопилота (страница 2 пост 54) , я распечатал чтоб изучить но не читаются надписи, непонятно. хорошоб покрупнее
А то мои монологи уже всем надоели…
Отнюдь, все по делу, ждемс не дождемся исходников.
Даже если Сергей их выложит, там, подозреваю, черт ногу сломит. Сплошной асм. Имею в виду ОСД. Другими средствами такую красивую картинку не получить, да еще и навигация…
если Сергей их выложит, там, подозреваю, черт ногу сломит.
Ну дык уже влез, железо на мази, приходится на кого то полaгаться. Тут по ходу присматриваюсь к OpenPilot GCS.
была картинка с алгоритмом автопилота…
Сейчас она малость устарела… Будет время, пройдусь по коду, обновлю… Кстати тогда был разочарован, что не было никаких вопросов, замечаний, предложений…
Кстати, Сергей, а генерацию видео при помощи SPI делаете или вручную сдвиг делаете ?
К сожалению передающий регистр SPI в атмегах не буферирован и выводить им графику не получится. Приходится программно двигать. Ближе к началу темы есть исходный код вывода строки.
простите за дилетантский вопросик, а в атмегах нельзя делать непосредственный сдвиг в выходном порту
типа portb<<1 ?
чтоб сдвиг за один такт, конечнож потеряются остальные выводы порта для использования с другим функционалом, но у атмеги их полно
Такой команды в атмегах нет. Собственно за один такт все равно не получится, надо подгружать данные в порт, проверять условия… Но здесь уважаемый abalex предложил гениальный код вывода строки всего по 3 такта на пиксель.
К сожалению передающий регистр SPI в атмегах не буферирован и выводить им графику не получится. Приходится программно двигать. Ближе к началу темы есть исходный код вывода строки.
что значит не буферизирован ?
я тут считал как то…
настраиваем частоту spi например на 1/2 такта (при тактировании в 16 мгц это будет 8 мгц - это 8 точек на 1мкс!!)
и далее:
-подготовили байт для выдачи
loop:
-ожидаем освобождения регистра данных spi
-отправляем байт для вывода в SPI SPDR (после этого spi сам будет сдвигать байт выдавая его на MOSI, и после передачи последнего бита выдаст флаг освобождения - по нему можно либо прерывание либо просто ожидание делать в цикле вывода)
-проверим все ли байты строки передали, если да то выходим
-пока передается байт по spi готовим следующий байт, у нас на это около 10 тактов (уже 2 потратили на проверку всю ли строку передали, еще 2 нужно будет на переход, и еще 2 на проверку освобождения SPI)
-переход на loop
таким образом технически разрешение по горизонтали которое можно достичь достигает около 52 мкс*8=416 точек, ИМХО, это очень даже неплохо для телевизора, пусть по 50 точек слева и справа оставим на бордер, останется 300 точек по горизонтали, столько же по вертикали - ИМХО хорошее поле для вывода!
в данном алгоритме мы на вывод пискела тратим 2 такта 16 мгц… + самое главное пока пикселы байта выводятся - мы не теряем время, и готовим следующий байт для вывода ! то есть накладных расходов между байтами вообще небудет !! ИМХО это важно поскольку позволит при достаточно серьездном разрешении получить отсутствие эффекта увеличения интервала каждые 8 точек… я не помню можно ли тактировать SPI от тактовой частоты… тогда вывод будет еще более мелкий… причем мы все равно будем успевать !
я планировал использовать внешнюю память, тем более что мне тут дали наводку на atmega162 - если к ней подключить внешнюю RAM то на все поле телевизора можно хоть картинку выводить ! (иначе не хватает внутренней памяти меги для хранения)
p.s. кстати в smalltim mini вывод тоже сделан сдвигом вручную (не так как я написал выше)…странно… я думал там сильная проработка вывода сделана…
p.p.s. посмотрел стр163 даташита на мегу162 - делитель spi не менее 2… так что разрешение что я описал максимально
я планировал использовать внешнюю память, тем более что мне тут дали наводку на atmega162 - если к ней подключить внешнюю RAM то на все поле телевизора можно хоть картинку выводить ! (иначе не хватает внутренней памяти меги для хранения)
если текст или векторная графика зачем ей забивать память? на обратном ходе строчного импульса налету считать строку и помещать ее в массив в рам, а на обратном ходе кадрового импульса считать векторы и подготавливать текст по позициям
с spi может быть засада что если ждать освобождения то это значит когда 8 бит выведены будет задержка на 1 такт минимум и это отразится на картинке
если текст или векторная графика зачем ей забивать память? на обратном ходе строчного импульса налету считать строку и помещать ее в массив в рам, а на обратном ходе кадрового импульса считать векторы и подготавливать текст по позициям
ну если кроме как считать графику больше делать нечего то согласен, а иначе не будет других задач…
тем более что строчный импульс это всего 8 мкс на все, включая прерывания… это в лучшем случае 64 команды - особо не рассчитаешь ничего
кадровый тоже не настолько велик чтобы успеть чтото расчитать из графики…
а у нас тут еще кучу периферии нужно обслужить…
так что никакой графики на лету не получиться 😦 это я уже считал…
с spi может быть засада что если ждать освобождения то это значит когда 8 бит выведены будет задержка на 1 такт минимум и это отразится на картинке
к сожалению моя макетка другим занята, поэтому я не занимался реализацией и оптимизацией алгоритма, но уверен что можно сделать “гладкий вывод” без какой либо задержки (посчитать такты команд наконец!)…
еще раз повторюсь получив очень большое разрешение, можно добиться того чтобы картинка была очень гладкой… времени на это предостаточно! получили ведь 16 тактов запаса при отправке байта ! вопрос только как их использовать… быстродействие в 2 такта на бит - тоже очень не кислый результат…
в текущей реализации 3 такта на один бит изображения и никаких запасов или возможностей к улучшению… 😦
Эх… если бы на SPI был аппаратный буфер хоть 1 регистр… жизнь была бы проста и неинтересна…
А тут… если такты считать и синхронно после передачи последнего бита (такт в такт!) записывать в сдвиговый регистр SPI след. байт… Может и есть шанс… Но ни о каком опросе флагов и тем более прерывании речи быть не может…