МАРСОХОД

Open Source Hardware Project

Проекты Altera Quartus Prime для платы Марсоход3

Передача видео кадров в плату Марсоход3


Вот закончил очередной этап моего проекта USBTerm. На этом видео показано, как видеофайл декодируется на ноутбуке c с помощью программы FFMPEG, а отображается на плате Марсоход3.

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

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

Следующее улучшение в программной части на компьютере. Там у меня была программа cpp_draw_pict которая брала из командной строки имя файла картинки и посылала ее в плату. Нашелся и там баг: загрузка картинки шла очень медленно, около 380 миллисекунд и я все не мог понять почему так медленно. Оказывается просто использовались много небольших блоков для передачи и это нехорошо. Увеличение размера блока для функции FT_Write(...) существенно улучшает производительность системы.

Ну и, наконец, я написал еще одну программу на C/C++ - это vplayer. Программа может читать из stdin бинарные данные как битмапы и посылать их в плату Марсоход3. Это сделано вот так для того, чтобы использовать vplayer совместно с программой декодирования видео FFMPEG. При этом командная строка для передачи видео на плату может выглядеть как-то вот так:

> c:\test\ffmpeg -i c:\common\h264\test_video\test_video_640x360.mp4 -c:v bmp -f rawvideo -an - | vplayer.exe

В командной строке вывод одной программы (FFMPEG) перенаправляется другой программе (VPLAYER) с помощью "|" 

Конечно, это не совсем настоящее кино, но до 14-ти кадров в секунду вполне прокачивается. Внимательный зритель конечно заметит, что кадры на экране монитора выглядят "рваными". Это известный эффект, который объясняется тем, что и для записи и для воспроизведения используется всего один фреймбуффер. Желательно было бы иметь двойной буфер: один выводится на экран, второй заполняется новым кадром. Потом во время кадрового импульса буферы моли бы меняться местами. Ну мне это пока не нужно, так, что я на это просто закрываю глаза.

Что дальше с проектом USBTerm?

Нужно сделать еще 2 крупных части:

  1. Поскольку я хочу использовать USBTerm, как терминал к виртуальной машине, но нужно написать сервис для Windows, который будет копировать изменения на экране виртуальной машина в терминал.
  2. Нужно подключить USB мышь и клавиатуру к терминалу. У меня есть Shield разъемов. Вот его возьму, вставлю в плату и к нему буду подключать внешние мышь и клавиатуру. Ну и протокол передачи кодов клавиш и движения мыши нужно еще продумать.

Вот этим дальше и планирую заниматься.

PS: весь проект на GITHUB: https://github.com/marsohod4you/UsbHwThinClient4Vm

 

 

 

Комментарии  

0 #20 nckm 23.12.2016 06:17
Цитирую Bur:
Здравствуйте!

Проект не собирается. Выдает ошибку "Error (18496): The Output SDRAM_DQ[15] in pin location 27 (pad_2788) is too close to PLL clock input pin (CLK100MHZ) in pin location 26 (pad_8)"
Не нравится ему, что пины эти рядом.. Старые версии с коммитами от даты статьи имею ту же проблему.

Собираю на Quartus Prime Light Edition 16.1.0

К сожалению есть такая проблема. С квартусом 15.1 такого нет.
0 #19 Leka 22.12.2016 13:39
Можно попробовать в *.qsf прописать нулевую частоту переключения данного пина:
set_instance_assignment -name TOGGLE_RATE "0 MHz" -to SDRAM_DQ[15]
0 #18 Bur 22.12.2016 12:53
Здравствуйте!

Проект не собирается. Выдает ошибку "Error (18496): The Output SDRAM_DQ[15] in pin location 27 (pad_2788) is too close to PLL clock input pin (CLK100MHZ) in pin location 26 (pad_8)"
Не нравится ему, что пины эти рядом.. Старые версии с коммитами от даты статьи имею ту же проблему.

Собираю на Quartus Prime Light Edition 16.1.0
0 #17 hedemay 29.05.2016 04:45
Какой смысл делать через плату то,
с чем ноутбук прекрасно справится и сам.
(тем более что ноутбук выполняет дополнительную нестандартную программу). Интересны задачи, где абсолютно невозможно обойтись без данной платы (средствами ноутбука).
0 #16 kvas 27.01.2016 04:31
Цитирую Leka:
Цитирую kvas:
KVM-switch ... HDMI-switch

Посмотрел, HDMI-switch заметно дешевле KVM-switch, и проще купить...
Они разные проблемы решают. KVM-switch позволяет иметь одну клавиатуру+мышь +монитор(VGA), а HDMI-switch позволяет обходиться только одним монитором HDMI. Проблему размножения клавиатур+мышей он не решает, поэтому и дешевле.
0 #15 kvas 27.01.2016 04:29
Цитирую Leka:
Цитирую kvas:
KVM-switch ... HDMI-switch

Но для отображения картинки от ПЛИС лучше не переключение, а режим "картинки в картинке" - чтобы монитор работал в родном разрешении.

Функция "картинка в картинке" доступна только на недешёвых мониторах и телевизорах. Хотя, можно преобразователь для использования этой функции на любом мониторе сделать на ещё одной ПЛИС. Только зачем усложнять? Мне не трудно кнопку на HDMI-switch нажать для переключения входа, или на мониторе, для переключения между DVI и VGA входами.
0 #14 Leka 26.01.2016 21:13
Цитирую kvas:
KVM-switch ... HDMI-switch

Посмотрел, HDMI-switch заметно дешевле KVM-switch, и проще купить...
Но для отображения картинки от ПЛИС лучше не переключение, а режим "картинки в картинке" - чтобы монитор работал в родном разрешении.
-1 #13 kvas 25.01.2016 14:54
Цитирую Leka:
Цитирую kvas:
[...HDMI-switch...

Какой, кстати, и каковы впечатления? Искал в свое время HDMI+USB(не PS/2) switch, но засомневался и не купил - мало предложений, очень большой разброс цен, отсутствие отзывов.

Пару лет назад брал Mini HDMI-301 примерно такой: http://www.alibaba.com/product-detail/Mini-HDMI-Switch-3x1-301-Switch_60219103422.html
Доволен. Пультом ДУ не пользуюсь. Особенность обнаружилась одна: когда включаешь источник сигнала на любом порту, этот порт сразу становится активным. Но один-два раза ткнуть кнопку переключения не сложно. Один фиг порекомендую если брать, то пятипортовый - аппетит приходит во время еды :)
0 #12 Leka 25.01.2016 10:26
Перепутал, искал не HDMI, а DVI-switch (с USB).
0 #11 Leka 25.01.2016 10:20
Цитирую kvas:
[...HDMI-switch...

Какой, кстати, и каковы впечатления? Искал в свое время HDMI+USB(не PS/2) switch, но засомневался и не купил - мало предложений, очень большой разброс цен, отсутствие отзывов.
0 #10 kvas 25.01.2016 08:54
Цитирую Leka:
В обычном варианте на один стол нужно ставить два монитора, две клавиатуры, две мыши - для ПК, на котором крутится Квартус, и для Марсохода. Марсоход при этом д/б связан с ПК по JTAG.

Проблема увеличения количества клавиатур и мышей вполне решается простым KVM-switch, раньше у меня был двухпортовый KVM-121 (один набор портов для домашнего ПК и один для приносимых на "посмотри, что-то он у меня того..."), сейчас, планируя заняться ПЛИС обзавёлся уже четырёхпортовым DKVM-4K. Поскольку второй монитор ставить тоже некуда - ещё покупал для себя HDMI-switch, правда трёхпортовый, но сейчас горюю, что пятипортовый не взял, запаса уже не стаёт.
0 #9 alman 24.01.2016 13:04
Ох уж это ограничение на длину комментариев. может быть на форуме продолжим?

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

Маршрутизатор тут будет лишняя сущность и существенно снизит надёжность. При том, что Марсоход сам сможет выполнить функции маршрутизатора.
0 #8 alman 24.01.2016 13:00
Цитирую Chaosorg:
Ethernet задействовать реально и протоколы без излишних усложнений существуют.


Насчёт Ethernet/IP/UDP согласен, что это неплохой вариант для связывания Марсоходов - три заголовка на каждый пакет данных и эти заголовки можно сформировать аппаратно. Думаю, со временем кто-то это сделает. Но такая сеть не будет очень надёжной - в случае обрыва связи или повреждения маршрутизатора сеть навернётся. А вот если "хитрую" топологию сделать, типа Mesh сети, то можно сделать динамическую маршрутизацию на случай повреждения одного или нескольких путей.

Можно не ходить далеко и придумать замену Ethernet. Разработать, например, протокол Marsohod Bus и пустить поверх него IP пакеты. Overhead где-то 1,5% - на каждый пакет данных 1500 байт приходится 20 байт заголовка IP.
0 #7 Chaosorg 23.01.2016 07:10
Ethernet задействовать реально и протоколы без излишних усложнений существуют. Если их соблюдать, то любое количество марсоходов можно просто через хаб объединить, причем не нарушая работу других подсоединенных к ней же устройств. Это в разы проще USB, который ни разу еще не был задействовано как хост ни на одном и Марсоходов (USB трекер не в счет).
Реализовать USB хост тоже реально и это весьма достойная задача - я бы даже не стал говорить об этом просто как о спортивном интересе. А про Ethernet тоже можно сказать как о неспортивной реализации - там есть очень простые протоколы.
Если кого-то коробит соединять марсоходы без каких-то стандартных разъемов, то для этой методики тоже есть различные модные названия и стандарты шин и магистралей, если это является необходимым признаком спортивности:) Начиная с какого-то объема потока информации обмена между ПЛИС такие методы становится единственно подходящими.
0 #6 alman 22.01.2016 20:39
Цитирую Chaosorg:

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

Это неспортивно. :)
Гораздо интереснее выглядел бы новый шилд, с помощью которого можно было бы соединить Марсоходы в сеть и разработать протокол для этой сети.

Ну да, такой шилд и протоколы уже есть - https://marsohod.org/2016-05-23-18-16-40/shethm

Но можно попробовать сделать интересней - сделать специальный шилд, который позволит подключить любой Марсоход (2/3/etc) к трём другим Марсоходам. Затем на основе этого шилда построить надёжную Mesh-сеть.
0 #5 Chaosorg 22.01.2016 05:18
Я открытый и бесплатный USB хост на HDL чисто для FPGA (без отдельных USB host/slave микросхем) с подходящей программной поддержкой пока не нашел. На opencores есть три проекта, но они USB 1.1 и программный USB стек либо не опубликован, либо Linux, т.е. сложен и не поместится. Всякие FreeRTOS, eCos и т.д. поддерживают USB в своих платных Pro разновидностях или за счет платных отдельных библиотек.

Я надеюсь, что кто-нибудь укажет мне на то, что я плохо искал и подскажет готовый проект хотя бы для USB 1.1 (я хочу с флешками с FAT работать), а Вам тут надо USB 2.0 для таких потоков - сомневаюсь, что такое бывает бесплатно.

Реальнее просто связать марсоходы по какому-то простому собственному протоколу. Вернее даже чтобы это было настолько просто (поток байтов), чтобы и протоколом не могло называться.
0 #4 alman 22.01.2016 01:45
Цитирую nckm:

Сделать для Марсоход2 можно, но слишком медленная запись будет. Там нельзя сделать запись в режиме синхронного фифо FTDI..

Я имел в виду две платы - один Марсоход видеотерминал, а второй другой Марсоход - хост.
А usb по шилду разъёмов запустить.
+1 #3 nckm 21.01.2016 09:48
Цитирую alman:
Цитирую Leka:
Мне кажется, что более актуальной является противоположная задача - использование ПК в качестве "тонкого клиента" к плате Марсохода, при разработке и отладке FPGA-дизайнов с GUI.

А я бы хотел использовать этот проект в качестве видеоадаптера для... второй платы Марсоход. В идеале - графический терминал для второй платы Марсоход.

Хотя количество логических элементов в Марсоходе3 вполне достаточно чтобы поместить всё в одну ПЛИС. Наверное.

Сделать для Марсоход2 можно, но слишком медленная запись будет. Там нельзя сделать запись в режиме синхронного фифо FTDI..
0 #2 alman 18.01.2016 12:37
Цитирую Leka:
Мне кажется, что более актуальной является противоположная задача - использование ПК в качестве "тонкого клиента" к плате Марсохода, при разработке и отладке FPGA-дизайнов с GUI.

А я бы хотел использовать этот проект в качестве видеоадаптера для... второй платы Марсоход. В идеале - графический терминал для второй платы Марсоход.

Хотя количество логических элементов в Марсоходе3 вполне достаточно чтобы поместить всё в одну ПЛИС. Наверное.
0 #1 Leka 18.01.2016 12:15
Мне кажется, что более актуальной является противоположная задача - использование ПК в качестве "тонкого клиента" к плате Марсохода, при разработке и отладке FPGA-дизайнов с GUI.

В обычном варианте на один стол нужно ставить два монитора, две клавиатуры, две мыши - для ПК, на котором крутится Квартус, и для Марсохода. Марсоход при этом д/б связан с ПК по JTAG.

А удобнее было-бы запускать на ПК "удаленное окно", отображающее весь видеовывод ПЛИС, и транслирующее в ПЛИС коды клавиатуры/мыши . По одному кабелю, включая прошивку. В дизайне для ПЛИС использовать для этого специальный отладочный модуль. Тогда на столе только комп + плата с ПЛИС, без лишней периферии и проводов (на время разработки/отла дки).

Добавить комментарий


Защитный код
Обновить


GitHub YouTube Twitter
Вы здесь: Начало Проекты Проект Марсоход3 Передача видео кадров в плату Марсоход3