[an error occurred while processing this directive]
Покритикуйте идею передачи информации из компьютера через VGA
(«Телесистемы»: Конференция «Микроконтроллеры и их применение»)

миниатюрный аудио-видеорекордер mAVR

Отправлено CD_Eater 31 января 2006 г. 22:55

Предположим, что компьютер программным способом генерирует последовательность данных, которую нужно передавать наружу, во внешнее устройство. Данные от устройства в компьютер или не передаются, или передаются, но в значительно меньших объёмах. Какой порт выбрать, если скорость - около 100 Мбит/сек ?

Думаю: что мешает применять выход VGA видеокарты для выдачи произвольной информации (не только видео) ? Представим, как это могло бы быть.

Программа синхронизируется с развёрткой экрана и выводит очередную порцию специальным образом закодированных данных в видеопамять, а видеокарта, абсолютно не загружая ЦПУ (в отличие от всех остальных портов, включая USB), выводит эти данные наружу.

Давайте подсчитаем: возьмём стандартный режим 1600 на 1200 (современные дешёвые видеокарты поддерживают даже ещё бОльшие разрешения), частоту экрана 60 Гц - получим 115 МегаПикселей в секунду. Теперь вспомним, что в VGA есть 3 сигнала - RGB, один возьмём за SCK, два другие - за DATA1 и DATA2. Получим SPI с "удвоенной" линией данных и общей пропускной способностью 115 Мбит/сек. (Точнее, это будет не совсем SPI, поскольку оба фронта SCK - положительный и отрицательный - будут сопровождаться новыми данными). Реальная частота будет немного выше 115 МГц из-за обратного хода луча, во время которого ничего не передаётся.

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

С точки зрения программирования:
Поскольку в Win есть проблема с отслеживанием минимальных отрезков времени, то разумно будет выбрать разрешение экрана побольше, а частоту вертикальной развёртки поменьше. Ветвь программы, генерирующая поток данных (с низким приоритетом) заполняет некоторый буфер, откуда "отображающая" ветвь программы (с высоким приоритетом) будет своевременно копировать в следующую часть видеостраницы, ориентируясь на номер текущей отображаемой строки экрана, который можно получить через интерфейс DirectX7. Например, можно посадить "отображающую" ветвь на таймер, чья частота хотя бы ненамного выше частоты обновления экрана.

А теперь сравним:
1) Такое решение позволяет делать простые и дешёвые устройства, обмен данных с которыми не требует интеллектуальной отладки, как с USB (SPI - что может быть проще ?).
2) Длина VGA-кабеля от компьютера может достигать нескольких метров, такие кабели и видеокарты (а также компьютеры :) ) изготавливаются массовыми тиражами, поэтому их легко достать :) Требования к железу компьютера минимальные (в юзер-мануале к устройству можно написать: работает с любым компьютером)
3) Реально добиться 100 Мбит/сек на самой дешёвой (напр., интегрированной) видеокарте. (USB будет по расчётам где-то раза в 3 быстрее, но эти "в 3 раза" окупаются простотой)

Замечу, что скорости выше 100 Мбит/сек вряд ли будут интересны, поскольку генерировать потоки данных компьютером с такой скоростью не всегда получится (100 Мбит/сек - это приблизительно соответствует скорости чтения файла с винчестера).

Изготовители рекламных экранов (из светодиодов или лампочек) используют следующий трюк - компьютер выводит ролик на экран, а на DVI-порту видеокарты висит ПЛИСка и принимает эту инфу. Заметим, что раскодированный видеоролик для полноцветных экранов требует 320*240 (пикселей) * 24 (бита на цвет пикселя) * 25 (кадров в сек) примерно 46 Мбит/сек, то есть, тоже укладывается в 100 Мбитную пропускную способность.

Когда DVI станет более широко распространённым стандартом, можно будет использовать его вместо аналогового RGB-выхода. Таким образом можно будет добиться более 100 МБит/сек, если такие скорости кому-нибудь будут нужны. В принципе, можно использовать DVI и сейчас, но тогда устройством не сможет пользоваться юзер с компьютером "эконом-класса".

Для тех, кто любит смотреть на монитор, можно установить вторую видеокарту, куда программа отображает что-то ещё.
Можно также вставить устройство не вместо монитора, а в разрыв провода между монитором и компьютером, так что, остановив поток данных, на монитор можно выводить обычное изображение :) Это можно сделать вполне цивильно: выбрав для передачи информации высокое разрешение экрана, не поддерживаемое монитором, но которое может генерировать видеокарта, во время передачи данных монитор просто будет гаснуть (Signal out of range или что-то в этом роде). Или можно, интерпретируя сигналы гор/верт. синхронизации, определять разрешение и частоту, и при совпадении (с выбранной для передачи данных) отключать монитор от VGA-линий (напр., с помощью реле). Ну, или ориентироваться на некоторую сигнатуру, которая означает начало передачи данных, чтобы на мониторе не отображать этот ужас.

Но есть и проблемы - сигналы RGB 0.7-вольтовые, и потребуется их как-то преобразовать в логику, желательно без ошибок, вызванных помехами на VGA-провод (особенно учитывая то, что RGB не дифференциальные, а относительно общей земли). Но поскольку в реальных мониторах (с самыми обычными VGA-шнурами) не наблюдается сильного влияния помех на отображаемый цвет, то значит, эту проблему можно будет решить.
В нашем случае цветовые компоненты RBG будут или = max, или = min, что должно увеличить помехоустойчивость и, надеюсь, сделать возможным использование 5-метровых VGA-проводов (а бывают ещё 20-метровые), чем переплюнем "близорукость" USB.

Как я представляю обработку в устройстве принимаемых сигналов:
что-то вроде длинного высокочастотного сдвигового регистра (800 бит для каждой линии данных DATA1 и DATA2), который во время прямого горизонтального хода луча заполняется (последовательно), а во время обратного - считывается (параллельно) сравнительно медленными МК (не 100 МГц-овыми). Или можно горизонтальный ряд 1600 точек разбить на несколько частей и считывание производить после завершения каждой части, что уменьшит длину сдвиговых регистров, но также уменьшит количество полезных битов из-за необходимых пауз (между частями) на считывание.

Хотелось бы выслушать от знатоков критику, а также ответы на вопросы:
1) Пробовал ли кто передавать информацию через VGA (где почитать о подобных проектах) ?
2) Как проще всего преобразовать аналоговые сигналы RGB в логические на частотах около 100 МГц ?

Составить ответ  |||  Конференция  |||  Архив

Ответы


Отправка ответа

Имя (обязательно): 
Пароль: 
E-mail: 
NoIX ключ Запомнить

Тема (обязательно):
Сообщение:

Ссылка на URL: 
Название ссылки: 

URL изображения: 


Rambler's Top100 Рейтинг@Mail.ru
Перейти к списку ответов  |||  Конференция  |||  Архив  |||  Главная страница  |||  Содержание

E-mail: info@telesys.ru