Förra veckan byggde jag en LED-kub – 64 lysdioder att du kan programmera för att göra fantastiska futuristiska ljusshower – och jag hoppas att du också gjorde det, för det är ett fantastiskt projekt för att motivera dig och utöka din Arduino-färdighet. Jag lämnade dig med några grundläggande appar för att få dig att tänka, men idag kommer jag att presentera några fler programvaror som jag skapade för kuben, tillsammans med kodförklaringar. Syftet med detta är både att ge dig några fler vackra ljusshower att köra, men också att lära dig om några av begränsningarna med att programmera kuben, och lära dig några nya programmeringskoncept i processen.
Det här är ganska avancerad kodning; du måste verkligen ha läst alla mina tidigare Arduino-tutorials och vår Arduino-guide för nybörjare innan du anpassar koden som tillhandahålls.
App 1: Mini Snake
Istället för att köra en fast ormliknande mönstersekvens ville jag programmera en orm – en konstgjord som skulle göra sina egna slumpmässiga val och vara helt oförutsägbar. Det är begränsat till endast 2 segment, vilket jag ska förklara senare, och du kan se demon nedan. Ladda ner hela koden här.
När du hanterar 3D-utrymme behöver du tre koordinater för en enda punkt: X, Yoch Z.
Men i vår kub representeras X- och Z-planen av LED-stift, medan Y är direkt mappad till katodplanen. För att underlätta arbetet med dessa koordinater och räkna ut rörelse runt kuben skapade jag därför en ny datatyp (med struct) att representera en enda punkt på kuben – som jag kallade “xyz”. Den består av bara två heltal: “xz” och “y”. Med denna struktur skulle jag då också kunna representera en riktning, angiven nedan i vårt speciella (xz,y) koordinatsystem:
Y rörelse (upp ner): (xz,y+1), (xz, y-1)
Z rörelse (framåt, bakåt): (xz-1, y), (xz+1, y)
X-rörelse (vänster höger): (xz+4, y), (xz-4,y)
Till exempel för att flytta lysdioden i läge (0,0) en till vänster, vi ansöker (xz+4, y) och sluta med (0,4).
Det finns vissa begränsningar som sätts för rörelse – nämligen att Y-koordinater bara kan vara möjliga 0 till 3 (0 är det undre lagret, 3 är det översta), och XZ-koordinater kan bara vara det 0 till 15. En ytterligare begränsning sätts på Z-rörelsen för att förhindra att “hoppa” från baksidan till framsidan av kuben, och vice versa. I det här fallet använder vi modulfunktionen för att testa för multipler av 4 och förneka det rörelseförsöket. Detta är logik representeras i giltig() funktion, som returnerar ett sant om den föreslagna riktningen är ett acceptabelt drag, och falskt annars. Jag har lagt till ytterligare en funktion för att leta efter en omvänd riktning – det vill säga om ormen är på väg åt ett håll vill vi inte att den ska gå baklänges på sig själv, även om det annars är en giltig plats att flytta till – och en flytta() funktion, som tar en koordinat, en riktning och returnerar den nya koordinaten.
De XYZ data typ, giltig(), flytta() och omvänd() funktioner kan alla hittas i xyz.h fil i nedladdningarna. Om du undrar varför detta lades in i en separat fil istället för huvudprogramfilen, beror det på några komplicerade Arduino-kompilatorregler som hindrar funktioner från att returnera anpassade datatyper; de måste placeras i sin egen fil och sedan importeras i början av huvudfilen.
Tillbaka i huvudruntime-filen lagrar en rad anvisningar alla möjliga rörelser som ormen kan göra; vi kan helt enkelt välja en slumpmässig arraymedlem för att få en ny riktning. Variabler skapas också för att lagra den aktuella platsen (nu), den föregående riktning och tidigare plats. Resten av koden borde vara ganska uppenbar för dig; bara for loopar och tända och släcka lysdioder. I huvudslingan kontrollerar vi om den föreslagna riktningen är giltig, och om det är så går vi den vägen. Om inte väljer vi en ny riktning.
Det enda att påpeka i huvudslingan är några kontroller för att rätta till en bugg som jag hittade som involverade multiplexering: om den nya platsen var på samma katodplan eller samma anodstift, skulle en avstängning av den tidigare lysdioden resultera i att båda slocknade. Det är också vid denna tidpunkt som jag insåg att det skulle bli omöjligt att gå längre än en 2-segments orm med min nuvarande implementering: försök att tända 3 lysdioder i ett hörn. Det kan du inte, för med 2 lager och 2 LED-stift aktiverade skulle 4 lysdioder tändas, inte 3. Detta är ett inneboende problem med vår begränsade multiplexade kubdesign, men oroa dig inte: vi behöver helt enkelt använda kraften hos ihållande syn för att skriva om ritmetoden.
Beständig syn innebär att när ljus når våra ögon sekventiellt – snabbare än vi kan bearbeta det – verkar det vara en enda bild. I vårt fall, snarare än att rita alla fyra skikten samtidigt, borde vi rita det första, inaktivera det, rita det andra och inaktivera det: snabbare än vi kan säga att någon förändring till och med sker. Detta är principen efter vilken meddelandeförfattare arbetar, som den här:
Ny ritningsmetod med hjälp av Persistens of Vision
Först och främst, en ny ritrutin. Jag har skapat en 4 x 16 tvådimensionell array av bitar (sant eller falskt) för att vara en bokstavlig representation av LED-kubens tillstånd. Ritningsrutinen kommer att implementera beständig syn genom att helt enkelt iterera över detta och spola ut varje lager till kuben en kort stund. Den kommer att fortsätta att rita sig själv i det aktuella tillståndet tills uppdateringstiden har förflutit, då vi skickar kontrollen tillbaka till huvudslingan(). Jag har sparat den här delen av koden i denna LED_cube_POV-fil, så om du bara vill hoppa in i att programmera dina egna spel och så free att använda detta som bas.
App 2: Game of Life
Låt oss för nu utveckla detta till en grundläggande version av Conways Game Of Life. För er som inte är bekanta (försök att googla för att hitta en fantastisk påskägg-animation)den Game of Life är ett exempel på cellulära automater som skapar ett fascinerande mönster av framväxande beteende med bara några få enkla regler.
Det är till exempel hur myror verkar röra sig med intelligens och ett bikupa sinne, trots det biologiska faktum att de faktiskt bara följer mycket grundläggande hormonella regler. Här är hela koden för nedladdning: tryck på återställa knappen för att starta om. Om du märker att du får samma mönster om och om igen, försök att hålla ned viloknappen längre.
Här är reglerna för Game of Life:
Varje levande cell med färre än två levande grannar dör, som om de orsakats av underbefolkning. Varje levande cell med två eller tre levande grannar lever vidare till nästa generation. Varje levande cell med fler än tre levande grannar dör, som av överbefolkning. Varje död cell med exakt tre levande grannar blir en levande cell, som genom reproduktion.
Kör koden. Du kommer att märka inom 5 till 10 “generationer”, att automaterna förmodligen har stannat och stabiliserat sig på en viss position; ibland kommer det här stabila mönstret att byta plats och flytta runt på brädet. I sällsynta fall kan de till och med ha dött ut helt. Detta är en begränsning av att bara ha 4x4x4 lysdioder att arbeta med, men det är en bra inlärningsövning ändå.
För att förklara koden:
Du kanske inte är bekant med memcpy() fungera. Jag har använt detta för att spara det tidigare speltillståndet, eftersom arrayer inte bara kan tilldelas varandra som normala variabler – du måste faktiskt kopiera över minnesutrymmet (i det här fallet 64 bitar). howManyNeighbours() funktionen bör vara självförklarande, men om den inte är det – den här metoden tar en enda koordinat och går genom varje möjlig granne (samma riktningar som vi tidigare använde i snake-appen), för att kontrollera om de är giltiga. Den kontrollerar sedan om dessa grannlysdioder var “på” i det tidigare spelläget och räknar hur många det finns. Huvudfunktionen för denna Game of Life-app är progressGame()som tillämpar automatreglerna på det aktuella spelläget.
Förbättringar: Jag har ägnat alldeles för lång tid åt detta hittills, men du kanske vill prova att lägga till en check som automatiskt återställer tavlan efter 5 eller så generationer av samma mönster. snälla meddela mig då! Jag skulle också föreslå att du försöker lägga till POV-metoden till ormspelet för att förhoppningsvis göra en längre orm möjlig.
Det var det från mig idag. Jag kanske återvänder till några fler Arduino LED-kubappar vid ett senare tillfälle, men förhoppningsvis borde du kunna ändra min kod och skapa dina egna spelregler: låt oss veta vad du hittar på i kommentarerna, så att vi alla kan ladda ner dina skapelser! Som alltid kommer jag att vara här för att svara på dina frågor och försvara mina fruktansvärda kodningsförmåga.
Bildkredit: kartesiska koordinater – Wikimedia-användare Sakurambo
Om författaren
James Bruce (720 publicerade artiklar)
James har en BSc i artificiell intelligens och är CompTIA A+ och Network+ certifierad. När han inte är upptagen som Hardware Review Editor, gillar han LEGO, VR och brädspel. Innan han började på MakeUseOf var han ljustekniker, engelskalärare och datacenteringenjör.
Mer från James Bruce
Prenumerera på vårt nyhetsbrev
Gå med i vårt nyhetsbrev för tekniska tips, recensioner, free e-böcker och exklusiva erbjudanden!
Klicka här för att prenumerera
