Egy Arduino szerintem sosem fagy le, csak a benne futó program lehet hibás.

Az arduinó eléggé korlátos ilyen felhasználásra. Ha szoftver debuggot akarsz, akkor az AVR stúdió egy hasznos fejlesztő környezet. Nincs annyi példaprogram (bár mintha aza arduinós forrásokat is be lehetne alá pakolni) , cserébe viszont lépésenként tudod ellenőrizni a programod állapotát. Arduinón szerintem marad a programod részekre bontása, ellenőrzése. A Serialprint() pedig jól megválasztott változók jól megválasztott helyen kiíratásával tud sokat segíteni (ha az adott lábak szabadok).

Majdnem. Nagyjából egyet értek, de azzal kiegészítve, hogy nem mindegy hova írod ki az eepromba. Én úgy csinálnám, hogy a tömböt kíírnám az aktuális helyre (pl. 0. pozícióba), a következő helyre pedig (egy tömbnyivel odébb) egy üres tömböt (0xff-fel töltve). Legközelebb megkeresném az elejéről számolva ez első helyet ahol 0xff értékű üres tömb van, tehát az élő adatok egy tömbnyivel visszább vannak. Legközelebb amikor menteni kell, akkor az aktuális pozíciót követő üres helyre írnám be, és megint egy üreset a végére. Így mindig a friss adatokat tudod olvasni, nem kell összehasonlítgatni az eltárolt adatokkal az újakat, és nem fárad el a cella, mert mindig másikba írod. Amikor átfordul akkor kezded elölről. Így örök élet.

Nekem sem a kedvencem az arduino-s programozás (AVR-t eddig inkább bascom-ban piszkálgattam), de sajnos csak ezzel találtam megoldást amivel el tudok indulni. Ahogy időm engedi megpróbálom átírni a jelenlegi kódot, a loopban csak a nyomógombok figyelése és az lcd kezelése maradna, a többit átrakom subrutinokba, ha ez működik akkor megyek tovább az eeprom tárolás irányába.

Mi volt az előző képernyő? Lehet, hogy ebben nem ST7687 van, csak valami kompatibilis ami gagyibb.

Az Atmega 328-nak van 1kB adat EEPROM-ja. Ebbe gondolom bőven több belefér az 5db beállított csatornához szükséges információ. Én a nyomógombokkal beállítható dolgokat úgy szoktam EEPROM-ba eltárolni, hogy csak akkor tárolom el, ha már legalább 5 másodperce nem történt semmilyen gombnyomkodás (ha belefér az a hiányosság, hogy nem történik mentés abban az esetben, ha a nyomkodás után egyből kikapcsolod a készüléket). A másik dolog, hogy csak azokat a bájtokat érdemes átírni, amik megváltoztak. Erre kell csinálni olyan EEPROM író függvényt ami először kiolvassa az aktuálisan EEPROM-ban található adatot és csak akkor írja ha ez eltér a beleírni kívánttól. A sargarigo által javasolt mindig máshova írás szerintem inkább akkor célszerű, ha rendszeres időközönként el kell menteni valami mért adatot (pl. hőmérsékletet).

Megoldás lehet az EERAM használata, vagy megszakítást indítani kikapcsoláskor és azonnal menteni azt a pár változót. Utóbbihoz kell egy nagyobb kondenzátor a táplábakon.

Persze lehet tovább ragozni, de már az általam leírt módon megoldva is hamarabb kopik el a kezelőszervek nyomógombja, encodere, az ujjunk hegye, stb., mint ahogy a belső EEPROM elfárad.

Köszönöm!
Egy Ilyen starter kitt jó lehet tanulni meg próbálgatni?
Bővebben: Link

Ez több mint elég!!!

Akkor jó
Bármit képes vagyok elrontani, elhagyni Inkább több legyen.

Egy érdekes hibára lettem figyelmes.

Az programban egy ilyen sor kellett:

Y= K*2000/X

Ahol
K =(1-60)
X=(-99).
Nos a fenti formában az eredmény csak K=1-töl 16-ig stimmelt.
Ha megforditottam a sorrendet:

Y=2000/X * K

Akkor minden rendbe jött.
Valamennyi változo sima egész szám ( int)

Szia!

Szerintem ( bár nem használom) az int az 16 bites előjeles, ami azt jelenti, hogy -32768...0...32768-ig lehetnek benne a számok. Ha 2000-et megszorzol 17-el, akkor átbillen és negatívnak fog látszani... !

Ez valoban igy van, ezek szerint számit a sorrend is. . ( a long int nem segitett).

Így sem jó?

Nem probáltam, de a long int Y nem segitett.

Az nem is fog segíteni, mert az a végeredményre vonatkozik nem a közbenső számításokra. Amúgy gondolom 8 bites prociról van szó, mert ott 16 bites az int (32 bitesen 32 bit az int is, én ezért jobban szeretem használni az int8_t, int16_t, int32_t változó típusokat, mert egyértelműbben meghatározza a változó méretét).

Majd még utánnanézek, de a probléma a sorrend változásával megoldodott.

Azért több lesz a kerekítésekből eredő hiba, ha előbb osztasz és utána szorzol.

A zárójel használatát legjobb mihamarabb megszokni matematika müveleteknél és feltétel vizsgálatoknál úgyszintén. Mivel csak a program író tudhatja hogy mit szeretne kiszámoltatni maga a fordító ezt nem tudhatja és ha nincs világosan feltüntetve (zárójelezve) akkor a fordító fogja megoldani (nagy valószínüséggel nem úgy ahogy Te szeretnéd).Ilyen müveleteknél van egy elsöbbségi sorrend hogy melyik müveletet hajtja végre elöbb és balról jobbra halad és ilyen meglepetések érhetnek. Ugyszintén elöfordulhat változó túlcsordulás ha pl. az Y változód nem megfelelö méretüre lett deklarálva.Tehát ez szerintem nem a fordító hibája.

Itt egy kis iromány az elsöbbségekröl, és itt egy "arduinós" .

Azt kiprobáltam, de nem segitett, pl Y = K*(2000/X) ugyanazt a hibát adta. Elvben az adott számtartományokban mindenütt bele kellett volna férnem az int tartományba, kizárolag a K*2000 eredménye lehetett több, amit viszont azonnal le kellett volna osztani X= (5-99) számmal.
Azaz kizárolag a sorrend segitett Y=(2000/X)*K zárojellel vagy anélkül.
( az Y változo méretezése sem segitett - azt viszont nem tudom miért hiszen a legnagyobb értéke az adott tartományokban 10000 alatt van.)

Ezt írd a 2000 helyett: (signed long)2000
A hibás sor is működőképes lesz.

Hasonló hibával találkoztam már én is. Én ezt egyszerűen úgí oldom meg, hogy két vagy több lépésben számolok:

Y=2000/X
Y=Y*K

Ezt úgy írják egyszerűen, hogy 2000L.

Köszönöm mindannyiatoknak. Nekem is sikerült megoldani a gondot, szamomra csak az vikt meglepetés, hogy még ilyesmivel nem futottam az Arduino IDE-n össze.
A minap a fiam matek dolgozatánál is volt egy hasonlo gond ( ott is megakadtunk, mert egy képlet nem adta azt az eredményt, amit vártunk - csak ott nem volt lehetöség ilyen büvészkedésre - a program iroja valoszinü nem számolt ilyesmivel. Más számokat beadva a képlet jol müködött) .
Lehet, hogy ez a C++ nyelv specialitása?

Milyen program, milyen feladat? C vagy nem C, oda kell figyelni, hogy a műveletek végrehajtásakor milyen oldalági mellékhatások léphetnek fel. Sajnos előfordulnak ilyen dolgok, én is számtalanszor vakartam már a fejem ilyenek miatt.

Azt nem tudni, egy komolyabb feladat - matek érettségi tételek közül ( valoszinü korábbi ) Ök csak a feladatot kapják meg elektronikus formában, azon dolgoztak lépésröl lépésre, amikor eljutottak egy képlethez, ami már nekem gyanus volt, mert a 4 változo a képletbe egészen vad mératáronyokban került (cm/s, liter, ora stb - már nem igen emlékszem), és a képlet ezt figyelembe vette, azaz csak a helyes méretarányokban lehetett bevinni az adatokat. ( és azt rontották el két oldallal korábban). Nagyon utáltam mindig az olyan feladatokat ahol minden mértékegység keveredett. (Azaz a képletbe ha beirtam valos számokat az eredmény rossz lett). Ebben a példában meg pontosan ez volt kihivás, és ahelyett, hogy rávezették volna a tanulot, hogy elöbb alakitsa át mindenféle tarka barka adatot valamilyen célravezetö egységes (SI) formára, itt a végeredményig minden a maga vad méretegységében futott és csak az utolso sorban alakitotta át képlet valamilyen SI méretre. Ebböl kifolyolag a sok egyenlet a példában igen kacifántos volt.

Igen. Csak azt nem tudom, hogy típus konverzió ténylegesen végrehajtódik-e, vagy esetleg a fordító kihagyja. Ki kell próbálni.

"ez a C++ nyelv specialitása? " - igen, van jó oldala is (kisebb a kód, feleslegesen nem foglalnak a konstansok nagy helyet), meg rossz is (honnan is tudná a fordító, hogy a 2000, ami int-be belefér, később már csak long-ba fér bele?). De ha ASM-ben programoztál, szerintem ott is előjött hasonló probléma. Idővel rájön az ember.
Én is úgy jöttem rá, hogy rosszul számolt a függvényem. Ekkor szépen kiírattam soros porton minden műveletet, és számológéppel ellenőriztem. Volt fejvakarás nálam is, pár órát elvett.