Здравствуйте!

У меня совсем уж нубский вопрос к знающим людям.
Итак, имеем задачу: получить видеосигнал с устройства, подключенного к плате через S-Video. Устройство - камера. Получаемое видео отобразить на форме.

Что имею: Борда Advantech SOM-C3530 (CPU TI OMAP 3530, встроенный DSP TMS320C64x+ и, если это важно, TV Decoder TVP5150AM1 от тех же TI), ОС Windows Embedded CE 6.0, среда разработки Visual Studio 2005 и 2008, BSP пока нет, но Advantech обещал выслать "как только, так сразу", т.ч. можно сказать что он как-бы есть. Писать я это дело буду на C# под .NET Compact Framework

Теперь собственно вопросы:
1) Верен ли выбор C# как инструмента, в плане поставленой задачи. Может быть есть такие "камни", что лучше (но не проще, я понимаю) выбрать C\C++ ?
2) Если Шарп использовать можно и нужно, то с чего начать? "Формочку с двумя кнопками" я уже нарисовал в 2008-й студии и запустил в эмуляторе на СЕ 6.0, теперь бы добавить одной из кнопок функционал для получения видеосигнала... Камк мне представляется, когда соберу образ с использованием BSP, придется юзать DllImport для драйверов, т.к. отдельных managed библиотек нет?

На этом пока всё, но в будущем вопросы еще будут, по мере того, как я начну вникать в суть.

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

Заранее всем спасибо!

Вопрос номер раз: а как забираем сигнал с борды в комп?

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

Так а какой API дает Advantech?

Пока ж не прислали BSPшку. Жду вот.
Но судя по тому, что я видел в "универсальном" BSP для OMAP35 слитом из Adeneo Embedded, будут dll-ки, кним буду обращаться ищ приложения, как собственно и писал в шапке. Хорошо, что сырцы есть, и функции можно посмотреть.

Кстати, вот еще вопрос: Судя по моей задаче, с каким устройством мне придется работать, что, т.с., "программировать" - DSP или же этот декодер?

Так вам дается API, скорее всего C-шный, вот с ним и будет идти вся работа.

Драйвер устройства, преобразующий видео сигнал в пригодную для апликации форму, у вас уже есть? А железо, к которому вы подключите S-video и оно совершит работу под управлением драйвера у вас есть?
Если драйвер стоит и работает, значит у вас видео поток в форме буферов уже имеется. Посему апликации надо работать с ними. Совершенно неважно S-video, HDMI, DVI или VGA было на физическом уровне.

Коннектор мышки точно такой как S-video.

Бес попутал, там не S-Video а RCA разьем, но может и не суть.
Драйвера нету пока. Китайцы праздновали НГ, но обесчают BSP на этой неделе.
По поводу железа - если Вы имеете в виду источник видео-сигнала, то такой есть. Если по поводу принимающего - то, как я понял из мануала по декодеру, сигнал с него идет на DSP, и уже оттуда мне надо его снимать

Ну этот сигнал отличается от С-видео только тем, что цветность идет по тому же проводу, а не по отдельному. Такой же точно видео сигнал внутри телевизора.
Должен быть преобразователь аналогового сигнала в цифровой. Я не уверен, что ДСП это содержит. У вас есть схема вашего устройства и название ДСП?

Да, всё инфо есть в шапке темы: встроенный DSP TMS320C64x+ и TV Decoder TVP5150AM1
схему устройства - прилагаю

Я понимаю архитектуру своей программы так:
1) Настраиваю работу декодера, что бы он передавал, грубо говоря, нужную мне картинку на DSP
2) Настраиваю DSP на метод сжатия видеосигнала
3) Снимаю готовое видео с DSP и отображаю у себя в приложении

Верен такой алгоритм или нет?

ДСП и сжатие не надо. Сжатие требуется для передачи сигнала по каналу связи или для экономии места на диске.

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