Как работать с видео сигналом? - Страница 7

nonamedov · 20.10.2011, 00:38

Нет я так не считаю, просто вся "оцифровка" будет сделана за три последовательных кадра (полный цикл), это сильно облегчить обработку, уменьшит число ключей+интеграторов, без особого ущерба. Это как бы "цветовой фильтр".

nonamedov · 20.10.2011, 01:01

Easyrider83, в принципе для разделения синхроимпульсов можно (и даже нужно) использовать интегрирующую (для кадровой) и дифференцирующую(строчной) цепь + периферию МК, так выделялись СИ в старых телевизорах, так и нужно и здесь, тем более здесь это не критично.
Что касается декодирования, я было подумал, как бы обойтись без декодера, ведь нам нужна лишь малая доля информации, но кажется без него никак.

Сообщение от Easyrider83

В принципе, проект и вправду не сложный. Просто я ленивый.

Он средней сложности, я тоже ленивый, часто другим приходится потакать меня, на этом все и держится или как там у Окуджавы:

Цитата:

Давайте жить, во всем друг другу потакая,–
тем более что жизнь короткая такая.

Wugluscr · 20.10.2011, 01:20

Сообщение от nonamedov

дифференцирующую(строчной)

Вcе же "инерционный элемент" (генератор на F cтр) желателен - и для помехозащищенности, и чтобы избежать непредсказуемой пляски счетчиков (в МК) во время кадрового гасящего. Любая микруха от любого телевизора (современных я уже не знаю, надо будет пошарить в сети).

nonamedov,
если я правильно понял, Вы предлагаете из одного поля извлечь и обработать R, из второго G, из третьего B ?
Разумно и действительно экономно. Быстродействие (и качество декодирования) тут никому не нужны.

nonamedov · 20.10.2011, 01:32

Да, Вы правильно поняли, именно так.

Сообщение от Wugluscr

Вcе же "инерционный элемент" (генератор на F cтр) желателен - и для помехозащищенности, и чтобы избежать непредсказуемой пляски счетчиков (в МК) во время кадрового гасящего.

Во первых, сигналы будут обработаны МК; а во-вторых, во время кадровых СИ, передаются и строчные СИ.

Wugluscr · 20.10.2011, 09:05

Сообщение от nonamedov

во время кадровых СИ, передаются и строчные СИ.

Знаю, занимался синхриками.
Конечно можно программно решить игнор уравнивающих, врезок (32 мкс) и прочих помех и перекосов.

Надо коллективно прикинуть по поводу RGB с обновлением через 3 поля: 16 Герц получается, задержка 60 мсек. Да вроде не критично.

Easyrider83 · 20.10.2011, 10:04

Я на этом же форуме генератор видео сигнала надыбал.

Easyrider83 · 20.10.2011, 10:37

Вот скарт:

Идея такая - из видеовыхода (контакт 19) выделить кадровые синхроимпульсы. Это просто - они отрицательной полярности. Правда, идут вместе со строчными, но интегратор это исправит. Далее уже берем сигнал RGB и действуем по ранее утвержденному плану. Проблема только одна - я не хотел применять отрицательное питание для схемы. Как вариант - применить LM1881. Она у нас за 3 евро лежит. Не проблема. Дальше синхронизация особо не нужна - средствами контроллера все сделаем. Смущают только тайминги. Строка идет с периодом 32мкс. Если строку делить на 5, получается около 6мкс. Т.е. это период интеграции АЦП. Не уверен, что восьмибитный пик потянет. Есть у меня ультра дешевые STM32F100R6TB, но они тоже на 24МГц максимум работают, а PIC16F1827 легко идет на 48МГц, зато памяти у него мало для хранения и обработки кадра. Из того, что есть, видимо, придется выбрать ARM.
Для кадра придется выделить память. 3 кадра по 625 строк по 5 измерений на строку при 8 битах точности = почти 10кБ. Дофига. Надо резать. Т.е. применять маску для кадра и писать только полезную информацию, обрабатывая на лету. Т.е. в каждом цикле захвата проверять, попадает ли измерение в маску. Тогда можно уменьшить память, но придется задрать тактовую -надо больше циклов. Может быть озадачиться поиском какого-нибудь LPC1xxx, который 72МГц даст? С этим уже можно работать.

Wugluscr · 20.10.2011, 11:50

Easyrider83

Надо четко себе представлять временнЫе параменты строки
Период строки - 64 мкс
"Активная часть" (где передается изображение) 52 мкс. Это формат 4:3.
Вот эти 52 мкс и надо делить на нужные зоны.

Easyrider83 · 20.10.2011, 11:54

Вот такая штука получается. Когда строка закончена, есть пауза на обратный ход луча. За это время проверяем по маске столбцы и увеличиваем 32х битную переменную на значение АЦП. По окончанию кадра делим эти переменные на количество измерений в них. Получаем среднее значение.
Таким образом временные диаграммы получаются жесткие - программная пауза и пять тактов АЦП. Если програмную паузу заменить на таймер, то вообще весь захват будет работать в прерывании. Для одного кадра без применения маски нужно 3кб памяти. Может быть и таким путем пойду.

Поясните, как лучше в Keil на графике посмотреть временные диаграммы? Мне нужно четко по времени отладить начала событий.

Wugluscr · 20.10.2011, 12:23

Сообщение от Easyrider83

Wugluscr, спасибо, не полегчало.

Да ничего там страшного нет.

Видимая часть телевизионного поля (полукадра) начинается (по стандарту) через 22,5 строк (22,5*64=1440 мкс) от отрицательного фронта кадрового синхроимпульса.
Видимых строк в полукадре 287,5, берем 288
Геометрически они идут растром с промежутками
(промежутки заполнят строки из другого поля/полукадра).

Вот и прикиньте временнЫе параметры Ваших "квадратов" (или прямоугольников) экрана.
По горизонтали - отсчитывать такты или цифры,
по вертикали - количество строчных синхроимульсов.
Я сам не работаю с МК (на то есть другие умельцы), но в идее Nomamedov'a ничего сложного нет.
Главное - четко поймать каждый сигнал и привязаться к временам.

В былые годы основной трах по синхронизации - это удержать болтанку видеомагнитофона. Бывало, процессор тактировали от контурного генератора с варикапом, без кварца. И разрисовывали на бумаге эпюры на все 625 строк.
Сейчас конструкторам полегче.

Вперед!

P.S. Микросхема синхроселектора может выдавать "свои" сгенерированные строчные и кадровые синхроимпульсы.
Их позиция и длительность может НЕ совпадать с синхроимпульсами видеосигнала. При отладке проги это придется учесть.