Ez a 100000 EEPROM írási/törlési ciklus külön minden egyes bájtra / bitre / elemi tároló cellára külön külön vonatkozik vagy a teljes területre.
Esetleg lehetne "fregmentálással" szétszórni az adatokat hogy ne csak egy kis tár terület kopjon. Habár lehet ez az EEPROM védő algoritmus teljesen lefoglalná a uC amúgy is szűkös program FLASH területét .
Mondjuk az első pár bájtot beáldozni amolyan "üzemóra számláló" irási/törlési ciklus tárolónak és
annak függvényében mindig más más EEPROM terület részre allokálni a mentendő bájtokat.
Igaz ez némi "FAT szerű" táblázatot eredményez az EEPROM területén és az kopna el leghamarabb.

Esetlegesen használhatsz 24C02, 24C04, stb EEPROM-ot. 1000000 írás ciklust bírnak, tehát tízszerese a 328-ban lévőnek. I2C buszon keresztül használhatod. Filléres dolog, de rengeteg mindenből tudsz kitermelni, ha éppen nem vagy bolt közelben. Monitoron keresztül az SDRAM modulig sok kidobott cuccban van.

Ez a projekt abból épült amit itthon találtam! Semmit nem akarok hozzá venni, tenni (ez megdőlt az SSR-nél, mert ami itthon volt, az 20V-ot akart, de az nem volt a Nano kimenetén )!
Ráadásul így könnyen után építhető. Találtam sok projektet, de mindegyikkel az volt a bajom, hogy vagy nokia kijelző kellett, vagy magának építette az SSR-t (bár ez utóbbi még foglalkoztat, benne rejlik a teljesítmény szabályozás lehetősége, de mivel igazából most kezdek az arduinoval, egyszerűbb a nullátmenetes SSR-t készen megvenni, lesz ami lesz alapon), vagy nyákot kellett hozzá készíteni, mert csak a procit használta az arduino-ból, I2C átalakítót rakott a kijelzőre (ezt mondjuk gyorsan lehetett orvosolni) és így tovább. Szóval ez ilyen 5 percesen után építhető most, tényleg minimális alkatrészből. Azért a 100e írás sokáig elég kell legyen, pár száz után már ránézésre lehet tudni az első hegesztés után, hogy mit állítson az ember szerintem. Gondolom, amíg egy szalag el nem fogy, kb. ugyan azzal a beállítással végig lehet dolgozni. Töröm az agyam, hogy el lehessen tárolni többet, és akkor még kevesebbszer kell írni az eepromot (esetleg egy peremkerekes kapcsolóval lehet programot váltani, mert az van itthon és akkor el sem kell tárolni semmit, hogy mi volt a legutóbbi beállítás )
Ehhez most kell egy Arduino panel (nálam Nano), egy pontmátrixos kijelző (nálam 2x16 karakteres), egy SSR (kb 3000Ft költség, az enyém 9€+1,65€ posta volt, kínából ez olcsóbb), egy KY-040 enkóder, pár ellenállás, egy termisztor, egy elkó, ha nem menne az enkóder, kábel, egy mikrokapcsoló és a mikrosütő trafója.

Minden egyes bájtra. Egy bit írásakor is törli az adott bájtot majd a módosítottat írja vissza.

Megoldás lehet az EERAM használata. Pl.: 47C16. Igaz, ezek perpillanat elég kis méretben kaphatóak (2 kByte és 512 Byte).

Szerintem a nem létező problémát bonyolítjátok itt az egekig túl!
Ha csak akkor ment EEPROMba, mikor szükséges.
Kijöhet olyan 50 írás havonta max, ha minden hétvégén használja?
100000/50/12= 166év?!

Ez újabb problémát vet fel, mert csak 100 évig garantálja az adatok tárolását az adatlap.

Hogyan kapták ezt a 100 évet?
Még nem is gyártanak 100 éve AVRt!

Hali!
Pont nem nullátmenetes SSR-t szoktak használni.
A szinuszhulámok (20ms) számát állítják be időnek, teljesítményt meg a szinuszhullám fázishasításával állítják be, vagyis a szinuszpúpból mekkora időt vezet a triak/ssr.
Mindenképp a nullátmenethez kell szinkronizálni.
Ha lemondasz a teljesítményszabályozásról, akkor esetleg mehet a zerocross-os SSR, de akkor is szinkronizálnod kell a nullátmenethez a gyújtást

Hát ez az Az eredeti projekt, amiből indultam nem néz semmit, 50ms a lépésköz és nullátmenetes az SSR. Az enyémben 10ms a lépés és még abból a projektből származó weld rutint használom kicsit kibővítve, de mindenféle fázis figyelés nélkül. A végén mégsem úszom meg a saját SSR építést Egyenlőre kipróbálom, hogy így mit alkot, aztán próbálkozom először a szinkronnal, aztán másik SSR-el vagy sajáttal teljesítményt szabályozni ha kell.

A nullátmenetes ssr-t a nullátmenetnél lehet begyújtani. Ha jóval nullátmenet után próbálsz impulzussal gyújtani, semmi nem történik... Vagy olyan hosszú gyújtóimpulzus kell (10ms körül) ami garantáltan átfedi a nullátmenetet - szóval bizonytalan. Ha 9ms-t választasz akkor lehet hogy nem gyújt, ha meg 11-et akkor lehet kétszer gyújt, Ha pont 10-et akkor az is érdekes eset.
Szóval mindenképp szinkronizálni kell a nullátmenethez, ha megnézel több projektet akkor egy optokapun keresztül jelez a proc lábára...
Szerintem nem véletlen a 20ms (+ és - szinuszpúp) lépésköz, hogy a hálózatból mindkét periódust terhelje...

Láttam pár ilyet, de a legtöbb nem foglalkozik vele és nem is 10ms a lépésköz. Ez itt nagyon korrektül van összerakva, 10ms a lépése, majd ebből indulok. Jól jönne egy szkóp ami itt nincs

D2-n ott van az optós nullátmenet figyelés...
A szoftvert nem rágtam át, de itt figyel: //Ráköltözünk a ZCD interrupt-ra
attachInterrupt(digitalPinToInterrupt(PIN_ZCD), zeroCrossDetect, FALLING);

Azt gondolom, ha a beállítható bekapcsolási idő nem legalább ötszöröse a hálózati periódusidőnek, mindenképpen kell szinkronizálni. Nem mindegy hogy egy hullám, vagy kettő, (ez már ott is 10% hiba). Fázishasításhoz meg teljesen alkalmatlan szinkronizálás nélkül. A szabályzás, meg a hálózati frekvencia keveréke nagyon szép hullámzó kimenetet eredményez.

igen, ez felvetődött bennem is, ezért kérdeztem. Fázishasítást még nem tervezek, majd egyszer talán. A githbon a keresőben "arduino spot welder" találati listából, talán minden huszadik foglalkozik a ZCD-vel és talán ha 1-et találtam amelyikben van és SSR-t használ. Teljesítmény szabályozást meg igazán nem is láttam ha jobban meggondolom.

Talátam egy ilyet (a ZCD a 2-es lábra megy nano-n):



A 2-es nanón int bemenet. Megoldja a megszakításkezelést automatikusan az arduino? Esetleg kell valami extra neki, mégiscsak egy dedikált folyamat.

Ebben nincs interrupt kezelés, egyszerűen megvárja a következő nullátmenetet a 2 while-vel, majd vár sinusMax_us időt, és ms ideig adja a gyújtóimpulzust.
Amit előzőleg linkeltél, és beidéztem ott van az interrupt deklaráció.

Köszönöm! Megnyugodtam Amiben volt, sehol nincs interrupt, csak a 2-es lábra kötötte és azt hittem, hogy a megszakítás miatt. Ezt nem értettem. Ezzel a megoldással mehetne bármelyik lábon a zerocrossdetect? Megvárja a sinus maximumát, ad egy gyújtóimpulzust a megadott időtartamig, az SSR meg a következő nullátmenetnél bekapcsol (az enyém nullátmenetnél kapcsol) és úgy marad amíg van a bemenetén jel, ami szintén a maximum környékén szűnik meg.

Engem nagyon zavar, hogy ilyen elemi dolgokat nem ismersz, mint:
Előbb deklaráljuk a változót:

Esetleg még így lenne jó:

Igazad van, elismerem. Nem így volt a kódrészletben pont ott ahonnan másoltam és nem akartam kihagyni (bár jobb lett volna), hogy a 2esen figyel és odaírtam (bizonyára valahol benne volt, de nem itt). Külön fájlban deklarálok, ezt meg csak úgy találtam a githubon és az érdekelt volna, hogy mindenképpen megszakítás kezeléssel kell-e kezelnem a nullátmenetet vagy mehet más pinről is. Legközelebb odafigyelek rá, bocsánat!
Az meg, hogy a weld(1) mit csinál fogalmam sincs, nem az én kódom, csak a nullátmenetet keresgéltem épp.
Tehát a kérdés, hogy kell-e mindenáron megszakítással kezelni a nullátmenet érzékelését?

Szerintem kár 2 byte-ot elszótni erre az 1 byte-nyi adatra, ami ráadásul konstans...

Nem szükséges interrupt, de talán egyszerűbb úgy.

Igazad van!

De arduino berkekben ez sajnos bevett szokás!
Könnyebb mindenűt egyféle típust használni, mint megtanulni mi köztük a különbség.
És melyiket mikor kel vagy célszerű használni?

Félve kérdezek, de mi az oka? Ha az alábbi kódrészletet jól értem, mindenképp akkor lép tovább, ha a beállított késleltetés eltelt a nullátmenet után. Ebből esetleg egy megszakítás tudná elvenni a vezérlést ha jó amit eddig olvastam az arduinoról (ami egyáltalán nem biztos kb. 2 hete kezdtem olvasgatni és 1 hete próbálok valamit írni is rá.) Ha nem szakítja meg semmi, akkor ez is lehet elég pontos detektálás?

Mivel neked nem kellene minden null-átmenetre megszakítás, hanem csak akkor, ha nyomod az indító gombot.
Ezért szerintem felesleges bele bonyolódni!
Jó ide az alkalmazott lekérdezéses eljárásod.

Ezt eleve a gombnyomás után gondoltam lekérdezni abban az ágban ahol a kimenetet (SSR) kapcsolja.

Érten én!
Ezért felesleges az interupt 50Hz minden nul-átmeneténél.
Mert nem is akarsz mindig kapcsolni SSRt.

Pedig az lenne a korrektebb, ha a trafót fázishasítással kapcsolnád be, mondjuk 4 félperiódus alatt felfuttatva. Persze, tudom, általában nem foglalkoznak vele.

Az lenne a lágyindítás, de akkor nem lenne 10ms-os impulzus! Hmm...

Beállítások EEPROM-ba mentését én úgy csináltam, hogy akkor mentettem, ha már legalább 5 másodperce nem történt semmilyen felhasználói beavatkozás, tehát gyakorlatilag befejeződött a beállítás. Ráadásul csak azokat a bájtokat írtam, amiknek a tartalma megváltozott (semeddig nem tart olyan saját EEPROM író függvényt írni, ami először összehasonlítja az EEPROM aktuális tartalmát a beleírandó tartalommal, és csak akkor ír ha ez eltér).

Ha belegondolsz, egy 10msec-es impulzust, egy félperiódust, egy DC jelnek is tekinthetsz. Nem szeretik ezt a trafók. Az iparban is lágyan futtatják fel, mert a transzformátor mágneses állapotának ez a kedvező. Ha nincs lágy-indítás, akkor is elvileg egy 90°-os gyújtásszöggel kellene kezdeni, hogy ne vidd mindjárt az első félperiódussal telítésbe a vasat.