А не сделать ли нам OSD?
MAX7456 часто горят
Почитайте этот топик.
да там все просто - лезем в даташит и видим комфортные границы работы 4.8-5.2В и критическую разницу между потенциалами цифровой и аналоговой земли 0,3В
при питании 4.9-5В - нагрев минимальный
при меньшем, а также большем - сбои и/или нагрев
вылетают из-за разводки умных европейцев/китайцев - питание цифры и аналога с разных сторон = наводки на аналоговую землю из-за мишуры проводов
из-за мишуры проводов
Кругом засада… (😃) Всю голову изломал - как запихнуть OSD в основной проц. контроллера полёта, пока безрезультатно…, то портов не хватает, то прерывания мешают друг другу… Щас вот мучаю DAC, как источник сигнала, вроде работает, но тоже свои проблемы…
Кругом засада… () Всю голову изломал - как запихнуть OSD в основной проц. контроллера полёта, пока безрезультатно…, то портов не хватает, то прерывания мешают друг другу… Щас вот мучаю DAC, как источник сигнала, вроде работает, но тоже свои проблемы…
ибо ненадо этого делать.
ненужно скрещивать баги осд с багами системы стабилизации полета.
сделайте модульную конструкцию так будет надежнее. с зависшим осд долететь можно, а есл иполетник глюконет - тут будет больше проблем
с зависшим осд долететь можно
У меня многозадачная ОС…, а “виснет” в основном (и то редко) как раз канал передачи данных между процами…
от сам реализованный замысел (исходники ни при чём… проблема однозначно в lm1881):
идея использовать мультиплексор 74HC4052D а не лепить чреватый цветными переливами на переходах от осд к картинке миксер на рассыпухе очень неплоха.
а как практически. на разных картинках по насыщености, с разными телеками и камерами?
картинка остается со стабильно хорошими переходами?
У меня многозадачная ОС…, а “виснет” в основном (и то редко) как раз канал передачи данных между процами…
винда вон тоже многозадачная но когда зависнет иное приложение и остальное так тормозить начинает,
ну и блюскрин как аргумент
а как практически. на разных картинках по насыщености
Картинка чёткая, никаких нареканий, “на халяву” (даже не разбирался почему) получается эффект - что на светлых участках картинки символы сами темнеют, а наилучший вариант когда выводишь чёрным на белой “подложке”… Камеры пробовал две разные, но обе 600 тВл (как пишут) никакой разницы, на ЖК телевизоре всё норм., а с кинескопом у меня уже нет…
Тесты пока только на столе…
(даже не разбирался почему) получается эффект - что на светлых участках картинки символы сами темнеют
это потому что уровни заданные резисторами за мультиплексорами просаживаются на нагрузке, которая подключается при переключении на белый. А черная - тень и так на минимуме, там не куда просаживаться.
Сообщение от alexeykozin
как телевизор разбирает какой сверху рисовать какой снизу?
Там в таймингах и кол-вах следования строк заполнения кадрового импульса есть разница. Кадровый импульс четного и нечетного кадра отличается.
Не совсем верно,во времена когда это все было придумано телеки ничего не разбирали а “рисовали” все как есть в реальном времени, и для того что бы одно из полей кадра попадало между строк другого ,кадровый импульс в разных полукадрах просто сдвинут относительно строчных на пол строки, сам кадровый импульс и количество строк (312.5) в обоих полях одинаковы.
кадровый импульс в разных полукадрах просто сдвинут относительно строчных на пол строки
строчный от кадрового во втором полукадре идет с задержкой на одну линию?
строки то считаем от конца кадрового импульса
т.е. в первом полукадре первая строка идет с меньшим интервалом от кадрового импульса а во втором как бы с пропуском одной полу строки
или всетаки непостоянна именно частота кадров 50 гц?
количество строк (312.5) в обоих полях одинаковы.
как может быть количество строк нецелым?
от начала экрана до середины рисует а конец не прорисовывается?
т.е. в первом полукадре первая строка идет с меньшим интервалом от кадрового импульса
По идее, по другому и быть не может…, к тому же рисовать на экране “луч” начинает с 23-й строки, а предыдущие строки называются “служебные” (??), чем и кому они “служат” в ГОСТе не указано… 😃
строки то считаем от конца кадрового импульса
хотя это и не принципиально но принято считать и так гораздо удобней для программиста , от начала импульса.
т.е. в первом полукадре первая строка идет с меньшим интервалом от кадрового импульса а во втором как бы с пропуском одной полу строки
как может быть количество строк нецелым?
Верно ,в первом полукадре начало КСИ совпадает с началом первой строки ,и заканчивается посередине 3,а во втором полукадре наоборот, таким образом из 625 строк 5 из которых тратится на межкадровую синхронизацию остается четное количество ,все дело не в количестве строк а во времяни ,все сигналы четко привязаны к периоду в 64мкс (счетчик строк ведь тикает непрерывно даже во время КСИ)
от начала экрана до середины рисует а конец не прорисовывается?
какбы да ,просто все это остается за кадром,ведь реально видимые строки с 23 по 310 в одном полукадре и аналогично в другом.
Вот довольно толковая картинка все объясняющая vg.ucoz.ru/_ld/0/19_6271c7720749.png
а предыдущие строки называются “служебные” (??), чем и кому они “служат” в ГОСТе не указано…
Как же не указано , все есть ГОСТ_7845-92, тут подробней
счетчик строк ведь тикает непрерывно
Тут надо понять, что сигнал ПТС разрабатывался для аналогового тракта приёма (этим и обуславливается его избыточная сложность), где никаких “счетчиков” не могло быть в принципе… Поэтому то, “служебные” строки с их вспомогательной информацией для нашего использования просто не нужны.
Что то тема затихла, будет убийца всех осд или нет? 😉
У нескольких человек да. 😃
У нас - похоже что нет.
это осд работает только при наличии внешней синхры от камеры. нет синхры - нет осд.
поэтому пока продукт неготов к употреблению.
видимо у разработчиков пока нет времени на доработку
олег анонсирует новый алгоритм вывода видеоданных с стм
rcopen.com/forum/f134/topic224458/5653
может родится новое осд
Пока не знаю, чем все закончится с этой темой. У программиста, который код писал, вообщем-то много чего было почти готово. Давно с ним не связывался. Свяжусь, спрошу. Персонально я не очень хочу заниматься конкретно кодом, потому-что у меня есть грандиозные планы по своим задачам на этот сезон.
олег анонсирует новый алгоритм вывода видеоданных с стм
Это вряд ли новый 😃 , у моего АП с самого начала так было задизайнено и воплащено в результат, и в той железке, которая под эту тему создавалась тоже полностью аппаратное формирование кадра.
будет убийца всех осд или нет?
Какими свойствами и характеристиками, по Вашему, должен обладать этот “убийца” ? Куда ещё направить усилия ?
и в той железке, которая под эту тему создавалась тоже полностью аппаратное формирование кадра
А мне показалось(?) что у Вас всё же осталось одно прерываннице…
А мне показалось(?) что у Вас всё же осталось одно прерываннице…
Нет, в данном ОСД нет прерываний на развертке. Вы путаете с моим АП первой версии, там кадровые 50Гц оставались для смены указателей ДМА на буфер развертки перед стартом нового кадра, кроме того мне кадровые там парсить приходилось, так как не было LM1881. В этой ОСД стоит LM1881 и прерывания там на фиг не нужны.
стоит LM1881 и прерывания там на фиг не нужны.
Всю ветку вашу просмотрел, вроде, …(?) тогда , если не трудно , вкратце - основные принципы Вашего вывода на экран обозначте…