Создание собственной системы стабилизации
Искурив весь даташит на F407, всёж заставил его работать как аппаратный OSD (использование ядра - 0%), таким образом имеем контроллер полёта+OSD в одном флаконе, цена вопроса: 38 килобайт ОЗУ (640х480 монохром), LM1881 и 74HC08…
Кому интересны подробности, поделюсь…
мавлинк - осд интересно (без функций автопилота)
но чтоб работало железно не только когда есть внешняя синхра но и в случае если сигнал от камеры пропал
как аппаратный OSD (использование ядра - 0%),
ну там не совсем 0% наверно? Запуск нового кадра и строки ведь программно?
но чтоб работало железно не только когда есть внешняя синхра но и в случае если сигнал от камеры пропал
Это возможно, не знаю как у Олега сделано, можно сделать автономное формирование синхроимпульсов с ног таймеров проца, сами таймеры обвязать петлёй ФАПЧ с задачей от ЛМ1881.
Вот только ног у проца на полетнёг уже не хватит, на ОСД нужен отдельный.
ну там не совсем 0% наверно?
Именно - 0… (из за этого и возился, почти месяц).
Вот только ног у проца на полетнёг уже не хватит
И ног хватило: весь полётник (6 каналов) + DAC говорилка + MICRO/SD + ADC(2 канала)… всё пашет.
Именно - 0… (из за этого и возился, почти месяц).
0 - это на вывод картинки. а сколько уходи на генерацию картинки?
а сколько уходи на генерацию картинки?
А какая теперь разница (?)…, пиши в память что угодно и когда угодно, главное что реалтайм свободен (никакие прерывания друг об друга не спотыкаются) и артефактов на картинке никаких… и никакие мавлинки с проводами не нужны…
Чёт мне не верится… допустим даже не надо перерисовывать всю картинку а только вносить изменения - их нужно взять и перенести - когда - ну допустим когда проц “курит” между циклами, это опять же при условии, что петля не слишком “страшная” типа вий марг… если что-то посерьёзней - будет не есть гуд, далее заряжаем ПДП SPI, а там х.з. во, вернёмся к нашим баранам - в пресловутом Pixhawk с его 428-м процем при использовании ИНС на EKF (50Гц) и полного логирования - петля впритык 400Гц и есть предупреждения, что цикл не стабилен! (можно любой лог с пикса взять) И вы утверждаете что загрузка ОСД = 0% времени ядра? сомневаюсь…
стоп а ПДП из памяти в память можно?
загрузка ОСД = 0% времени ядра?
Сам процесс отрисовки у большинства OSD требует прерывания с наивысшим приоритетом (15625 Гц) как раз для “перезарядки” DMA SPI, которое несмотря на навороченный NVIC, происходит с с разной задержкой в зависимости от того - чего оно прерывает… таким образом про другие реалтайм прерывания можно забыть…
А у меня теперь проц даже не знает, что три его таймера сами выводят картинку на экран, моё дело теперь - только в видеобуфер кидать точки… типа “видеокарты stm” получилось…
DMA на OSD все равно немного мешает остальному т.к. держит шину данных
DMA на OSD все равно немного мешает остальному т.к. держит шину данных
поэтому существует специальный тип памяти для видеокарт двуканальный память одна а шин две
через один канал проц кладет картинку
через второй счетчик пикселей выгружает на выход
Кому интересны подробности, поделюсь…
Конечно интересны, делись! Я так понимаю, теперь весь вопрос в создании ПО, с этим может чем поможем!
поэтому существует специальный тип памяти для видеокарт двуканальный память одна а шин две
через один канал проц кладет картинку
через второй счетчик пикселей выгружает на выход
Ну в F4 помойму не такая SRAM и еще + busmatrix
Конечно интересны, делись!
Это схема, если нужно, скину файлик с инициализацией таймеров и функциями вывода графики/текста…
Это схема, если нужно, скину файлик с инициализацией таймеров и функциями вывода графики/текста…
да. без программной части замысел не ясен, в частности как спи загружает очередной байт данных в буффер
ПДП (DMA) - это за гранью понимания.
да. без программной части замысел не ясен
Если коротко, - то таймерами из смеси синхроимпульсов выделяются только строчные, причем осуществляется их сдвиг в видимую область экрана, SPI в <slave> режиме тактируется от таймера 9, DMA ессно в <Circular> режиме…
Кстати, если не заморачиваться с объединением полетника и OSD и делать OSD отдельно, то можно второй SPI параллельно подрубить и запросто сделать двухцветный OSD (ч/б)… (в принципе можно и третий SPI использовать 😃)
Кстати, если не заморачиваться с объединением полетника и OSD и делать OSD отдельно, то можно второй SPI параллельно подрубить и запросто сделать двухцветный OSD (ч/б)…
Это блаж, вот формирование теней на это нада.
Аналогичную схему реализовал АлексСнег, подробностей уже не помню, но вроде без внешних элементов и с одним прерыванием.
если отдельно ОСД, то можно и от lm1881 отказаться)))
Это блаж, вот формирование теней на это нада.
Так и обводи белый символ чёрным контуром…
без внешних элементов и с одним прерыванием.
цена избавления от этого прерывания - дополнительный корпус, а уж насколько это кому нужно - другой вопрос.
Так и обводи белый символ чёрным контуром…
так то нужна отдельная зарисовка теней ( Если горизонтали затенить легко аппаратно, то вертикали не…
Это схема, если нужно, скину файлик с инициализацией таймеров и функциями вывода графики/текста…
Поздравляю, вы почти близки к результату. Однако ж пока не наступили на грабли, на которые наступил я в первой версии своего АП.
Я как бы не знаю как реализован микшер аналоговый, но попробуйте зажечь самый первый пиксел в первой строке кадра и последний пиксел во всех строках.
Есть еще один момент, который может подпортить всю малину, и который надо решать, а именно - рисовать в момент развертки кадра, особенно, если таки решите делать тень вторым каналом (у меня это именно так), по хорошему не получится. То есть, швыряние пикселов в видеобуфер абы когда приведет к неприятному морганию картинки. Этот эффект можно наблюдать на Векторе. Поэтому либо вы полностью новый кадр зарисовываете во время обратного хода кадровой развертки, либо имеете два буфера под каждый канал SPI, чтобы быть на 100% независимым от прерываний. ОСД с наполненной картинкой, зарисовать в период кадрового импульса может не получиться, если EKF крутится 1000 раз в секунду и все остальное требует немедленных реакций. У меня это не получилось в первой версии АП и там пришлось иметь 4 буфера в памяти. В новой версии, я уже был умнее и по максимуму все внешние функции были переложены на возможности аппаратуры. Например, были пересмотрены таймеры, которые вяжутся в каскады внутренними коммутациями, а не внешними. Не каждый таймер может формировать прерывание под АЦП и т.д. ЦАПЫ мешаются с ножками, которые требуются под SPI, а еще градации яркости хочется, а ЦАП каналов всего только два, один из которых звук, а второй перекрывает SPI CLK. Вообщем вот в новой версии All-in-One, которую я буду в этом сезоне испытывать мне пришлось полностью перелопатить схему аппаратуры и архитектуру софта. И только сейчас вот у меня на руках есть опытный образец, который реально успевает обслуживать и сервы, и радиомодуль, и блютуз, и ЮСБ и SBUS и сервохабы, и кучу АЦП каналов, и плотное ОСД в межкадровке зарисовать, и EKF крутить на частоте гироскопа. Я вот это все к тому, чтобы локальная победа над ОСД не остановила на пути пересмотра и переработки кода Арду под ваш контроллер.
Успехов 😃 !
P.S. Посмотрел вашу схемку пристальнее. Все ж таки мне кажется перебор с внешними элементами. Если изучить ДШ, то можно найти способ получить тактирование SPI подвязанное под нужные фазы синхры и без внешней обвязки а только путем замыкания пары правильных ножек на микроконтроллере. Есть еще над чем поработать 😉