roboforum.ru

В принципе мне подойдет такой вариант.
В этом случае я смогу выставив через порт С управлять значением отдельных битов порта В.

Проще ничего не смог придумать. Микросхема я так понимаю ЛИ1(74HC08N), да (логическое неинвертирующее И)? Соотв. 2 шт мне их понадобится. Если порт С весь в 1, то сигнал с В идет в полном объеме. если какие-то биты порта С в 0, то соотв. биты на ЦАПе всегда в 0. Правильно я мыслю?

Реализовал в железе. Работает нормально. Еще немного приглажу и покажу результат.

Доделал и вылизал вывод видео.
Результат можно посмотреть тут
На видео видны некоторые артефакты, на самом деле их нет - это последствия не очень качественного видео-захвата и компрессии при закачке на ЮТуб.

Возможности:
4 видеорежима.
40х29 64 градации серого
64х38 16 г.с.
80х58 4 г.с.
128х77 2 г.с.

Все написано мной с нуля на чистом Си (из ассемблерных вставок только NOPы для подгонки размеров пикселей). Конечно часть решений было заимствовано в других статьях, найденных в инете.
Проц загружен почти по полной, т.к. он все время занят генерацией видео строк.

С проблемой полосатости изображения я все таки избавился с помощью программного отключения внутренней подтяжки входов без применения дополнительных микросхем. До этого подобный метод не работал из-за ошибки в программе.

На следующей неделе буду прикручивать I²C и будет у меня графический/текстовый I²C терминал

Очень даже неплохо! А насколько этот проект далёк от OSD?

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

круто, осталось добавить pll генератор вместо osc avr с синхронизацией от строчных импульсов, чтоб убрать зазубрины и можно osd делать. Где-то видел хорошую схему pll, если надо, найду...

Для нормального OSD надо LM1881 или подобную микросхему. Чисто программно будет не очень, хотя надо попробовать, интересно. Ожидаю проблему с через-строчной разверткой.

Зазубрины на телевизоре не видны. Есть очень незначительное дрожание из-за неточного попадания в прерывание (разница 1-3 такта - это около 20% пикселя). Причем на хороших теликах (например на 40" самсунге) дрожания нет вообще, видимо он сам подстраивается. 20% это на мелком LCD 5" (мой основной тестовый) - это дрожание заметно, но пренебрежимо мало, по крайней мере для таких разрешений.

Чел делал для логотипа в кабельном TV, очень профессионально...
как бонус - микшер tv сигнала для osd
http://www.imeda.nm.ru/osd/index.htm

Ну... скажем прямо, не вижу смысла заменять маленькую микросхему с которой схема будет минимальной и красивой на кучу усилителей, логики и других деталей. У нас просто в городе нет лм1881 и в чипе-дипе нет, найду - обязательно буду делать osd, т.к. нужна для использования на моих моделях. Готовые покупать не хочу, т.к. получаю кайф от пайки и программирования мк

Программное решение без 1881 - это интересно, но боюсь качество будет так себе. но попробую. отпишусь.

Попробовал чисто программный метод - фиг. Пока распознается синхронизация, пока определиться, что это именно кадровая, плюс расчет номера строки - уже примерно пол-строки проходит. И то из за медлительного АЦП получается очень неточное позиционирование. Написал прогу, где подмешивается вертикальная линия к чужому видео, но скажем так... она только условно вертикальная. Плавает очень сильно от строки к строке. Да и свободных вычислительных ресурсов вообще 0 остается.

Зато нашел наконец LM1881. думаю за следующую неделю будет готовый модуль OSD на макетке в первом приближении. Результаты выложу конечно.

А зачем АЦП? Можно компаратором ловить. Строки считать, чтобы знать заранее, какой следующий фронт - строчный, кадровый или какой-нибудь еще (выравнивающий, например). Кадровые от строчных отличать повторной проверкой через пять (или сколько надо) микросекунд.

Чтобы точно срабатывать, можно извращаться - например _перед_ ожидаемым фронтом уходить в слип
(ну и другие не менее извращенческие кривые способы есть:))...

если найдешь ba7046, ставь ее вместо lm1881, она с AFC, значительно лучше формирует строчные импульсы, особенно в шумном сигнале

Реализовал прототип OSD модуля. Пока 128х68 разрешение, 2 градации (белый и прозрачный). Проверял с 2 PAL камерами и с моим NTSC генератором видеосигнала. Все работает отлично.
Продолжаю допиливать.
Задача - повысить разрешение и сделать как минимум еще черный цвет.

Думаю попробовать прикрутить SRAM. Вроде недорого, а памяти там дофига. Переживаю только насчет скорости. Например у CY7C1019DV33-10ZSXI (1 Mbit) которая мне легко доступна написано 10 нс время доступа. Что то меня это настораживает. Мне надо читать около 5 байт за 1 нс.

Добавлено спустя 4 минуты 24 секунды:
ой туплю, мне 5 байт за 1 мкс надо, так что 10 нс/байт мне хватит за глаза. Отлично.

10 нс/байт это 100 МГц... Мы все еще говорим про AVR?
На самом деле будет медленнее и скорость будет определяться не sram, а AVR. Конкретно скоко будет - зависит от реализации. 5 байт за мкс теоретически может успеть - в линейном коде, без циклов, по 3 команды на одно чтение.
Или я чего-то не понял, как вообще планируется ОЗУ это подключать?

Яж дописал, что ошибся во времени. Скорости хватит без проблем.

16 бит адреса на 2 порта авр, на входы/выходы памяти сразу ЦАП. Память постоянно в режиме чтения.
Соотв вывод 1 пикселя это PORTC++;
Между строками будет PORTD++;
Между кадрами PORTC = 0; PORTD = томуто;

Так что скорость будет максимальна.

А - все, понял, я думал ты читать из памяти в AVR собрался. Да, просто перебирать адреса - не вопрос. А записывать в это ОЗУ когда? Между строками/кадрами? Тогда надо на шину данных ОЗУ буфера поставить, чтоб от ЦАП его отключать на время записи.