Szia!

Mikor, és hol dől el, hogy mennyi lesz az animációk száma? Ez a loop-on belül is változhat? Azaz, valami memóriából, vagy SD kártyából is jöhet?

Dinamikusan az alloc és a malloc utasításokkal lehet csak megoldani, illetve pointerekkel. Ha változik a tömb, akkor azt törölni kell, mielőtt újra felépíted.

De vitatkoznak rajta, hogy ez mennyire tesz jót a futás stabilitásának:

Bővebben: Link


Itt egy példa dinamikus tömbre:

Bővebben: Link

Az animációk száma, az animációkon belüli lépésszám, és hogy egy lépésen belül mennyi különböző színt kell beállítani a a fejlesztéskor dől el.
Ha lesz új, akkor max újra lesz fordítva.

Jelenleg a teszt alatt az arduino memóriában vannak a leírások, de tudom ez pazarló.
Van yl-90 (24LC256) modulom. Ezt tervezem ha lehet itt tárolni, vagy ha lassú lenne az olvasás, akkor mindig csak az aktuálisan futó animácó adatait tölteném fel az arduino memóriájába. (de ez még odébb van.)

A saját struktúrámat kipróbáltam.
Amint valamit belet teszek abban a pillanatban szól is, hogy elfogyott az Arduino nano memóriája, tehát nagyon pazarló a fix tömb mint gondoltam is.

kapu48 leírását alkalmazva megcsináltam az én struktúrámra a dolgot.
Sokkal jobb a helyzet vele.



A lekérdezés is megy:


Ami nem tetszik, hogy az animáció adatok feltöltése nagyon sok lépésre szétdarabolt (anim1_step1, anim1_step2, anim1).
Ezért nehéz lesz idővel kezelni.

Sem az anim1[]-be sem a leiras[]-ba viszont nem engedi közvetlen feltölteni az adatokat.

Így próbáltam, de nem engedi:

Én inkább szétszedném az elemeket.
Ha minden example-nek más az érték halmaza.
Valahogy, így:


A struct definíciók még nem részei a lefordított programnak.
Majd csak mikor létrehozol példányokat belőlük, és feltöltöd értékekkel a tömböket.
Esetleg csinálhatsz kisebb részlet animációkat, és ezeket aztán tetszőlegesen kevert sorrendben ismételheted.

Admeg definiáláskor a tömb méretét. Akkor nem const-ként hozza létre.
Igy:

Akkor #define. Mármint ezekkel előre megmondhatod, hogy az adott tömb mekkora lesz.

Mikor újra kell fordítani, akkor elég lesz ezeket a változókat cserélni, majd fordítani.

Bővebben: Link

De agyalok rajta, mert lehet nem ez kell neked.

Tömböket létrehozhatsz a flashban const ként, de akkor felkel töltened közvetlenül létrehozáskor.
Vagy memóriában, ha menetközben akarod feltölteni.

Ok, hogy deffine, de ha az egyszerű feldolgozás miatt egységes sruktúrát szeretnék.
(Így is emellett sok mindet folyamatot figyel még az Arduino.)
Ha fix méretet adok, akkor a lehető legnagyobb méretet tudom csak megadni.
Tehát ha vagy egy animáció, ami 20 lépésből áll, és vagy egy olyan olyan animáció aminek az egyik lépésénél mind a 16 led más színen világít, akkor az általam írt nagy tömböket kell megadnom. Azt viszont tudom, hogy ebben az esetben az arduino teljese memóriája elfog az első adat beletöltésekor.

kapu48:
A te elgondolásod alapján nagyon jó memóriaértékek jöttek ki mikor a bővített struktúrámba beillesztettem. Csak sok lépés után sok önálló változót kell létrehozni, és egyesíteni őket. Ezt lenne jó csak egyszerűsíteni.

Amit most javasoltál külön szétszedni elemekre az maga az is járható út lenne.
De a FastLed.h-nál először az összes ledről rendelkeznem kell, hogy melyik milyen színű legyen, majd ha minden meg van, utána kiadni a show parancsot. Ez után jön két nem neopixeles led, aminek pwm-jét állítom be (ledB).

Tehát ezért kellett külön még egy belső dinamikus struktúra, amiből minden lépésnél annyi darab kell ahány darab szín van egy-egy lépésnél (van hogy 1 van, hogy 16).

Így viszont már nem nagyon tudom hogy lehetne szétszedni annyira, hogy ezt a feldolgozó részen egységesen lehessen még kezelni.

Csináltam 1 tesztet, const-ba raktam a tömbjeidet.
Így felszabadult a memória (36 Byte ezen a kis teszten!)



Viszont nem értelek?
A különböző effekt tömböket, mindenféleképen egyedileg kel létrehoznod.
A lejátszáshoz pedig pointerezéssel hozhatsz létre különböző struktúrákat.
Lényeg, hogy nem másolgatod be minden tömbbe a rész tömböket, hanem csak a pointert adod meg rájuk.

Köszi.
Tényleg nagyon jó az eredménye.
Csak félek ha lesz 10 effekt, és mindben 5-10 lépés és lépésenként 4-5 szín, akkor sok egyéni változót kell létrehozni, és félek nehezen lehet idővel átlátni.

Tehát lesz sok ilyen, hogy
anim1_step1[]
anim1_step2[]
anim1_step3[]
anim1_step4[]
anim1_step5[]

anim2_step1[]
anim2_step2[]
anim2_step3[]
anim2_step4[]
anim2_step5[]

...
anim1[]
anim2[]
anim3[]

De ha nem lesz más, akkor ez marad.
Csak kár, hogy valahogy ide

Az anim1_step1 helyére nem tudom rögtön beírni valahogy az anim1_step1 tartalmát.

Nem ismerem az alkalmazott HW-t?
És hogy mi a célja a feladatnak?
Mert ahhoz kel a program megoldásait kialakítani.

Video1
Video2

A 2x8 neopixel (ws2812) a két szem és és a két szem mögött ami nem világit van 2 db 10mm-es kék led, aminél meg PWM-el a fényerőt szabályozom.

1-1 effekt/animáció nem más mint pl. a pislogás, ahol időzítetten kell a ledeket kikapcsolni, majd visszakapcsolni.
De lehet egy animáció, egy vérben forgó szem, vagy bármi más ahol egy egy lépésben lehet minden lednek más a színe (a videókban most nincs olyan, hogy minden led színe más).

Most a vezérlő Arduino Nano, de mivel sok feladatot lát el, lehet Arduino Mega 2560 Pro Mini lesz.

És van egy időzítő sor, ami folyamatosan lekérdezi a nyomógombokat, a hőmérsékletet, a fényerőt, stb. Ebbe az időzítő sorba kerülne bele a szemek világítása is.
És erre lenne ez a struktúra, hogy meg van melyik animáció fut éppen és azon belül meg van milyen időközönként kell változtatni valamit, és azon belül le van írva, hogy mikor változatain kell egyszerre valamit, akkor mit. Mivel sok esetben nem mind a 16 led színe különböző így a színenként "color" írom le a változást, illetve mivel pont 16 led van, azét "leds" banálisan megadja az adott színt mely ledekre vonatkozik. Ezzel mind memóriát tudnék megspórolni ahhoz képest, hogy minden fázisban egyesével minden lednek meg kéne adnom a színét feleslegesen. De csak akkor ha nem kell lefoglalnom feleslegesen a memóriát.

Ez hála nektek már teljesül. Csak maga a leírás része (kód) most olyan, hogy a színeket és a lépéseket is külön-külön változóban kell leírni, és utána összeláncolni. Nem tudom egyben mintha kicsit ilyen JSON-os lenne. Persze ha nincs jobb módszer akkor így lesz, mert memória használatban viszont nagyon jó.

Én készítenék hasonló effekt tömböket:


Ez 1 állandó színnel akár már le is játszhatnád.
Vagy a te módszereddel, tudod a színeket is megadni:


Ezeket akár visszafele is lejátszhatod.

Üdv!
Szeretnék építeni egy motorvezérlést, de nem tudom hogy álljak neki. Túlzottan még nem is értek az arduinohoz ezért kérem a segítségeteket.
Egy ismerősöm kért meg, hogy segítsek neki. Épít egy felhőpásztát, aminek forgatnia kell a fejét.
Lényegében azt kéne csinálni, hogy van 2db végállás kapcsoló, mikor az egyiket megnyomja a fej forduláskor, akkor polaritást vált, és elindul vissza a fej, a másik oldalon lévő kapcsolót megnyomva szintén polaritást vált.

Van valami ötletetek?

Előre is köszönöm!

Az ablaktörlő motor is ezt csinálja. Ezt minek kellene arduval elbonyolítani, pár dióda és 2 áramkörös váltó kapcsoló kérdése az egész.Sebességet pedig pwm-el szabályzó elektronika megoldja

Mivel most úgy van megoldva, hogy van egy 3 állású kapcsoló középen. Viszont mivel a fejnek nagy súlya van, szállítás közben rengetegszer eltörött a kapcsoló. Ezért gondoltam az arduinos megoldásra.

Akkor is kell valami ami mechanikai elmozdulást érzékeli mindegy mi a vezélése ardu vagy más . Akkor ajánlatos lenne pl.: mágnes és hall elem vagy optokapu

Az a baj, túlzottan nem vagyok otthon az ilyen dolgokban, de majd próbálkozom!

Bármilyen elmozdulás / pozíció érzékelő jó neked amivel 2 állapot az "ott lévőség vagy nem ott lévőség ", állapota eldönthető. Ennek a kimenetét kell illeszteni a meglévő további motor forgató rendszerhez.Jó helyen jársz csak nem a jó topicban tetted fel a kérdést
Keresőbe itt fent írbe a "végállás" szót sok sok motoros mozgolódós topickot fogsz találni

Dinamikus tömböket lehet használni, de nem egyszerű.

Amit nem értek, az az, hogy minden egyes led minden egyes tulajdonságát el lehet menteni egy byte típusú tömbbe. Ráadásul egy kétdimenziósba. De akár háromba is.

1 lednek mennyi bájt kell? RGB-hez 3. PWM hez 1. 16 Led-nél mindez 64 byte. Kell egy plusz az időzítéshez, plusz egy lesz-e még animáció. Ez eddig nem sok.

Led[10][Ledek száma x annyi bájt ami kell egy lednek +2]
Ezeket kell feltöltened mikor tudod, hogy egy anim mennyi frame-ből fog állni, akkor az első 10 helyett annyit írsz bele amennyit szeretnél.
A következő dimenzióban annyi adat megy, amennyi led van, illetve plusz az időzítés, illetve még ami kell. Vagy háromdimenziós tömböt használsz.

Tesztként, ha 16 led van:

1 frame összesen 16*(3+1)+2 azaz 66 byte. Szerintem ilyen kevés lednél ez semmi.

Mármost ezt ha feltöltöd, pl szövegfájlból, vagy serial monitoron, vagy akárhonnan, akkor ez mehet.

Az Arduino loop-ban megoldja, hogy az adott tömb i-ik indexű eleme mikor mehet, ha mehet egyáltalán.

Ügyes kódolással ebbe a tömbbe simán belerakhatsz sok animációt is, majd pl egy gomb vagy akármi, kiválaszthatja, hogy melyik anim engedélyezett. Így, mivel a második dimenzió adott, csak az elsőt kell megadni.

Az időzítéshez valóban nem elég a byte, de ki akar olyan animot, ami 1 milisec alatt változik? Azaz a kiértékeléskor a 255 nem milsec-et fog jelenteni, hanem pl tized másodpercet. Így egy bájton 25.5 sec lehet a max időzítés.
A loop-ban egy index ami a tömb első dimenziójában lépked, míg egy másik, ami a másodikban.

Egy ciklussal megadod a led lábának értékeit a második dimenzióból, majd egy if, hogy várjon ameddig kell, vagy ugorjon másik külső indexre, stb.

Mindezt ki lehetne egészíteni úgy, hogy pl egy sd kártyáról tölti fel az animációk tömböt, sokkal átláthatóbb lesz minden szerintem.

A gond inkább az lehet, hogy az Arduino-t fel kell készíteni az adatok fogadására, pl soros monitoron, de úgy, hogy egy frame-nyi infót kapjon pl szövegként, vesszővel tagolva. Természetesen miután meg lett mondva, hogy mennyi frame lesz. Itt kell majd az újra dimenzionálás, de csak egyszer. (De ezt el kellene kerülni) Ezt is kikerülheted, ha az arduino-ra azt a kódot töltöd fel, amiben az előre definiált tömb első indexe meg fog egyezni, a rátöltendő anim számával, így nem kell az arduino kódban látnod minden egyes frame bittérképét, de nyilván az elején meg kell adni neki, mekkora lesz az a tömb. (Megoldható, hogy a feltöltés előtt átdimenzionálja ezt, de szerintem kerülendő, jobb ha kódból van megadva, majd az adatok később)

Sőt!

Ha egy SD-kártyán byte térképen tárolod a frame-eket, akkor az arduino-n elég az épp aktuális frame-et tárolnod és a következőt. Így minden esetben két ilyen tömb kell! Fixen! Az arduino meg olvassa a következő frame-et, max időzít. közben csere! Ha minden frame azonos hosszúságú, akkor a bináris fájlban seek()-el, vagy hasonlóval gyorsan arra a recordra tudsz állni, ami a következő frame lesz a fájlban.

Vagy:

Abban ez esetben, ha tudnál egy olyan segéd programot írni, ami egy meglévő .ino fájlba egyszerűen beilleszti az összes adatot, akkor már feltöltés előtt tudni fogsz mindent, ezért azt már töltheted direktben az arduino-ra.

Pl Excelben egy kis makró, ami pl. a ledek számától és a frame-töl függő byte adatokat szépen kiírja egy ino-ba, de olyanba, amiben a definiált tömb már annyi amennyi kell, tartalmazza már a többi kódot stb. (úgy legyen megszerkesztve, hogy azt már ctrl+c, ctrl+v vel a megfeleő helyre beillesztve, magát a tömböt annak elemeinek felsorolásával.)Szerintem egy ilyen Excel nagyon hasznos lehet, mert a cella háttér színe már lehet az RGB érték, a frameeket külön kölön látod, egyszerűen csak export, a makró összerakja a kódot, azt feltöltöd direktben az arduino-ra és kész.

De ezek csak ötletek, lehet nem is értem pontosan a feladatot ha így van akkor bocsánat!

Bocs a sok hibáért de hason fekve kell pötyögnöm telefonon mert szétment a derekam. Telóhoz meg nem szoktam hozzá!

Kipróbáltam ezt a titkos tápfeszültségmérési módszert egy arduino unon 328P felületszerelt proc van rajta, de nekem csak nullákat küld vissza a roros monitoron. Nektek működik?


Read arduino VCC doc...
Read arduino VCC video...

Nincs return a függvényben. Azaz mindig 0 lesz az eredmény. Kellene egy retrurn result;

Óóó picsbe, ott van az a 10 .-ik sorba, csak elmaradt egy sortörés...
Úgy már megy...

Első két három mérés alatt még ugrál pár mV -ot, de utánna már egyet sem. Azt hittem, nagyobb hiszterézise lesz, de úgy látom, szerintem ez a módszer elég lesz a BMS rendszerembe cellafeszültség méréshez. Elvileg működik attiny85 -ön is (csak most épp még nincs ilyen tokom), így marad egy szabad láb, amire eddig az ellenállásosztós tápfeszültségmérést terveztem.

Ez egész jó. Amit én ismertem, az botrányos, a belső hőmérőt használja. Megnéztem, az Attiny84-nél is tudsz Bandgap feszültséget mérni, szóval ott is lesz tápfeszültség eredményed.

Igen azt én is olvastam, hogy elvileg hőmérő is van benne, szóval akár tokhőmérsékletet is lehet vele mérni, de az annyira nem érdekel. Külső hőmérőszenzor lesz, amit beteszek minden egyes cellapakk közé...

Mitől ennyire stabil? Nem látok átlagot sehol sem!

Fogalmam sincs, nem értek hozzá.
De multival mérve a tápfeszt, az sem változik többet, legfeljebb +-0.002 V -ot...
Gyakorlatilag én ebből a readVcc() fügvényből semmit nem értek, csak arra sikerült rájönnöm,
hogy az utolsó előtti sorban a "result = 1107880L / result;" értékkel lehet kalibrálni...

Ahogy nézem, 8biten kapta Roli az eredményt. Ez a maximum. 20mV/bit. Szerintem használható. Egy kis átlagolással tovább finomítható. Egy a lényeg itt is, a referencia feszültséget be kell írni a programba, akkor lesz még pontosabb.
Úgy is lehet kalibrálni, hogy a result változót az osztás előttről kiíratjuk soros monitorra mondjuk, eközben mérjük a tápfeszültséget, majd ebből a kettőből kiszámoljuk a szükséges osztót.