FPGA räddar räckvidd från dumpsteren

Jag är alltid på utkik efter ett kvalitet till mitt laboratorium som respekterar min strikta budget. Nyligen har jag funnit mig att driva Hertz-barriären med alla andra projekt som jag gör och därmed önskat ett högt bandbreddsområde. Tyvärr har bara nyligen 70 MHz till 100 MHz verkligen överkomliga, medan ett nytt quad Channel Oscilloskop i 500 MHz till 1 GHz-sortiment fortfarande kostar en förmögenhet att förvärva. Mitt enda alternativ var att hitta ett absolut mirakel i form av ett gammalt högt bandbreddsområde.

Det verkade gudarna av hand mig ner elektronik leende på mig när jag hittade denna dumpster avsedda HP 54542C. Det verkade vara i god form och var den bästa hunden i sin dag. Men något måste brytas rätt? Visst nog var skärmen klart felaktig och oläslig. Vill du veta hur jag fixade det? Fyra bokstäver: FPGA.

Problemet
Några grunda forskning om detta omfattning avslöjade någon intressant historia. Detta var förmodligen HP: s första high end räckvidd med en LCD och var också föregångaren till Infiniium-serien av Scopes som skulle gå vidare till riktlinjen. LCD-skärmen kände dock en eftertanke. Omfattningen hade en annars liknande variant med en CRT-skärm, och den version jag förvärvade helt enkelt hade CRT-matsmältningsorganen eliminerade och en färg LCD installerad av HP. Jag hoppades att LCD-skärmen var på fel och inte Asikens körning, det verkade som en bra satsning som en mild kran skulle i vissa fall föra skärmen tillbaka till livet!

Jag började undersöka grundorsaken och började med att ta bort LCD-skärmen. Jag hittade att viss vätska hade spillts över hela det; Ingenting hade korroderat, men rengöring och ominstallation gjorde ingen skillnad. Återförening Omfattningen till dumpsteren var inte ett alternativ, för bortsett från LCD-skärmen kände räckvidden som en absolut skattkorg. Trots att LCD: s chaufförbräda var helt värdelös nu, kom det från en tid då branschen ännu inte hade flyttat till subatomisk stifthöjd på tråd-till-kartonganslutningar. Detta underförstod att jag kunde bekvämt lödda på en konventionell 26-kabelband-kabel-tv för att knacka på alla nödvändiga signaler och börja processen för omvändteknik som protokollet används.

Omvänd teknik LCD-protokollen

Band kabel-tv lödd ovanpå den befintliga kontakten
Det första steget i processen var att identifiera signalerna på kontakten. Jag var på utkik efter den mest generiska uppsättningen signaler som krävdes att köra någon LCD-skärm. Detta bör innehålla några strängt periodiska signaler, ett par något slumpmässiga signaler och naturligtvis den typiska kraften och marken. De periodiska signalerna skulle troligen vara pixelklockan och synkroniseringssignalerna som skulle markera början på en ny linje och ram; Å andra sidan skulle de slumpmässiga signalerna vara de faktiska pixeldata som ska visas. Att döma i sin ålder förväntades ett ganska lätt protokoll. Guidad av denna intuition började jag probing kontakten och snart nog hade jag alla 25 signaler räknat ut.

Jag hittade bara två perfekt periodiska signaler: en, en relativt låg 31,25 kHz-signal gated vid en misstänkt 60 Hz, och den andra en 25 MHz kvadratvåg. Den förstnämnda måste vara en integrerad synkroniseringssignal. 60 Hz var en död giveaway som den motsvarade den nominella bildhastigheten. Den underliggande signalen 31.25 kHz bör då motsvara den horisontella linjeshastigheten i en ram. Slutligen måste 25 MHz-signalen vara klockan för hela systemet, det var faktiskt pixelklockan.

Därefter var jag tvungen att känna av de slumpmässiga signalerna som uppenbarligen var pixeldata. För det första var behovet av en 25 stiftkontakt helt och hållet hänvisat till någon form av parallell RGB-konfiguration. Totalt fann jag nio sådana signaler som helt skiljer sig med tre och inslagna att LCD-skärmen använde nio bitar per pixel och tre bitar per färgkanal R, G och B.

Exempel: VGA Patio Scheme
Att räkna ut systemet och pin-out var en del av utmaningen. Eventuellt mycket viktigare var att räkna ut tidpunkten för signalerna som används. Nästan alltid har råvisningssignaler vad som kallas “verandor”. Dessa kan anses vara regioner inom varje ram där data inte kan skrivas. Dessa härstammar i de dagar av CRT där den fysiska strålen av elektroner tog tid att sopa från slutet av en linje tillbaka till början av den andra, eller till och med från botten av skärmen till toppen. Även om de är mindre uttalade i moderna elektroniska skärmar, finns dessa regioner fortfarande eftersom LCD-kontrollen tar tid bearbetning och shuffling inkommande data.

Determining the timings

För att extrahera de tidpunkter jag försökte korrelera pixeldata med synkroniseringssignalerna. Jag letade efter några regioner där pixlarna var konsekvent otillåtna.

Horisontella tidpunkter
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 toantingen alla höga eller helt låga under denna period. När jag hade minskat dessa regioner använde jag markörerna för att mäta sin varaktighet och översätta den tiden till ett motsvarande antal pixlar.

Detta var en viktig del av information som skulle garantera en stabil och lämplig reproduktion på VGA-monitorn. Planen var att mata dessa värden som konstanter i verilog och använda räknare till “resa” motsvarande logik för att uppnå de nödvändiga vågformerna.

Vertikala tidpunkter
Slutligen måste LCDS-upplösningen identifieras som jag skulle behöva köra ersättningsskärmen i samma inställningar. Detta gjordes genom att helt enkelt mäta de olika aktiva perioderna och jämföra dem med andra signaler, såsom pixelklockan som hade en period 40 ns. Den horisontella aktiva tiden bestämdes att vara omkring 25,7 US, vilket utgör totalt 642,5 pixlar och på liknande sätt var den vertikala aktiva perioden 15,42 ms och med en horisontell period av 30 US, som motsvarar 481 linjer. Tydligen var detta en konventionell 640 x 480-display med en revitalize-hastighet på 60 Hz.

Hitta en möjlighets ersättning

Den 8 tums frälsaren
Så den befintliga displayen [visade sig vara] ganska vanlig i slutändan, och en ersättare verkade helt plausibel. Tyvärr var storleken lite udda; Det är lätt att hitta sju-tums skärmar men åtta? Trots att jag inte kunde hitta någon ganska prissatta droppe i byte på webben, råkade storleken bara vara densamma som den som användes av många moderna efter marknadsföringsändringar på bilar. Dessa är bra billiga “Eyoyo” toppkvalitetsskärmar (£ 50) och accepterar bokstavligen alla utvecklar av videoingång från all analog till VGA och till och med HDMI. De stöder också en mycket högre upplösning på 1024 * 768. Jag är förvånad över den här skärmen är inte massivt populär inom Raspberry Pi-samhället.

Slutligen tycktes allt klicka ihop. Jag kan inte bara ersätta LCD-skärmen med den här VGA-skärmen, den skulle passa perfekt som räckvidden även hade tillräckligt med utrymme för en CRT!

Så exakt, hur utför man LCD-skärmen till VGA-konvertering? Med en FPGA självklart!

Signalomvandling

Vid denna tidpunkt har det enda som står mellan mig och ett fungerande 500 MHz-omfattning framgångsrikt omvandlade de tidigare nämnda LCD-signalerna till VGA. Det var tydligt att en sådan relativt snabb bearbetning endast kunde göras på en FPGA, men vilken? Mitt mål var att vid någon tidpunkt lämna FPGA inuti räckvidden med skärmen, så jag behövde något litet och billigt. Lyckligtvis verkar Ebay ha massor av dessa gamla Altera Cyclone II-baserade utvecklingsbrädor för ett sinne Boggling £ 10! Dessa är ganska kapabla FPGA, håller cirka 4K logiska element och optimalt för ett litet skalaprojekt som detta.

Ett vanligt sätt Dessa visningsomvandlingar görs använder rambuffertar. Tanken är att buffra en hel ram, utföra omvandlingen och spotta den i den andra änden. Tyvärr kräver det en respektabelt externt RAM på FPGA. Dessa FPGA-brädor är berömda för att inte ha någon extern RAM, så detta system var av frågan. Efter lite tänkande handlade jag om att realiseringen av LCD-signalerna och VGA inte var så annorlunda. Vad händer om jag kunde konvertera från en till den andra på en linjebaserad basis, och kringgå behovet av en rambuffert alls?

Jämförelse: VGA vs LCD. Detta diagram gäller både de horisontella och vertikala segmenten
Sammanfattningsvis:

LCD har:

En pixelklocka

Kombinerade synkroniseringssignaler

Endast främre uteplats

VGA har:

Ingen pixel klocka

Separata synkroniseringssignaler

Fram och bak uteplats med en synkroniseringsperiod

Den integrerade synkroniseringssignalen
I detalj av hur VGA fungerar är bortom omfattningen av den här artikeln, men jag fixar det senare. För närvarande, om vi helt enkelt undersöker timing skiss, ser vi att den enda skillnaden mellan de två signalerna är antalet förekomster och platser i verandorna och placeringen av giltiga data.

Skissen gör att konverteringen ser lätt ut, men är bara giltig om de två ramarna är i fullständig synkronisering. För att berätta för FPGA att börja producera en motsvarande LCD-ram över VGA, bör vi först identifiera starten på en ny ram som kommer från LCD-kontakten så att vi kunde synkronisera 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-kanalen avslöjade mycket redundans: De olika bitarna var praktiskt taget alltid identiska, vilket indikerar ett mycket grunt utnyttjande av den fulla nio-bitars färgpalett. Detta var inte chockerande som HP var mestadels återanvända firmware från CRT-versionen av omfattningen. Allt detta innebar att jag kom undan med att bara koppla upp MSB av varje färgkanal med praktiskt taget ingen förlust i den slutliga bilden. Detta räddade mig ännu mycket dyrbart minne på FPGA.

Det viktigaste problemet var att LCD-skärmen använde 5 V TTL-signaler. FPGA kan acceptera i bästa fall 3,3 V signaler så att nivån konvertering skulle utföras. Jag valde att utnyttja de ingående klämdioderna i några av de 74HC-serie logikbuffertarna för att utföra denna omvandling. Detta tenderar att förstöra stigning / fall gånger betydligt. Exempelvis har 74HC4050 även polysilikonmotstånd i serie med dioden i munstycket, som förskjuter behovet av ett externt seriemotstånd. Jag spelade det säkra och lade till 1 kΩ-seriemotstånd till ingången till denna buffert och utsignalen från matades in i FPGA. Utgången från FPGAs HSYNC- och VSYNC-utgångar var anslutna direkt till monitorn medan RGB-linjerna länkades genom 330 Ω motstånd.

Framgång

Framgång!
Efter att ha tömt den 25 MHz Pixel Clock att uppträda på en breadboard och haka upp FPGA till den nya externa

Övervakning av VGA-porten, var räckvidden tillbaka till sin formella ära! Även om allt fungerade perfekt, var den här inställningen ganska buller-benägen. Allt jag behöver göra nu är att göra en PCB och bevilja VGA-övervakningen en permanent bosättning inom räckvidden.

Så vad är det då du frågar? Tja, för närvarande är det enda sättet att spara skärmdumpar genom en daterad diskettenhet. Men för att vi nu har LCD-data som går igenom en FPGA, varför inte skriva det till ett SD-kort?

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Post