Azért érdemes lenne megnézni a bootloader működését, hogy milyen feltételek kellenek ahhoz, hogy bekapcsoláskor vagy resetkor töröljön valami területet a programmemóriában. Nem kizárt hogy a bekapcsolási tranzienskor össze tud ez jönni.

Én is ugyanolyan tápokat használok mint a te ujabb verziod ( jobb oldali kép).

Pusztán a flash írni, zavarok miatt elég valószínűtlen dolog! Sokkal nagyobb eséllyel kóvályoghat el a program oda, ahol már "hivatalból" történik flash írás!
Egy biztos: ha reset, és tápelvétel után nem gyógyul, akkor bizony megsérült a flash tartalma!

Megoldás lehet ilyen helyzetekre, ha a bootloadert kidobjuk. Ekkor nem lesz a kódban olyan hely, ahonnan lehetne eséllyel felülírni a flasht...

Ez csak elviekben lehetséges, gyakorlatilag az írás feltétele, hogy meglegyen a törlés. Az írást végző függvény nem hajtódik végre e nélkül. Ez egy ellenőrző biten keresztül történik. Ezzel megint oda lyukadunk ki, hogy túl sok együttállásra van szükség, hogy bekövetkezhessen a program memória felülírása.

Kizártnak tartom, hogy a bootloader felül tudná véletlenül írni a program memóriát. Túl sok feltételnek kell egyidejűleg teljesülnie ehhez, aminek a véletlen bekövetkezése szinte lehetetlen.

De itt hibás működésről van szó. Simán lehet, hogy többször beesik és túlfut a tápfeszültség egymás után többször, rövid idő alatt. Na, olyankor megjósolhatatlan, mit fog tenni az MCU. Ezért érdemes használni a beépített BOD-t. Mondjuk én kazán esetén raknék rá egy megfelelően stabil és hibatűrő voltage supervisor IC-t is.

Addig, amíg flasht (hivatalból)írni tudó rutin van a kódba, az esély arra, hogy odatéved a program, nagyságrendekkel nagyobb, mint ha az nem lenne benne, így a veszélye is annyival nagyobb, hogy valamit átír!

Nem állítom 100%, hogy ennél is így van, de más mikrovezérlőknél simán írható, törléstől függetlenül is egy bit 1-ből 0-ba! Ennek semmi köze nincs ahhoz, hogy előtte volt e törölve vagy sem, amíg 1-es a bit, írható, ha már 0-ban van, az csak törléssel tehető 1-be...

Emberek honnan ez a hitetlenség a ma modern kapcsitápokkal szemben? Azok nagyságrenddel stabilabbak mint amit régebben használtunk, és kizárt dolog, hogy egy kapcsitáp tullöjjön a beállitott feszültségen. Amiket használok extra védelem van a tulfeszültségre meg az áramra.
Szoval onnan biztos nem jön olyasmi ami zavarna. Az elöfordulhat, hogy olyankor szünik meg az áram, amikor a proci éppen valamit büvészkedik, sajnos ezt viszont elég nehéz kezelni, és a táp megszünése eddig soha nem okozott gondot egyetlen berendezésnél sem amit eddig épitettem ( és az nem kevés).
Szoval egy kicsit érthetetlen a dolog mi is történhetett, mitöl akadt meg a program.

A zavar, a zaj a kimeneten nem függvénye annak, hogy átlagfeszültség, amit mérsz a multival, század Voltra pontosan 12.00V, vagy hogy van áramkorlát. A zaj a DC feszültségre rárakódott AC komponens. És igen, az olcsó kínai tápok zajszűrése lehetséges, hogy alig ér valamit.

Azt hiszed nincs szkopom?
Hogyan zavarhat egy nagyfrekis majdnem nègyszögjel egy graetzhidon és kondikon?.
Azért a spanyol viaszt már régen feltalátlák. Pontosan kapcsitáp fö elönye a régi tápokkal szemben, hogy duplán választja le a és szüri a szekundert a hálozattol. Azaz a hálozati zavarokbol szinte kizárt, hogy valami átjusson egy ilyen áramkörön.

Azért ezzel a nagy bizakodással óvatosan, lehet a te problémádnak nem ez az oka, de ha zavarmentes tápot szeretnék, még mindig a transzformátorban bízom inkább. A mai tápok egy részéből szinte mindent kispórolnak, a kondenzátorok élettartama igen záros ( es ki mondta, hogy 1 perc alatt veszítik el a kapacitásukat.) A bemenet meg a kimenet közötti Y kondenzátorral sincs sok jó tapasztalatom. Persze nagy teljesítmény kis súly, nagyon előnyös ki ne szeretné.

Köszönöm! Valóban egy kicsit "Ágyúval verébre" esetnek tűnik. A terv, hogy érzékelők indítják és állítják le a fénysorompót és peronvilágítást is vezérelnének.
Akkor így, ha jól értem a delay() és a while() egyformán leállítja a programot.

Nem tudom, nekem abszolut nincsenek rossz tapasztalataim kapcsitápokkal. Elöfordult, hogy egyik másik kinyult, a korábban használt német toroidokkal sokkal többet szivtam. 10-böl 2-3 halt meg, valoszinü a beépitett termosztat, de az a két tekercs között volt, igy javithatatlan. Gyakran 3-4szer többe került, mint egy hasonlo teljesitményü kapcsitáp.
Egyszer kaptam egy ládával a neves kék-sárga butoráruház termékeiböl, mert azokat a kisugárzott zavarszint miatt nem lehetett beépiteni ( valami egészségügyi központba szánták) , igy a villanyszerelö haver odaadta az összeset. Egyetlen egy sem ment eddig tönkre ( de én is csak itt ott használom, és csak fémdobozos szerkezetekbe épitek ilyet, mert nagyon zavarnak, de a kimenet teljesen sima és megbizhato. Azota van egy AM rádio is a mühelyben, ha zavar a kapcsitáp, egyböl hallom és akkor megy vissza a fiokba vagy elosztogatom a fiam barátainak.

Úgy fogalmaznék, hogy megakasztja. Márpedig a loop-nak az az értelme, hogy gyorsan "pörögjön", hogy az eseményekre, pl. egy bemenet állapotváltozása, minél rövidebb idő alatt tudjon reagálni. Ha a kódodban elhelyezel egy loop elejére egy soros monitorra való írást, akkor látni fogod, hogy az megvárja a villogást és annak ütemében kerül kiírásra.

Ebben az esetben valóban nem lesz jó, mert kezelni kell az érzékelőket is. Ami neked jó lehet, az az időzítő megszakítása:



A kódot nem én írtam, csak idemásoltam Forrás

Enkóder kezeléssel kísérletezek. Van-e arra valamilyen egyszerű algoritmus, amivel a dupla lépéses és a szimpla lépéses enkódert felismerheti ill. megkülönböztetheti a program?

Egyelőre azzal próbálkoztam, hogy dupla lépésesként kezeli a szoftver, de ha olyan állapotban áll hosszabb ideig az enkóder, ahol a dupla lépéses nem állhatna, akkor átvált szimpla lépésesre. Ez működik is, de tudom szándékosan úgy tekerni a dupla lépéses enkódert, hogy a program szimpla lépésesnek vegye.

Először azt kéne tisztázni, hogy milyen enkóderről beszélünk. Relatív, abszolult, lineáris, rotary, digitális vagy analóg.
Én úgy tudom, hogy az enkóderek nem képesek fizikailag átkofigurálni magukat és megváltoztatni az elmozduláshoz képest az impulzusok számát. Ha tiéd ilyen, azért lenne jó tudni, hogy milyen típusról beszélsz.
Amennyiben feltételezzük, hogy a hobbisták körében általánosan használt 2 fázísú rotary enkóderről van szó, azzal kapcsolatban az szokott előfordulni a gyengébb minőségű példányoknál, hogy el van tolódva a 2 fázis, azaz nem egyenlő időközönként vannak a váltások, így a kezelő szoftver gyors mozgásnál már nem veszi észre a másik jel változását. Illetve már belefutottam a megnövekedett prell problémájába is. Ezt egy nagyon egyszerű programmal vizsgáltam és eléggé lesújtó eredményt kaptam egyes példányoknál.
Próbáld ki ezt a programot és a soros plottert kapcsold be, ne a soros monitort A loop üresen marad. Ezzel meg tudod nézni, hogy milyen minőségű a rotary enkóder.

Mechanikus enkódernél nem is szabad arra építeni, hogy tiszta jeled lesz! Ez még vadi új korában sem feltétlen jellemző ezeknél, használat közben egészen biztosan bezajosodik!
Én pl egész hosszú, 64-es átlagolást használok a két csatornán, s csak utána döntöm el, volt e változás érdemben...

Én kissé indokolatlannak tartom a jelfeldolgozást ezeknél az eszközöknél, mivel nem számít, hogy mennyire pontos. Pl., hogy 1 fordulatra 24, 20 vagy 28 impulzust ad, teljesen mindegy. Tekergeted és látod, hogy mennyit változik az érték. Ahol számít a precizitás, oda meg nem ilyet kell rakni.

Én is találkozok ilyen enkóderekkel. 2 féle szoftver kell, mert az egyik ilyen, a másik olyan. A HEStore-ban is van mindegyikből. Valahogy így jelölik ott őket:
-15imp/30pos
-24imp/24pos.
Tehát nem arról van szó, hogy selejtbe futottunk bele.

Szerintem senkit se biztassunk arra, hogy interrupt handlerben a soros porton adatot küldjön. Ha gyorsan követik egymást a megszakítást okozó események, akkor akár többnek a detektálásáról is lemarad a szoftver. Egy ISR legyen a lehető legrövidebb.

A pontossága számszerileg talán tényleg nem minden esetben fontos, de pl az iránya igen!
Mondjuk én azért annak sem örülnék, ha egy lépés helyett kettőt, vagy n-et lépne, amikor én csak 1-et szeretnék...
Mindenképpen kell az átlagolás, vagy szoftveresen, vagy hardveresen(mondjuk kondikkal megfelelően támogatva)

Általánosan használt 2 fázísú rotary enkóderről van szó. Nem az a probléma, hogy ne működne a programom - mert tulajdonképpen jól működik, csak ahogy mateatek írta, a fix poziciók száma és az impulzusok száma lehet egyező vagy fele annyi, az enkóder tipusától függően.
A programban viszont mindíg a mechanikus pozícióknak megfelelően kell lépni. Mondjuk menüben beállíthatóvá lehetne tenni, az enkóder típusát (van ahol így oldják meg), de elegánsabb megoldás lenne ha automatikusan felismerné a szoftver.

Jelen esetben külső felhúzó ellenálllások + RC szűrő lenne a hardveres megoldás (ez talán hosszabb vezetékezést is lehetővé tesz), vagy minden külső hardvert mellőzve, a belső felhúzó-ellenállásokat aktiválva csak az enkódert kellene bekötni, de akkor a szoftver lesz némiképp bonyolultabb (nagyobb lesz és több lesz az erőforrásigénye).
Jelenleg szoftveresen oldottam meg, de elgondolkoztam, hogy néhány passziv alkatrész megspórolása tényleg megéri-e, a szoftveres trükközést...

Talán úgy lehetne ezt programban megcsinálni, hogy bekapcsoláskor, benyomott enkóder gomb mellett a program kéri, hogy kattintsál valamelyik irányban pl. 6-ot. Ebből a program bármely típusú szoftverrel, bármely enkóderrel tudni fogja, hogy mi a helyzet és úgy módosít, ha kell.

Nem biztattam senkit semmire. Melyik rész az amiből ezt írod?

1-1 kondenzátor sokat segíthet, szerintem érdemesebb azt választani, mint szoftveresen "bajlódni" vele, de természetesen számít, hogy milyen alkalmazásban van használva, hogy mennyi idő marad másra. De ez is lehet ízlés kérdése, mindenki úgy csinálja, ahogyan működik neki

Így már értem, hogy mire gondolsz. Egy ilyen automatikus felismerést megnéznék, mivel nincs semmilyen információ arról, hogy milyen sebességgel forgattad az enkódert. Talán tapasztalati úton lehetne egy intervallumot meghatározni, mivel általában nagyjából egy adott sebességgel forgatjuk az enkódereket, legalábbis legelőször, amíg nem látunk érték változást. Ez mérhető mind a 2 enkóder esetében és ebből már lehetne következtetni, hogy melyik milyen. Ki kéne próbálni. Most úgyis tervben van egy 8 enkóderes projekt midi kezelőhöz, ott lehet kipróbálom, főleg ha nem sikerül 8 egyforma enkódert venni

Az encoder2 és az encoder3 nevű függvényed egy-egy megszakításkezelő függvény. A lehető legkevesebb, és leggyorsabban végrehajtható kódot szabad csak beletenni. A Serial.print viszont elég költséges hívás, hosszan blokkolja a processzor normál működését. A megszakításkezelőben csak egy változót kellene írni, és a loop függvényben figyelni, mikor változik az értéke, és onnan végezni a soros portra írást.