ap_larin

Кит не подходит по периферии. И подключить мои внешние устройства не получится. Увы. Так что лучше модуль и несущая плата своя.

Да, Дмитрий, тепловидение!

А для этого AM3517-SAU Module плата-носитель есть или самому делать? Вообще я посмотрел у sauris на сайте этот модуль: штука интересная. Только схемы модуля нет. Как потом редизайн делать?

Dr.Alex, накладываемая графика не зависит от изображения никак. В этом смысле анализировать изображение не надо. По поводу STM32... этот вариант интригует, но есть сомнения, что даже без ОС его ARM не справится с регулировками поступающего видео (яркость, контрастность, гамма-коррекция ...). Или я не прав? Как это оценить? У ST есть подобные примеры? А если не ST то какой вариант?

Что касается применения AM335x и AM3517, а есть ли там вход камеры? Накладывать графические примитивы необходимо на каждый кадр.

Религиозных предпочтений по выбору кристалла не имею, НО с AD дела не имел. Относительно AD Blackfin возникают вопросы по средствам разработки. Непонятно почему С6748, L-138 не приспособлены для видео. Порты-то есть! Теперь уточню некоторые моменты. С камеры выходит чёрно-белая картинка с частотой 9/25/30 кадров в минуту по протоколу BT.656 (параллельная шина 8bit + CLK (YUV 4:2:2)). С такой же частотой кадров и в дисплей нужно отдать, можно быстрее. Что касается раскраски картинки. Тут не так всё печально. Нужно раскрашивать либо в чёрно-жёлтые, либо в чёрно-фиолетовые, чёрно-зелёные и т. д. Накладывать графику в виде цветных фигур необходимо также в пределах 16-ти цветов.

Всем доброго времени суток! Прошу оказать помощь в выборе аппаратных средств обработки видео. Задача такая. Получить ч/б картинку с камеры (320 х 240) либо непосредственно с матрицы, либо по ВТ.656 (PAL/NTSC). Наложить цветную графику (примитивы в виде линий, квадратов и т.д., либо текст). Передать на дисплей с разрешением 640 х 480 (800 х 600) либо по BT.656, либо RGB888. Попутно при необходимости делается цифровой zoom от 0.5 до 8, раскраска картинки, регулировка яркости, контрастности. Сам анализирую разные варианты. Это и OMAP3530, и L138, и С6748, и DM3730 и т.д. или ПЛИС. Сейчас у ST F439-й что-то может делать с камерой и TFT. Сомнения в возможностях решить такую задачу (ST). Признаюсь, что опыта работы с перечисленными изделиями нет, но приближающийся проект требует конкретных решений и всецелого погружения в тему. Сроки... Прошу обосновано помочь с выбором. Я планирую для начала взять какой-нибудь конструктор, а далее сделать редизайн под себя. Как оценить требуемые ресурсы по быстродействию и памяти? Где найти какие-нибудь исходники для решения подобных задач? Есть правда ограничение по потребляемой мощности порядка 0.5Вт !

Если можно - поподробнее пожалуйста об этом. А вообще давайте представим, что имеется BeagleBone (как прототип конечного устройства), подключенный к хосту через USB и Ethernet. С хоста мы можем увидеть процесс загрузки ВВ и наверное порулить I2C, и остановить загрузку после u-boot и ещё много чего, Но мы НИЧЕГО не увидим на OLED-е пока не отправим на него по I2C набор кодов настройки отображения. Что же тогда делать если хоста не было бы?! На целевой системе он мне не нужен!!! Тогда на каком этапе "прикручивать" драйвер и как его писать? На этапе отладки ПО наверное как можно раньше, а на целевой системе пользователю точно не нужно видеть процесс загрузки, ему и заставки хватит!

Да! Я только начинаю в этом разбираться! Но такой дисплей необходим для решения конкретной задачи.

Давайте рассмотрим пример с платой BeagleBone. На её разъёмы выведен видеопорт 24bit с сигналами синхронизации HSYNC, VSINC, DE, CLK и порт I2C. И всё это живёт своей жизнью. Мне необходимо подключить МОЙ дисплей, у которого все упомянутые сигналы имеются и для начала отображения по I2C необходимо отправить определённые коды настроек. 1. Как сделать, чтобы порт I2C считался принадлежащим дисплею? Писать свой драйвер? Тогда как? Какой для этого инструментарий необходим, откуда берётся, правила написания и т. д. Может где про это подробно написано, тогда прошу дать ссылки. 2. Можно посмотреть на проблему иначе. Пусть I2C так и остаётся самостоятельным портом, подключенным к дисплею. Об этом ведомо только разработчику. И просто отправлять коды по порту, зная для чего они предназначены. Как Вам такой вариант. Что для этого надо дополнительно сделать? В любом случае дисплей должен что-либо отображать уже на этапе загрузки u-boot (до uImage!). Готов экспериментировать на живой плате по шагам.

Для SAURIS GmbH. Платы интересные. Только вот выход на LCD через LVDS и никак иначе. Значит на базовой плате необходимо установить преобразователь LVDS->RGB888. На первых порах для макета может и сойдёт. Про загрузку без u-boot можно поподробнее? Какова технология создания драйвера I2C для моего случая? Что касается L138, то для меня RGB565 вполне достаточно !

Прошу Вас по возможности вернуться к решению конкретных вопросов. Процессоры, на которых я предполагаю реализацию проекта это либо L138, либо AM3715, либо DM3730.

Как промежуточный этап для решения задачи хотелось бы использовать готовое "железо" от Embest, LigicPD, CALIXTO и т.д. и ПО, поставляемое вместе с железом. Но ни железо, ни ПО сразу использовать для своей задачи нельзя. Реализация алгоритмов видеообработки пока не рассматриваю, только настройку корректной работы системы. 1. Что необходимо сделать для настройки портов видеовхода и видеовыхода для приёма и передачи сигналов по BT.656? 2. На каком этапе и как производится передача кодов инициализации, чтобы заработали камера и дисплей? Уже на этапе загрузки u-boot дисплей должен иметь возможность отображать информацию. А если это сделать позднее..? 3. На каком конструкторе по Вашему мнению лучше отлаживаться? 4. Как организовать рабочее место с ПО. Что ставить на хосте? 5. Что писать в u-boot, если требуемая мне конфигурация прописывается там и что писать в Linux, если сам Linux (ядро) должен производить отправку кодов инициализации ? Правила написания, компиляции, прошивки.

Здравствуйте, уважаемые участники форума! У меня имеется новый проект, в реализации которого есть большие затруднения. Некая система должна получать на входе видеосигнал по протоколу ВТ.656 (8 bin parallel + clk (27 MHz)). С полученной картинкой необходимо производить различные действия по изменению размеров, регулировкой яркости и т.д. с наложением поверх картинки простой графики. Далее, необходимо передать результирующее изображение на OLED (800х600) либо по тому же протоколу ВТ.656, либо RGB888. Грузиться система должна с FLASH. Это присказка. На начальном этапе хотелось бы поэкспериментировать на готовом железе, максимально приближенным по архитектуре и возможностям для решения задачи. Речь идёт конечно же об оценочных платах от TI, Embest, LogicPD, CALIXTO, MENTOR. Во всех платах имеются видеовходы, выходы на LCD и кнопки. Но есть проблемы. Эти платы спроектированы под определённую периферию, немного не похожую по интерфейсу с моей. Управление камерой производится по UART, а управление дисплеем по I2C. В частности, например, чтобы заработал дисплей, необходимо отправить ему серию кодов инициализации по I2C, иначе он не включится. На каком этапе производится инициализация? Я полагаю инициализацией должен заниматься u-boot. Тогда как его настроить? Прошу знающих людей объяснить мне технологию адаптации нового оборудования в Linux от и до. Что прочитать и т. д. Хочется во всём разобраться самому. Ну и заодно может подскажите на каком конструкторе из выше названных лучше пробовать (с доработками или без).

Контур платы изначально был нарисован в P-CADe в слое board. Либо сама СПЕКТРА создаёт неполноценный файл, либо P-CAD плохо пролечен. Кстати, из P-CADа СПЕКТРА не запускается, всё обратно валится в P-CAD.