RGB LED матрица: 5 стъпки

2024 Автор: John Day | [email protected]. Последно модифициран: 2024-01-30 07:54

Търсете Instructable и можете да намерите много проекти за LED матрици. Никой от тях не беше точно това, което исках, а именно да проуча взаимодействията на хардуерния и софтуерния дизайн, за да произведа нещо, и да произведа крайния продукт в чиста печатна платка с драйвер, който нека да нарисувам към „LED екрана“, използвайки високо ниво конструкции (напр. чертане на линия за разлика от задаване на конкретни пиксели). Тази част беше важна за мен, тъй като много от драйверите за LED матрици са голи кости и не осигуряват много по пътя на програмното създаване на изображение или анимация. Това не означава, че не можете да създавате изображения и анимации с другите драйвери, просто че ще трябва да вършите по -повтаряща се работа от проект на проект.

Затова се заех да осъществя визията си. Първата стъпка беше проектирането на хардуера. Това вероятно беше най -голямото предизвикателство за мен, тъй като моят опит е повече софтуер. Отново имаше много предварително изпечени дизайни и със сигурност ги използвах за вдъхновение, но исках да се уча чрез правене, затова прототипирах 4x4 матрица на чертеж. Научих много чрез този процес, тъй като първите ми няколко повторения не работеха. Но аз направих хардуерен дизайн, който работеше, което от своя страна ми позволи да започна да разработвам драйвер.

Избрах Arduino като моя платформа за драйвери, защото той е широко достъпен и има много референции онлайн. Докато кариерата ми позволи да стигна до работеща версия на драйвер по -хлъзгаво от хардуерните ми усилия, все още имаше много итерации, докато оптимизирах производителността на драйвера за микроконтролера ATMega и разработих програмен API, който ми хареса.

Този Instructuctable документира дизайна и някои ключови знания от моя проект. Повече информация за този проект можете да намерите на моя уебсайт тук, включително пълни комплекти, които можете да закупите, за да изградите своя собствена RGB LED матрица.

Стъпка 1: Дизайн на хардуера

Основната цел на моя хардуерен дизайн беше да създам масив от RGB светодиоди, които да мога да програмирам, но също така не исках да харча много пари. Подходът, на който се спрях, беше да използвам регистрите за смяна на 74HC595 за управление на светодиодите. За да се сведе до минимум необходимия регистър на смяна, аз подредих RGB светодиодите в матрично оформление, където общите аноди бяха свързани заедно в редове, а червените, зелените и сините катодни проводници бяха свързани в колони. За матрицата 4х4, електрическата схема изглеждаше като приложената електрическа схема.

Едно нещо, което веднага ще забележите, е, че предвид матричната верига, има някои конфигурации на LED осветление, които не могат да бъдат направени, когато всички желани светодиоди са включени едновременно. Например, матрицата не може едновременно да свети два светодиода, които са диагонални един от друг, защото захранването както на редовете, така и на колоните ще накара двата противоположни светодиода да светят по перпендикулярния диагонал на желаните светодиоди. За да заобиколим това, ще използваме мултиплексиране за сканиране през всеки ред. Има много ресурси в мрежата, които покриват техниката на мултиплексиране, няма да се опитвам да ги копирам тук.

Тъй като използвам обикновени анодни светодиоди, това означава, че редовете осигуряват положителна мощност и колоните потъват на земята. Добрата новина е, че регистрите за смяна на 74HC595 могат да генерират и поглъщат енергия, но лошата е, че те имат ограничение за това колко енергия могат да източат или потънат. Отделните щифтове на 74HC595 имат максимално изтегляне на ток от 70 mA, но най -добре е да запазите по -малко от 20 mA. Отделните цветове в нашите RGB светодиоди имат около 20 mA теглене. Това означава, че 74HC595 не може директно да захранва цял ред светодиоди, ако желая да ги включа всички.

Така че вместо да захранва реда директно, 74HC595 вместо това ще управлява транзистор за всеки ред, а транзисторът ще включва или изключва текущото захранване на реда. Тъй като дизайнът използва общ аноден светодиод, превключващият транзистор ще бъде PNP. Ако използвахме общ катоден светодиод, превключващият транзистор ще бъде NPN. Обърнете внимание, че с използването на PNP транзистор за задвижване на ред, настройката на регистъра за смяна, за да го включи, сега става ниска, тъй като PNP транзисторът се нуждае от отрицателно напрежение между емитер и база, за да се включи, което ще позволи положителен ток да тече в ред.

Друго нещо, което трябва да се вземе предвид, е желаното битово оформление на регистрите за изместване. Тоест измежду регистрите за смяна, които битове контролират кои редове или колони в матрицата. Дизайнът, с който изпратих, е мястото, където първият бит, или "най -значимият бит", изпратен до регистрите за смяна на маргаритка, контролира колоната от светодиоди червен елемент, вторият бит контролира зеления елемент на първата колона, третият бит контролира първата син елемент, четвъртият бит контролира червения елемент на втората колона, … този модел се повтаря в колоните отляво надясно. След това следващият изпратен бит контролира последния или най -долния ред, следващият втори до последния ред, … това се повтаря, докато последният изпратен бит, или „най -малкият бит“, контролира първия или горния ред в матрицата.

И накрая, трябваше да определя какви резистори ще използвам за всеки от светодиодите в RGB LED. Въпреки че можете да използвате стандартната формула, която комбинира напрежение напред и желания ток, за да изчислите необходимия резистор, открих, че настройката на тока на всеки светодиод до 20 милиампера води до почти бял цвят, когато всички червени, зелени и сини светодиоди са включени. Така че започнах да го оглеждам. Твърде много червено в бялото означава увеличаване на резистора на червения светодиод за намаляване на тока. Повтарях смяна на резистори с различни омове, докато не намерих комбинация, която произведе бял цвят, който смятах за правилен. Крайната комбинация беше 180 Ω за червения светодиод, 220 Ω за зеления светодиод и 100 Ω за синия светодиод.

Стъпка 2: Конструиране на хардуер - План

Първата фаза на хардуерния конструктор беше качването на хляб. Тук направих 4х4 матрица с RGB светодиоди. Тази матрица ще изисква 16 бита за управление, 12 за RGB колони и 4 за всеки ред. Два регистра за смяна 74HC595 могат да се справят с всичко. Първо проучих и проектирах схема, която смятах, че ще работи, след което я изградих върху макета.

Вероятно най -голямото предизвикателство при изграждането на макет е управлението на всички проводници. Взех предварително оформен теленен комплект за дъски, но събитието тогава беше малко тромаво. Един трик, който намерих за полезен, беше да създам „порт“за свързване към платката Arduino. Тоест, вместо да свързвате щифтовете на Arduino директно към различните IC пинове на макета, посветете няколко реда на макета като точка за свързване на Arduino и след това свържете съответните идентификационни щифтове към тези редове. За този проект имате нужда само от пет връзки към Arduino: +5V, земя, данни, часовник и ключалка.

След като изграждането на макета беше завършено, трябваше да го тествам. Въпреки това, без някакъв драйвер, който да изпраща правилните сигнали към регистрите за смяна, не успях да проверя дали хардуерното оформление работи.

Стъпка 3: Дизайн на софтуера на драйвера

Като се има предвид собственият ми опит в кариерата с разработка на софтуер, това беше частта от проекта, която може би бях най -ясна относно пътя, който трябва да извървя. Проучих много от другите драйвери за LED матрици, базирани на Arduino. Въпреки че със сигурност има налични добри драйвери, никой не е имал желания от мен дизайн. Моите дизайнерски цели на шофьора бяха:

• Осигурете API на високо ниво, за да можете да създавате програмно изображения и анимации. Повечето шофьори, които видях, бяха по-фокусирани върху твърдо кодирани изображения. Също така, тъй като съм програмист на C ++, исках да използвам добър обектно -ориентиран дизайн, за да прилагам и управлявам дейностите по рисуване към LED матрицата.
• Използвайте подход с двоен буфер, за да управлявате изображението на екрана. Единият буфер е това, което се вкарва програмно, докато другият представлява състоянието на пикселите на матрицата във всеки даден момент. Предимството на този подход е, че не се изисква да изобразявате напълно следващата актуализация на кадъра за екрана между циклите на актуализация на мултиплексирането.
• Използвайте PWM, за да разрешите повече от седемте примитивни цвята, които RGB може да изобразява чрез прости комбинации от червени, зелени и сини елементи.
• Напишете драйвера така, че да "просто работи" с RGB LED матрици с различен размер, които следваха моя подход към общия дизайн на матрицата. Обърнете внимание, че макар хардуерният ми дизайн да използва регистри на смяна 74HC595, очаквам моят драйвер да работи с всеки механизъм за включване/изключване на стил на регистър на смяна, който е изложен с помощта на подобно оформление на битове като моя хардуерен дизайн. Например, очаквам моят драйвер да работи с хардуерен дизайн, който използва чипове DM13A за контрол на колоните и чип 74HC595 за контрол на редовете.

Ако искате да преминете директно към разглеждане на кода на драйвера, може да го намерите в GitHub тук.

Първата итерация на моя драйвер беше малко крива на обучение за възможностите на платформата Arduino. Най -очевидното ограничение е RAM, който е 2K байта за Arduino Uno и Nano. Използването на C ++ обекти в такъв сценарий често не се препоръчва поради натоварване на паметта на обектите. Въпреки това, чувствах, че ако се направи правилно, ползата от обектите в C ++ надвишава тяхната цена (в RAM).

Второто голямо предизвикателство беше да си представим как да приложим широчинно-импулсната модулация чрез регистрите за смяна, така че да мога да генерирам повече от седемте примитивни цвята на RGB LED. След като програмирах в продължение на много години на Linux платформи, бях свикнал да използвам конструкции като нишки за управление на процеси, които изискват последователно време. Времето на операцията за актуализиране на регистъра за смяна се оказва доста критично, когато се създава драйвер за LED матрица, която използва мултиплексиране. Причината е, че въпреки че мултиплексирането се случва толкова бързо, че очите ви не могат да видят отделните светодиоди да мигат и изключват, очите ви могат да открият разлики в общото съвкупно време, през което някой от светодиодите е включен. Ако един ред светодиоди е постоянно включен за по -дълъг период от време от останалите, той ще изглежда по -ярък по време на мултиплексирането. Това може да доведе до неравномерна яркост в матрицата или периодично стробиране на матрицата като цяло (това се случва, когато един цикъл на актуализация отнема повече време от останалите).

Тъй като имах нужда от последователен механизъм за синхронизиране, за да направя актуализациите на регистъра за смяна съгласие, но Arduino официално не поддържа нишка, трябваше да създам свой собствен механизъм, подобен на нишки. Първата ми итерация на това беше просто да създам таймер за цикъл, който зависи от функцията Arduino loop () и ще задейства действие, когато е изминало определено време от последното задействане на действието. Това е форма на „съвместна многозадачност“. Звучи добре, но на практика това се оказа непоследователно, когато скоростта на стрелба беше измерена в микросекунди. Причината за това е, че ако бях пуснал два от тези таймери, едно от техните действия често отнемаше достатъчно време, за да предизвика второто действие да се задейства по -късно от желаното.

Открих, че решението на този проблем е да се използва механизма за прекъсване на часовника на Arduino. Този механизъм ви позволява да стартирате малка част от кода на много последователни интервали. Затова проектирах кода на драйвера около елемента на дизайна, като използвам прекъсване на часовника, за да задействам кода за изпращане на регистрите за смяна на матрицата за следващата актуализация в мултиплексния цикъл. За да направя това и да позволя да се появят актуализации на изображението на екрана, за да не пречат на активно изхвърляне на регистрите за смяна (нещо, което бихме нарекли "условие за състезание"), използвах подход, за да имам двойни буфери за битовете на регистъра за смяна, един за писане и един за четене. Когато потребителят актуализира матричното изображение, тези операции се извършват в буфера за запис. Когато тези операции приключат, прекъсванията временно се преустановяват (това означава, че прекъсването на часовника не може да се задейства) и буферът за запис се разменя с предишния буфер за четене и това не е новият буфер за четене, тогава интерпретациите се активират отново. След това, когато прекъсването на часовника се задейства, което показва, че е време да се изпрати следващата битова конфигурация към регистрите за смяна, тази информация се чете от текущия буфер за четене. По този начин никога не се случва записване в буфер, който в момента може да се чете по време на прекъсване на часовника, което може да повреди информацията, изпратена до регистрите за смяна.

Проектирането на останалата част от водача беше сравнително ясен случай на обектно -ориентиран дизайн. Например, създадох обект за управление на битово изображение на регистъра за смяна за всяко дадено състояние на екрана. Чрез капсулиране на кода, свързан с управлението на битово изображение, създаването на гореспоменатия подход с двойни буфери само по себе си беше просто упражнение. Но не съм написал този Instructable, за да възхвалявам добродетелите на обектно -ориентирания дизайн. Други елементи на дизайна включват концепцията за глиф и RGB изображение. Глифът е основна конструкция на изображение, която няма вродена цветна информация. Можете да мислите за това като черно -бяло изображение. Когато глифът е изтеглен към LED екрана, се дава информация за цвета, която показва как трябва да се оцветят "белите" пиксели. RGB изображение е изображение, при което всеки пиксел има своя собствена информация за цвета.

Препоръчвам ви да прегледате примерите за скици на Arduino и да прегледате документацията на заглавката на драйвера, за да се запознаете с това как да използвате драйвера за създаване на изображения и анимации на RGB LED матрица.

Стъпка 4: LED Ghosting

В светодиодна матрица "призраци" е явлението светодиод в матрицата да свети, когато не е желателно, обикновено много намалено ниво. Първоначалният ми хардуерен дизайн беше податлив на призраци, най -вече в последния ред. Причината за това се дължи на две неща: транзисторите не се изключват веднага и паразитен капацитет в RGB светодиодите.

Докато сканираме през редовете, поради факта, че транзисторите не се изключват веднага, предишният ред в цикъла на сканиране все още е частично захранван, когато следващият ред се включи. Ако дадена колона, която е била изключена в предишния ред, е ново включена, когато новият ред се захранва, светодиодът на тази колона в предишния ред ще свети за кратко, докато превключващият транзистор на този предишен ред все още е в процес на завъртане изключен. Това, което кара транзистора да отнеме забележимо време за изключване, е наситеността в основата на транзистора. Това кара пътя на транзисторния колектор-емитер да продължи да се провежда, когато токът се отстрани от основата, поне докато насищането се разсее. Като се има предвид, че нашият цикъл на актуализиране на мултиплексиране причинява нарочно включване на редове за период от време, измерен в микросекунди, времето, през което наситеният транзистор на предишния ред остава проводим, може да бъде забележима част от това. В резултат на това окото ви може да възприеме това много малко време, през което светодиодът на предишния ред е включен.

За да се реши проблемът с насищането на транзистора, към транзистора между основата и колектора може да се добави диод на Шотки, за да предизвика малко обратен ток към основата, когато транзисторът е включен, предотвратявайки насищането на транзистора. Това от своя страна ще доведе до по -бързо изключване на транзистора, когато токът се отстрани от основата. Вижте тази статия за задълбочено обяснение на този ефект. Както можете да видите от снимката в този раздел, без диода ореолът е доста забележим, но добавянето на диода към веригата за всеки ред значително премахва призраците.

RGB светодиодите са податливи на друго явление, наречено паразитен капацитет. Първопричината за това е фактът, че всеки от трите цветни светодиода в RGB LED модула има различно напрежение напред. Тази разлика в напреженията напред може да предизвика ефекта на електрическия капацитет между всеки от отделните цветове на светодиода. Тъй като електрически заряд се натрупва в светодиодния модул, когато се захранва, когато се изключи захранването, паразитният капацитет трябва да се разреди. Ако тази колона LED е включена иначе за захранването на друг ред, паразитният заряд ще се разреди през този светодиод на колоните и ще я накара да свети за кратко. Този ефект е обяснен добре в тази статия. Решението е да се добави разряд за този паразитен заряд, различен от самия светодиод, и след това да се даде време на светодиода да се разреди, преди колоната да се захранва отново. В моя хардуерен дизайн това се постига чрез добавяне на резистор към захранващата линия на всеки ред, който свързва силата към земята. Това ще доведе до извличане на повече ток, когато редът се захранва, но осигурява път на разреждане за паразитния капацитет, когато редът не се захранва.

Струва си да се отбележи обаче, че на практика намирам ефекта от паразитния капацитет едва забележим (ако го търсите, можете да го намерите) и затова смятам добавянето на този допълнителен резистор като опция. Ефектът от забавеното време за наситени транзистори е много по -силен и забележим. Независимо от това, ако разгледате трите снимки, предоставени в този раздел, можете да видите, че резисторите премахват напълно всички призраци, които все още се появяват извън това на времето за бавно изключване на транзистора.

Стъпка 5: Окончателно производство и следващи стъпки

Последната фаза на този проект беше за мен да създам печатна платка (PCB). Използвах програмата с отворен код Fritzing за проектиране на моята печатна платка. Въпреки че имаше много повтарящи се задачи, които трябва да бъдат изпълнени, за да разположим 100 светодиода на платка 10x10, всъщност намерих тази фаза на проекта странно удовлетворяваща. Измислянето на начина, по който всеки електрически път ще бъде разположен, беше като пъзел и решаването на този пъзел създаде усещане за постижение. Тъй като не съм настроен да произвеждам платки, използвах един от многото онлайн ресурси, които правят малки тиражи персонализирани печатни платки. Запояването на частите беше доста право напред, тъй като моят дизайн използваше всички части с отвори.

По време на писането на тази инструкция имам следните планове за моите проекти за RGB LED матрица:

1. Продължете да подобрявате драйвера на API слоя, за да активирате по-висока функционалност на програмиста, най-вече превъртането на текст.
2. Създайте по -големи матрични дизайни, като 16x16 или дори 16x32.
3. Разгледайте използването на MOSFET вместо BJT за превключване на захранването на реда
4. Проучете, като използвате DM13As драйвери за постоянен ток, а не 74HC595s за превключване на колони
5. Създайте драйвери за други платформи за микроконтрол, като Teensy, ODROID C2 или Raspberry Pi.

Обърнете внимание, че както хардуерният дизайн, така и драйверът са пуснати под лиценза с отворен код GPL v3 в това хранилище на GitHub. Освен това, въпреки че производителите на печатни платки правят "малки тиражи" на моя дизайн на печатни платки, аз все още получавам много повече, отколкото лично се нуждая. Така че продавам пълни комплекти за различните ми RGB LED матрични дизайни (печатни платки и всички включени части) от моя уебсайт тук.