Вот закончил очередной этап моего проекта 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 крупных части:
- Поскольку я хочу использовать USBTerm, как терминал к виртуальной машине, но нужно написать сервис для Windows, который будет копировать изменения на экране виртуальной машина в терминал.
- Нужно подключить USB мышь и клавиатуру к терминалу. У меня есть Shield разъемов. Вот его возьму, вставлю в плату и к нему буду подключать внешние мышь и клавиатуру. Ну и протокол передачи кодов клавиш и движения мыши нужно еще продумать.
Вот этим дальше и планирую заниматься.
PS: весь проект на GITHUB: https://github.com/marsohod4you/UsbHwThinClient4Vm

К сожалению есть такая проблема. С квартусом 15.1 такого нет.
set_instance_assignment -name TOGGLE_RATE "0 MHz" -to SDRAM_DQ[15]
Проект не собирается. Выдает ошибку "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
с чем ноутбук прекрасно справится и сам.
(тем более что ноутбук выполняет дополнительную нестандартную программу). Интересны задачи, где абсолютно невозможно обойтись без данной платы (средствами ноутбука).
Функция "картинка в картинке" доступна только на недешёвых мониторах и телевизорах. Хотя, можно преобразователь для использования этой функции на любом мониторе сделать на ещё одной ПЛИС. Только зачем усложнять? Мне не трудно кнопку на HDMI-switch нажать для переключения входа, или на мониторе, для переключения между DVI и VGA входами.
Посмотрел, HDMI-switch заметно дешевле KVM-switch, и проще купить...
Но для отображения картинки от ПЛИС лучше не переключение, а режим "картинки в картинке" - чтобы монитор работал в родном разрешении.
Пару лет назад брал Mini HDMI-301 примерно такой: alibaba.com/.../...
Доволен. Пультом ДУ не пользуюсь. Особенность обнаружилась одна: когда включаешь источник сигнала на любом порту, этот порт сразу становится активным. Но один-два раза ткнуть кнопку переключения не сложно. Один фиг порекомендую если брать, то пятипортовый - аппетит приходит во время еды :)
Какой, кстати, и каковы впечатления? Искал в свое время HDMI+USB(не PS/2) switch, но засомневался и не купил - мало предложений, очень большой разброс цен, отсутствие отзывов.
Проблема увеличения количества клавиатур и мышей вполне решается простым KVM-switch, раньше у меня был двухпортовый KVM-121 (один набор портов для домашнего ПК и один для приносимых на "посмотри, что-то он у меня того..."), сейчас, планируя заняться ПЛИС обзавёлся уже четырёхпортовым DKVM-4K. Поскольку второй монитор ставить тоже некуда - ещё покупал для себя HDMI-switch, правда трёхпортовый, но сейчас горюю, что пятипортовый не взял, запаса уже не стаёт.
Я имею в виду что если соединять Марсоходы между собой по нестандартному интерфейсу, то надо сразу реализовывать возможность коммуникации на физическом уровне каждого Марсохода с тремя другими. А поверх этого интерфейса можно запустить любой существующий протокол более высокого уровня.
Маршрутизатор тут будет лишняя сущность и существенно снизит надёжность. При том, что Марсоход сам сможет выполнить функции маршрутизатора.
Насчёт Ethernet/IP/UDP согласен, что это неплохой вариант для связывания Марсоходов - три заголовка на каждый пакет данных и эти заголовки можно сформировать аппаратно. Думаю, со временем кто-то это сделает. Но такая сеть не будет очень надёжной - в случае обрыва связи или повреждения маршрутизатора сеть навернётся. А вот если "хитрую" топологию сделать, типа Mesh сети, то можно сделать динамическую маршрутизацию на случай повреждения одного или нескольких путей.
Можно не ходить далеко и придумать замену Ethernet. Разработать, например, протокол Marsohod Bus и пустить поверх него IP пакеты. Overhead где-то 1,5% - на каждый пакет данных 1500 байт приходится 20 байт заголовка IP.
Реализовать USB хост тоже реально и это весьма достойная задача - я бы даже не стал говорить об этом просто как о спортивном интересе. А про Ethernet тоже можно сказать как о неспортивной реализации - там есть очень простые протоколы.
Если кого-то коробит соединять марсоходы без каких-то стандартных разъемов, то для этой методики тоже есть различные модные названия и стандарты шин и магистралей, если это является необходимым признаком спортивности:) Начиная с какого-то объема потока информации обмена между ПЛИС такие методы становится единственно подходящими.
Это неспортивно. :)
Гораздо интереснее выглядел бы новый шилд, с помощью которого можно было бы соединить Марсоходы в сеть и разработать протокол для этой сети.
Ну да, такой шилд и протоколы уже есть - marsohod.org/.../shethm
Но можно попробовать сделать интересней - сделать специальный шилд, который позволит подключить любой Марсоход (2/3/etc) к трём другим Марсоходам. Затем на основе этого шилда построить надёжную Mesh-сеть.
Я надеюсь, что кто-нибудь укажет мне на то, что я плохо искал и подскажет готовый проект хотя бы для USB 1.1 (я хочу с флешками с FAT работать), а Вам тут надо USB 2.0 для таких потоков - сомневаюсь, что такое бывает бесплатно.
Реальнее просто связать марсоходы по какому-то простому собственному протоколу. Вернее даже чтобы это было настолько просто (поток байтов), чтобы и протоколом не могло называться.
Я имел в виду две платы - один Марсоход видеотерминал, а
второйдругой Марсоход - хост.А usb по шилду разъёмов запустить.
Сделать для Марсоход2 можно, но слишком медленная запись будет. Там нельзя сделать запись в режиме синхронного фифо FTDI..
А я бы хотел использовать этот проект в качестве видеоадаптера для... второй платы Марсоход. В идеале - графический терминал для второй платы Марсоход.
Хотя количество логических элементов в Марсоходе3 вполне достаточно чтобы поместить всё в одну ПЛИС. Наверное.
В обычном варианте на один стол нужно ставить два монитора, две клавиатуры, две мыши - для ПК, на котором крутится Квартус, и для Марсохода. Марсоход при этом д/б связан с ПК по JTAG.
А удобнее было-бы запускать на ПК "удаленное окно", отображающее весь видеовывод ПЛИС, и транслирующее в ПЛИС коды клавиатуры/мыши . По одному кабелю, включая прошивку. В дизайне для ПЛИС использовать для этого специальный отладочный модуль. Тогда на столе только комп + плата с ПЛИС, без лишней периферии и проводов (на время разработки/отла дки).