En LED -humörlampa på $ 1 med ATtiny13 och WS2812: 7 steg

2024 Författare: John Day | [email protected]. Senast ändrad: 2024-01-30 12:36

Av arduinocelentanoFölj mer av författaren:

Detta är en billigt humörlampa med fyra lägen.

1. Regnbåggnista. En gnista av ljus rör sig uppåt gång på gång och ändrar gradvis färgen.

2. Rainbow glöd. En stabil glöd som gradvis ändrar färgen.

3. Simulering av stearinljus.

4. Av.

Du kan byta läge genom att trycka på en knapp på toppen. Det aktuella läget sparas i EEPROM -minnet efter avstängning.

Hur liten är ATtiny13?

Tanken var att få maximala funktioner från minsta hårdvara, något mer komplext än automatiserad switch eller termometer, ett projekt nära kanten av denna lilla mikrokontroller. När allt kommer omkring, begränsningar får dig att tänka kreativt, eller hur? Tja, det såg ut så i början.

Det mest utmanande i detta projekt var att skjuta in all kod i ATtiny13. Mikrokontrollern har 1K byte flash och bara 64 byte RAM. Ja, när jag säger "byte" menar jag de som består av åtta bitar. 64 byte för alla dina lokala variabler och samtalsstack. För att göra det klart, tänk på att vi måste styra 8 RGB -lysdioder. Var och en av dem definieras av 3 byte (en för röd, grön respektive blå kanal). Så, bara för att lagra tillståndet för 8 lysdioder, måste vi implementera en grupp med 8 strukturer 3 byte vardera och en pekare till början av denna matris skulle ta ytterligare en byte. Således är 25 av 64 byte ute. Vi har precis använt 39% av RAM -minnet och har inte riktigt börjat än. För att lagra sju grundläggande regnbågsfärger behöver du dessutom 7 × 3 = 21 byte, så 72% av RAM -minnet är slut. Tja, när det gäller grundläggande färger överdriver jag: vi behöver inte dem alla samtidigt i RAM och de ändras aldrig, så de kan implementeras som en konstant array som ska lagras i flash istället för RAM. Hur som helst ger det ett helhetsintryck om begagnad hårdvara.

När jag kom ihåg Knuths uttalande om för tidig optimering började jag från att prototypera tre lamplägen separat för att se vad som händer. Jag har testat dem separat för att se till att de fungerar som de ska och att alla passar min mikrokontroller. Det tog ett par kvällar att uppnå det och allt gick bra … tills jag försökte sätta ihop dem inuti switch -statement. avr-size-verktyget rapporterade en 1,5 Kb stor textstorlek (med -s flagga av avr-gcc). Just då var min ursprungliga avsikt att ta lite ATtiny25 med 2Kb blixt och det kunde ha varit det lyckliga slutet på den här historien.

Men på något sätt kände jag att jag efter en omfattande optimering kunde lyckas krympa den där galna koden till 1Kb. Det tog dock en vecka till för att inse att det är omöjligt och en vecka till att uppnå det ändå. Jag var tvungen att klippa en regnbåge till fem grundfärger (utan signifikant visuell skillnad). Jag blev av med ärendebesked och använde en kedja av if-then-if för att minska binär kodstorlek. Brandanimering behöver en pseudoslumpgenerator som är ganska skrymmande, så jag implementerade en förenklad version av LFSR med konstant initialvärde. Jag bryr mig inte om PRNG full cykellängd och bara letar efter en nedstigningsbalans mellan kodstorlek och "realistisk eldanimation". Jag implementerade också många mindre optimeringar som jag inte kan komma ihåg just nu och lyckades till och med blinka alla lägen förutom eld i chipet. När jag fick slut på idéer var min totala kod cirka 1200 byte.

Jag tog timeout och hade läst mycket om AVR -kodoptimering. Jag var nära att ge upp och skriva om allt på monteringsspråk men gav det sista chansen. Under den sista optimeringsrusningen har jag klippt en regnbåge till tre grundfärger och fått andra att beräknas i farten, jag inspekterade allt och följde AVR -optimeringsrekommendationer och slutligen …

avrdude: skrivande blixt (1004 byte):

Skrivning | #################################################### | 100% 0,90 -tal

Det finns ingen anledning att säga att jag använde nästan allt RAM -minne och bara en byte EEPROM för att lagra aktuellt läge. Jag antyder inte att detta är ett idealiskt och ultimat genomförande. Det fungerar bara och passar mikrokontrollern. Jag är säker på att du kan göra det bättre. Jag är verkligen. Jag vill bara dela med mig av det roliga att lösa ett till synes opraktiskt problem som du anser nästan omöjligt i början. "Hackning innebär alltså att utforska gränserna för vad som är möjligt …" -Richard Stallman.

Tillbehör:

1x ATtiny13 MCU ($ 0,28 = $ 0,24 för MCU i SOP-8-paket och $ 0,04 för DIP8-adapter)

8x WS2812 RGB -lysdioder (jag rekommenderar en bräda eller en bit LED -rand) ($ 0,42)

1x TTP223 Touch -knapp ($ 0,10)

1x Micro USB till DIP -adapter ($ 0,14)

1x 10kΩ motstånd (<$ 0,01)

1x 100nF keramisk kondensator (<$ 0,01)

1x 10–47µF elektrolytkondensator (<$ 0,01)

Totalt <$ 0,97

Steg 1: Programinstallation

Du behöver avr-gcc verktygskedja för att sammanställa källkoden och avrdude-verktyget för att ladda upp mikrokontrollerns ROM. Installationsprocessen är ganska enkel och okomplicerad, men det beror på ditt operativsystem. Om du använder någon form av GNU/Linux har du förmodligen redan rätt paket i ditt förvarsträd. Projektets källkod kan laddas ner här:

github.com/arduinocelentano/t13_ws2812_lamp

Du behöver också ett light_ws2812 -bibliotek:

github.com/cpldcpu/light_ws2812

När du har fått avr-gcc verktygskedja och projektkällor, kör din terminal och skriv följande kod:

cd sökväg/till/projekt

göra

Steg 2: Programmering av mikrokontrollern

Om du har någon form av USBASP -programmerare kan du bara ansluta den till Attiny enligt dess pinout. Vanligtvis skulle det se ut så här men jag rekommenderar starkt att kolla in din faktiska pinout!

Alternativt kan du använda ett Arduino -kort som programmerare. Öppna Arduino IDE och hitta Arduino ISP -exemplet i "Arkiv → Exempel" -menyn. Efter att du har laddat upp skissen fungerar ditt Arduino -kort som programmerare. Kommentarer i skisskoden skulle ge dig en ledtråd till pinout.

Kör nu

göra blixt

för att blinka MCU och

gör en säkring

för att ställa in säkringsbitar.

Steg 3: Scheman