Fórum témák
» Több friss téma |
A klónok CH340 Soros-USB illesztőjének drivere (Letöltés)
Csinálhatsz két párhuzamos állapotgépet, és az egyik vezérelheti a másikat. A "külső" gombnyomásra 20 másodpercig van aktív állapotban. A belsőt a külső aktiválása indítja és állítja le és közben ismételgeti amit kell neki. A sokat emlegetett állapotgépes megoldással így néz ki kb:
Ha hosszútávon pontos időzítést akarsz, akkor
A hátránya, hogy szerintem sokkal érzékenyebb lesz mint egy Arduino UNO.
Nem hülyeség egyébként teljes Linuxot tenni Wifihez, mert amint drót nélkül kapcsolódunk azonnal kritikussá válik, hogy titkosítva legyen a kapcsolat, és ezt Linux alatt gyerekjáték megcsinálni - például SSH-val -, mikrovezérlő alapon meg egyáltalán nem egyszerű. Szerintem a díszdobozos UNO árába beleférhet ez is, olyasmi árúnak képzelem, mint egy router. A háttértár és a RAM az általam elképzelt célokra jócskán túlméretezett, de az nem baj. Az STM-eket szeretem, jó doksijuk van és jók hozzá a toolok is.
Köszönöm. Nem teljesen világos (még) minden, de majd tanulmányozom.
Az a bajom vele, hogy szép, szép, csak tökéletlen megoldás, mivel mezítláb látványos, de ha csak egyetlen shield-et is rádugsz közvetlenül... Azokat majd átlátszó alkatrészekből építik?
Egyébként 8x12, megszámoltam. : -] Bár nem szeretem azokat a parányi kijelzőket, amik mostanában a kisebb projectekhez nem irritálóan drágák, de talán mégis célszerűbb lett volna, akár kihosszabbíthatóan. Sok ilyen létezik.
Hátulról/alulról kell dugni
 A hozzászólás módosítva: Okt 19, 2025
Gondoltam rá, de alulról mintha nem lehetne csatlakoztatni őket, és azokon még inkább lehetnek kezelőszervek, kijelzők. Maradnak a szalagkábelek.
Alulról az UNO féle csatlakozó kiosztás nem érhető el, kizárólag felülről. Cserébe alul van rengeteg kivezetése a panelnek, amik meg 1,8 V-osak. Érdekes koncepció.
Tüske/hüvelysor ráforrasztható alulra utólag, nem?
Persze, megoldható (Kellő ügyességgel, de nem hinném, hogy szakszerű lenne, mivel egy eleve beforrasztott csatlakozósor forrasztási pontjaihoz kellene forrasztani az új csatlakozót. Vagy kiveszed az eredetit és alulra nézve forrasztasz be tüskesort.), de akkor valójában nem férsz hozzá a többi csatlakoztatási ponthoz, pont azokhoz, ami miatt érdemes beruházni egy ilyen lapkába.
A lényeg az, hogy ha két folyamatnak két külön állapotgépet csinálsz két külön függvénnyel megvalósítva, akkor egymástól függetlenül fognak párhuzamosan működni. Tehát a process2 állapotgépet önmagában nézheted. Az eredeti hozzászólásod nem olvastam elég figyelmesen, hogy lényeges, hogy a különböző időzítéseket hogyan valósítod meg. Csak a process2-t átírva tetszőleges idő mintát meg lehet valósítani, amit leírtál, az kb így nézhet ki. 5 állapotunk van, a kikapcsolt állapot, és minden várakozás 1-1 állapotnak felel meg.
Nagyjából ez lenne a blokkoló megvalósítás pszeudókóddal, ami ugyanezt csinálja:
Köszönöm, ez szimpatikus megoldás. Még tanulmányozom, de elsőre jónak tűnik. Köszönet a fáradozásért mindenkinek!
Uno qMeg is vettem a uno q, majd mondom eljátszadozom vele, persze a program nem indul ami hozzá van az App Lab, csak az ide 2.x, szép egy start
Jött egy frissítés ami megoldotta a gondot!
Majd mesélj, milyen példaprogramokat adtak hozzá...
Lehet két hét után már nem aktuális , de azért volna egy tippem a gomb figyelés-20 másodperces kihagyására .
void gombfigyelés() { if(!gnyomi) { bool x=digitalread(gomb); if(x) gnyomi=true , húszmásodperces() ; // kizárod magad a gombfigyelő eljárásból } } void húszmásodperces () { végevan=false; .....tevékenység..... if (végevan) gnyomi=false; // engedélyezed a gombfigyelést. } Nyílván ez csak egy ötlet ezt ki kell dolgozni és a részletekben megbújó ödögöt pedig kizavarni belőle. Villogtatás és egyebek: A mikros() függvénnyel tudsz pontos időmarkereket létrehozni (a millis egy rakat sz.... azzal ne foglalkozz ) unsigned long ms = micros(); idoalap=ms/100000 ; // időalap változód minden tizedmásodpercben fog egyet lépni előre. Ha változtatod az osztót akkor más időalapot kapsz. /1000 =1mS (és ez pontos is) Erre alapozva annyi egymástól független időzítést villogtatást , programrészlet lefutást tudsz létrehozni amennyit csak akarsz (illetve amit a chip elbír). Ja és a delay is mehet a kukába. Gombfigyelés: Sokszor láttam már azt a módszert amikor a belső felhúzó ellenállást bekapcsolják és ráakasztanak egy gombot a bemenetre amely gombnak a prellezése miatt írnak egy k@rvára bonyolult eljárást, mellyel kiküszöbölik a nyomigomb okozta problémát. Hát lehet így is de egy kerámia kondi meg két ellenállás is megoldja , főleg ha minden le van időzítve a programban. Ott a módszer fentebb . Ha tizedmásodpercenként egyszer nézel rá a gombra és a mellékelt fotón látható módon kötöd be akkor a prellezést és a kapcsolódó programozási hókuszpókuszt el is felejtheted végleg. üdv
Pedig csupa izgalom; face detector meg minden. : -) Köszi.
Közben írtam egy használható verziót, de ebben is van, ami szimpatikus. A delay eleve kiesett, a millis szóba jöhet, mert nem kritikus az idő. Ezzel együtt köszönöm a fáradozásod!
"a millis egy rakat sz.... azzal ne foglalkozz"
Igazából mi a probléma a millis()-sel? A wiring.c-ben található a forrásuk, és ugyanolyan számláláson alapszik a kettő, semmilyen lényegi különbség sincs köztük. Egyszerűsítve ilyenek:
Ha szabályos időközönként foglalkozol a nyomógombokkal (te tizedmásodpercenkéntit írsz, én általában harmincadmásodpercenkénti lekérdezést szoktam használni, de ez részletkérdés), akkor szerintem teljesen felesleges a hardvert kondikkal és ellenállásokkal bonyolítani, nem okoz gondot a gombok prellezése. Én külön eseménykódot szoktam hozzárendelni a gomb lenyomásához, meg a gomb felengedéséhez, sőt nem sokkal bonyolultabb megoldani, hogy kezelve legyen a gomb ismétlése meg a rövid/hosszú gombnyomás utáni felengedés megkülönböztetése. Ezzel a PC billentyűzetéhez hasonló működést lehet megvalósítani.
Szia!
Gondolom már minden megy, és akkor az jó, de miért nem használtál timer-eket? Azok erre vannak kitalálva, bár a milis() is ere épül. De ha jól tudom az Arduino-ban is több timer van. Ha a timer 8 bites, akkor hamar lefut, azaz számlálók kellenek bele, nem túl bonyolult. A ComparA és társai is hasznosak lehetnek ekkor, de a sima overflow -val is megoldható, csak akkor a timer kezdeti értékét kell megadni. A másik: Tömbökbe ki leht szervezni a bekapcsolt és kikapcsolt időtartamokat, így a tömb indexeivel kell lépni csak. Másik: Ha a szünetek ideje számtani sorozat mentén nő, akkor egy sima változó, ami mindig x értékkel nő. Ebben az esetben tömb sem kell. Valójában nem bonyolult annyira szerintem, mert egy olyan timer kell, amivel megoldod a 20s időt és egy másik, ami ezzel együtt indul, majd az szabályoza a ki/be kapcsolásokat. Ha a 20s lejár, akor ez a timer kinulláz, overflow flag 0, és leállít (illetve maga a 20s timer is leáll, alaphelyzetbe téve). Gombnyomásra logikai változó átáll, indulnak a timerek. Ezt a lábat simán lehet interruptra tenni is, így a fő ciklusban nem kell if a láb figyelésére. Szóval pár volatile logikai és egyéb változó és a timer-ek megoldják, igen kevés processzor időt felhasználva, így a fő main-be lehetnek még egyéb kódok. A timer-ek az órajellel vannak összekötve, számlálók valójában és bizonyos esetekben (overflow, comparA, stb) esetekben megszakítást kérnek, azaz addig, míg ez nem történik meg, a cpu futhat gond nélkül. Ezek a feladatok nem terhelik meg a cput annyira, hiszen más áramkörök dolgoznak a háttérben ekkor. (bár ebben az esetben a sima serial olvasás írás lehet gondban lenne, mert ha jól emlékszem az is megszakításokkal operál, lehet ebből gond lehet, ezt nem tudom pontosan) De: Sima milis()-el is simán megoldható, interruptok nélkül is akár. A lényeg, hogy a milis() a timer0-t használja. Ezért több nem lehet ha jól sejtem, de nem is kell feltétlenül. De inkább kipróbálom, megpróbálom megírni. Ha sikerül bemásolom ide. REmélem menni fog!
Ezt hoztam össze, ez sima millis()-el megy:
Bővebben: Link A kód úgy megy, hogy a gomb megnyomása után 20 másodpercig villogtatja a piros LED-et, a zöld LED jelzi, hogy a 20 másodpercben vagyunk. Ha a 20 másodperc nem telt le, akkor a gombot hiába nyomjuk meg, nem veszi figyelembe. A piros LED 1 másodpercig világít, utána 0.2s ig nem, majd megint 1 s de utána 0.4s-ig nem. A növekmény 200ms minden lépésben. Könnyen átírható lenne akár tömbben tárolt időkre is szerintem. A változók nevei azért ilyen hosszúak, mert így sokkal érthetőbbé válik szerintem, de 1-2 helyen hosszú lesz.. A szimuláció remélem elérhető, de a kódot ide is bemásolom:
Régen írtam Arduino kódot, ráadásul Timer-ekkel szoktam megoldani, ezért lehet ezt még egyszerűsíteni esetleg, illetve nem tudom pontosan, hogy maradt-e benne felesleges váltizó vagy sem.
És ez a rész már nem is kell bele:
Mikor elkezdtem akkor kellett csak, ezt nem feltétlen kell már bele. A fejlesztés elején kellett, de a későbbi változók mint például a "Piros_LEDnek_kell_vilagitania" megoldja ezt a problémát. A hozzászólás módosítva: Okt 25, 2025
Köszönöm szépen a fáradozásod!
Arduino UNO Q és használataArduino UNO Q – Az új korszak kezdete: Linux és valós idejű vezérlés egy lapon.Hátha egyszer még előkerül... Bővebben: Link Valakinek van tapasztalat vele? Az USB C-re rakott video nélül már el sem indul?
En meg nem lattam megvasarolhato peldanyt, kiveve ezt az Aliexpress-en.
Bar nekem jok a tapasztalataim az ottani (Aliexpress) rendelesekkel, de ezt meg nem mertem bevallani
18 rugó: Bővebben: Link
|
Bejelentkezés
Hirdetés |
