Fórum témák
» Több friss téma |
A klónok CH340 Soros-USB illesztőjének drivere (Letöltés)
Ajjaj! Az egér gombja akkor reagál amikorra a szoftverfejlesztô akarja. PC-n külön esemény az egér lenyomása, felengedése, a klikkelés és a dupla-klikk is. (benyisszantottam egy képet utólag)
A hozzászólás módosítva: Okt 30, 2021
De ha úgy van beállítva, hogy fölengedésre reagáljon, akkor sincsen szétnyomkodva.
Visszatérve az arduinóra, ha a gombnyomást úgy írjuk meg, hogy lenyomásra reagáljon, akkor is regisztrálni kell a fölengedést, mert adott esetben sokszor végrehajtódhat a lenyomásra programozott művelet. Ha skori leírását is hozzá vesszük, akkor is feltétlenül szükséges azt tudni, hogy a gomb mikor lett fölengedve. Tehát a gomb fölengedése legalább olyan fontos, mint a lenyomása. Ha ez nincsen a programban lekezelve, akkor az okozhat problémákat. Ha csak a lenyomást kezeli a programozó, az baj. A vita indító hozzászólásomat inkább úgy kellett volna írnom, hogy nem csak a lenyomást kell a programban kezelni, hanem a fölengedést is.
Hát igen. Elég egy modern CAD programot kézbe venni.Amit én használok az egér eddig 20 különbözö funkciot tud, és nincs kizárva, hogy még nem is ismerem valamennyit.
Oz ott egy onClick és egy onDoubleClick, utóbbi ügye nyom-felenged-kis szünet-nyom-felenged. Nincs onPress és onRelease - legalábbis itt.
Próbáld ki egy automatával a büfé mögött !
OnMouseUp az egyenlô onRelease, és felette a másik a lenyomás, csak más programnyelvben másként hívják.
Így igaz, bár az egérben ugye további hardver kezeli a gombokat, az extra funkciókat pedig részben az oprendszer, részben a CAD program adja hozzá. De ez arduino esetében sem olyan bonyolult.
Régebben kigondoltam egy nyomógomb kezelő megoldást, amit már párszor alkalmaztam is arduino-n, amikor nincs sok nyomógomb, de azt ügyesen kell kezelni. Ez olyanok felismerésére is képes, hogy "A" gombot nyomva tartom, közben a "B" gombot lenyomom háromszor, de mondjuk a harmadik gombnyomás felengedése előtt az "A" gombot engedem fel. Ráadásul az ilyen extrább feltételeket is olyan módon kezeli, hogy nem lesz tőle bonyolult a program. Pl. egy ilyen feltétel kezeléséhez is csak egyetlen if()-el kell bővíteni a programot. Persze pont ilyen elég ritkán kell, de adott esetben jó lehet, mondjuk egy szerviz menü aktiválásához, mert véletlenül aligha nyom be ilyen kombinációt a felhasználó. A hozzászólás módosítva: Okt 30, 2021
Ne viccelj, akkor nem lehetne vele "megfogni", odébb húzni, majd elengedni.
Szia!
Hogy még jobban tudjunk segíteni, jó lenne még több info; a nyák terv, az elrendezés. A nyomógomb távolságát nem látom, hogy valahol írtad volna. Ha nyákon a proci mellett van, akkor teljesen jó lehet a proci belső felhúzó ellenállása is. A kapcsolási rajból nem derül ki nekem, hogy milyen tápot használsz. Ha analóg jelet is olvasol, fontos a táp megfelelő szűrtsége, a táp és gnd felület kialakítása nyákon. Egyáltalán, az egész rendszer zavarmentes felépítése. Amit a kapcsolási rajból látok, hogy hiányoznak a szokásos hidegítő kondenzátorok, a processzor mellől biztosan (100nF + 1µF kerámia kondi), de szerintem kell az SD kártya és a MAX melléi is kellene. Érdemes volna néhány applikációt megnézned, hogy az analóg és digitális tápra összekötésére milyen ajánlások vannak (ATMegát még nem használtam, más mikrovezérlőknél legalább szűrés szintjén szét szokás választani a kettő tápot). Egy közelben elmenő kábel akkor okozhat gondot, ha kapacitíve vagy mágnesesen tud rászórni az elektronikára. Az első ellen védelmet nyújt az árnyékolás. Mágneses szórás a vezetéken átfolyó áramtól függ elsősorban. Ha nagy áramok folynak a vezetékben, akkor célszerű inkább távolabb tenni tőle az elektronikát. Ha mágneses szórás várható, akkor különösen törekedni kell a kis méretre, a kis hurkokra a nyákon és a vezetékezésben. Amit készíteni akarsz, azt úgy is hívják, hogy beágyazott rendszer. Néha én is erre a területre tévedek, és szép műszaki kihívásnak tartom egy-egy ilyen feladat megoldását. Sok sikert kívánok neked is ehhez!
Csak egy szösszenet az életből :
Drága berendezésünk vezérlője a hiba nyugtázásához "csak" a nyugtázó gomb benyomott állapotát figyelte... Gondolhatjátok "okos" kollegák betámasztották a gombot és ment a rendszer, mig ki nem jött a füst. Szervizesünk átállította a nyugtázást "gomb felengedésekor" állapotra...
A lefutóél és a lenyomott állapot idejének együttesét kell figyelni egy "alap gomblenyomásnál", ha valaki utána nem írja feltételnek a felengedést, akkor persze úgy járhat !
Te a WWII alatt az Abwehr vagy a SIS kódfejtőit segítetted az ötleteiddel ?
Ez a gombkezelő megoldás érdekel, meg tudod mutatni?
Tudom nem én lettem megszólítva, meg már évek óta nem Arduinoztam, de én így csinálnám:
u.i.: a program más részén ugyanúgy lekezelhető ezzel a kóddal a négy gomb, csak ott pl. gombfejlec('H')..tól indulva továbbfejlesztve. A hozzászólás módosítva: Okt 30, 2021
Arra reagáltam azzal a hozzászólásommal, hogy azért, mert egy gomb fölengedésre reagál, senki nem fogja azt szétnyomni.
Nagy vonalakban úgy működik, hogy amikor meghívom a függvényt, akkor a beolvasott gombok állapotát berakja egy változó bitjeibe. Ezután megnézi, hogy ez a változó eltér-e az előző olvasáskori állapotától. Ha eltér akkor tárolja az új értéket, és az időt, majd kilép.
Ha a változó értéke stabil legalább 2...6 msec óta, akkor már nincs prellezés -> feldolgozható az érték. Ekkor gombok állapotát tartalmazó változót balra shiftelem annyival, ahány gombom van, és az alsó bitekbe beteszem az aktuális állapotot. Tehát pl. egy 32 bites változó, három gomb esetén, a gombok utolsó 10 állapotát tartalmazza. Attól függően, hogy hány korábbi állapotot akarok figyelembe venni maszkolom a változót, majd összehasonlítom egy célértékkel. Pl. if ((gombok & 0b111111) == 0b000010) {......} feltétel azt jelenti, hogy mindhárom gomb fel volt engedve, majd a középső gombot megnyomták. Egy ilyen felépítésű feltétellel gyakorlatilag bármilyen, maximum 10 állapotból álló tetszőleges kombináció vizsgálható. Van két további változó ami 1 be áll ha a gombok állapota változott. Sima gombnyomás feldolgozásakor nullázom az első változót, így tudható hogy az adott állapot már fel van dolgozva (ebben az esetben megint csak kilép a függvény). Mivel minden híváskor tudható, hogy mióta stabil az adott nyomógomb állapot, a másik voltozó a hosszú gombnyomás nyugtázására szolgál. Azaz ha egy állapot adott ideje fennáll, és a hosszú gombnyomás még nincs nyugtázva, akkor erre az eseményre ugrik. Természetesen ez is lehet egyetlen változó több bitje, és többféle hosszúság is feldolgozható. Ezen kívül a tárolt idő is módosítható nyugtázás nélkül, így lehet az ismétlődést beállítani egy adott állapotra. A függvény egyszerűen hívható a loop-ból, ha az nem fut túl lassan, de kicsit átalakítva részben megszakítással is működhet. Mivel általában törekszem rá, hogy a loop a lehető leggyorsabban fusson, így nálam ez adja magát. A hozzászólás módosítva: Okt 30, 2021
Köszi, hogy elmesélted a működését. De meg is tudod mutatni?
Mert nekem is van egy saját, nem lib-re épülő gomb kezelő függvényem, ami rövid és hosszú gombnyomást detektál, természetesen prell-el együtt. Mind a 3 idő paraméter állítható. Ezért érdekelne a te kódod, mert összevetném az enyémmel a hosszúságát. Amúgy csak azért írtam egy ilyet, mert a fellehető megoldások nekem túl sok memóriát foglaltak le.
Ha nyilvánosságra akartam volna hozni a kódot, akkor már megtettem volna. A leírás alapján, ha érted a működését, akkor könnyen leprogramozható.
A függvényem statikus változói 10 bájtot foglalnak, és még 5 bájtnyi lokális változója van. Mivel a legtöbb esemény egy-egy újabb függvényhívást jelent, ezért ehhez nyilván még a stack-en foglal valamennyit. A függvényt nem raktam ki külön fájlba sem, és a paraméterei is többnyire "be vannak égetve", ezért mindig az adott programhoz igazítom ha szükséges. Ha úgy alakul, hogy nagyon gyakran lesz szükség rá, akkor lehet, hogy majd átírom univerzálisabbá. Bár igazából nem egy nagyon hosszú függvény, az egész elfér kb. egy oldalon az IDE-ben, bár nyilván attól is függ, hogy hányféle állapothoz akarsz eseményt rendelni. A hozzászólás módosítva: Okt 30, 2021
Ha meg is osztanád sem lenne Josi777 előrébb, mert egy gombkezelés annyira specifikus, hogy nem lehet csak hip-hop 3 gomb helyett 4-et lekezelni. Emlékszem, ahányszor megírtam a gombkezelő fv-em, mindig ugyanaz volt az elv, de a végén teljesen más alakult ki. E köré egy komplett állapotgépet kell tervezni, de olyan könnyű belegabalyodni, hogy jobb, ha az ember mindent előre megtervez.
Példa: gomb nyomva tartásakor folyamatosan gyorsulóan növekvő számláló léptetés... Szép kis feladat volt, de ehhez még hozzá jött a finomhangolás! Túl gyors, túl lassú, lomhán vált át a sima egyesével változásból az automatikusba, meddig emelkedjen a sebesség, a kijelző ezt a gyors változást hogyan (mikor) kezelje le, stb. Millió probléma. Idézet: „Ha meg is osztanád sem lenne Josi777 előrébb” Honnan tudod? Ráadásul nem használni, hanem összehasonlítani szerettem volna.
Szerintem elég szemléletes és részletes leírást adott Skori, ebbôl kiindulva lazán meg lehet írni a kódot. Igaz nem Ardu, de összetett gombkezelést én is írtam már régebben, MPASM-ben Bővebben: Link
A hozzászólás módosítva: Okt 31, 2021
Rosszul fogalmaztam. Nem kifejezetten Te, hanem általánosságban, csak példaként tudnánk használni, de egy példából működő kódot összehozni nehezebb, mint újra megírni. Én a saját kódomat nem tudtam újrahasználni, pedig csak kicsi változtatás kellett (több gomb), ezért elölről újra kellett írnom, talán jobbra is sikerült, mint az előző. Ja, és ezt se fogom tudni felhasználni később, sőt, azóta már máshogy oldanám meg, mert a végére a rengeteg feltételrendszer meg ideiglenes változó megjegyzése nagy kavarodást okoz.
A hozzászólás módosítva: Okt 31, 2021
Mint már említettem, nincs szükségem másik gombkezelőre, csak érdekelt volna a megvalósítás. Az a lámpás 1 gombos dolog érdekes, a használata egy kis ügyességet igényel, de szellemes megoldás, kaptál is rá mancsot
A mellékletbe én is beraktam egy gombkezelő eljárást. Igaz ez még 1000 éve pic-re íródott, de nem hiszem, hogy gondot okozhat az arduino-ra történő átalakítása. A példa 16 gombot kezel (2x8 mátrixba kötve), detektálja a lenyomást, a rövid időn belüli felengedést, a hosszú idő utáni felengedést, tudja a gombismétlést (ha lenyomva van tartva - mint egy PC billentyűzet).
Annyi a lényege, hogy nekünk kell gondoskodni arról, hogy kb 30ms időközönként legyen meghívva a GetButtons() függvény - ezt megtehetjük akár a loop-ban a millis() függvényt használva, vagy megszakításban. A Btn globális változóban kapjuk vissza a lenyomott gomb kódját, a BtnType-ben meg hogy éppen mi történt azzal a gombbal (lenyomták, rövid időn belül felengedték, már hosszan le van nyomva, lenyomva tartva ismétel, hosszú lenyomás után felengedték).
Sziasztok!
Van valami módja, hogy egy Arduino nano-ból a benne lévő programot kiolvasni, és azt lementeni? (pl. usb pendrive) Ha bármi gond adódik, akkor ezt a lementett állományt vissza lehessen tölteni a nano-ra. Köszönöm.
Tulajdonképpen ugyanazt kérdezem, lehet kapni olyan usb AVR programozót ami win10 kompatibilis?
Atmel ICE
Pickit 4 AVR ISP mk II (Atduino Microbol vagy Leonardoból könnyedén építhető.)
Ha nincs védve a kiolvasás, akkor igen.
Ez jó hír. Mi a metódus?
1. Veszel vagy készítesz egy programozót. Én Atmel ICE-t és Pickit 4-t használok.
2. Letöltesz egy szoftvert, ami képes elvégezni a feladatot. Én Microchip Studiot használok. 3. Megnézed az adott mikrokontroller adatlapján a lábkiosztását, csatlakoztatod a programozót. 4. A választott szoftverrel fájlba másolod a flash tartalmát. 5. Ha olvasás védett, akkor csupa FF lesz a fáljban, ha jól emlékszem. |
Bejelentkezés
Hirdetés |