RGB LED Matrix: 5 stappe

2024 Outeur: John Day | [email protected]. Laas verander: 2024-01-30 07:27

Soek Leerbaar en u kan baie LED -matriksprojekte vind. Nie een van hulle was presies wat ek wou hê nie, naamlik om die interaksies van hardeware- en sagteware-ontwerp te ondersoek om iets te vervaardig, en die finale produk te vervaardig in 'n netjiese PCB met 'n bestuurder wat ek na die "LED-skerm" kan trek met behulp van hoë vlak konstrukte (bv. 'n lyn trek in plaas van die stel van spesifieke pixels). Hierdie deel was vir my belangrik, aangesien baie van die LED -matriksbestuurders kaalbene is en nie veel bied om programmaties 'n beeld of animasie te skep nie. Dit beteken nie dat u nie beelde en animasies met die ander bestuurders kan skep nie, net dat u meer herhalende werk van projek tot projek moet doen.

Daarom het ek my visie probeer bereik. Die eerste stap was om die hardeware te ontwerp. Dit was waarskynlik die moeilikste vir my, aangesien my agtergrond meer sagteware is. Weereens was daar baie voorgebakte ontwerpe, en ek het dit beslis as inspirasie gebruik, maar ek wou leer deur te doen, en ek het 'n 4x4-matriks op 'n broodbord prototipe. Ek het baie geleer deur die proses, aangesien my eerste paar iterasies nie gewerk het nie. Maar ek het hardeware ontwerp wat gewerk het, wat my weer toegelaat het om 'n bestuurder te begin ontwikkel.

Ek het die Arduino gekies as my bestuurdersplatform, want dit is wyd beskikbaar en het baie verwysings aanlyn. Alhoewel my loopbaanervaring my toelaat om vinniger na 'n werkende weergawe van 'n bestuurder te kom as my hardeware -pogings, was daar steeds baie herhalings, terwyl ek die bestuurderprestasie vir die ATMega -mikrobeheerder geoptimaliseer het en 'n programmerings -API ontwikkel het waarvan ek hou.

Hierdie instruksies dokumenteer die ontwerp en 'n paar belangrike leerstellings uit my projek. Meer inligting oor hierdie projek kan op my webwerf hier gevind word, insluitend volledige kits wat u kan koop om u eie RGB LED -matriks te bou.

Stap 1: Hardeware -ontwerp

Die hoofdoel van my hardeware -ontwerp was om 'n verskeidenheid RGB -LED's te skep wat ek kon programmeer, maar ek wou ook nie baie geld spandeer nie. Die benadering waarop ek besluit het, was om 74HC595 -skofregisters te gebruik om die LED's te beheer. Om die aantal skofregisters wat nodig is te verminder, het ek die RGB -LED's in 'n matriksuitleg gerangskik waar die algemene anodes in rye vasgemaak is en die rooi, groen en blou katodeleiers in kolomme vasgemaak is. Vir die 4x4 -matriks het die stroombaandiagram soos die aangehegte kringdiagram gelyk.

Een ding wat u dadelik sal opmerk, is dat gegewe die matrikskring, daar 'n paar LED -beligtingskonfigurasies is wat nie gedoen kan word terwyl al die gewenste LED's gelyktydig aan is nie. Die matriks kan byvoorbeeld nie gelyktydig twee LED's wat diagonaal van mekaar is, aansteek nie, want as die rye en kolomme aangedryf word, sal die twee teenoorgestelde LED's die loodregte diagonaal van die verlangde LED's laat brand. Om dit te vermy, gebruik ons multiplexing om deur elke ry te kyk. Daar is baie hulpbronne op die internet wat die tegniek van multiplexing dek; ek gaan dit nie hier herhaal nie.

Aangesien ek gewone anode -LED's gebruik, beteken dit dat die rye positiewe krag bied en die kolomme tot op die grond sink. Die goeie nuus is dat die 74HC595 -skofregisters beide krag en sink kan kry, maar die slegte nuus is dat hulle 'n beperking het op hoeveel krag hulle kan kry of sink. Individuele penne van die 74HC595 het 'n maksimum stroomverbruik van 70 mA, maar dit is die beste om minder as 20 mA te hou. Die individuele kleure in ons RGB -LED's het elk ongeveer 20 mA trek. Dit beteken dat die 74HC595 nie 'n hele reeks LED's direk kan aanstuur as ek dit wil aanskakel nie.

Dus, in plaas daarvan om die ry direk aan te skakel, sal die 74HC595 in plaas daarvan 'n transistor vir elke ry aandryf, en die transistor sal die stroom wat die ry aandryf aan of uitskakel. Aangesien die ontwerp 'n gemeenskaplike anode LED's gebruik, sal die skakel transistor PNP wees. As ons 'n gewone katode LED gebruik, sou die skakel transistor NPN wees. Let daarop dat met die gebruik van 'n PNP -transistor om 'n ry te ry, die skofregister se instelling om dit aan te skakel nou laag word, aangesien 'n PNP -transistor 'n negatiewe spanning tussen die emitter en die basis moet aanskakel, waardeur positiewe stroom in die ry.

Nog 'n ander ding wat u moet oorweeg, is die gewenste bituitleg van die skofregisters. Dit is, onder die skofregisters, watter bisse bepaal watter rye of kolomme in die matriks. Die ontwerp waarmee ek gestuur het, is waar die eerste bit, of 'die belangrikste bit', gestuur na die madeliefieketting -skofregisters die kolom van die LED's se rooi element beheer, die tweede bit die groen element van die eerste kolom, die derde bit beheer die eerste kolom se blou element, die vierde bis beheer die rooi element van die tweede kolom, … hierdie patroon word oor die kolomme van links na regs herhaal. Dan beheer die volgende gestuurde bietjie die laaste, of onderste, ry, die volgende een die tweede tot laaste ry, … dit word herhaal totdat die laaste bietjie gestuur, of "minste betekenisvolle bit", die eerste of boonste ry in die matriks beheer.

Uiteindelik moes ek bepaal watter weerstande ek vir elk van die LED's in die RGB -LED sou gebruik. Alhoewel u die standaardformule wat die voorwaartse spanning en die gewenste stroom kombineer, kon gebruik om die benodigde weerstand te bereken, het ek gevind dat die instelling van die stroom van elke LED op 20 milliampies 'n spierwit kleur tot gevolg het wanneer al die rooi, groen en blou LED's aan was. So ek het begin om dit te baljaar. Te veel rooi in die wit beteken dat die weerstands ohm van die rooi LED verhoog word om die stroom te verminder. Ek het herhaaldelik weerstands van verskillende ohm verwissel totdat ek 'n kombinasie gevind het wat 'n wit kleur gekry het wat ek voel reg was. Die finale kombinasie was 180 Ω vir die rooi LED, 220 Ω vir die groen LED en 100 Ω vir die blou LED.

Stap 2: Hardeware -konstruksie - broodbord

Die eerste fase van die hardeware -konstruksie was die broodplankry. Hier het ek 'n 4x4 -matriks gemaak met die RGB LED's. Hierdie matriks benodig 16 bisse om te beheer, 12 vir die RGB -kolomme en 4 vir elke ry. Twee 74HC595 -skofregisters kan dit alles hanteer. Ek het eers 'n kring ondersoek en ontwerp wat ek gedink het sou werk, en dit toe op die broodbord gebou.

Waarskynlik die grootste uitdaging van die broodbordbou was om al die drade te bestuur. Ek het 'n vooraf gevormde draadstel vir broodborde opgetel, maar toe was dit 'n bietjie ongemaklik. 'N Truuk wat ek nuttig gevind het, was om 'n' poort 'te skep om aan te sluit op die Arduino -bord. Dit wil sê, eerder as om die penne op die Arduino direk aan die verskillende IC -penne op die broodbord te koppel, moet u 'n paar rye op die broodbord daarop toewy om die verbindingspunt vir die Arduino te wees en dan die relevante ID -penne aan die rye te koppel. Vir hierdie projek benodig u slegs vyf verbindings met die Arduino: +5V, grond, data, klok en grendel.

Nadat die broodbord gebou is, moes ek dit toets. Sonder 'n soort bestuurder om die regte seine na die skofregisters te stuur, kon ek egter nie toets of die hardeware -uitleg werk nie.

Stap 3: Ontwerp van bestuurdersagteware

Gegewe my eie loopbaanervaring met sagteware -ontwikkeling, was dit die deel van die projek wat ek waarskynlik die duidelikste in gedagte gehad het. Ek het baie van die ander Arduino-gebaseerde LED-matriksbestuurders ondersoek. Alhoewel daar beslis goeie bestuurders beskikbaar is, het niemand die ontwerp wat ek wou hê nie. My ontwerpdoelwitte van die bestuurder was:

• Bied 'n hoëvlak-API om beelde en animasies programmaties te kan skep. Die meeste bestuurders wat ek gesien het, was meer gefokus op hardgekodeerde beelde. Aangesien ek 'n C ++ programmeerder is, wou ek ook 'n goeie objekgeoriënteerde ontwerp gebruik om die aktiwiteite van teken na die LED -matriks te implementeer en te bestuur.
• Gebruik 'n dubbelgebufferde benadering om die beeld op die skerm te bestuur. Die een buffer is waarby programmaties ingetrek word, terwyl die ander die toestand van die matrikspixels op 'n gegewe oomblik verteenwoordig. Die voordeel van hierdie benadering is dat u nie die volgende raamopdatering vir die skerm volledig moet weergee tussen die opdateringsiklusse van die multiplexing nie.
• Gebruik PWM om meer as die sewe primitiewe kleure toe te laat wat 'n RGB kan weergee deur eenvoudige kombinasies van die rooi, groen en blou elemente.
• Skryf die bestuurder so dat dit "net werk" met verskillende grootte RGB LED -matrikse wat my algemene matriksontwerpbenadering gevolg het. Let daarop dat terwyl my hardeware -ontwerp 74HC595 -skofregisters gebruik, ek van my bestuurder sou verwag om te werk met enige aan-/af -meganisme van die skuifregisterstyl wat met 'n soortgelyke bituitleg as my hardeware -ontwerp uiteengesit word. Ek sou byvoorbeeld verwag dat my bestuurder sou werk met 'n hardeware -ontwerp wat DM13A -skyfies gebruik het om die kolomme te beheer en 'n 74HC595 -chip om die rye te beheer.

As u direk na die bestuurderkode wil kyk, kan u dit hier op GitHub vind.

Die eerste herhaling van my bestuurder was 'n bietjie van 'n leerkurwe oor die vermoëns van die Arduino -platform. Die duidelikste beperking is die RAM, wat 2K grepe is vir die Arduino Uno en Nano. As gevolg van die geheue -oorhoofse van voorwerpe, word dit dikwels nie aanbeveel om C ++ -voorwerpe in so 'n scenario te gebruik nie. Ek het egter gevoel dat die voordeel van voorwerpe in C ++ die koste (in RAM) swaarder weeg as ek dit reg doen.

Die tweede groot uitdaging was om te bepaal hoe ons die impulswydte-modulasie via die skofregisters kan implementeer, sodat ek meer as die sewe primitiewe kleure van die RGB LED kan genereer. Nadat ek baie jare op Linux -platforms geprogrammeer het, was ek gewoond daaraan om konstruksies soos drade te gebruik om prosesse te bestuur wat konsekwente tydsberekening vereis. Die tydsberekening van die opdatering van die skofregister is uiteindelik baie krities wanneer u 'n bestuurder maak vir 'n LED -matriks wat multiplexing gebruik. Die rede hiervoor is dat, alhoewel die multiplexing so vinnig gebeur dat u individuele LED's nie aan en af kan knip nie, u ayes verskille kan optel in die totale totale tyd wat enige van die LED's aan is. As een ry LED's vir 'n langer tyd konsekwent aan is as die ander, sal dit tydens die multiplexering helderder lyk. Dit kan lei tot ongelyke helderheid in die matriks of periodieke strooi van die matriks in sy geheel (dit gebeur as een opdateringsiklus langer neem as die ander).

Aangesien ek 'n konsekwente tydsberekening nodig gehad het om die opdaterings van die skofregister toestemming te gee, maar die Arduino nie draad formeel ondersteun nie, moes ek my eie draadagtige meganisme skep. My eerste herhaling hiervan was om eenvoudig 'n lustimer te skep wat afhang van die Arduino -lus () -funksie en 'n aksie sou afskakel as 'n sekere tydsverloop verloop het sedert die laaste keer dat die aksie afgevuur is. Dit is 'n vorm van 'koöperatiewe multitasking'. Dit klink goed, maar in die praktyk was dit teenstrydig toe die afvlugtempo in mikrosekondes gemeet is. Die rede hiervoor is dat as ek twee van hierdie lustimers aan die gang gehad het, een van hul aksies gereeld lank genoeg geneem het om die tweede aksie later as wat verlang is, af te vuur.

Ek het gevind dat die oplossing vir hierdie probleem is om die onderbrekingsmeganisme van die oorspronklike klok van Arduino te gebruik. Met hierdie meganisme kan u 'n klein bietjie kode met baie konstante tussenposes uitvoer. Ek het dus die bestuurderkode ontwerp rondom die ontwerpelement van die gebruik van 'n klokonderbreking om die kode vir die stuur van die matriks se skofregister die volgende opdatering in die multiplex -siklus te aktiveer. Om dit te doen en toe te laat dat opdaterings op die skerm se beeld plaasvind om nie 'n aktiewe storting in die skofregisters te belemmer nie (iets wat ons 'n 'rasvoorwaarde' sou noem), het ek 'n benadering gebruik om dubbele buffers te hê vir die skofregisterstukkies, een vir skryf en een vir lees. As die gebruiker die matriksbeeld opdateer, vind hierdie bewerkings plaas in die skryfbuffer. As hierdie bewerkings voltooi is, word onderbrekings tydelik opgeskort (dit beteken dat die klokonderbreking nie kan brand nie) en die skryfbuffer word omgeruil met die vorige leesbuffer en dit is nie die nuwe leesbuffer nie, dan word die interpretasie weer geaktiveer. As die klok dan onderbreek, wat aandui dat dit tyd is om die volgende bis -konfigurasie na die skofregisters te stuur, word die inligting uit die huidige leesbuffer gelees. Op hierdie manier gebeur daar nooit 'n skryf van 'n buffer wat tans gelees kan word tydens 'n klokonderbreking nie, wat die inligting wat na die skofregisters gestuur word, kan beskadig.

Die ontwerp van die res van die bestuurder was 'n relatief eenvoudige geval van objekgeoriënteerde ontwerp. Ek het byvoorbeeld 'n voorwerp geskep om die skuifregister -bitbeeld vir 'n gegewe skermtoestand te bestuur. Deur die kode wat betrekking het op die beeldbeeldbestuur te omhul, was die opstel van bogenoemde tweelingbufferbenadering self 'n eenvoudige oefening. Maar ek het hierdie Instructable nie geskryf om die deugde van objekgeoriënteerde ontwerp te prys nie. Ander ontwerpelemente sluit in die konsep van 'n Glyph en 'n RGB -beeld. 'N Glyph is 'n basiese beeldkonstruksie wat geen aangebore kleurinligting bevat nie. U kan dit as 'n swart en wit beeld beskou. As die Glyph na die LED -skerm getrek word, word kleurinligting gegee om aan te dui hoe die "wit" pixels gekleur moet word. 'N RGB -beeld is 'n beeld waar elke pixel sy eie kleurinligting het.

Ek moedig u aan om die Arduino -sketsvoorbeelde na te gaan en die dokumentasie van die bestuurderopskrif na te gaan om vertroud te raak met hoe u die bestuurder kan gebruik om beelde en animasies op 'n RGB LED -matriks te skep.

Stap 4: LED Ghosting

In 'n LED -matriks is "spook" die verskynsel van 'n LED in die matriks wat gloei as dit nie verlang word nie, gewoonlik 'n baie verlaagde vlak. My oorspronklike hardeware -ontwerp was vatbaar vir spook, veral in die laaste ry. Die oorsaak hiervan is te wyte aan twee dinge: transistors skakel nie onmiddellik af nie en parasitiese kapasitansie in die RGB LED's.

Terwyl ons deur die rye skandeer, word die vorige ry in die skanningsiklus nog gedeeltelik aangeskakel as die volgende ry aangeskakel word omdat transistors nie onmiddellik afskakel nie. As 'n gegewe kolom wat in die vorige ry afgeskakel is, weer aangeskakel word as die nuwe ry aangeskakel word, sal die LED van die kolom in die vorige ry 'n kort tydjie gloei terwyl die transistor van die vorige ry nog besig is om te draai af. Wat veroorsaak dat die transistor 'n merkbare tyd neem om uit te skakel, is versadiging in die basis van die transistor. Dit veroorsaak dat die transistor-kollektor-emiter-pad voortgaan om te stroom wanneer die stroom van die basis verwyder word, ten minste totdat die versadiging verdwyn. Aangesien ons multiplex -opdateringsiklus veroorsaak dat rye doelbewus aangeskakel word vir 'n tydperk gemeet in mikrosekondes, kan die hoeveelheid tyd wat die versadigde transistor van die vorige ry geleidend bly, 'n merkbare deel daarvan wees. As gevolg hiervan, kan u oog die baie klein tyd waarneem dat die LED van die vorige ry aangeskakel is.

Om die transistorversadigingsprobleem op te los, kan 'n Schottky -diode by die transistor tussen die basis en die kollektor gevoeg word om 'n bietjie terugstroom na die basis te veroorsaak as die transistor aan is, wat voorkom dat die transistor versadig raak. Dit sal weer veroorsaak dat die transistor vinniger afskakel as die stroom van die basis verwyder word. Sien hierdie artikel vir 'n diepgaande verduideliking van hierdie effek. Soos u op die prentjie in hierdie afdeling kan sien, is die spook sonder die diode redelik merkbaar, maar die toevoeging van die diode tot die stroombaan vir elke ry verwyder die spook aansienlik.

RGB -LED's is vatbaar vir 'n ander verskynsel genaamd parasitiese kapasitansie. Die hoofoorsaak hiervan is die feit dat elk van die drie kleur -LED's in die RGB LED -eenheid elk verskillende voorspannings het. Hierdie verskil in voorspannings kan die effek van elektriese kapasitansie tussen elk van die individuele LED -kleure veroorsaak. Aangesien 'n elektriese lading in die LED -eenheid opgebou word wanneer die krag aangeskakel word, moet die parasitiese kapasitansie ontlaai word wanneer die krag verwyder word. As die LED -kolom andersins aangeskakel is vir 'n ander ry se krag, sal die parasitiese lading deur die kolom -LED ontlaai en dit kort laat gloei. Hierdie effek word mooi verduidelik in hierdie artikel. Die oplossing is om 'n ontladingspad vir hierdie parasitiese lading by te voeg, behalwe deur die LED self, en dan die LED tyd te gee om te ontlaai voordat die kolom weer aangeskakel word. In my hardeware -ontwerp word dit bereik deur 'n weerstand by elke ry se kraglyn te voeg wat krag met grond verbind. Dit sal veroorsaak dat meer stroom getrek word terwyl die ry aangedryf word, maar dit bied 'n afvoerpad vir die parasitiese kapasitansie as die ry nie aangedryf word nie.

Dit is egter opmerklik dat die effek van parasitiese kapasitansie in die praktyk skaars merkbaar is (as u daarna soek, kan u dit vind), en daarom beskou ek die toevoeging van hierdie ekstra weerstand as opsioneel. Die effek van die vertraagde tyd vir versadigde transistors is baie sterker en merkbaar. As u egter die drie foto's in hierdie afdeling inspekteer, kan u sien dat die weerstande alle spook wat nog steeds plaasvind buite die van die stadige transistor af, heeltemal verwyder.

Stap 5: Finale vervaardiging en volgende stappe

Die laaste fase van hierdie projek was om 'n printboard (PCB) te skep. Ek het die open source -program Fritzing gebruik om my PCB te ontwerp. Alhoewel daar baie herhalende take was om 100 LED's op 'n 10x10 -bord uit te lê, het ek eintlik gevind dat hierdie fase van die projek vreemd bevredigend was. Om uit te vind hoe elke elektriese pad uiteengesit word, was soos 'n raaisel, en die oplossing van die raaisel het 'n gevoel van prestasie veroorsaak. Aangesien ek nie ingestel is om die printplate te vervaardig nie, het ek een van die vele aanlynbronne gebruik wat klein hoeveelhede aangepaste PCB doen. Om die dele aanmekaar te soldeer was redelik eenvoudig, want my ontwerp het alle deurgaande dele gebruik.

Ten tyde van die skryf van hierdie instruksies, het ek die volgende planne vir my RGB LED Matrix -projekte:

1. Gaan voort om die bestuurder by die API-laag te verbeter om meer funksionaliteit op die hoë vlak vir die programmeerder moontlik te maak, veral teksblaai.
2. Skep groter matriksontwerpe, soos 16x16 of selfs 16x32.
3. Ontdek die gebruik van MOSFET's in plaas van BJT's vir die ry -skakelaar
4. Ontdek die gebruik van DM13A's as konstante stroombestuurders eerder as 74HC595s vir die omskakeling van kolomme
5. Skep bestuurders vir ander mikrobeheerplatforms, soos die Teensy, ODROID C2 of Raspberry Pi.

Let daarop dat beide die hardeware -ontwerp en die bestuurder vrygestel is onder die GPL v3 open source -lisensie in hierdie GitHub -bewaarplek. Aangesien die PCB -vervaardiging 'n klein hoeveelheid van my PCB -ontwerp vervaardig, kry ek steeds baie meer as wat ek persoonlik nodig het. Ek verkoop dus volledige kits vir my verskillende RGB LED -matriksontwerpe (PCB en alle onderdele ingesluit) vanaf my webwerf hier.