I’m always on the lookout for a quality addition to my lab that would respect my strict budget. Recently, I’ve found myself pushing the Hertz barrier with every other project I do and thus desperately desired a high bandwidth scope. Unfortunately, only recently have 70 MHz to 100 MHz become really affordable, whilst a new quad channel oscilloscope in the 500 MHz to 1 GHz range still costs a fortune to acquire. My only option was to find an absolute miracle in the form of an old high bandwidth scope.
It seemed the Gods of Hand Me Down electronics were smiling upon me when I found this dumpster destined HP 54542C. It appeared to be in fairy good shape and was the top canine in its day. but something had to be broken right? sure enough, the screen was clearly faulty and illegible. want to know how I fixed it? four letters: FPGA.
Эта проблема
Some shallow research on this scope revealed some interesting history. This was supposedly HP’s first high end scope with an LCD and was also the precursor to the Infiniium series of scopes that would go on to guideline the market. The LCD did feel like an afterthought though. The scope had an otherwise similar variant with a CRT display, and the version I acquired simply had the CRT digestive tracts eliminated and a colour LCD installed by HP. I hoped the LCD was at fault and not the ASIC’s driving it, this seemed like a good bet as a gentle tap would in some cases bring the screen back to life!
I began investigating the root cause, and started by taking apart the LCD. I found some liquid had been spilt all over it; nothing had corroded, but cleaning and reinstalling did not make any difference. Reuniting the scope with the dumpster wasn’t an option, because aside from the LCD, the scope felt like an absolute treasure trove. even though the LCD’s chauffeur board was completely useless now, it came from a time when the industry had not yet moved onto subatomic pin pitch on wire-to-board connectors. This implied I could conveniently solder on a conventional 26 pin ribbon cable television to tap off all the required signals and begin the process of reverse engineering the protocol in use.
Reverse engineering the LCD Protocols
Ribbon cable television soldered on top of the existing connector
The first step of the process was to identify the signals on the connector. I was on the look-out for the most generic set of signals required to drive any LCD. This should include a few strictly periodic signals, a couple somewhat random signals and ofcourse the typical power and ground. The periodic signals would many likely be the pixel clock and the synchronisation signals which would mark the start of a new line and frame; on the other hand the random looking signals would be the actual pixel data to be displayed. Judging by its age, a fairly easy protocol was expected. Guided by this intuition I began probing the connector and soon enough I had all 25 signals figured out.
I only found two perfectly periodic signals: one, a relatively low 31.25 kHz signal gated at a suspicious 60 Hz, and the other a 25 MHz square wave. The former had to be a integrated synchronisation signal. The 60 Hz was a dead giveaway as it corresponded to the nominal frame rate. The 31.25 kHz underlying signal should then correspond to the horizontal line rate within a frame. Finally, the 25 MHz signal had to be the clock for the whole system, in fact it was the pixel clock.
Next, I had to make sense of the random-looking signals which were evidently the pixel data. Firstly, the need for a 25 pin connector was clearly alluding to some kind of parallel RGB configuration. In total I found nine such signals which perfectly divides by three and wrapped up that the LCD was using nine bits per pixel and three bits per colour channel R,G and B respectively.
Example: VGA patio scheme
Figuring out the scheme and pin-out was part of the challenge. possibly much more essential was figuring out the the timings of the signals in use. Almost always, raw display signals have what are called “porches”. These can be thought of as regions within each frame where data cannot be written. These originated in the days of CRT where the physical beam of electrons took time to sweep from the end of a line back to the start of the other, or even from the bottom of the screen to the top. Although less pronounced in modern electronic screens, these regions still exist because the LCD controller takes time processing and shuffling incoming data.
Determining the timings
To extract the timings I tried to correlate the pixel data with the synchronisation signals. I was searching for any regions where the pixels were consistently unasserted.
Horizontal Timings
After staring at the data for a while, it was clear the LCD was using a simple, single patio scheme on both the horizontal and vertical portion of the integrated sync signal. This was easy to identify because the pixels were set toлибо все высокое, либо все низкое в течение этого периода. Как только я определил эти регионы, я использовал курсоры для измерения их продолжительности и переведен в то время в эквивалентном количестве пикселей.
Это был жизненно важный кусок информации, которая гарантирует бы стабильное и подходящее воспроизведение на мониторе VGA. План состоял в том, чтобы кормить эти значения в качестве постоянных в Verilog, и используют счетчики для «отключения» соответствующей логики для достижения необходимых форм волн.
Вертикальные сроки
Наконец, решение LCDS должно было быть определено, поскольку мне придется запустить замену монитора в те же настройки. Это было сделано просто измерение различных активных периодов и сравнивая их с другими сигналами, такими как пиксельные часы, которые имели период 40 нс. Горизонтальное активное время было определено, что составляет около 25,7 США, что, таким образом, составляющее в общей сложности 642,5 пикселей и аналогично вертикальный активный период составлял 15,42 мс и с горизонтальным периодом 30 нами, что соответствует 481 линиям. Очевидно, что это было обычное отображение 640 x 480 с ревитализацией скорости 60 Гц.
Найти возможность замены
8 дюймов Спаситель
Таким образом, существующий дисплей [оказался] довольно распространен в конце, а замена казалась полностью правдоподобной. К сожалению, размер был немного странным; Легко найти семидюймовые экраны, но восемь? Несмотря на то, что я не мог найти какую-либо справедливую падение замена в Интернете, размер просто оказался таким же, как и в использовании многочисленных современных после рыночных ЖК-инсталляций на автомобилях. Это хорошие недорогими экранами высшего качества «Eyoyo» (50 фунтов стерлингов) и принимают буквально все разрабатывают видео вход от всего аналогового на VGA и даже HDMI. Они также поддерживают гораздо более высокое разрешение 1024 * 768. Я поражен, этот экран не очень популярен в рамках сообщества Raspberry Pi.
Наконец, все, казалось, нажав вместе. Могу ли я не только заменить ЖК-дисплей с этим монитором VGA, он отлично поместится, так как объем даже имел достаточно места для CRT!
Так что именно, как один проводит ЖК-дисплей на VGA? С FPGA конечно!
Преобразование сигналов
На этом этапе единственное, что между собой, стоящее между мной, и функционирующим объемом 500 МГц, успешно преобразуют ранее упомянутые ЖК-сигналы на VGA. Было ясно, что такая относительно быстрая обработка может быть сделана только на FPGA, но какой? Моя цель заключалась в какой-то момент, покидайте FPGA внутри масштаба с экраном, поэтому мне нужно что-то маленькое и дешевое. К счастью, eBay, кажется, имеет тонна этих старых altera Cyclone II на основе досок развития на основе ума, ошеломляющих £ 10! Это довольно способные FPGA, удерживающие около 4K логических элементов и оптимальные для небольшого проекта в масштабе.
Общий способ выполнения этих преобразований отображения, используют буферы кадров. Идея состоит в том, чтобы буфер целую раму выполнять преобразование и выплюнуть его на другом конце. К сожалению, это призывает респектабельный размер внешней ОЗУ на FPGA. Эти платы FPGA печально известны, что не имеет внешнего баран, поэтому эта схема была вне вопроса. После немного мышления я относился к осознанию, что ЖК-сигналы и VGA не были в конце концов. Что, если я смогу преобразовать от одного на другой на линейной основе, и обведите необходимость в буфере кадров вообще?
Сравнение: VGA VS LCD. Эта диаграмма применяется как к горизонтальным, так и на вертикальных сегментах
В итоге:
ЖК-дисплей имеет:
Пиксельные часы
Комбинированные сигналы синхронизации
Только передний патио
тогда как VGA имеет:
Нет пикселей часов
Отдельные сигналы синхронизации
Передний и задний патио с периодом синхронизации
Интегрированный сигнал синхронизации
Будучи деталью того, как работает VGA за пределами объема этой статьи, но я исправлю это позже. На данный момент, если мы просто изучаем эскиз синхронизации, мы видим, что единственное различие между двумя сигналами – количество вхождений и местоположений подъездов и размещение допустимых данных.
Эскиз заставляет преобразование выглядеть легко, но действителен только в том случае, если две кадры в полной синхронизации. Чтобы сказать FPGA начать производить соответствующую ЖК-кадр по VGA, мы должны сначала идентифицировать начало нового кадра, исходящего из LCD Connector, чтобы мы могли синхронизировать к нему. Это, возможно, самая сложная часть процесса, потому что просто изучение краев интегрированного сигнала синхронизации от ЖК-дисплея недостаточно.
Мы должны вместо того, чтобы измерить время между двумя краями и флаг возникновение нового кадра. Остальное является относительно простым набором логических ворот, которые создают вышеуказанную диаграмму Timing. Наконец, в качестве ЖК-дисплея нет пульса на спине или синхронизации, входящие данные RGB должны быть во времена, используя крошечный FIFO, чтобы он отлично выравнивался, где его автоматический выравнивается. После того, как указано выше, в Verilog было завершено, я продолжал справиться с аппаратным обеспечением.
Настройка оборудования
Настройка оборудования
Конфигурация оборудования была к счастью, очень минималистичной. HP не совсем использовал ЖК-дисплей к полному потенциалу. Проверка индивидуальных битов EКанал ACH выявил много избыточности: различные биты были практически всегда одинаковыми, что указывает на очень мелкое использование полной девятибитной цветовой палитры. Это не было шокирующим, поскольку HP в основном повторно использовал прошивку от CRT-версии объема. Все это подразумевало, что я ушел с простым подключением MSB каждого цветного канала практически без потери в конечном изображении. Это спасло меня даже более ценной памяти на FPGA.
Самая значительная проблема заключалась в том, что ЖК-дисплей использовал сигналы 5 В TTL. FPGA может принять в лучшем виде сигналов 3,3 В, поэтому преобразование уровня должна быть выполнена. Я решил использовать входные зажимные диоды в некоторых из логических буферов серии 74HC для выполнения этого преобразования. Это имеет тенденцию уничтожать восхождение / время падения значительно. Например, 74HC4050 даже имеет полисиликоновые резисторы последовательно с диодом в уме, вытесняв необходимость в резисторе внешнего ряда. Я сыграл его безопасным и добавил резисторы серии 1 кОм к входу этих буферов, и вывод подавался в FPGA. Выход выходов FPGA Hsync и VSync напрямую подключен к монитору, в то время как линии RGB были связаны через резисторы 330 Ом.
Успех
Успех!
После укрощения пиксельных часов 25 МГц ведут себя на макете и подключать FPGA к новому внешнему
Порт VGA монитора, объем был возвращен к своей формальной славе! Хотя все сработало отлично, эта настройка была довольно шумным. Все, что мне нужно сделать сейчас, это сделать PCB и предоставить VGA отслеживать постоянное проживание внутри масштаба.
Так что дальше вы спрашиваете? Ну, в настоящее время единственный способ сохранить скриншоты – через датированный дисковод. Но потому что у нас есть данные ЖК-дисплеи, проходящие через FPGA, почему бы не написать, что на SD-карту?