Melyik mikrokontrollerről van szó? Miért nem használod a beépített watchdogot?
A boot időt nagyban lerövidíti, ha nem használsz bootloadert. Az ugye bekapcsoláskor vár, hátha jön új firmware.
Cél IC-ből van hosszabb/állítható időzítésű is.

Sokan lehet nem tudják ám, miért emlegetjük annyit a röntgen gépet. Pedig szerintem a Therac-25-öt tanítani kellene.
Wiki
Részletes elemzés
Mennyire könnyű elcseszni...

Hardveres watchdog áramkört sokféleképpen lehet készíteni, pl. CMOS kapukkal, vagy akár 1...2db tranzisztorral is + passzív lakatrészekkel. Milyet szeretnél építeni? Kb. mekkora időzítést szeretnél?

Arduino Pro Mini alaplapot használom hozzá, Atmega328P 5V-os.
A beépített watchdog nem jól működik, nem resetelődik ill. végtelen ciklusba kerül tőle, úgy, hogy a reset sem hozza ki belőle, csak ha a tápfeszültség ki van kapcsolva. Ha működne, akkor nem kellene külső áramkör.
Igen, a bootloader kihagyása megoldás lehet, de nem ez a feladat, az csak a megkerülése. Nem szívesen választanám azt a megoldást.
Ahogy írtam, ezt az IC-t sikerült azonnal beszereznem, ezért próbálom ezzel. A TPL5010 lenne talán a legjobb, de azt meg kell rendelni. Azzal fogom majd próbálni, ha ezzel nem sikerül megoldani.

Célszerű olyan hardvert tervezni, ami egy katasztrofális szoftverhiba esetén sem hibásodik meg, és nem okoz más problémát sem (pl. balesetet). A szoftverfejlesztéskor pedig át kell gondolni, és tervezetten beleírni a szoftverbe, hogy mi történjen ha hibás adatokat kap a program, vagy irreális értékek jönnek ki. Azaz a bemenő és a kimenő adatokat is célszerű ellenőrizni.

Pl. egy mikrosütő, bármilyen "okos vezérlést" is kap, mindig ott van a mechanikus retesz is, ami pl. ajtónyitás esetén kikapcsolja a magnetront.

Végülis szinte mindegy, hogy milyen, hely van bőven, csak biztonságosan működjön. Kb. 4 sec lenne a legjobb. A tipikus 1,2s, 1,6s fix idejűek nem jók, azt ahogy mértem, kevés. A felügyelő jel periódusa 2s lenne, hogy ne a loop-ba kelljen váltogatni a jelet, hanem egy 1 sec-es szoftveres timer végezné.

Most, hogy ezt leírtad, elő is kaptam a forrasztóállomásom szoftverét, hogy megnézzem, azzal mi történne negatív értékek esetén. Amúgy szerencsére semmi , mindenhol int32_t változókban vannak a hőmérsékletek, (tizedfokos felbontással). Esélye sincs (egyik irányban sem), pl. túlcsordulni.

Pl. CD4060-as CMOS IC van kéznél? Egy RC tagon keresztül resetelné a "felügyelő jel", ha viszont el tud számolni addig (mert nem kapott reset impulzust), hogy egy adott kimenete H szintre váltson, akkor pl. egy kis FET-el resetelheti az MCU-t. Mivel addig nincs további impulzus, amig el nem indul az MCU, ezért a 4060 tovább pörög, és megszünteti az MCU resetre adott jelet, majd el tud indulni az MCU. Ha ez az idő sok, akkor a kis FET-et is RC tagon keresztül kell vezérelnie, hogy rövidebb reset impulzust adjon, vagy pl. saját magát is resetelheti a 4060 pár orajel impulzussal később. A beépített számláló miatt egész pontos időzítést lehet készíteni ezzel az IC-vel.
De mint írtam 1..2 tranyóval is megoldható, csak ha egyetlen RC tag időzít mondjuk 4 másodpercre, az kevésbé lesz stabil. De ha nem kritikus pontosan 4 másodpercet tartani, akkor ilyen megoldás is működhet.

MAX6301 lehet kondenzátorral beállítani az időzítéseket.

Szia!
Otthon van régebbről 1-2 darab reset IC-m, este megnézem milyenek. Ha érdekel akkor szívesen odaadom, nekem aligha lesz rá szükségem...

Jó ötlet, nekem is eszembe jutott, csak én CD4017-es IC-vel gondoltam, mivel a bináris számlálóval a resetnek használt kimenet magas szinten marad T_w ideig. A HeStoreban van egy közlekedési lámpa kit, BK-0705 azonosítóval, azon van 555-ös IC az órajelnek, a CD4017 és már csak 1 tranzisztort kell hozzárakni, hogy OC legyen a resetelő kimenet. Abban az esetben csak egy "tikkelés" ideig van reset állapotban az Arduino. A probléma azzal is az, hogy a számláló törlését (CD4017 RST bemenet) mennyire lehet megbízhatóan megoldani. Ugyanis nem magas vagy alacsony szint kell, hanem éldetektálás. Egy sima kondi is megteszi, a kérdés az üzembiztonság. A diszkrét elemekből készült watchdognak szerintem ez a sarkalatos pontja.

A soros kondin átmennek az "élek", a reset lábra meg kell egy ellenállás és egy dióda, és már kész is. A 4060 annyiban ügyesebb, hogy nem kell hozzá külön órajel generátor, mert van benne két kapu amivel megoldható. Ráadásul emlékeim szerint jól tűri a lassan változó jeleket is. De a 4017-es megoldásod is jól működhet szerintem.

Pedig annak működnie kellene. Érdemes lenne megkeresned az okát, hogy a te projektedben mi a hiba.

Abban egyetértek, hogy atomerőmű, repülőgép vagy röntgengép sw-nek nem Arduino IDE alatt állnék neki random Pistike libekkel. És nyilván ha 10 milliós tervezett darabszámra tervezünk, és egy kicsit komolyabban megírt sw esetén elég lehet egy 10 centtel olcsóbb uC is, megéri. De messze nem annyira tragikus a helyzet, ahogy elsőre elmondtad.

És igen, sokszor "beleragad" a project, és a legtartósabbak általában az ideiglenesnek szánt megoldások. Evvan.

Két egyforma alaplapon is ugyanazt a hibát produkálja, minden "projekt" nélkül, azaz semmi más nincs a programban, csak a watchdog tesztelése. Miután az első próbánál a legelején kiállt hibára, ami blokkolta a soros porton való programozását is, csak ISCP-vel sikerült visszahozni az élők sorába. A továbbiakban egy 5 sec-es delay-el kezdődik a program, különben a watchdog reset teljesen elérhetetlenné teszi.

Csak törpölök, de az nem megoldás, hogy amikor a bootlader lefutott és rendben elindult a programod, akkor a megmaradt szabad kivezetéssel inditod a watchdogot? Pl áram alá helyezéssel. (Mármint a külső watchdogra gondoltam természetesen)

Jó ötlet, megfordult már a fejemben, készítettem is egy rajzot hozzá (de észrevettem rajta egy hibát, azért nem teszem közzé). Én arra gondoltam, hogy a watchdog IC magáról az I/O portról kapja a tápot, csak aza baj, hogy egy kész panelről van szó, aminek a 13-as kivezetése szabad csak. Azt pedig a bootoláskor elkezdi villogtatni, így a watchdog IC is azonnal elkezd működni.

Én a helyedben felraknám ide a watchdog tesztelő programot (több szem többet lát alapon), meg akkor más is ki tudná próbálni egy saját alaplapon. Kiderülhetne, hogy az alaplappal, vagy a tesztelő programmal van-e a hiba.

Ezzel a programkóddal teszteltem:

A 2-es kivezetésre csatlakoztatott gomb megnyomására nem lesz a wdt timer törölve.
Nálam kb. 1 sec után történik egy watchdog esemény. Ha csak az interrupt van beállítva, akkor megy tovább a program, de a következő watchdog eseménynél lefagy, úgy, hogy a reset gomb elengedése után sem tér magához.

Az alaplapfüggő hosszúságú long típus helyett próbálj inkább uint32_t típust használni.
Megszakításból szerintem nem célszerű soros portra írni (esetleg az is megszakítást használ, és rel. sokáig is tart), ebből is simán lehet lefagyás...

Így van. Interrupt handlerben nem csinálunk szinte semmit. Flag billentése, majd a főprogram lekezeli. Esetleg port írás vagy olvasás.

Ezek szerint nem próbáltad ki a kódot, mert nem a Soros portra íráskor fagy le. Azt simán megcsinálja. Ráadásul 8 secen belül simán végez
A long vagy uint32_t csak fordításkor különbözik, a kódja ugyanaz.
Amúgy meg a megszakítás teljesen érthetetlen módon nem 8 sec után, hanem sokkal hamarabb bekövetkezik, még akkor is, ha nincs bekapcsolva a watchdog. A WTD reset üti ki, ami viszont tényleg 8 sec múlva történik a wdt_reset() elmaradása után.

Ismét nem vitatkozok a városi legendáról! Az adott problémának ismét semmi köze a megszakításhoz!

Nem városi legenda.
Nálunk (és sok más helyen sem) rivjún nem engedünk be ilyen kódot, visszakapja a feladatot a fejlesztő. Pont az a probléma, hogy nem feltétlenül okoz gondot, de okozhat. Néha. Piszok nehéz a hibakeresés. Volt, hogy örökültünk olyan kódot, amiben a teljes alkalmazás ISR-ekben volt implementálva. Hol működött, hol nem. Szóval nem OK.
Igen, te éppen egy tesztet csinálsz, ahol jelezni akarod meddig jutott a program. Lehet kimeneteket billenteni. Vagy ha ragaszkodsz a soros adatküldéshez, akkor küldj egy karaktert direktben, kikerülve az Arduino println függvényét.

Nem csak hogy nem célszerű, de ATMEGA328-on az Arduino kódban a serial írás nem pufferelt, csak a hardveres 1 bájt van pufferelve. A következő bájt írása blokkolja a futást ameddig az első ki nem ért a csőből. A folyamatot interruptból kezelné, de az ugye le van tiltva, és soha nem fog bekövetkezni, ezért fagy le a program. Arra vár, hogy felszabaduljon hely a pufferben, de az sosem következhet be. Deadlock.
Interruptban valóban a lehető legkevesebb dolgot kell csinálni. Ha feltétlen muszáj loggolni belőle, akkor egy olyan serial bufferelést kell implemenálni, ami garantáltan blokkolás-mentes. Lehet ilyet csinálni, de akkor meg az overflow-t nem tudod kizárni.

Otthon saját projektben mindenki azt csinál amit akar, de ha fejlődni akarsz akkor érdemes nem csak a saját tapasztalatodra támaszkodni, hanem a sok-sok tapasztalt programozó által megalkotott kódolási konvenciókat és programozási mintákat követni. A blokkoló soros port használata megszakításból egy anti pattern, amit érdemes elkerülni. Ettől még lehet, hogy neked éppen most nem okoz problémát, de pont azért hogy minimalizáld annak a lehetőségét, hogy később okozzon, kerülni kell.

Lehet ezen rugózni, csak tök felesleges, főleg úgy, hogy pont nem releváns. Aki szerint helytelen a kód, az gyakorlatilag azt állítja, hogy a soros port írása több mint 8 másodpercig tart, ami bizony elég nagy botorság
Da a legnagyobb probléma, és nem csak most, hanem úgy általában a segíteni szándékozók körében, hogy egyrészt nem is ismerik mélységében az adott problémához tartozó működést, de legfőképp, hogy ki sem próbálják, tehát tippelnek. Valamint adott egy probléma, de mivel ahhoz semmit sem konyítanak, hát csinálnak egy másikat, hogy legalább úgy tűnjön, hogy képes érdemben valamihez hozzászólni.
A soros port kezelése teljesen független a watchdogtól, mondhatni, közük nincs egymáshoz, valamint ez egy teszt kód, kizárólag erre a problémára, tehát nem általános érvényű, így teljességgel értelmezhetetlen általános érvényűként hivatkozni rá!

Nem, nem azt akarom tudni, hogy meddig jutott a program. Azt mutatom ezzel, hogy hibásan működik a watchdog a nálam lévő alaplapokon. Majd ha működik rendesen a watchdog, akkor jöhet a meddig jutott, vagy a hol fagyott le jelzők elhelyezése. De úgy veszem észre, hogy senki sem érti a watchdog működését. Ugyanis ha aktiválódik a watchdog, akkor már nincs loop, ahova vissza tudjon térni, hiszen pont ez váltotta ki a watchdog eseményt! 3 féle módon futhat tovább a program: megszakítás, reset és megszakítás és reset. A megszakításból oda fog visszatérni, ahol végtelen ciklusba került, tehát nem tudsz semmilyen bitet vizsgálni, amit a megszakításban állítottál át, mert nincs loop, hiszen pont ezért lett aktív a watchdog. A másik 2 esetben meg pláne, hogy semmit sem fogsz tudni róla, még azt sem, hogy watchdog esemény következett be, hiszen resetelődik a kontroller, így egyetlen lehetőséged a külvilág felé jelezni, hogy watchdog esemény következett be, az az, hogy a megszakításba írod bele. És ilyenkor már bármit írhatsz, mert semmit sem fog tudni blokkolni, deadlockolni, ... stb, semmit sem fogsz tudni elrontani, mert már összeomlott a program, az adott folyamatban nem fogsz tudni visszatérni a loop ciklusba! Csak egy újraindítás segíthet.
Ettől a leírástól elő lehet idézni eltérő működést, de az most nem releváns, a lényegen nem változtat.

Én sosem használtam a watchdog interruptot, mert ahogy írod ott már sok lehetőséged amúgy sincs. Hagyni kell, hogy a watchdog resetelje a kontrollert. Induláskor pedig megnézni, hogy mi volt a reset oka, ha watchdog akkor regisztrálod magadnak ahogy akarod, hogy watchdog reset történt, majd fut a programot tovább.

A probléma pont az, hogy nálam nem reseteli, hanem egy "másik" végtelen ciklusba kényszeríti. Az Atmega328P-nél nincs róla tudomásom, hogy lenne valamilyen flag, ami jelezné a reset forrását. Vannak olyan kontrollerek, amiknél a reset forrása kiolvasható, de ebben az esetben ilyen nincs. Azon kívül, mint említettem, nem ez a gond, hanem az, hogy rosszul működik a watchdog reset-je.

szerk.:
Miután nincs a reset forrását jelző bit, ezért csak az interruptjában lehet valamilyen formában jelezni, hogy a reset a watchdog miatt történt.