Доброго времени суток!

Пытаюсь нарисовать свою картинку поверх телевизионного сигнала, поступающего с камеры, с помощью lpc2138, но ничего не получается...

Проблема в том, что:
1) не удается засинхронизироваться от видеосигнала (вход в прерывание - величина не постоянная);
2) не хватает скорости порта, чтобы выводить нужную мне информацию (проц не /01)

Есть ли какие-нибудь идеи? Или сразу плюнуть на много дней работы и поменять камень?
Кто-нибудь вообще делал подобные вещи на арме?

Если очень хочется использовать именно этот процессор, то могу посоветовать использовать для вывода своей картинки синхронный порт. Наличие ФИФО на SPI и возможность посылать 16 разрядные слова несколько сглаживают проблему относительно долгой реакции на прерывания.
Синхронизацию со строчными синхроимпульсами внешнего видеосигнала можно уличшить путем запрета использования в фоновой программе команд множественных пересылок регистров типа STM и LDM. Говорят, что у некоторых С компиляторов есть такая опция.

spi это хорошо, но 16 бит на строку это мало, а между словами опять возникнет задержка на опрос spi, наверное так.
что-то мне подсказывает, что прийдется таки переходить на другой проц. может блэкфин? что еще бывает в такой ценовой категории (кроме sx)?

Там есть ФИФО на 8 слов, то-есть если по простому то 8*16 бит на строку.

на 720 отсчетов согласно ITU не потянет... даже 128 это приметно 1/6 экрана. мало :-/
вобщем нужно сделать простой видеорегистратор. на сколько я понимаю - самая сложная задача - это вывод меню при просмотре картинки (или линий - зон детектора движения). остальное - вывод картинки из озу, с этим справляется epm3064.

ИМХО лучше всего PIP (Picture-In-Picture) реализовывать на основе того же ОЗУ в котором находится исходная картинка. Только ОЗУ для таких целей должно быть двухпортовым.

чтобы не мудрить, вопрос 2:
реально ли применить для таких целей блэкфин? очень нравится цена, но с дсп дел еще не имел.
вопрос 3:
если блэкфин удовлетворит потребности в выводе меню поверх картинки, может он еще и jpeg успеет сжать миллисекунд за 150-200? кадр - ч/б 720*576

Блэкфин может сжимать такие картинки со скоростью 30 кадров в секунду.
Для разработчиков выпускается стартовый набор:
http://www.analog.com/processors/platforms/msk.html

А чем ПЛИС то не нравится?
Внешняя шина проца на ПЛИС, в ПЛИС реализация псевдодвухпортовости памяти, ну и какаянить SRAM за ПЛИС. Из проца только "картинку" в SRAM загоняете/меняете, остальное ПЛИС сама делает.
Ну а в идеале ещё и отдельный генератор запускающийся/синхронизирующийся с началом каждого строчного импульса.

тогда при изменении картинки, например при переключении пунктов меню, арм имхо будет сильно тормозить вывод на экран.
таким образом дело быстро приблизится к штуке баксов

У меня в паре проектов видеосигнал формируется ПЛИСиной, а простенькая менюшка и разные служебные символы заливаются в ПЛИСину АВРкой (16 атмега), так что АРМ и подавно должен успевать.

а какая плис?

Циклон, в одном проекте EP1C6, в другом EP1C3.

afair телесистемы в такой ценовой категории сделали wavelet, управление от мега128

Малацы, тока мне вавелет не понадобился пока, схему их видел на этапе разработки своей, первый проект по схеме похож на телесистемский мАВР, тоже видеодекодер использовал .

мне тоже вэйвлет не нужен, максимум - монохромный jpeg. при этом стоимость комплектующих не должна превышать 30 баков. если пользовать арм - растет количество вспомогательных корпусов (уже плисину поставил, которая растет как грибы после дождя). другое дело dsp - цена от арма практически не отличается, но я работал только с пиками, аврками, армами. в dsp я полный ноль, а еще раз ошибиться при выборе проца - смерти подобно

1) Считаешь время прошедшее с проедыдущего прерывания. Если больше 48мкс - это строчная, если меньше - кадровая. Схема выделения в аттаче.
2) В свое время был сделан титлер на АТ90S2313 10Мhz. Все прекрасно успевал. Выводил текст наложением на видеосигнал.

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

Поставьте ПЛИС подешевле, ИМХО с видеопотоком без нее неправильно работать, а по поводу проца, опять же ИМХО, блэкфин.

блэкфин на 400 мгц сам, без плис, разве не справится с синхронизацией видеосигнала с разумным значением джиттера?

Нежелательно авр работать с видеопотоком напрямую - успеть-то может и успеет, но ничего серьезного, кроме врезки в видео уже не осилит. Это проект на грани, потребность небольшого усложнения - и вся аппаратная часть насмарку.

Возможно не учитываешь разницу между четными и нечетными полями. Отсюда и гребенка.
У меня алгоритм такой: ловлю первый кадровый, далее следует еше несколько - пропускаем, как только попался строчный - начинаем отсчет активных строк.
Еше возможно проскакивают ложные импульсы из за замусоренного сигнала. Лечится подключением по входу конденсатора на землю на 470р.

Несомненно справится, и даже на меньшей частоте, поймите, дело не в мегагерцах, а в разнице по сути между ПЛИС и процами, процы есть вещь последовательная, а ПЛИС за 1 такт может любой "огород сгородить". Блэкфин без ПЛИСа можно поставить, если Вы не собираетесь делать еще что-то серьезное, кроме врезки, да и последущее развитие и усложнение проекта в будущем будет под вопросом, потому как задачи будут "толкаться за время". Поставьте ПЛИС и, при любых усложнениях в последствии, Вы будете иметь гарантированные времянки. Строго говоря, это стратегия разработок - на потоках ПЛИСы, на математике и сервисе - процы.

как же не учитывать, если разница в пол строки
я делал генератор синхроимпульсов через модуль сравнения и прерывания. в этом же прерывании дергал ногами - генерил синхроимпульсы и вертикальные полосы, естесственно получал гребенку. переделал генератор с прерываний на полностью программный - эффект исчез, но "точку" шириной менее пяти миллиметров на диагонали 14" так и не получил, думаю что из-за медленного порта.



Кроме врезки необходимо тактировать АЦП и ОЗУ для оцифровки сигнала, реализовать простенький детектор движения, записать кадр в MMC-карту, потом считать и вывести на экран тактированием ОЗУ и R2R ЦАПа. Если зватит времени - добавится еще и сжатие в JPEG. думаю, что самая критичная к времени задача - именно синхронизация от внешней синхросмеси (не считая сжатия). Ну а по мере усложнения проекта ПЛИС может быть и добавится. Я все-таки с ними еще не работал по серьезному, только схемы рисовал, так что изучение может занять достаточно много времени, учитывая их сомнительную полезность в текущем проекте. Ну а далее, естественно, и до ПЛИСов доберусь.

ПЛИС, батенька, только ПЛИС, у Вас слишком много задач.

Делаем мы видеорегистраторы.Можно посмотреть на моем сайте.
Сжемотехника такая:
;..............DAC
;................||
;SDRAM=FPGA=ADC
;................||
;.............ARM(MEGA)

расскажите пожалуйста поподробнее, почему в данном случае нельзя обойтись без ПЛИС? какие на него надо будет возложить функции, с которыми не справится DSP?

Рассказывать, в общем-то, нечего - даже блэкфин просто физически не успеет выполнить перечисленные Вами задачи. Я думаю товарищ Kalex со мной согласится.

у меня стоит задача сделать что-то подобное ASV-MF05. на сколько мне известно, в нем Вы обошлись без блэкфинов, ПЛИСов...

ПЛИС:
1.Снимает сигнал с АЦП, кладет в ОЗУ. При необходимости сжимает, кладет во флеш или др. носитель.
2. Раскрутка видео из ОЗУ.
3. Наложение OSD.
4. Доступ ЦП к ОЗУ. (рисуем в ОSD, детектор движения и пр.)
5. При желании реализуются функции зум, сглаживание и пр.
Прелесть в том, что делается это все в нескольких потоках, никоим образом не мешая друг другу.


Там всем рулит SX48 тактовая 40М. Но только отдельные ч\б кадры. 512х256 точек.
В сквозняке ч\б меню на 256х256 точек наложением(врезкой) из ОЗУ.

По-моему всё абсолютно без проблем можно сообразить на арме. Непостоянная задержка входа в прерывание - совсем не проблема. Так или иначе строчную синхронизацию нужно делать через программный ФАПЧ. После которого для начала каждой строки будет некое число - сдвиг (плавающий от прерывания к прерыванию). И всё. Далее выводить картинку уже относительно этого сдвига. Синхро прерывание поставить на FIQ. Однако, пытаться жать джипег и выводить картинку вероятнее всего не получится ни на каком проце. Процы два дела одновремено делать ещё не умеют. Хотя и это наверно я бы попытался осилить через SPI+FIFO как уже тут предлагали. Причём с очень высокой разрешающей способностью графики. Совсем не 8*16 точек.

С одной стороны - надо сделать быстро, пусть и просто. С другой стороны - еще больше хочется сделать что-нибуть более стоящее, но боюсь что не успею в срок, влезая в незнакомую для меня область.
Говорят, что на нормальное освоение плис нужно не менее месяца. Это не считая того, что в ЦОС я неграмотен. Да еще и делаю практически все "на коленке", из приборов - полуубитый С1-81 и моя голова.



как сделать ФАПЧ, если я не могу с уверенностью сказать, когда пришел строчный синхроимпульс? Где про это почитать?

Никаких ФАПЧей не нужно.
С той моей схемки идет прекрасный сигнал. Можно даже увидить на полуубитом С1-81. Подаешь его на ногу проца. Конфигурируешь прерывания по порту на спад фронта. Если есть другие прерывания - устанавливаем наивысший приоритет, либо вообще запрещаем(про вложенные прерывания тут недавно было). В прерывании считываем и обнуляем таймер. Смотрим что получилось, кадровый или строчный. Все.

Это хорошо, когда время входа в прерывание - 30 нс
В АРМах такого, к сожалению, нет. Да и SX48 на Украине приобрести можно только под заказ.

Реакция на FIQ от (с запасом) 3 до 30 тактов проца. При 60 МГц максимальная задержка 500 нс. Вообще, это достаточно слабое дрожание = 1/128 от ширины строки. Но его можно ещё уменьшить во много раз именно ФАПЧем. После окончания кадрового синхроимпульса нужно в прерывании запоминать значение таймера (постоянно тикающего на максимуме частоты PCLKFREQ = SYSFREQ/1). С каждым новым строчным синхроимпульсом будет увеличиваться среднее арифметическое ширины строки. Таким образом за 10 первых строк после начала кадра можно уменьшить дрожание в 10 раз. А 10 первых строк (и даже больше) на экране обычного телевизора даже не видны. То есть сделать отсутствие дрожания на одном кадре очень легко. Сложнее сделать отсутствие дрожание на нескольких последовательных кадрах. Но думаю если хорошенько подумать, то и это не проблема

Да хоть 3000. Но оно всегда будет одно и то же, если правильно написать основной цикл.

На сколько я понял, достаточно в основном цикле делать опрос таймера, и, при приближении его значения к ожидаемому синхроимпульсу, влепить несколько NOP'ов и спокойно ждать прерывание?
И хватит ли скорости порта LPC2138 для изменения вида меню в ОЗУ?
Кстати, я не нашел в даташите, какая скорость порта в LPC2138/01

PS: если не секрет, как вы решили вопрос с привязкой уровня черного? Ведь если переключать выход на монитор между выходом камеры и выходом ЦАПа, должны меняться уровни черного и белого

Не совсем понятно знаком ли человек с архитектурой армов и что он имел ввиду этим.


Уж если хотите сделать что-то подобное, то не опрашивайте таймер вручную, а сделайте прерывание, которое незадолго до прихода строчного синхроимпульса вызовет подготовительное прерывание с NOPами. Однако оно опять же будет похоже на ФАПЧ. То есть нужно будет знать период синхры.

2138 ревизии C и выше дёргает ножками быстро (2 или 3 такта кажется).

У меня период получается в 100 тактов, наверное потому, что команды дергантя ногой выполняются из флэша. Вопрос чайника: как одну функцию разместить в ОЗУ?

PS - все решило RTFM

PPS - сделать период менее 0.4 мкс все-равно не получается. может /01 спасет?

Из флэша можно дёргать с теми же 2-3 тактами. Нужно только включить акселератор на полную. Почему получаеться 100 тактов - затрудняюсь сказать.

А что такое RTFM и /01 мне не понятно.

PS чтобы разместить функию в ОЗУ нужно перед именем написать __ramfunc. Это в IARe

По поводу уровня черного. Врезку в видеосинал условно можно разделить на 2 вида:
1) Самый простой - коммутировать выход устройства то с выходом ЦАПа (врезка), то с выходом видеокамеры(непосредственно видеосигнал). Получаете только врезку, никаких наворотов с оцифровкой, обработкой и сжатием, зато просто и дешево. Для привязки уровня черного ставят разделительный конденсатор и производят дополнительное коммутирование с эталоном уровня черного в момент после строчного синхроимпульса, такой сигнал генерят и LM1881, и EL4581, и EL4583(надеюсь Вы используете какую-либо из них).
2) Сложнее схема с АЦП, зато, имея оцифрованный сигнал, можете обрабатывать и сжимать как душе угодно. Оцифровывать можно простыми АЦП или видеодекодерами, первое дешево и просто, зато второе позволяет получить стандартный BT.656 и работу с цветным видео. Врезка на цифровом уровне.

Думайте сами, решайте сами, поиметь или не поиметь (с)

1) посмотрите Fig 17 user manual'а, там нарисованы осциллограммы с включенным на полностью акселератором;
2) RTFM - read the f*ing manual, /01 - модификация lpc2138/01, у которой порты висят на локальной шине ядра



Меня устроит вид 1, LM-ку я не использую. AFAIK для привязки нужна только синхросмесь, так что попробую обойтись схемой на двух pnp транзисторах для выделения синхры, ну а различать номера строк можно и программным способом.

может это оффтоп, но аналогичное устроиство зделано и на AVR. для уменщения дрожания там проц останавливается перед ожиданием INT от синхоимпулса, так как проц выидит с HALT всегда одинаково, дрожания нет.

очень даже не оффтоп спасибо, Ваша идея наверноеь лучше, чем куча NOP'ов

Абсолютно верно. Титлер на АТ2313 так и был реализован.