Jeg er alltid på utkikk etter et kvalitets tillegg til laboratoriet mitt som vil respektere mitt strenge budsjett. Nylig har jeg funnet meg selv å presse Hertz barrieren med hvert annet prosjekt jeg gjør og dermed desperat ønsket et høyt båndbreddeomfang. Dessverre har det bare nylig nylig 70 MHz til 100 MHz blitt veldig rimelig, mens en ny quad-kanalsoscilloskop i 500 MHz til 1 GHz-serien fortsatt koster en formue å skaffe seg. Mitt eneste alternativ var å finne et absolutt mirakel i form av et gammelt høy båndbreddeomfang.
Det virket som Guds guder, jeg ned elektronikk smilte på meg da jeg fant denne dumpsteren som er bestemt HP 54542C. Det syntes å være i fairy god form og var den beste hunden i sin dag. Men noe måtte bli ødelagt? Sikkert nok, var skjermen klart feil og ulastelig. Vil du vite hvordan jeg løst det? Fire bokstaver: FPGA.
Problemet
Noen grunne undersøkelser på dette omfanget avslørte noen interessante historie. Dette var tilsynelatende HPs første high end-omfang med en LCD og var også forløperen til Infiniium-serien av scopes som ville fortsette å veilede markedet. LCD-skjermen følte seg som en ettertanke skjønt. Omfanget hadde en ellers lignende variant med en CRT-skjerm, og versjonen jeg kjøpte bare hadde CRT-fordøyelseskanalene eliminert og en fargeskjerm installert av HP. Jeg håpet LCD-skjermen var på feil, og ikke ASIC kjører det, dette virket som en god innsats som en mild trykk ville i noen tilfeller bringe skjermen tilbake til livet!
Jeg begynte å undersøke grunnårsaken, og begynte å ta fra hverandre LCD-skjermen. Jeg fant noen væske hadde blitt spilt over det; Ingenting hadde korrodert, men rengjøring og reinstallering gjorde ingen forskjell. Gjenforening omfanget med dumpsteren var ikke et alternativ, fordi bortsett fra LCD-skjermen følte omfanget som en absolutt skattekiste. Selv om LCDs sjåførstyret var helt ubrukelig nå, kom det fra en tid da bransjen ennå ikke hadde flyttet på subatomic Pin-tonehøyde på ledningskontakter. Dette underforstått jeg kunne enkelt loddes på en konvensjonell 26-pin-båndkabel-tv for å trykke på alle nødvendige signaler og begynne prosessen med omvendt ingeniørfag protokollen i bruk.
Reverse Engineering LCD-protokollene
Ribbon kabel-tv loddes på toppen av den eksisterende kontakten
Det første trinnet i prosessen var å identifisere signalene på kontakten. Jeg var på utkikket for det mest generiske settet med signaler som kreves for å kjøre noen LCD. Dette bør inneholde noen strengt periodiske signaler, et par noe tilfeldige signaler og selvfølgelig den typiske kraften og bakken. De periodiske signalene vil mange sannsynligvis være pikselklokken og synkroniseringssignalene som ville markere starten på en ny linje og ramme; På den annen side ville de tilfeldige signalene være de faktiske pikseldataene som skal vises. Å dømme i sin alder, var en ganske enkel protokoll forventet. Guidet av denne intuisjonen jeg begynte å undersøke kontakten og snart nok hadde jeg alle 25 signaler funnet ut.
Jeg fant bare to perfekt periodiske signaler: en, et relativt lavt 31,25 kHz-signal inngjerdet på en mistenkelig 60 Hz, og den andre en 25 MHz firkantbølge. Den tidligere måtte være et integrert synkroniseringssignal. 60 Hz var en død gave som den korresponderte med den nominelle bildefrekvensen. 31,25 kHz underliggende signal bør da svare til den horisontale linjen i en ramme. Til slutt måtte 25 MHz-signalet være klokken for hele systemet, faktisk var det pikselklokken.
Deretter måtte jeg gi mening om de tilfeldige signalene som åpenbart var pikseldataene. For det første var behovet for en 25-pin-kontakt klart referert til en slags parallell RGB-konfigurasjon. Totalt fant jeg ni slike signaler som perfekt deler med tre og innpakket at LCD-skjermen brukte ni biter per piksel og tre biter per fargekanal R, G og B henholdsvis.
Eksempel: VGA patio ordningen
Å finne ut ordningen og pin-out var en del av utfordringen. Muligvis var mye mer viktig å finne ut timingen av signalene i bruk. Nesten alltid har rå skjermsignaler det som kalles “porches”. Disse kan betraktes som regioner i hver ramme der data ikke kan skrives. Disse stammer fra CRTs dager hvor den fysiske bjelken av elektroner tok tid til å feie fra enden av en linje tilbake til starten av den andre, eller til og med fra bunnen av skjermen til toppen. Selv om det er mindre uttalt i moderne elektroniske skjermer, eksisterer disse regionene fortsatt fordi LCD-kontrolleren tar tid behandling og shuffling innkommende data.
Bestemme timingen
For å trekke ut timingen prøvde jeg å korrelere pikseldataene med synkroniseringssignalene. Jeg søkte etter noen regioner hvor pikslene var konsekvent 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 toenten alle høye eller alle lave i denne perioden. Når jeg hadde tenkt på disse regionene, brukte jeg markørene til å måle varigheten og oversatt den tiden til et tilsvarende antall piksler.
Dette var et vitalt stykke informasjon som ville garantere en stabil og passende reproduksjon på VGA-skjermen. Planen var å mate disse verdiene som konstanter i Verilog, og bruk tellere til å “tur” den tilsvarende logikken for å oppnå de nødvendige bølgeformene.
Vertikale timings
Til slutt måtte LCDSs oppløsning identifiseres som jeg måtte kjøre erstatningsskjermen på samme innstillinger. Dette ble gjort ved å bare måle de ulike aktive periodene og sammenligne dem med andre signaler som pikselklokken som hadde en periode 40 ns. Den horisontale aktive tiden ble bestemt til å være rundt 25,7 US, slik at den samles på totalt 642,5 piksler og tilsvarende var den vertikale aktive perioden 15,42 ms og med en horisontal periode på 30 US, som tilsvarer 481 linjer. Klart var dette en konvensjonell 640 x 480-skjerm med en revitalisert hastighet på 60 Hz.
Finne en mulig erstatning
Den 8 tommers frelseren
Så den eksisterende skjermen [viste seg å være] ganske vanlig i slutten, og en erstatning virket helt plausibel. Dessverre var størrelsen litt rart; Det er lett å finne syv-tommers skjermer, men åtte? Selv om jeg ikke kunne finne noen ganske priset fall i erstatning på nettet, skjedde størrelsen bare å være den samme som det som ble brukt av mange moderne etter markedet LCD-installasjoner på biler. Disse er gode lavpris “Eyoyo” toppkvalitetsskjermer (£ 50) og aksepterer bokstavelig talt alle utvikler videoinngang fra alle analoge til VGA og til og med HDMI. De støtter også en mye høyere oppløsning på 1024 * 768. Jeg er overrasket over at denne skjermen ikke er massivt populær i Raspberry Pi-samfunnet.
Endelig syntes alt å klikke sammen. Ikke bare kan jeg erstatte LCD-skjermen med denne VGA-skjermen, det passer perfekt som omfanget selv hadde nok plass til en CRT!
Så nøyaktig, hvordan utfører man LCD-skjermen til VGA-konvertering? Med en FPGA selvfølgelig!
Signal konvertering
På dette punktet var det eneste som står mellom meg og et fungerende 500 MHz-omfang, konverterte de tidligere nevnte LCD-signalene til VGA. Det var klart slik relativt rask behandling kunne bare gjøres på en FPGA, men hvilken? Målet mitt var å forlate FPGA på et tidspunkt i omfanget med skjermen, så jeg trengte noe lite og billig. Heldigvis synes eBay å ha massevis av disse gamle Altera Cyclone II-baserte utviklingsstyrene for et sinn som boggles £ 10! Disse er ganske dyktige FPGAs, som holder om 4K logikkelementer og optimal for et lite skala prosjekt som dette.
En vanlig måte disse skjermkonverteringene er gjort, bruker rammebuffere. Tanken er å buffere en hel ramme, utføre konverteringen og spytte den ut i den andre enden. Dessverre krever dette en respektabel størrelse ekstern RAM på FPGA. Disse FPGA-platene er beryktet for ikke å ha noen ekstern RAM, og dermed var denne ordningen ut av spørsmålet. Etter litt tenkning angrep jeg realiseringen om at LCD-signaler og VGA ikke var så ulik. Hva om jeg kunne konvertere fra den ene til den andre på en linje-for-linje, og omgå behovet for en rammebuffer i det hele tatt?
Sammenligning: VGA VS LCD. Dette diagrammet gjelder både de horisontale og vertikale segmentene
Oppsummert:
LCD har:
En piksel klokke
Kombinert synkroniseringssignaler
Kun foran terrassen
Mens VGA har:
Ingen piksel klokke
Separate synkroniseringssignaler
Foran og bakover terrassen med en synkroniseringsperiode
Det integrerte synkroniseringssignalet
Å gå i detalj av hvordan VGA Works er utenfor omfanget av denne artikkelen, men jeg løser det senere. For nå, hvis vi bare undersøker timingskissen, ser vi at den eneste forskjellen mellom de to signalene er antall forekomster og steder i verandaene og plasseringen av gyldige data.
Skissen gjør at konverteringen ser lett ut, men er bare gyldig hvis de to rammene er i fullstendig synkronisering. For å fortelle FPGA å starte produsere en tilsvarende LCD-ramme over VGA, bør vi først identifisere starten på en ny ramme som kommer fra LCD-kontakten slik at vi kan synkronisere med den. This is possibly the trickiest part of the process, because merely examining the edges of the integrated synchronisation signal from the LCD is not sufficient.
We should instead measure the time between two edges and flag the occurrence of a new frame. The rest is a relatively straightforward set of logic gates that produces the above timing diagram. Lastly, as the LCD does not have a back patio or sync pulse, the incoming RGB data should be balance out in time using a tiny FIFO so that it aligns up perfectly where the VGA monitor expects it. once equating the above into Verilog was completed, I proceeded to deal with the hardware.
Hardware setup
The Hardware Setup
The hardware configuration was fortunately very minimalistic. HP was not quite utilising the LCD to its fullest potential. Inspecting the individual bits of eAch-kanal avslørt mye redundans: De forskjellige biter var praktisk talt alltid identiske, noe som indikerer en svært grunne utnyttelse av den fulle ni-biters fargepaletten. Dette var ikke sjokkerende da HP var for det meste gjenbruk av firmware fra CRT-versjonen av omfanget. Alt dette antydet at jeg kom bort med bare å koble opp MSB av hver fargekanal med praktisk talt ingen tap i det endelige bildet. Dette reddet meg enda mye mer dyrebart minne på FPGA.
Det viktigste problemet var at LCD-skjermen brukte 5 V TTL-signaler. FPGA kan akseptere i beste fall 3,3 V signaler, slik at nivåkonvertering måtte utføres. Jeg valgte å utnytte inngangsdiodene i noen av de 74HC-serien logiske buffere for å utføre denne konverteringen. Dette har en tendens til å ødelegge økt / fall ganger betydelig skjønt. For eksempel har 74HC4050 til og med polysilikon motstander i serie med dioden i dysen, forskyvning av behovet for en ekstern serie motstand. Jeg spilte den trygg og la 1 kΩ-serien motstander til inngangen til denne bufferen, og utgangen av ble matet inn i FPGA. Utgangen fra FPGAs HSYNC- og VSYNC-utganger ble tilkoblet direkte til skjermen mens RGB-linjene var koblet til 330 Ω motstander.
Suksess
Suksess!
Etter å ha tamet 25 MHz pixelur for å oppføre seg på et brødbrett og hekte opp FPGA til den nye eksterne
Skjermens VGA-port, omfanget ble brakt tilbake til sin formelle herlighet! Selv om alt fungerte perfekt, var dette oppsettet ganske støy-utsatt. Alt jeg trenger å gjøre nå er å lage en PCB og gi VGA-skjermen en permanent bolig i omfanget.
Så hva er neste du spør? Vel, for tiden er den eneste måten å lagre skjermbilder, gjennom en datert diskettstasjon. Men fordi vi nå har LCD-dataene som går gjennom en FPGA, hvorfor ikke skrive det til et SD-kort?
