Programmering af din Arduino 4x4x4 LED-terning for at gøre nogle mere fantastiske ting

Sidste uge byggede jeg en LED-terning Sådan fremstilles en pulserende Arduino LED-terning, der ligner den kom fra fremtiden Hvordan man fremstiller en pulserende Arduino LED-terning, der ligner den kom fra fremtiden, hvis du har dybt med nogle nybegynder Arduino-projekter , men leder efter noget lidt permanent og på et helt andet niveau af awesome, så er den ydmyge 4 x 4 x 4 LED-terning ... - 64 lysdioder at du kan programmere til at lave fantastiske futuristiske lysshows - og det håber jeg også, for det er et fantastisk projekt at motivere dig og udvide dit Arduino-skillset. Jeg efterlod dig et par basale apps for at få dig til at tænke, men i dag vil jeg præsentere et par flere bits software, som jeg lavede til terningen sammen med kodeforklaringer. Formålet med dette er både at give dig nogle flere smukke lysshows at køre, men også at lære om nogle af begrænsningerne ved programmering af terningen, og lære nogle nye programmeringskoncepter i processen.

Dette er noget temmelig avanceret kodning; du har virkelig brug for at have læst alle mine tidligere Arduino-tutorials og vores begynders Arduino-guide før du tilpasser den medfølgende kode.

App 1: Mini Snake

I stedet for at køre en indstillet slangelignende mønstersekvens, ønskede jeg at programmere en slange - en kunstig, der ville gøre dens egne tilfældige valg og være helt uforudsigelige. Det er kun begrænset til 2 segmenter, som jeg vil forklare senere, og du kan se demoen nedenfor. Download den fulde kode her.

Når du arbejder med 3D-plads, har du brug for 3 koordinater til et enkelt punkt: x, Y, og Z.

I vores terning er X- og Z-planerne imidlertid repræsenteret af LED-stifter, mens Y er direkte kortlagt til katodeplanerne. For at gøre det lettere at arbejde med disse koordinater og finde ud af bevægelse omkring terningen oprettede jeg derfor en ny datatype (ved hjælp af struktur) at repræsentere et enkelt punkt på terningen - som jeg kaldte “xyz”. Det består af kun to heltal: “xz”, og “y”. Med denne struktur kunne jeg også repræsentere en retning, der er angivet nedenfor i vores specielle (xz, y) koordinatsystem:

Y bevægelse (op ned): (xz, y + 1), (xz, y-1)
Z bevægelse (frem, tilbage): (xz-1, y), (xz + 1, y)
X bevægelse (venstre højre): (xz + 4, y), (xz-4, y)

For eksempel at flytte LED i position (0,0) en til venstre, vi anvender (xz + 4, y) og ender med (0,4).

Der er visse grænser, der lægges på bevægelse - nemlig at Y-koordinater kun kan være en mulig 0 til 3 (0 er det nederste lag, 3 er det øverste), og XZ-koordinater kunne kun være 0 til 15. En yderligere grænse er placeret på Z-bevægelsen for at forhindre “hoppe” fra bagsiden til fronten af ​​terningen, og vice versa. I dette tilfælde bruger vi modulfunktionen til at teste for multipler af 4 og benægte dette bevægelsesforsøg. Dette er logik er repræsenteret i gyldig() funktion, der returnerer en sand, hvis den foreslåede retning er en acceptabel bevægelse og falsk ellers. Jeg tilføjede en yderligere funktion til at tjekke for en omvendt retning - det vil sige, at hvis slangen kører i en retning, ønsker vi ikke, at den skal gå baglæns på sig selv, selvom det ellers er et gyldigt sted at flytte til - og en bevæge sig() funktion, der tager en koordinat, en retning og returnerer den nye koordinat.

Det XYZ datatype, gyldig(), bevæge sig() og invers () funktioner kan alle findes i xyz.h fil i downloads. Hvis du undrer dig over, hvorfor dette blev lagt i en separat fil i stedet for hovedprogramfilen, skyldes det nogle komplicerede Arduino-compileringsregler, der forhindrer funktioner i returnering af brugerdefinerede datatyper; de skal placeres i deres egen fil og derefter importeres i starten af ​​hovedfilen.

Tilbage i den vigtigste runtime-fil gemmer en række retninger alle mulige bevægelser, som slangen kan foretage; vi kan blot vælge et tilfældigt array-medlem for at få en ny retning. Variabler oprettes også for at gemme den aktuelle placering (nu), den forrige retning og tidligere Beliggenhed. Resten af ​​koden skal være temmelig indlysende for dig; bare for sløjfer, og tænde og slukke lysdioder. I hovedsløjfen kontrollerer vi, om den foreslåede retning er gyldig, og hvis den er, går vi den vej. Hvis ikke, vælger vi en ny retning.

Den eneste ting at påpege i hovedsløjfen er nogle kontroller for at rette en fejl, jeg fandt involveret multiplexing: hvis den nye placering var på det samme katodeplan eller samme anodestift, ville det at slukke for den forrige LED resultere i begge slukke. Det var også på dette tidspunkt, at jeg indså, at det ville være umuligt at gå ud over en 2-segmentet slange med min nuværende implementering: prøv at tænde 3 LED'er i et hjørnearrangement. Det kan du ikke, for med 2 lag og 2 lysdioder, der er aktiveret, ville 4 lysdioder tændes, ikke 3. Dette er et iboende problem med vores begrænsede, multipleksede terningdesign, men ikke at bekymre dig: vi skal blot bruge kraften i vedvarende syn for at omskrive tegningsmetoden.

Vedholdenhed af syn betyder, at når lys når vores øjne i rækkefølge - hurtigere end vi kan behandle det - ser det ud til at være et enkelt billede. I vores tilfælde skal vi i stedet for at tegne alle fire lag på samme tid tegne det første, deaktivere det, tegne det andet og deaktivere det: hurtigere end vi kan fortælle, sker der endda nogen ændring. Dette er det princip, som meddelelsesforfattere fungerer på, som dette:

Ny tegnemetode ved hjælp af Persistence of Vision

Først derefter, en ny trækningsrutine. Jeg har oprettet en 4 x 16 todimensionel matrix af bit (sand eller falsk) for at være en bogstavelig repræsentation af LED-terningens tilstand. Trækrutinen implementerer vedvarende syn ved blot at itereere over dette og skylle hvert lag ud til terningen i et kort øjeblik. Det fortsætter med at tegne sig i den aktuelle tilstand, indtil opdateringstiden er gået, hvor vi overfører kontrol tilbage til hovedsløjfen (). Jeg har gemt dette afsnit af koden i denne LED_cube_POV-fil, så hvis du bare vil springe ind i programmering af dine egne spil og sådan, er du velkommen til at bruge dette som en base.

App 2: Game of Life

For nu, lad os udvikle dette til en grundlæggende version af Conway's Game Of Life. For dem af jer, der ikke er bekendt (prøv Googling for at finde en fantastisk påskeæg-animation), det Game of Life er et eksempel på celleautomater, der skaber et fascinerende mønster af fremvoksende opførsel kun få enkle regler.

Dette er for eksempel, hvordan myrer ser ud til at bevæge sig med intelligens og en bikube, på trods af det biologiske faktum, at de faktisk bare følger meget grundlæggende hormonelle regler. Her er den fulde kode til download: tryk på Nulstil knappen for at genstarte. Hvis du finder dig selv at få det samme mønster igen og igen, kan du prøve at holde resten-knappen nede længere.

Her er reglerne i Game of Life:

• Enhver levende celle med færre end to levende naboer dør, som om den skyldes underbefolkningen.
• Enhver levende celle med to eller tre levende naboer lever videre til den næste generation.
• Enhver levende celle med mere end tre levende naboer dør, som ved overfyldning.
• Enhver død celle med nøjagtigt tre levende naboer bliver en levende celle, som ved reproduktion.

Kør koden. Du vil bemærke inden for 5 til 10 “generationer”, automaten er sandsynligvis kommet til hvile og stabiliserer sig på en bestemt position; undertiden vil dette stabile mønster ændre placering og skifte rundt på brættet. I sjældne tilfælde kan de endda have døde fuldstændigt. Dette er en begrænsning af kun at have 4x4x4 LED'er at arbejde med, men det er alligevel en god læringsøvelse.

Sådan forklares koden:

• Du er muligvis ikke bekendt med memcpy () fungere. Jeg har brugt dette til at gemme den forrige spiltilstand, da arrays ikke bare kan tildeles hinanden som normale variabler - du skal faktisk kopiere på tværs af hukommelsesområdet (i dette tilfælde 64 bit).
• howManyNeighbours () funktion skal være selvforklarende, men i tilfælde af at det ikke er - denne metode tager en enkelt koordinat og løber gennem hver mulig nabo (den samme række retninger, som vi tidligere har brugt i slange-app), for at kontrollere, om de er gyldige. Derefter kontrolleres, om disse nabo-LED'er var 'tændt' i den forrige spiltilstand, og tæller, hvor mange der er.
• Hovedfunktionen i denne Game of Life-app er progressGame (), som anvender automatreglerne i den aktuelle spiltilstand.

Forbedringer: Jeg har brugt alt for længe på dette indtil videre, men du vil måske prøve at tilføje en check, der automatisk nulstiller tavlen efter 5 generationer af det samme mønster. så lad mig det vide! Jeg vil også foreslå at prøve at tilføje POV-metodikken til slangespil for forhåbentlig at muliggøre en længere slange.

Det er det fra mig i dag. Jeg kan besøge nogle flere Arduino LED-terning apps på et senere tidspunkt, men forhåbentlig skal du være i stand til at ændre min kode og oprette dine egne spilleregler: lad os vide, hvad du kommer frem til i kommentarerne, så vi alle kan downloade dine kreationer! Som altid vil jeg være her for at besvare dine spørgsmål og forsvare mine forfærdelige kodningsevner.

Billedkredit: kartesiske koordinater - Wikimedia-bruger Sakurambo