Tisztelt Fórumozók!

Van egy gondom az Arduino-val és egy NRF24L01-es modullal. A modul megszakításon keresztül ugrasztja az Arduino-t, ha vétel van. Vesz, elvégzi a feladatokat és minden rendben is van. De ha a kapcsolat messziről épül föl és közben megszakad a nagy távolság miatt, többé nem kapok megszakítást a modultól, noha a másik oldalon adásokat küld az ellen-állomás.
Innentől kezdve nem tudom vételre bírni, csak resettel. A program nem fagy le, nem ragadok végtelen ciklusba sem. Egyszerűen nem küld megszakítást a rádiós modul és a radio.available() sem teljesül.

Sziasztok! Tegnapról mára megállt az Arduino Ide-m? Inicializálásnál megáll. Letöröltem. Az "AppData\Local"-ból is is a dolgokat, a Dokumentumokban az Arduino könyvtárat átneveztem, újraraktam. Most már elindul néha, de nem tudok telepíteni semmit, Java.Lang.NullPointerException...

A probléma létezik. De az ajánlott megoldásod nem jó.
A linkelt oldal magyarázata is félrevezető mer a túl csordulást -érték (mínusz) ként kezeli.

meghatározás szerint: unsigned = pozitív egész szám.
Ez túl csorduláskor is pozitív egész érték marad, viszont az előző nagy értékből jóval kisebb értéket kapunk. Ha meg akarjuk oldani ezt a problémát akkor ezt a változást kell figyelnünk.

Mivel ez idő egység! Az időben pedig vissza menni nem tudunk, egyfolytában csak öregebbek leszünk. Ezért a jelenlegi idő - X idő problémával értelmetlen foglalkozni.

Közben megjavult. Nem értem

Igen, előjel nélküli tehát nem lehet negatív,hol kezelik negatív előjelesként? Nem a túlcsordulást érzékeljük vele (nem lessz tudomásunk róla hogy az unsigned long vagyis uint32 túlcsordult csupán nem akad meg az if feltételt vizsgáló kódrészletünk), próbáltam. Az alábbi részlet Gammon oldaláról kölcsönöztem:


Próbáld ki, ugorjunk az idöben állítsuk be a millis-t túlcsordulás elötti állaptoba. Ha feltöltöd az alábbi programot a terminálban látni fogod hogy megjelenik a "-" és a "+" is mivel mind a kettő feltétel teljesül (fel lehet cserélni a sorrendet a feltételvizsgálatnál) mivel nincs ami megakassza a programot és túlcsordulás előtt oda tud ugrani a feltételvizsgálathoz. De ha kiveszed kommentből az 1ms -os delayt (a programunk épp mást csinál amikor bekövetkezik a túlcsordulás) akkor már az összeadásos feltétel nem fog teljesülni, tehát a terminálban is csak a "-" fog láttszódni

Ha a reset segít, akkor watchdog lehet a barátod! Ez azt csinálja, hogy egy számlálót futtat, amit a szoftvered rendszeresen töröl. Ha valamiért mégsem tette meg, akkor a számláló túlfut, és dob egy resetet az áramkörnek.
Akár így, vagy akár átdolgozva a módszert neked is használhat!
Szerk.: Most olvasom jobban, neked az NRF modulod "fagy le"? Esetleg bizonyos idő elteltével pollingra váltani nem lehet? Legalább annyira hogy kiderüljön volt-e vétel.

Igazad van. Az "utolso" a bekapcsolás pillanatában 0, a "millis()" is. 0-ból 0 az 0. Nem okoz gondot.
Jó, hogy írtad, először félrenéztem a változókat.

Egy esetet kell még átgondolni:
Az "utolso" legyen a túlcsordulás előtti szám (maximális unsigned long szám-1), a millis legyen mondjuk 10. Ekkor 10-"max. uns. long-1"-et kell kiszámolni.

Leírok néhány példát, mindhárom szám unsigned long:
10-10=0
10-11=maximális unsigned long szám-1
10- "maximális unsigned long szám-1"=11
Jól számoltam? Szerintem igen.

Köszi, hogy megosztottad! Át fogok erre térni.
Azért negatívot nem érdemelt a hozzászólásod...

Biztos vagy benne, hogy nem küld és nem az Adruino szoftver nem keezel valamit? Ellenőrizted a kommunikációs vonalakat szkóppal, logikai analizátorral?

Szívesen, sajnálom ha beszólásnak tünt, nehezen fogalmazok, fórumon rosszul néz ki, visszaolvastam
, Itt egy nagyon hasznos számológép (tud valaki hasonlót linuxra?), beállíthatod hogy 32bites számokkal számolj és hogy előjeles vagy nem előjeles számokkal dolgozz.

Ez csak nyakatekert bele erőszakolása a - (mínusz) jelzésnek a feladatba.
Miközben annak semmi helye itten.
Az egész feladat megoldható az értékek kisebb illetve nagyobb figyelésével.

char, int, long 8, 16 illetve 32 bites egész változók
unsigned - típusmódosító: előjel nélküli számot jelöl)
boolean - logikai változó, ami elvileg 1 biten is elférne, de a bájt szervezésű memóriában muszáj neki egy bájtot fenntartani.

unsigned long nowTime, redTime, greenTime;
Három előjel nélküli 32 bites változónak foglalunk helyet

boolean rState=LOW, gState=LOW;
Két logikai változónak foglalunk helyet a LED-ek állapotának nyilvántartására.


A pillanatnyi időponthoz képesti eltolással adjuk meg, hogy mikor változzon a piros, illetve a zöld LED állapota.

Ez a vita értelmetlen, részemről inkább itt a helyes megoldás:


Figyelmébe ajánlom a probléma felvetőjének.

Az a '-' nem egy jelzés, az egy matematikai müvelet (kivonás), a másik amelyiknél fennáll a hiba lehetösége az pedig a '+' (összeadás).

A módszered csak jelzi a hibát.
Az enyém viszont megszünteti!

Melyik a jobb?

Egyszerüsíteni akarod pedig ez még komplikáltabb, 2 darab if et használsz. Itt Te is a kivonást ajánlod.

Épp hogy nem jelez, nem veszed észre a túlcsordulást

A 15:07-es linken levő válasz nem a millis túl csordulásáról szól.

Nem észrevenni kellene, hanem kiküszöbölni a millis túl csordulás általa okozott hibát!
Mivel ez nálam ki lett küszöbölve, már felesleges jelzésével foglalkozni.

Elbeszélünk egymás mellett, a válaszom erre a hozzászólásodra vonatkozik amikor is állítod hogy a , és erre írtam hogy (hejj így azért írkálva mégsem olyan egyszerü). A millis túlcsordulást én hoztam fel, nem volt téma és azt is csak azért hogy ha így szokunk hozzá az időzítés használatához akkor megeshet (kicsi a valószínüsége DE megeshet, ezt feltételes módban mondtam már az elsö hsz. ban is) hogy gond lessz a progiban. Mondjuk a kazánvezérlőnk 100 ms intervallummal beolvassa a hömérsékletet, ha balszerencsések vagyunk akkor tulcsordulás után ha nem olvassa be majdnem 50 napig a hömérsékletet akkor abból elég nagy gáz lehet, de hagyjuk. A millis idözítés használata amit Te és Kovidivi ajánlott az a helyes, én csak erre szerettem volna felhívni a figyelmet, mivel szinte semmivel sem komplikáltabb kivonást használni feltétel vizsgálatkor mint összeadást és ha ezzel ki lehet küszöbölni a lehetséges problémát akkor jobb úgy megszokni a használatát.

Próbáld ki így,

a setMillis csak azért kell hogy be állítjuk a millis-t túlcsordulás - 500 ms értékre, a delay pedig ha a progi valmi mással van elfoglalva akkor már a dupla if-ed sem fog segíteni. Ismét, kicsi az esélye de a hiba lehetösége fenn áll.

Így van, a te megoldásod kihasználja az unsigned long lehetőségeit, és plusz if-ek nélkül tökéletesen műkődik a túlcsordulás környékén is. Mindenféle plusz bonyolítás felesleges, csak plusz tárhely, prociidő és hibalehetőség.

Szkóppal nem ellenőriztem, de számlálom a megszakításokat. Ha kívülről ráerőltetek egy megszakítást arra a lábra, ahová a rádiónak kellene, akkor az lefut, de nem történik meg a vétel abban az esetben sem.
Ilyen, megszakadt kapcsolat esetén újra futtatom a rádió inicializálását, akkor újra működik. (14-19 sor).
Most még megpróbálok ráfeküdni a CE lábra, hátha a rádió valamiért nincsen engedélyezve ilyenkor.

Sziasztok!

Gondoltam megirom, hogy töltödött végül fel a progi. Rendeltem a HE store-bol egy FTDI-s illesztot, es egy uj ESP modult is. Ez a kombinacio elsore mukodott. Majd betettem az uj usb uart illesztobe a regi ESP-t, es az is mukodik. A CH 340G-s illesztokkel nem megy a programozas. A feltoltott programot meg nem probaltam ki, ahhoz meg hardver kell, de az ESP modulokra felment a progi. Az erdekes az, hogy a CH340G-vel is ment a kommunikacio, es az AT parancsok, csak programozasi modba nem volt jó, hiaba latszodott a rajta levo leden, hogy kuldi kifele az infot.

Szeretnek mindenkinek koszonetet mondani a segitsegert!

Sziasztok!

A túlcsordulást akarjátok detektálni? Mert azt lehet szerintem.

Nem, nem akarjuk detektálni.

Én is csináltam ezzel a csippel egy rádiós hőmérőt, és nekem is furán működött. Mivel breadboardon volt összerakva a mérő és az ablakpárkányon még eső is esett rá, a vevő pedig simán Arduino Uno-ra volt drótozva és USB-n lógott, ezért én kontakthibára gyanakodtam. Többször is néhány nap után újra kellett indítanom, hogy elkezdjen adni/venni annak ellenére, hogy látszólag minden oké volt.

Az én programom az adatlan alapján saját megvalósítással kommunikált és pollozta a csipet. Tehát ha közös módosú a hiba, akkor nem az IRQ küldés a probléma, hanem a vevő logika akad be valahol.

Egy hardver tervező ismerősömtől egyébként ezt a bölcsességet tanultam: mindig úgy kell mindent megtervezni, hogy a vezérlőnk ne csak soft resetet tudjon adni, hanem teljes tápelvételt is tudjon csinálni. Pont valami rádiós modullal szívtak, és ott lett végül az az egyetlen megoldás (inkább workaround), hogy időnként hard reszetelték a modult. A sima szoft reset nem volt elég

Nekem nyákon van a készülék, nem ázik. Igaz, a modul tüskesor aljzatba van bedugva.
Sajnos, nem ismerem kellően ezt a modult, itt a gond. Talán túlcsordul a vevő buffer és ezért nem küld megszakítást, vagy valami hasonló probléma lehet.

Nekem is meghalt az IDE-m!
Csomagok inicializálása ... és puff, kilép.

Windows 10 ...

Ok, köszi!

Akkor nem értem pontosan mit is szeretnétek. Azért leírom a gondolatimat, ha nem baj. A millis() egy Timer-en van. Az Arduino is csak egy uc, szóval van neki egy olyan opciója, hogy ugyan a Timer túlcsordulását nem tárolja a regiszterben, de egy interruptot ad. Erre az interruptra rá lehet aggatni egy függvényt, amiben egy változót pl. 1 re állít az ember. A fő programban ezt a változót figyelni kell. Ha 0, akkor minden megy ahogy kell. Ha 1 akkor az eltelt idő a korábbi millis és a túlcsordulásig kellő érték, plusz a jelenlegi érték. Utána persze ezt a változót 0-ra vissza kell állítani. Ez a változó volatile byte.

Csak leírom, mert hátha valakinek ötletet ad a későbbiekben.

Voltak hibák abban a libben, nem tudom most hol tart.
Egy kis ötletadó.