[Из песочницы] Передача видеоданных на частотах до 100МГц в ПК
Введение
Наш отдел занимается разработкой ПЗС матриц и линеек. Для каждого разработанного датчика необходимо создать фотоприемное устройство (ФПУ), которое позволит его тестировать, расчитывать параметры прибора — динамический диапазон, неравномерность выходного сигнала, уровень генерационно-рекомбинационного темнового тока и т.д.
ФПУ является своего рода видеокамерой но не такой, которую просто можно взять в руку и пойти в парк что-нибудь снимать (белочку например).
Фотоприемное устройство, обычно, состоит из нескольких плат. На одной плате располагаются стабилизаторы питания, фильтры, а на другой (или других) весь микросхемный фарш. В центре основной платы находится сам датчик, вокруг него — мощные быстрые ключи для подачи управляющих напряжений на электроды ПЗС. К выходу прибора подключен эмиттерный повторитель, потом идет видеопроцессор (умный АЦП для ПЗС) и завершает все ПЛИС. Она подает синхроимпульсы на ПЗС через ключи, тактирует видеопроцессор, забирает с него цифровой код и после необходимой обработки отправляет на выходной разъем. Помимо одного кода на выход идут синхроимпульсы — PCLK(синхронизация по пикселям), HSYNC(сигнал строчной синхронизации), VSYNC(кадровая синхронизация), которые необходимы для нормального получения информации на принимающей стороне.
Конечно же, ФПУ должно вносить в аналоговый сигнал с ПЗС как можно меньше помех, чтобы получить хорошие расчетные параметры прибора. Но статья ни о ФПУ и ни о ПЗС, а о том с помощью чего и как можно передать цифровой код на высоких частотах в ПК.
Краткое описание микросхемы-передатчика
Несколько лет назад появилась необходимость передать цифровой видео поток с матрицы с кол-вом элементов 1000х1000 (матрица нашей разработки). До этого МПЗС мы работали только с линейками (опять же — нашей разработки) и для передачи данных использовали USB 2.0 в режиме Hi-Speed. Для линеек вполне хватало скорости, проблем не было. Но вот на горизонте замаячила задача отправить 12бит. поток на частоте 40МГц. Из простых расчетов видно что 40МГц * 12бит = 480МБит/с. — это предел USB2.0 HI-SPEED, да к тому же еще и теоретический. Мы пошли по пути наименьшего сопротивления, в соседнем отделе попросили систему передачи по оптоволокну, запустили и все заработало. Но хотелось универсальности в связке ФПУ-ПК, тем более, что оптоволоконный передатчик был расчитан на шину PCI, которая уже практически канула в лету.
Пока эта связка для передачи работала, мы искали решения на базе шины USB3.0. Поиски увенчались успехом, решением оказался чип — EZ-USB FX3 SuperSpeed USB 3.0 peripheral controller от «Cypress». Функциональная схема контроллера изображена на рисунке 1.
Рисунок 1 — Функциональная схема контроллера
Данный контроллер располагает конфигурируемым интерфейсом GPIF II. При помощи него, к чипу можно подключить ПЛИС, память, необходимый процессор и т.д… Вся соль этого интерфейса в том, что его можно настроить как угодно. В его распоряжении 32-бит. шина данных, 8-бит шина адреса и большое кол-во линий синхронизации. Не обязательно использовать GPIF II на полную катушку, можно ограничиться меньшей шиной данных, убрать шину адреса, а освободившиеся ножки задействовать для других целей. Предельная частота работы интерфейса — 100МГц. Его программирование происходит в специальном ПО — GPIF II Designer. Написание основной прошивки идет в среде от «Cypress» основанной на Eclipse.
В качестве ядра трудится ARM926EJ на 200МГц. У EZ-USB FX3 нет Flash-памяти, программа загружается в SRAM из внешней Flash, EEPROM или через USB3.0 с ПК. Емкость SRAM и кол-во линий данных GPIF II зависят от модели контроллера. Максимальный размер оперативной памяти — 512kB, а минимальный — 256kB. Отладка осуществляется через JTAG. Контроллер помимо GPIO имеет стандартный набор интерфейсов — SPI, I2C, UART, I2S. Также в чипе реализован DMA-контроллер. Корпуса представлены следующими типами — BGA на 121 ногу и WLCSP на 131 пин.
Принцип передачи видеоданных при помощи EZ-USB FX3
Изначально планировал привести в качестве примера связку ФПУ — ПК на отечественной матрице 1000х1000 элементов с разбором создания прошивки для интерфейса GPIF II и самого контроллера, но не стал этого делать, слишком много нужно было бы написать для одной статьи. Тем более, что у «Cypress» есть очень хороший пример для HD матрицы по которому можно разобраться с работой м/схемы при передаче видеоданных.
Итак, весь каскад передачи данных:
Рисунок 2 — каскад передачи видеоданных
1) Интерфейс GPIF II. Он работает в двухпоточном режиме, каждый поток подключен к своему соккету. Соккет — это точка соединения между различной периферией контроллера, а так же — периферией и процессором. Producer Socket — соккет, через который записываются данные, Consumer Socket — соккет, через который данные читаются. Двухпоточный режим (Ping-Pong) позволяет без задержек записывать данные в буфера. Когда при работе нулевого потока заполнится нулевой буфер, то произойдет автоматическое переключение на другой поток и запись пойдет в новый буфер, а старый — будет отправлен в ПК. Отсутствие задержек позволяет передавать видео сигнал в реальном времени, ограничиваясь небольшим объемом памяти.
2) Блок DMA. В этом примере используется 8 буферов для приема и передачи данных. Массивы могут быть 8-ми, 16-ти или 32-ух разрядные. Глубина массивов зависит от конкретной задачи. Можно использовать разное количество буферов, главное чтобы они были одинаковой разрядности и объема и чтобы их суммарный объем не вылезал за пределы доступной памяти. Описание каждого буфера хранится в своем дескрипторе — Descriptor[7:0]. Все восемь дескрипторов делятся на две группы (Descriptor Chain 1 и 2). Каждая из двух групп подключена к своему записывающему сокету.
Цепь дескрипторов 3 относится к контроллеру USB и служит для упорядоченного чтения данных через USB Socket 3 из буферов 7-0.
Как Вы могли заметить, на рисунке нет блока CPU. Его отсутствие не случайно, т.к. если нет необходимости в обработке передаваемых данных, то ядро можно не задействовать и передавать данные напрямую.
При передаче данных без обработки принимающая сторона в виде ПК получает сосиску с информацией без опознавательных знаков. За начальную точку синхронизации принимают первый принятый элемент и ведут счет пикселей, строк и кадров от этого элемента. Зная кол-во пикселей в строке и кол-во строк в кадре такое провернуть можно. Получается асинхронная синхронизация, штука не очень приятная. Желательно, чтобы данные приходили уже пронумерованными.
Вот тут-то нам на помощь и приходит ядро ARM9, которое позволяет реализовать программную синхронизацию. При инициализации DMA-массивов необходимо зарезервировать в каждом буфере место под специальный заголовок (например 16 байт). Эти 16 байт никогда не будут заполняться видеоданными. При заполнении буфера контроллер DMA будет сигнализировать об этом процессору, а процессор, в свою очередь (при Вашей помощи) возьмет и запишет необходимые данные в заголовок. После оформления заголовка процессор даст команду на передачу буфера в ПК.
Для более полного описания принципа работы контроллера при передаче видеоданных рекомендую почитать этот гайд — «How to Implement an Image Sensor Interface Using EZ-USB FX3 in a USB» от «Cypress». В нем детально описан процесс создания прошивки для GPIF II. После разбора мануала можно скачать сопутствующий проект под Эклипс для самого контроллера и разобраться с ним.
Статья получилась вводной и малоинформативной с практической точки зрения. Если Вам захочется посмотреть на процесс программирования GPIF II и МК то, пишите в комментариях, постараюсь все расписать. В качестве примера разберу прошивку для отечественной линейки на 12 тысяч элементов.
