RGB LED -maatriks: 5 sammu

2024 Autor: John Day | [email protected]. Viimati modifitseeritud: 2024-01-30 08:50

Otsige juhiseid Instructable ja leiate palju LED -maatriksprojekte. Ükski neist ei olnud päris see, mida ma tahtsin, milleks oli uurida riist- ja tarkvaradisaini koostoimeid, et midagi toota, ja toota lõpptoode korralikus trükkplaadis koos draiveriga, mille lubage mul kõrgetasemelise „LED-ekraani” juurde joonistada konstruktsioone (nt joone joonistamine, mitte konkreetsete pikslite seadmine). See osa oli minu jaoks oluline, kuna paljud LED -maatriksidraiverid on paljad luud ega anna palju võimalust pildi või animatsiooni programmiliseks loomiseks. See ei tähenda, et te ei saaks teiste draiveritega pilte ja animatsioone luua, vaid see, et peaksite projektist projekti rohkem korduvat tööd tegema.

Nii asusin oma visiooni ellu viima. Esimene samm oli riistvara kujundamine. See oli minu jaoks ilmselt kõige keerulisem, kuna minu taust on rohkem tarkvara. Jällegi oli palju eelküpsetatud kujundusi ja ma kasutasin neid kindlasti inspiratsiooniks, kuid tahtsin õppida tegemise kaudu, seega prototüüpisin 4x4 maatriksi leivaplaadil. Ma õppisin selle protsessi kaudu palju, kuna minu esimesed kordused ei töötanud. Kuid ma tegin riistvara disaini, mis töötas, mis omakorda võimaldas mul hakata draiverit arendama.

Valisin oma draiveriplatvormiks Arduino, kuna see on laialdaselt saadaval ja sellel on palju viiteid veebis. Kuigi karjäärikogemus võimaldas mul jõuda draiveri tööversiooni juurde libedamalt kui riistvaralised jõupingutused, oli ATMega mikrokontrolleri jaoks draiverite jõudlust optimeerides ja programmeerimisliidese väljatöötamise ajal siiski palju kordusi.

Selles juhendis dokumenteeritakse minu projekti kujundus ja mõned peamised õppetunnid. Lisateavet selle projekti kohta leiate minu veebisaidilt siit, sealhulgas täiskomplektid, mida saate osta oma RGB LED -maatriksi ehitamiseks.

Samm: riistvara disain

Minu riistvara disaini peamine eesmärk oli luua hulgaliselt RGB LED -e, mida saaksin programmeerida, kuid samuti ei tahtnud ma palju raha kulutada. Lähenesin sellele, et kasutasin valgusdioodide juhtimiseks 74HC595 vahetusregistreid. Vajalike vahetusregistrite arvu minimeerimiseks paigutasin RGB LED -id maatrikspaigutusse, kus tavalised anoodid seoti ridadesse ja punased, rohelised ja sinised katoodijuhtmed veergudesse. 4x4 maatriksi puhul nägi skeem välja nagu lisatud skeem.

Üks asi, mida kohe märkate, on see, et maatriksiahelat arvestades on mõned LED -valgustite konfiguratsioonid, mida ei saa teha, kui kõik soovitud LED -id põlevad samal ajal. Näiteks ei saa maatriks korraga süttida kahte LED -i, mis on üksteisest diagonaalsed, sest nii ridade kui ka veergude toitmine põhjustab kahe vastassuunalise valgusdioodi süttimise soovitud valgusdioodidega risti. Selle vältimiseks kasutame iga rea skannimiseks multipleksimist. Veebis on palju ressursse, mis hõlmavad multipleksimise tehnikat, ma ei püüa neid siin korrata.

Kuna ma kasutan tavalisi anood -valgusdioode, tähendab see, et read annavad positiivset energiat ja veerud vajuvad maapinnale. Hea uudis on see, et nihkeregistrid 74HC595 võivad nii toiteallikat kui ka energiat tühjendada, kuid halb uudis on see, et neil on piirang, kui palju energiat nad saavad toota või alla lasta. 74HC595 üksikute tihvtide maksimaalne voolutugevus on 70 mA, kuid parem on hoida alla 20 mA. Meie RGB LED -ide üksikute värvide voolutugevus on umbes 20 mA. See tähendab, et 74HC595 ei saa otseselt toita tervet rida LED -e, kui soovin need kõik sisse lülitada.

Niisiis, selle asemel, et rea otse toita, juhib 74HC595 selle asemel iga rea jaoks transistorit ja transistor lülitab rea sisse toitevoolu sisse või välja. Kuna disain kasutab tavalisi anood -valgusdioode, on lülitustransistor PNP. Kui me kasutaksime tavalist katood -LED -i, oleks lülitustransistor NPN. Pange tähele, et kui kasutate PNP -transistorit rea juhtimiseks, muutub nihkeregistri seade selle sisselülitamiseks nüüd madalaks, kuna PNP -transistor vajab sisselülitamiseks emitteri ja aluse vahel negatiivset pinget, mis võimaldab positiivset voolu voolata rida.

Veel üks asi, mida tuleb arvestada, on nihkeregistrite soovitud bitipaigutus. See tähendab, et nihkeregistrite hulgas, millised bitid juhivad maatriksi ridu või veerge. Disain, millega ma saatsin, on see, kus esimene bit ehk "kõige olulisem bit", mis saadeti ahelaga aheldatud nihkeregistritesse, juhib LED -ide punast elemendi veergu, teine bitt kontrollis esimese veeru rohelist elementi, kolmas bit juhib esimese veeru sinine element, neljas bit juhib teise veeru punast elementi,… seda mustrit korratakse veergudes vasakult paremale. Seejärel juhib järgmine saadetud bit viimast või alumist rida, järgmine teine kuni viimane rida,… seda korratakse kuni viimase saadetud bitini või "kõige vähem olulise bitini", kontrollib maatriksi esimest või ülemist rida.

Lõpuks pidin ma kindlaks määrama, milliseid takistiteid ma kasutan iga RGB LED -i LED -i jaoks. Ehkki nõutava takisti arvutamiseks võiksite kasutada standardvalemit, mis ühendab edasipinge ja soovitud voolu, leidsin, et iga LED-i voolu seadmine 20 milliampile andis tulemuseks valkja värvi, kui kõik punased, rohelised ja sinised LED-id põlesid. Niisiis hakkasin seda silmatorkavalt vaatama. Liiga palju punast valges tähendas punase LED -i takisti oomi suurendamist voolu vähendamiseks. Kordasin erineva oomi takistite vahetamist, kuni leidsin kombinatsiooni, mis andis valge värvi, mis tundus mulle õige. Lõplik kombinatsioon oli punase LED -i puhul 180 Ω, rohelise LED -i puhul 220 Ω ja sinise LED -i puhul 100 Ω.

2. samm: riistvara ehitamine - leivaplaat

Riistvarakonstruktori esimene etapp oli leivalaud. Siin tegin 4x4 maatriksi koos RGB LED -idega. Selle maatriksi juhtimiseks oleks vaja 16 bitti, RGB veergude jaoks 12 ja iga rea jaoks 4 bitti. Kaks 74HC595 vahetusregistrit saavad selle kõigega hakkama. Uurisin ja konstrueerisin kõigepealt skeemi, mis arvasin töötavat, seejärel ehitasin selle leivalauale.

Tõenäoliselt oli leivaplaadi ehitamise suurim väljakutse kõigi juhtmete haldamine. Korjasin leivaplaatide jaoks ette valmistatud traadikomplekti, kuid siis oli see pisut raske. Nipp, mis minu arvates oli kasulik, oli luua "port" Arduino tahvliga ühendamiseks. See tähendab, et selle asemel, et ühendada Arduino tihvtid otse leivalaua erinevate IC -tihvtidega, pühendage paar leivalaua rida Arduino ühenduskohaks ja seejärel ühendage vastavad ID -tihvtid nende ridadega. Selle projekti jaoks vajate Arduinoga ainult viit ühendust: +5 V, maa, andmed, kell ja riiv.

Kui leivaplaadi ehitamine oli tehtud, oli mul vaja seda testida. Kuid ilma mingisuguse draiverita, kes vahetusregistritele õigeid signaale saatis, ei suutnud ma testida, kas riistvara paigutus töötab.

3. samm: draiveritarkvara projekteerimine

Arvestades minu enda karjäärikogemust tarkvaraarendusega, oli see projekti osa, mida tegin ilmselt kõige selgemini. Uurisin paljusid teisi Arduino-põhiseid LED-maatriksidraivereid. Kuigi kindlasti on saadaval häid draivereid, polnud ühelgi päris sellist disaini, nagu ma soovisin. Minu autojuhi disainieesmärgid olid järgmised:

• Pakkuge kõrgetasemelist API-d, et saaksite programmiliselt pilte ja animatsioone luua. Enamik autojuhte, keda ma nägin, keskendusid rohkem raskelt kodeeritud piltidele. Samuti, kuna olen ametilt C ++ programmeerija, tahtsin LED -maatriksile joonistamise rakendamiseks ja haldamiseks kasutada head objektorienteeritud disaini.
• Kasutage ekraanil oleva pildi haldamiseks topeltpuhverdatud lähenemisviisi. Üks puhver on see, mida programmiliselt tõmmatakse, teine aga maatriksi pikslite olekut igal hetkel. Selle lähenemisviisi eeliseks on see, et te ei pea multipleksimise värskendustsüklite vahel ekraani järgmist kaadervärskendust täielikult renderdama.
• Kasutage PWM -i, et lubada rohkem kui seitse primitiivset värvi, mida RGB suudab muuta punaste, roheliste ja siniste elementide lihtsate kombinatsioonide abil.
• Kirjutage draiver nii, et see "lihtsalt töötaks" erineva suurusega RGB LED -maatriksitega, mis järgisid minu üldist maatriksi kujundamise lähenemisviisi. Pange tähele, et kuigi minu riistvarakujundus kasutab 74HC595 vahetusregistreid, siis eeldan, et mu draiver töötab mis tahes vahetusregistri stiilis sisse- ja väljalülitusmehhanismiga, mis on paigutatud riistvaralise disainiga sarnase bitipaigutuse abil. Näiteks eeldan, et mu draiver töötab riistvaralise disainiga, mis kasutas veergude juhtimiseks DM13A kiipe ja ridade juhtimiseks 74HC595 kiipi.

Kui soovite otse draiveri koodi vaadata, leiate selle siit GitHubist.

Minu draiveri esimene iteratsioon oli natuke õppimiskõver Arduino platvormi võimaluste kohta. Kõige ilmsem piirang on RAM, mis on 2K baiti Arduino Uno ja Nano jaoks. C ++ objektide kasutamine sellises stsenaariumis ei ole sageli soovitatav objektide mälu üldkulude tõttu. Siiski tundsin, et kui seda õigesti teha, kaalub C ++ objektide kasu üles nende kulud (RAM -is).

Teine suur väljakutse oli välja mõelda, kuidas rakendada impulsi laiuse modulatsiooni vahetusregistrite kaudu, et saaksin genereerida rohkem kui seitse RGB LED-i primitiivset värvi. Olles aastaid Linuxi platvormidel programmeerinud, olin harjunud kasutama konstruktsioone nagu niidid, et hallata järjepidevat ajastust nõudvaid protsesse. Nihkeregistri värskendamise toimingu ajastus on multipleksimist kasutava LED -maatriksi draiveri tegemisel üsna kriitiline. Põhjus on selles, et kuigi multipleksimine toimub nii kiiresti, et teie silmad ei näe üksikute LED -ide vilkumist sisse- ja väljalülitamisel, võivad teie silmad märgata erinevusi kõigi LED -ide kogupikkuses. Kui üks LED -rida põleb pidevalt kauem kui teised, näeb see multipleksimise ajal heledam välja. See võib põhjustada maatriksi ebaühtlase heleduse või maatriksi kui terviku perioodilise löögi (see juhtub siis, kui üks värskendustsükkel võtab teistest kauem aega).

Kuna mul oli vaja järjekindlat ajastusmehhanismi, et muuta vahetusregistri värskendused nõusolekuks, kuid Arduino ametlikult lõime ei toeta, pidin looma oma niiditaolise mehhanismi. Minu esimene kordus selles oli lihtsalt luua silmuse taimer, mis sõltus funktsioonist Arduino loop () ja käivitaks toimingu, kui teatud aeg on möödunud selle toimingu viimasest käivitamisest. See on "ühistulise multitegumtöötluse" vorm. Kõlab hästi, kuid praktikas osutus see vastuoluliseks, kui tulistamiskiirust mõõdeti mikrosekundites. Selle põhjuseks on asjaolu, et kui mul oli kaks neist silmusetaimeritest käimas, võttis üks nende toimingutest sageli piisavalt kaua aega, et teine toiming käivituks soovitud ajast hiljem.

Leidsin, et selle probleemi lahendus on Arduino kohaliku kella katkestamise mehhanismi kasutamine. See mehhanism võimaldab teil käitada väikest bitti koodi väga ühtlaste intervallidega. Nii kujundasin draiveri koodi ümber kujunduselemendi, kasutades kella katkestust, et käivitada kood maatriksi vahetusregistrite saatmiseks multiplekstsükli järgmise värskenduse jaoks. Selleks ja lubamaks ekraanipildi värskendustel toimuda, et see ei segaks vahetusregistrite aktiivset tühjendamist (mida me nimetaksime "võistlustingimuseks"), kasutasin lähenemisviisi, kus nihkeregistri bittide jaoks olid kaks puhverit, üks kirjutamiseks ja üks lugemiseks. Kui kasutaja värskendab maatrikspilti, toimuvad need toimingud kirjutuspuhvris. Kui need toimingud on lõpule viidud, peatatakse katkestused ajutiselt (see tähendab, et kella katkestust ei saa käivitada) ja kirjutuspuhver asendatakse eelmise lugemispuhvriga ja see ei ole uus lugemispuhver, siis tõlgendused lubatakse uuesti. Seejärel, kui kella katkestus käivitub, näidates, et on aeg saata järgmine bitikonfiguratsioon vahetusregistritele, loetakse see teave praegusest lugemispuhvrist. Nii ei teki puhvrisse kirjutamist kunagi, kui kella katkestamise ajal võidakse seda praegu lugeda, mis võib rikkuda vahetuste registritesse saadetud teavet.

Ülejäänud juhi kujundamine oli suhteliselt lihtne objektorienteeritud disain. Näiteks lõin objekti, et hallata mis tahes ekraani oleku nihkeregistri bittkujutist. Bittkujutiste haldamisega seotud koodi kapseldades oli ülalmainitud kaksikpuhvrite lähenemisviisi loomine iseenesest lihtne ülesanne. Kuid ma ei kirjutanud seda juhendit, et ülistada objektorienteeritud disaini voorusi. Teised disainielemendid hõlmavad glüfi ja RGB -kujutise kontseptsiooni. Glüf on kujutise põhikonstruktsioon, millel puudub kaasasündinud värviteave. Võite seda kujutada mustvalge kujutisena. Kui Glyph tõmmatakse LED -ekraanile, antakse värviteave, mis näitab, kuidas "valged" pikslid peaksid olema värvitud. RGB -pilt on pilt, kus igal pikslil on oma värviteave.

Soovitan teil vaadata läbi Arduino visandinäited ja vaadata üle draiveri päise dokumentatsioon, et saada teada, kuidas draiverit kasutada piltide ja animatsioonide loomiseks RGB LED -maatriksil.

Samm: LED -kummitus

LED -maatriksis on "kummitus" nähtus, kus maatriksis olev LED -tuli hõõgub, kui seda ei soovita, tavaliselt väga madalal tasemel. Minu algne riistvarakujundus oli vastuvõtlik kummitustele, eriti viimases reas. Selle põhjuseks on kaks asja: transistorid ei lülitu kohe välja ja parasiitmahtuvus RGB valgusdioodides.

Kuna me ridu skaneerime, kuna transistorid ei lülitu kohe välja, on skaneerimistsükli eelmine rida järgmise rea sisselülitamisel endiselt osaliselt toidetud. Kui antud veerg, mis oli eelmises reas välja lülitatud, lülitub uue rea sisselülitamisel uuesti sisse, süttib selle rea veeru LED -tuli lühikeseks ajaks, kui eelmise rea lülitustransistor on veel keeramisprotsessis väljas. Transistori väljalülitamiseks kulub märgatavalt aega, mis on transistori aluse küllastumine. See põhjustab transistori kollektori-emitteri tee jätkamist, kui vool eemaldatakse alusest, vähemalt seni, kuni küllastus hajub. Arvestades, et meie multipleksimise värskendustsükkel põhjustab ridade tahtliku sisselülitamise mikrosekundites, võib eelmise rea küllastunud transistori juhtivus olla märgatav murdosa sellest. Selle tulemusena võib teie silm tajuda seda väga väikest aega, mil eelmise rea LED -tuli põleb.

Transistori küllastusprobleemi lahendamiseks võib aluse ja kollektori vahel olevale transistorile lisada Schottky dioodi, mis põhjustab transistori sisselülitamisel alusele veidi tagasivoolu, vältides transistori küllastumist. See omakorda põhjustab transistori kiiremat väljalülitamist, kui vool eemaldatakse alusest. Selle efekti põhjaliku selgituse leiate sellest artiklist. Nagu näete selle jaotise pildilt, on ilma dioodita kummitus üsna märgatav, kuid dioodi lisamine ahelasse iga rea jaoks eemaldab kummituse oluliselt.

RGB LED -id on vastuvõtlikud teisele nähtusele, mida nimetatakse parasiitmahtuvuseks. Selle algpõhjus on asjaolu, et kõigil kolmel RGB LED -seadme värvilisel valgusdioodil on erinev edasipinge. See erinevus pingetes võib põhjustada elektrilise mahtuvuse mõju iga LED -värvi vahel. Kuna LED -seadmesse koguneb toite ajal elektrilaeng, tuleb toite eemaldamisel parasiitmahtuvus tühjendada. Kui see LED -veerg on muul viisil teise rea toiteks sisse lülitatud, tühjeneb parasiitlaeng selle veergude LED -i kaudu ja põhjustab selle lühikest helendamist. Seda efekti selgitatakse selles artiklis kenasti. Lahendus on lisada selle parasiitlaengu jaoks tühjendustee muul viisil kui LED -i enda kaudu ja seejärel anda LED -le aeg tühjenemiseks, enne kui kolonni uuesti sisse lülitatakse. Minu riistvarakujunduses saavutatakse see, lisades iga rea toiteliinile takisti, mis ühendab tugevuse maapinnaga. See toob kaasa rohkem voolu, kui rida on sisse lülitatud, kuid tagab parasiitide mahtuvuse tühjenemise tee, kui rida pole toiteallikas.

Väärib aga märkimist, et praktikas leian, et parasiitide mahtuvuse mõju on vaevumärgatav (kui otsite, siis leiate), ja seetõttu pean selle lisatakisti lisamist vabatahtlikuks. Küllastunud transistoride aeglustusaja mõju on palju tugevam ja märgatavam. Sellegipoolest, kui vaatate selles jaotises esitatud kolme fotot, näete, et takistid eemaldavad täielikult kõik kujutised, mis esinevad kauem kui aeglase transistori väljalülitusajad.

Samm: lõplik tootmine ja järgmised sammud

Selle projekti viimane etapp oli minu jaoks trükkplaadi (PCB) loomine. PCB kujundamisel kasutasin avatud lähtekoodiga programmi Fritzing. Kuigi 100 LED -i paigutamiseks 10x10 tahvlile oli palju korduvaid ülesandeid, leidsin ma, et tegelikult oli see projekti faas kummaliselt rahuldav. Iga elektrilise raja paigutuse väljamõtlemine oli nagu pusle ja selle mõistatuse lahendamine tekitas saavutustunde. Kuna ma pole trükkplaatide tootmiseks valmis, kasutasin ühte paljudest veebiavarustest, mis teevad väikeseid kohandatud trükkplaate. Osade kokku jootmine oli üsna sirge, kuna minu disain kasutas kõiki läbi aukude osi.

Selle juhendi kirjutamise ajal on mul oma RGB LED -maatriksi projektide jaoks järgmised plaanid:

1. Jätkake draiveri täiustamist API kihis, et võimaldada programmeerijal rohkem kõrgetasemelist funktsionaalsust, eriti teksti kerimist.
2. Looge suuremaid maatrikskujundusi, näiteks 16x16 või isegi 16x32.
3. Avastage rea toite lülitamiseks BOS -ide asemel MOSFET -id
4. Avastage veergude vahetamiseks pigem DM13A kui pideva voolu draiverid kui 74HC595
5. Looge draivereid teistele mikrojuhtimisplatvormidele, nagu Teensy, ODROID C2 või Raspberry Pi.

Pange tähele, et nii riistvara disain kui ka draiver on antud GitHubi hoidlas avatud lähtekoodiga GPL v3 litsentsi alusel välja antud. Veelgi enam, kuigi kuigi trükkplaatide tootjad teevad minu PCB -disaini "väikseid töid", saan siiski palju rohkem, kui isiklikult vajan. Nii et ma müün oma veebisaidilt täiskomplekte erinevatele RGB LED -maatriksikujundustele (trükkplaat ja kõik osad).