A megszakításban enkódert kezelek.



De kezdek belegabalyodni. Ha letiltom LCD kezelés közben a megszakítást, akkor valamelyest működik. Azért valamelyest, mert néha "újraindul" az MCU. Lefut a setup és kezdődik újra minden, de a RAM-ban tárolt adatok maradnak.

Az összeadás precedenciája nagyobb, mint a shiftelésé! Biztosan így akartad ezt??

A RAM értéke resetkor nem változik meg, csak tápelvételkor....

Ezt kifejthetnéd bővebben. Életem első enkóder kezelő receptje ez. Működik, azóta ezt használom. Ha lehet gyorsabbra is írni, hát átírom.

Az még nem baj, de mindenképpen célszerű lenne érteni, hogy mit csinál a kód...!
Én pl nem igazán értem mi akar lenne a zárójeles rész...?!! Egy if-et nem hagytál le onnan?

De amiről én beszélek, az egy sunyi hiba, az összeadást végzi el előbb, majd ennek eredményével shiftel! Nagyon más lesz az eredmény, mintha fordítva lenne..., pedig az tűnik logikusabbnak )

Nem hagytam le if-et. Egyszerűen egy 8 bites változóba beletologatom a pinek értékét és megvizsgálom, hogy az előre lépés, vagy hátra lépés volt-e, vagy esetleg fals jel.

Akkor magyarázd el, mit is csinál ez szerinted? : ((PIND & _BV (4)) == 0)
Jobbik esetben a PIND 4. bitjét maszkolja..., aztán vizsgál egy egyenlőséget 0-val, de minek, és hogyan??! Itt valaha egy if lehetett gondolom.... Jelen esetben ignorálja a fordító feltehetően, majd az eredményhez hozzáadja az A változó korábbi értékét, és az egésszel shiftel egy 1-est A-ba! Nos, kötve hinném, hogy erre gondolt a költő eredetileg, és hogy ez így korrektül működne....

Szerintem működik, csak elég nehezen kibogozható, hogy hogyan (ötletes és kicsit kifacsart módszer). És a működéshez pont az kell, hogy az összeadással kezdje és a végén shifteljen.

Sziasztok!
Meg tudnatok nekem mondani, hogy kb. 10db led vezerlesere, egy modellbe melyik alaplapot celszeru megvenni? Automodell "kiviĺagitasa" lenne a cel. max 150mA aramfelvetel lenne. Meg sose dolgoztam arduinoval. Valaki a arduino nanot javasolta. Hestorba van valami szamomra hasznalhato szerintetek?
Koszonom!

Akkor esetleg leírnád ezt az ötletes módszert, hogy konkrétan hogyan működik szerinted?

A c fordító ugye úgy működik, hogy ha egy feltétel vizsgálat eredménye igaz, akkor az eredménye 1 (true) lesz, ha hamis akkor 0 (false).
Az második és a harmadik sorban a zárójeles részbe helyettesíts be 1-t ha az encoder vizsgált lába 0 (azaz rövidzár, ha GND-re húz), 0-t ha az encoder lába 1.
2. sor: A (static char) változó 1. bitjébe bekerül az 1 érték, ha D4 pin == LO.
3. sor: ha D7 pin == LO -> A.1 = 1, az eddig A.1-ben levő bit pedig átvándorol A.2-be
4. sor: a két bit shift után D4 és D7 pin értéke A.2 és A.3 bitbe kerül
5-6. sor: az előző megszakításkor bekerült és a most bekerült bitek alapján csökkenti vagy növeli lepes értékét. Mivel megszakításonként 4 bitet tolódik "A" változó értéke, mindig csak az aktuális és az előző megszakításkor bekerült encoder állapotát tartalmazza a régebbiek meg szépen kicsorognak felül.

Szerintem a char típus 8 bites, előjeles szám! Ez mikor tud 136/144 értéket felvenni?
A 4. sorban nem a 2,3 bitekbe kerülnek az értékek, hanem 3,4-be! Az első shiftelés nem kellene oda...

Ok, kapsz egy számot, ami az előző állapot, és az aktuálisból származtatott! Ez alkalmasnak tűnik arra, hogy eldöntsük volt e forgatás, és az irányát is meghatározzuk.
De mitől jó ez a kissé nyakatekert algoritmus, amikor nem nyújt semmi prellmentesítést a forgatás során?! Ami ezeknél a mechanikus(már ha itt olyan van) enkódereknél életbevágóan fontos... Ráadásul, megszakításban kezelve még véletlenül sem marad ki egy prell sem forgatás közben! Csoda, ha egyáltalán ez így használható valamire is...max optikai enkóderekhez, ahol nincs prell....

Igen, unsigned char az A, ezt kifelejtettem. Amúgy az egyenlőségvizsgálat szerintem jól fog működni előjeles változóval is, mert a 136 és 144 konstansból 0x88 és 0x90 értéket fog a fordító csinálni.
A bitek számolását lehet hogy elrontottam, de a lényeget azért leírtam.
Mechanikus enkódereknél a prell némi kondenzátorral simán megszüntethető, ha meg nincs megszüntetve, akkor lesz némi ugrálás a lepes változóban. Ha ezt a változót csak bizonyos időnként olvassuk akkor kész a prellmentesítés.

Hát nem, mert ezek előjeles értelmezésben negatív számok már! És te pozitív számmal hasonlítanád össze! Sosem fog egyezni )

Kondenzátorral valóban elég jól csökkenthető ez az effektus..., ám az amúgy is gyatra kontaktusok élettartam szempontjából nem áldásos a szűrőkondenzátor rövidzár szerű kisütése forgatáskor....

Emlékeim szerint előfordulnak ezeknél mechanikus defektek is, amik miatt egyes pozíciókban nem ad megfelelő állapotot a kapcsolók állása! Itt csak logikai trükközésekkel oldható meg az, hogy ekkor se tévesszen se irányt, se számolást. Ez sincs kezelve itt....

Nem tudom, hogy mit kell ezen annyit agyalni. Kellett egy enkóder kezelő rutin, és mivel a megszakítás lábaim már foglaltak voltak, hát csak PCinterrupttal tudtam megoldani. Mivel az enkóder könyvtárak akkorák, hogy fele programmemóriát lefoglalják, így eldöntöttem, írok egyet ami gyors és egyszerű. Nem volt kedvem 2000 soros agymenéseken átrágni magamat. Nem vagyok én programozó. A terv az volt, hogy mire a rendelkezésemre álló 3 sör elfogy, arra legyek készen. A prellt kondival megoldottam, a rövidzárat a kondi felől meg egy ellenállással.



Kiolvassa egy adott bemeneti pin értékét. Ha magas akkor 0-át, ha alacsony akkor 1-et ad vissza. Kicsit gyorsabb, mint a digitalRead és pont a fordítottja.
A végén az if-ekben pedig a bájtot összehasonlítom. 136 helyett írhatok oda akár 0b10001000-át, vagy 0x88-at is, a fordító ugyanúgy befordítja és működik.
Lehet, hogy a kód nem jó, de viszont működik. A kérdező kérdezte, hogy mi fut a megszakításban. Erre én beillesztettem neki. Felesleges ezen vitázni. Mindenki úgy használja az enkódert, ahogy akarja.

Próbáljad ki. Nyomógomb hiányában zárjad össze egy alkatrész lábbal vagy egy grafit ceruzával a nanó 11-12 lábát.

...Talán azért, mert bizonyos kódok csak a csillagok együttállásakor működnek..., aztán meg van a csodálkozás, hogy mi lehet a rossz??! Más kódot meg nem láttunk tőled, így ezen agyaltunk egy sort....

Felesleges leírnod még egyszer ezt, benjami már megtette, mi akart az ott lenni!

Tehát, ez a kód, ami fagy, vagy újraindulást eredményez néha. A kód még közel sem kész, a hardver konfigurálásához használom (használnám) egyenlőre.

Szerk: ha a megszakítást nem tiltom le az LCD kezelése előtt, akkor az enkóder első kattanására befagy. A 13-as lábon lévő LED-et azért villogtatom, hogy lássa, van-e fagyás.

Szia!
Nálam ugyan ilyen céllal NANO és UNO alaplapok vannak. Mind a kettő bőven megfelel a célnak, de a MICRO alaplap is jó. (Lényegében bármelyik Arduino alaplap megfelelő lehet.) Ami bonyolítja a dolgot, hogy ezeknek az alaplapoknak a kimenetei max. 40 mA-rel terhelhetőek, ezért valamilyen kihajtásra szükséged lesz hozzá.
A "trükk" nem a panel kiválasztása, hanem a program megírása. Nem annyira bonyolult, ha van egy kis informatikai affinitása hozzá az embernek.

Próbáld ki ezt a kódot:


Kicsit korrektebb így! A kódoddal az a baj, hogy függ az előző forgatás irányától is, viszont nincs lekezelve benne a 4 állapotból 2. így irányváltáskor kimaradhat az első impulzuscsomag!

Első ránézésre passz....
Másodikra..., próbálj ki egy másik LCD kezelő könyvtárat...! Elvileg nem kéne, hogy a kettőnek köze legyen egymáshoz, de ahogy láttam, már másnak is volt hasonló baja ezzel a könyvtárral!

Kipróbáltam, de sajnos nem működik.

Kipróbáltam másik I2C-s LCD könyvtárral is, de azzal is ugyanez volt. Másik IDE-t is próbáltam.
Nekiállok bogarászni az LCD könyvtárait. Érdekes, hogy csak akkor fagy, ha rá van csatlakoztatva az LCD. Ha fizikailag nincsen rajta, de ugyanaz a "fagyós" program fut, akkor nem fagy.

Szia, erre a célra tényleg bármelyik arduino megfelel, akár a legkisebb atmega168-assal szerelt is. A nano azért jó, mert nem kell a programozásához más eszköz, csak egy USB kábel. Abból viszont általában miniUSB (nem ugyanaz mint a telefonoké), de egyik sem drága, a nano168 egy ezres (vagy nano328 1200) , a kábel (ha nincs a fiókban) 240. Plusz szállítás.

Ez így elég érdekes. Biztosan jó a kijelző, jók a frekvenciák és a feszültségek? Mintha a kijelző bukdácsolna. Esetleg nem túl nagy az áramfelvétel a táp számára?

Valószínű, hogy az i2c kommunikáció kiesik a szinkronból valami miatt, és vár egy visszaigazolást, ami sosem érkezik meg. Timeout meg nincs benne, feltehetően....

Másik arduino panellel is kipróbáltad?

Ez érdekes. Ki nem próbáltam, de elvileg működnie kellene...

Sajnos az I2C-hez annyit értek, mint a harangöntéshez. Hagyományos, 4-bites módban használtam már karakteres LCD-t és PCinterruptot egyszerre. Ott semmi gond nem volt. Arra tudok gondolni, hogy a hagyományos LCD kezelésnél az MCU nem vár visszaigazolást az LCD-től a művelet befejezésére. Hanem várakozik kicsit. Ezért is lassabb az I2C-nél. Szerintem az I2C-s LCD kezelése addig, amíg a művelet be nem fejeződik, addig valahogy várakoztatja az MCU-t. Talán mint az analogRead() függvény. Amíg nincsen készen a mérés, addig egy while ciklusban pihentet. Könnyen lehet, hogy míg az MCU vár az LCD felől a visszaigazolásra, akkor közbeszól a megszakítás és ha a megszakításkor jön valami az I2C-n, azt nem veszi figyelembe.
Próbáltam másik MCU-val, ellenőriztem a tápot, a szűrést, puffert, áramokat. próbáltam másik LCD-vel.

Mellékelnéd a teljes LiquidCrystal_I2C libraryt, amit használsz?

Ezt használom.