RGB LED matice: 5 kroků

2024 Autor: John Day | [email protected]. Naposledy změněno: 2024-01-30 08:24

Hledejte Instructable a najdete mnoho projektů LED matrix. Žádný z nich nebyl přesně to, co jsem chtěl, což bylo prozkoumat interakce hardwarového a softwarového designu, aby se něco vyrobilo, a vyrobit konečný produkt v úhledné desce plošných spojů s ovladačem, který mi dovolí nakreslit na „LED obrazovku“pomocí vysoké úrovně. konstrukty (např. kreslení čáry oproti nastavování konkrétních pixelů). Tato část byla pro mě důležitá, protože mnoho ovladačů matice LED je holých kostí a příliš nezajišťuje programové vytváření obrazu nebo animace. To neznamená, že nemůžete vytvářet obrázky a animace s ostatními ovladači, jen že byste museli dělat více opakovaných prací od projektu k projektu.

Vydal jsem se tedy uskutečnit svou vizi. Prvním krokem byl návrh hardwaru. To pro mě bylo asi nejnáročnější, protože moje pozadí je více softwarové. Opět bylo mnoho předpečených návrhů a určitě jsem je použil pro inspiraci, ale chtěl jsem se to naučit dělat, a tak jsem prototypoval matici 4x4 na prkénko. Díky tomuto procesu jsem se hodně naučil, protože prvních několik iterací nefungovalo. Ale udělal jsem hardwarový design, který fungoval, což mi zase umožnilo začít vyvíjet ovladač.

Jako platformu ovladačů jsem si vybral Arduino, protože je široce dostupný a má spoustu referencí online. I když mi kariérní zkušenost umožnila dostat se k pracovní verzi ovladače hladčeji než mé hardwarové úsilí, stále bylo mnoho iterací, zatímco jsem optimalizoval výkon ovladače pro mikrořadič ATMega a vytvořil programovací API, které se mi líbilo.

Tento Instructuctable dokumentuje design a několik klíčových poznatků z mého projektu. Více informací o tomto projektu najdete na mých webových stránkách zde, včetně kompletních sad, které si můžete zakoupit k vybudování vlastní RGB LED matice.

Krok 1: Hardware design

Primárním cílem mého návrhu hardwaru bylo vytvořit řadu RGB LED, které bych mohl naprogramovat, ale také jsem nechtěl utrácet spoustu peněz. Přístup, na kterém jsem se usadil, byl použít k ovládání LED diody posuvné registry 74HC595. Aby se minimalizoval počet potřebných posuvných registrů, uspořádal jsem LED diody RGB do maticového uspořádání, kde byly společné anody svázány dohromady v řadách a červené, zelené a modré katodové svody byly svázány dohromady ve sloupcích. U matice 4x4 vypadalo schéma zapojení jako přiložené schéma zapojení.

Jedna věc, kterou si hned všimnete, je, že vzhledem k maticovému obvodu existují některé konfigurace osvětlení LED, které nelze provést, když jsou současně zapnuty všechny požadované LED diody. Například matice nemůže současně rozsvítit dvě LED diody, které jsou navzájem diagonální, protože napájení obou řad a sloupců způsobí rozsvícení dvou protilehlých LED na kolmé úhlopříčce k požadovaným LED. Abychom to vyřešili, použijeme pro skenování v každém řádku multiplexování. Na webu je spousta zdrojů, které pokrývají techniku multiplexování, nebudu se je zde pokoušet replikovat.

Protože používám běžné anodové LED diody, znamená to, že řady poskytují kladný výkon a sloupce klesají k zemi. Dobrou zprávou je, že posuvné registry 74HC595 mohou jak zdroj, tak i zdroj potopení, ale špatná zpráva je, že mají limit na to, kolik energie mohou získat nebo potopit. Jednotlivé piny 74HC595 mají maximální odběr proudu 70 mA, ale je nejlepší ponechat méně než 20 mA. Jednotlivé barvy v našich RGB LED diodách mají odběr přibližně 20 mA. To znamená, že 74HC595 nemůže přímo napájet celou řadu LED diod, pokud je chci všechny zapnout.

Takže místo přímého napájení řady 74HC595 místo toho bude pohánět tranzistor pro každou řadu a tranzistor zapne nebo vypne proud napájející řadu. Protože konstrukce využívá LED diody se společnou anodou, bude spínací tranzistor PNP. Pokud bychom používali běžnou katodovou LED, spínací tranzistor by byl NPN. Všimněte si toho, že s použitím tranzistoru PNP k řízení řady se nastavení posuvného registru pro zapnutí nyní sníží, protože tranzistor PNP potřebuje k zapnutí záporné napětí mezi emitorem a základnou, což umožní protékání kladného proudu do řádek.

Další věc, kterou je třeba zvážit, je požadované bitové rozložení posuvných registrů. To znamená, že mezi posuvnými registry, které bity řídí, které řádky nebo sloupce v matici. Konstrukce, se kterou jsem odeslal, je ta, kde první bit nebo „nejvýznamnější bit“odeslaný do posuvných registrů zapojených do řetězce ovládá sloupec LED červeného prvku, druhý bit ovládá zelený prvek prvního sloupce, třetí bit ovládá první sloupec modrý prvek, čtvrtý bit ovládá červený prvek druhého sloupce … tento vzor se opakuje ve sloupcích zleva doprava. Pak další odeslaný bit ovládá poslední nebo dolní řádek, další druhý až poslední řádek … toto se opakovalo, dokud poslední odeslaný bit nebo „nejméně významný bit“ovládá první nebo horní řádek v matici.

Nakonec jsem potřeboval určit, jaké odpory použiji pro každou z LED v RGB LED. Zatímco pro výpočet požadovaného odporu můžete použít standardní vzorec, který kombinuje dopředné napětí a požadovaný proud, zjistil jsem, že nastavení proudu každé LED na 20 miliampérů mělo za následek špinavě bílou barvu, když byly všechny červené, zelené a modré LED diody zapnuté. Tak jsem to začal koukat do očí. Příliš mnoho červené barvy v bílé barvě znamenalo zvýšení odporu červené LED diody pro snížení proudu. Opakoval jsem střídání odporů různých ohmů, dokud jsem nenašel kombinaci, která produkovala bílou barvu, kterou jsem považoval za správnou. Konečná kombinace byla 180 Ω pro červenou LED, 220 Ω pro zelenou LED a 100 Ω pro modrou LED.

Krok 2: Konstrukce hardwaru - Breadboard

První fází konstrukce hardwaru bylo stravování chleba. Zde jsem vytvořil matici 4x4 s RGB LED diodami. Tato matice by vyžadovala 16 bitů pro ovládání, 12 pro sloupce RGB a 4 pro každý řádek. Dva posuvné registry 74HC595 to všechno zvládnou. Nejprve jsem prozkoumal a navrhl obvod, o kterém jsem si myslel, že bude fungovat, a pak jsem ho postavil na prkénko.

Pravděpodobně největší výzvou konstrukce prkénka bylo zvládnout všechny dráty. Zvedl jsem předem připravenou drátěnou soupravu pro prkénka, ale pak to bylo trochu nepraktické. Trik, který mi přišel nápomocný, byl vytvořit „port“pro připojení k desce Arduino. To znamená, že místo připojení pinů na Arduinu přímo k různým IC pinům na desce, věnujte několik řádků na desce jako místo připojení pro Arduino a poté připojte příslušné ID piny k těmto řádkům. Pro tento projekt potřebujete pouze pět připojení k Arduinu: +5 V, uzemnění, data, hodiny a západku.

Jakmile byla konstrukce prkénka hotová, potřeboval jsem ji vyzkoušet. Bez nějakého ovladače, který by posílal správné signály do posuvných registrů, jsem však nemohl vyzkoušet, zda funguje hardwarové rozložení.

Krok 3: Návrh softwaru ovladače

Vzhledem k mým vlastním profesním zkušenostem s vývojem softwaru to byla ta část projektu, ve které jsem měl asi nejjasnější cestu, kterou se mám vydat. Zkoumal jsem mnoho dalších ovladačů LED matice na bázi Arduina. I když určitě jsou k dispozici dobré ovladače, žádný z nich neměl takový design, jaký jsem chtěl. Mé konstrukční cíle řidiče byly:

• Poskytněte API na vysoké úrovni, abyste mohli programově vytvářet obrázky a animace. Většina řidičů, které jsem viděl, se více soustředila na pevně zakódované obrázky. Protože jsem obchodním programátorem C ++, chtěl jsem použít dobrý objektově orientovaný design k implementaci a správě aktivit kreslení do matice LED.
• Ke správě obrazu na obrazovce použijte přístup s dvojitou vyrovnávací pamětí. Jedna vyrovnávací paměť je programově vykreslena, zatímco druhá představuje stav pixelů matice v daném okamžiku. Výhodou tohoto přístupu je, že nemusíte mezi cykly aktualizace multiplexování úplně vykreslovat další aktualizaci rámce pro obrazovku.
• Pomocí PWM povolíte více než sedm primitivních barev, které může RGB vykreslit pomocí jednoduchých kombinací červených, zelených a modrých prvků.
• Napište ovladač tak, aby „fungoval“s různými velikostmi RGB LED matic, které následovaly můj obecný přístup k návrhu matice. Všimněte si toho, že zatímco můj návrh hardwaru používá posuvné registry 74HC595, očekával bych, že můj ovladač bude pracovat s jakýmkoli mechanismem zapnutí/vypnutí stylu posuvného registru, který je rozložen pomocí podobného rozložení bitů jako můj návrh hardwaru. Například bych očekával, že můj ovladač bude pracovat s hardwarovým designem, který používá čipy DM13A k ovládání sloupců a čip 74HC595 k ovládání řádků.

Pokud se chcete rovnou podívat na kód ovladače, najdete ho na GitHubu zde.

První iterace mého ovladače byla trochu křivkou učení o schopnostech platformy Arduino. Nejviditelnějším omezením je RAM, což jsou 2 kB bytů pro Arduino Uno a Nano. Použití objektů C ++ v takovém případě se často nedoporučuje kvůli režii objektů v paměti. Cítil jsem však, že pokud se to udělá správně, výhoda objektů v C ++ převáží jejich náklady (v RAM).

Druhou velkou výzvou bylo vymyslet, jak implementovat modulaci šířky pulzu pomocí posuvných registrů, abych mohl generovat více než sedm primitivních barev RGB LED. Po mnoha letech programování na platformách Linux jsem byl zvyklý používat konstrukty jako vlákna pro správu procesů, které vyžadují konzistentní načasování. Načasování operace aktualizace posuvného registru je při vytváření ovladače pro matici LED využívající multiplexování velmi důležité. Důvodem je to, že i když multiplexování probíhá tak rychle, že vaše oči nevidí blikat a zhasínat jednotlivé LED diody, vaše oči mohou zaznamenat rozdíly v celkovém souhrnném čase, kdy jsou některé z LED rozsvíceny. Pokud jedna řada LED trvale svítí delší dobu než ostatní, bude při multiplexování vypadat jasněji. To může vést k nerovnoměrnému jasu v matici nebo k pravidelnému strobování matice jako celku (k tomu dochází, když jeden aktualizační cyklus trvá déle než ostatní).

Protože jsem potřeboval konzistentní mechanismus časování, abych způsobil, že aktualizace posuvných registrů budou souhlasné, ale Arduino vlákno formálně nepodporuje, musel jsem si vytvořit vlastní mechanismus podobný vláknu. Moje první iterace byla jednoduše vytvořit časovač smyčky, který závisel na funkci smyčky Arduino () a spustil akci, když od posledního spuštění akce uplynula určitá doba. Jedná se o formu „kooperativního multitaskingu“. Zní to dobře, ale v praxi se to ukázalo jako nekonzistentní, když byla rychlost střelby měřena v mikrosekundách. Důvodem je to, že pokud jsem nechal běžet dva z těchto časovačů smyčky, jedna z jejich akcí často trvala dostatečně dlouho, aby způsobila, že se druhá akce spustí později, než bylo požadováno.

Zjistil jsem, že řešením tohoto problému je použít nativní mechanismus přerušení hodin Arduina. Tento mechanismus vám umožňuje spustit malý kousek kódu ve velmi konzistentních intervalech. Tak jsem navrhl kód ovladače kolem designového prvku pomocí přerušení hodin pro spuštění kódu pro odeslání posuvných registrů matice další aktualizaci v multiplexním cyklu. Abych to provedl a umožnil, aby aktualizace obrazu na obrazovce nezasahovaly do aktivního výpisu do posuvných registrů (něco, co bychom nazvali „závodní podmínkou“), použil jsem přístup s dvojitou vyrovnávací pamětí pro bity posuvného registru, jednu na psaní a jeden na čtení. Když uživatel aktualizuje obraz matice, dojde k těmto operacím ve vyrovnávací paměti pro zápis. Když jsou tyto operace dokončeny, přerušení jsou dočasně pozastavena (to znamená, že přerušení hodin nelze spustit) a vyrovnávací paměť pro zápis je prohozena s předchozí vyrovnávací pamětí pro čtení a nejedná se o novou vyrovnávací paměť pro čtení, poté se znovu povolí tlumočníci. Poté, když se spustí hodinové přerušení, což naznačuje, že je čas poslat další bitovou konfiguraci do posuvných registrů, jsou tyto informace načteny z aktuální vyrovnávací paměti pro čtení. Tímto způsobem nedochází k žádnému zápisu do vyrovnávací paměti, ze které by se právě mohlo číst během přerušení hodin, což by mohlo poškodit informace odeslané do posuvných registrů.

Navrhování zbytku ovladače bylo relativně přímočarým případem objektově orientovaného designu. Například jsem vytvořil objekt pro správu bitového obrazu posuvného registru pro jakýkoli daný stav obrazovky. Zapouzdřením kódu týkajícího se správy bitových bitů bylo vytvoření výše uvedeného přístupu dvojitých vyrovnávacích pamětí samo o sobě jednoduchým cvičením. Ale nenapsal jsem tento Instructable, abych vyzdvihl přednosti objektově orientovaného designu. Mezi další designové prvky patří koncept Glyph a RGB Image. Glyf je základní konstrukt obrazu, který nemá žádné vrozené informace o barvě. Můžete si to představit jako černobílý obrázek. Když je symbol Glyph přitažen na obrazovku LED, zobrazí se informace o barvě, která udává, jak by měly být vybarveny „bílé“pixely. RGB obraz je obrázek, kde každý pixel má své vlastní barevné informace.

Doporučuji vám prostudovat si příklady skici Arduino a přečíst si dokumentaci záhlaví ovladače, abyste se seznámili s tím, jak pomocí ovladače vytvářet obrázky a animace na matici RGB LED.

Krok 4: LED Ghosting

V LED matici je „ghosting“jev, kdy LED v matici svítí, když to není žádoucí, obvykle velmi snížená úroveň. Můj původní design hardwaru byl náchylný ke ghostingu, zejména v poslední řadě. Příčinou jsou dvě věci: tranzistory se nevypnou okamžitě a parazitní kapacita v LED diodách RGB.

Když skenujeme řádky, vzhledem k tomu, že tranzistory se nevypnou okamžitě, předchozí řada v cyklu skenování je stále částečně napájena, když se zapne další řada. Pokud se daný sloupec, který byl v předchozím řádku vypnutý, znovu zapne, když se nový řádek napájí, LED tohoto sloupce v předchozím řádku bude krátce svítit, zatímco spínací tranzistor předchozí řady je stále v procesu otáčení vypnuto. Co způsobuje, že vypnutí tranzistoru trvá znatelně dlouho, je nasycení v základně tranzistoru. To způsobí, že cesta kolektoru a emitoru tranzistoru pokračuje ve vedení, když je proud odebrán ze základny, alespoň dokud se sytost nerozptýlí. Vzhledem k tomu, že náš aktualizační cyklus multiplexování způsobuje, že řádky jsou účelově zapnuty po dobu měřenou v mikrosekundách, může doba, po kterou nasycený tranzistor předchozího řádku zůstává vodivý, představovat zlomek toho. V důsledku toho může vaše oko vnímat velmi malé množství času, kdy se rozsvítí LED předchozí řady.

Chcete -li vyřešit problém s nasycením tranzistoru, lze k tranzistoru mezi základnou a kolektorem přidat Schottkyho diodu, která způsobí malý zpětný proud k základně, když je tranzistor zapnutý, což zabrání nasycení tranzistoru. To zase způsobí rychlejší vypnutí tranzistoru, když je proud odebrán ze základny. V tomto článku najdete podrobné vysvětlení tohoto efektu. Jak vidíte na obrázku v této části, bez diody je ghosting docela znatelný, ale přidání diody do obvodu pro každý řádek výrazně eliminuje ghosting.

RGB LED diody jsou náchylné k dalšímu jevu zvanému parazitní kapacita. Hlavní příčinou je skutečnost, že každá ze tří barevných LED diod v jednotce RGB LED má každá jiná dopředná napětí. Tento rozdíl v dopředných napětích může způsobit účinek elektrické kapacity mezi každou z jednotlivých barev LED. Protože je v jednotce LED při napájení vytvořen elektrický náboj, je při odpojení napájení parazitní kapacita vybita. Pokud je tento sloupec LED jinak zapnutý pro napájení jiného řádku, parazitní náboj se vybije prostřednictvím LED diod sloupců a způsobí jeho krátké rozsvícení. Tento efekt je v tomto článku pěkně vysvětlen. Řešením je přidat vybíjecí cestu pro tento parazitický náboj jinak než přes samotnou LED a poté dát LED čas vybít, než bude kolona znovu napájena. V mém návrhu hardwaru je toho dosaženo přidáním odporu do napájecího vedení každé řady, který spojuje sílu se zemí. To způsobí odběr většího proudu, když je řada napájena, ale poskytuje výbojovou cestu pro parazitní kapacitu, když řada není napájena.

Stojí však za zmínku, že v praxi považuji účinek parazitní kapacity za stěží znatelný (pokud ho hledáte, můžete jej najít), a proto považuji přidání tohoto extra odporu za volitelný. Účinek zpomaleného času u nasycených tranzistorů je mnohem silnější a znatelný. Nicméně, když se podíváte na tři fotografie uvedené v této části, můžete vidět, že rezistory zcela odstraní všechny duchy, které se stále vyskytují mimo časy vypínání pomalého tranzistoru.

Krok 5: Konečná výroba a další kroky

Poslední fází tohoto projektu bylo, že jsem vytvořil desku plošných spojů (PCB). K návrhu své DPS jsem použil open source program Fritzing. I když bylo třeba provést mnoho opakujících se úkolů pro rozložení 100 LED na desku 10x10, ve skutečnosti mi tato fáze projektu připadala podivně uspokojivá. Zjistit, jak by byla rozložena každá elektrická dráha, bylo jako hádanka a řešení této hádanky vytvořilo pocit úspěchu. Protože nejsem nastaven na výrobu desek s obvody, použil jsem jeden z mnoha online zdrojů, které dělají malé série vlastních desek plošných spojů. Pájení dílů dohromady bylo docela přímočaré, protože můj návrh využil všechny části skrz otvor.

V době psaní tohoto Instructable mám pro své projekty RGB LED Matrix následující plány:

1. Pokračujte ve zlepšování ovladače ve vrstvě API, abyste programátoru umožnili více funkcí na vysoké úrovni, zejména rolování textu.
2. Vytvářejte větší návrhy matic, například 16x16 nebo dokonce 16x32.
3. Prozkoumejte použití MOSFETů místo BJT pro přepínání výkonu řady
4. Prozkoumejte použití přepínačů konstantního proudu DM13A místo 74HC595s pro přepínání sloupců
5. Vytvořte ovladače pro další platformy pro mikro řízení, jako jsou Teensy, ODROID C2 nebo Raspberry Pi.

Všimněte si toho, že jak design hardwaru, tak ovladač byly vydány pod open source licencí GPL v3 v tomto úložišti GitHub. Navíc, i když výrobci desek plošných spojů dělají „malé série“mého návrhu desek plošných spojů, stále dostávám mnohem více, než osobně potřebuji. Prodávám tedy plné sady pro své různé designy RGB LED matic (včetně DPS a všech součástí) z mého webu zde.