Project->Build options->Project->Linker->Fill talán erre való, próbáld ki.

Azt megtaláltam én is, de mit írjak be?

Adatlapban keresd meg annak az utasításnak a kódját, amivel fel akarod tölteni.

Beírom, hogy goto wdtreset és ezt dobja:
Error [1204] ; . -FILL value must be between 1 and 8 bytes long

Megpróbáltam ezt:

De syntax error-t ír.

Csak partszélről... Szerintem konstanst próbálj beírni...
tartományt jól adod meg? nem írná felül az 1FFE-t?

Milyen konstanst?

Nyilván az utasítás hexa kódját

De én nem utasítással akarom feltölteni, hanem watchdogreset-tel, hogy ha bármi miatt olyan helyre téved a program, akkor resetelődjön.
Annak meg legjobb tudomásom szerint nincs utasítása.

A legjobb megoldás, ha végtelen ciklusba küldöd az eltévedt programot, amiből majd a Wathdog reset hozza csak ki. A 16F88x -nél a program memóriát feltölteni csak utasítással lehet, nincs relatív ugrás és a program memória lapokra van osztva. Az üresen maradt utasítások helyére tegyél ugrást a lap végére (goto 0x7FFF azaz 0x2FFF kódot). Biztosítsd, hogy egyetlen lap utolsó utasítását sem használod ki, ott is a 0x2FFF kód legyen.

CLRWDT is utasítás !
Meg a RESET is utasítás !
A hex file-ba utólag tudsz belekavarni a Hexmate.exe programmal.
Fordító doksiban jól benne van :

-fill=[const_width:]fill_expr[@address[:end_address]]

Erre a funkcióra, amit Te akarsz, szerintem nem nagyon van értelme !
Ha véletlenül eltéved a kód úgyis lefagy, akkor meg bejön a WD.
Ha meg olyan helyre ugrik ahol netán értelmes kód van akkor azzal nem lehet mit kezdeni.
Megfelelően állítsd be a WD időt és nem lesz baj.
Az újabb procikban elég sok hibatűrő dolog van, főleg az oscickra...(legtöbb gond innen jöhet) ...olvass utána.
Én csináltam olyan kütyüket ami évekre magukra vannak hagyva... és szépen működik minden...sosem jeleztek gondot.
A WD csak igen extrém körülmények között de leginkább hibás programnál jön be.

Hát nem lenne túl bölcs, ha ezzel tölteném fel a program memória ki nem használt részeit. Akkor aztán tényleg soha nem indulna újra, ha odaugrana, mert állandóan törölni a wd-t. Az a gond a hibás programmal, hogy van úgy, hogy hetekig tesztelem itthon 24 órában, és minden rendben, aztán mikor kihelyezem terepre, akkor meg jeleznek hogy igen ez történt meg az. Ezt kiküszöbölve használom a wd-t, csak azzal meg az a gondom, hogy a főciklusom nem állandó ciklusidejű. A megszakításom tele van szemaforokkal, amik bizonyos esemény, vagy eltelt idő után billennek 1-be, amit a főciklus a végrehajtás után töröl. így van úgy, hogy a főciklus pl 10 us, de van, hogy 300ms. Ekkor milyen időzítés legyen a wd?

Mit vezérelsz? Rakétát ?! Ott sok a 300 ms, de általában jó az emberi reakciókhoz( pl. szerintem a hőmérőknél sem sok !), tehát ettől válaszd nagyobbra egy kicsit ! Én még megvoltam a WDT nélkül ( csak sleep-hez használtam ), mégis üzembiztosan mennek a programok! Ha külső zavarás van, akkor azt kell megszüntetni, arra nem a WDT az igazi ( az csak az üzembiztonságot javítja ), ha otthon tuti, akkor a terepen kell keresgélni ( ami nehéz! )!(

Szia!
És ha timer megszakításba raknád be a clrwdt-t?

LCD kiírás + 24 darab ds18b20 hőmérés (8 db 1 lábon, utána lábváltás...) + modbus rtu kommunikáció (ha lekérdezik a hőmérőket). Jó elég durva volt az a 300ms, de ha belevesszük azt a "lassú" lcd-t, míg kiíratom az adatokat..., plusz ha pont akkor kérdezem le a hőket, akkor el kell készíteni a választ is, utána el kell küldeni, blablabla.

Tudtommal megszakításba soha nem szabad belerakni clrwdt-t mert attól, hogy a program lefagy, még a megszakítás működik.

Igen, közbe rájöttem, kicsit kómás voltam még, nem rég keltem föl.

Ha hibásan van megírva egy a megszakításból hívogatott rutin, simán belefagy a megszakításba is. De ettől függetlenül nem a megszakításba szoktam rakni a törlést, már ha használom egyáltalán a WDT-t, mert nem szoktam. A PIC nem fagy le, ez nem PC, csak a programnak kell jónak lennie. Tehát WDT-vel korrigálni a program hibáját, megkerülve, hogy megkeressük mit rontottunk el, az elég gáz!

A hőmérők lekérdezése nem időkritikus, legfeljebb abbahagyod a kommunikációt, ha nem érsz rá... A MODBUS az az, de ott se kell folyamatos adat küldés, az LCD-re is csak akkor kell kiírni, ha változott valami. Egy siló hőmérséklet mérésénél ha 5 percenként mérsz egyet ( akár egy kört, akár egy vezetéket ), akkor se fogsz meglepődni, tehát ha véletlenül lefagy a rendszer és 1 s múlva indul újra WDT miatt, akkor még senki se lesz ideges !
Viszont, ha valami miatt többször újraindul a rendszer, akkor keresd meg a hiba okát és hárítsd el!

Akkor miért rakja bele minden gyártó? PLC, TV. router...

Egyáltalán nem vészes, csak ezek az anomáliák érdekesek picit. Viszont ha már ez nem releváns, akkor hadd tegyek már fel még egy kérdést.
Szóval a hőmérők lekérdezésénél tapasztaltam egy olyat, hogy kiküldök egy mindenkinek szóló üzenetet, hogy kezdjék el a mérést. Aztán ahogy fut a program, példaképpen lehúzok egy érzékelőt, erre szépen vissza is tér a függvény hibával, minek következtében értesülök róla, hogy gond van. Majd visszadugom menet közben, erre +85-tel tér vissza első olvasáskor, utána már jó lesz. Adatlap írja, hogy ez a default érték bekapcsoláskor. Na de ezt hogyan javítsam? Mármint, hogy ne legyen hiteles mérés? Az a gond, hogyha erre az értékre azt mondom, hogy rossz és aztán meg tényleg ennyi a hő, akkor? Vagy ismételjem meg mégegyszer a mérést?

Ha jött szenzor hiba, akkor billents át egy flag-et, amit akkor törölsz ha lefutott 2...5 mérés. Így biztosan sikeres lesz és 85 foknál sem lesz hiba.

Köszi, ez jó ötlet!

Mert nincs idejük rendesen tesztelni... Valamint nem mikrovezérlő van bennük...

Én ezt használom üzem közben is: ha bejön egy hibás mérés, akkor meghagyom az eredeti mért értéket és csak adott hibás mérés után veszem hibásnak a mérést, az sok helyen bőven megfelel ( pl. ha percenként mérsz, akkor 3 hiba esetén 3 perc után már tudod, hogy gond van!).

Na én is kiakadtam (megint) a C-re. Az osztás miatt akartam benne programozni, mivel ASM-ben gyakorlatilag lehetetlen számomra ezt megvalósítani (16 bites szám osztása nem egész számmal). Szép pontosan ki is számolja a nyavalyás, de mivel nekem időkritikus feladatot kell csinálnom, ezért azon kiakadtam, amikor megláttam mit művel amikor belép a megszakításba.


Biztosan meg van az oka, de nekem nincs szükségem rá, hogy 14 regisztert másolgasson ide-oda indirekt címzéssel. Ráadásul alig lehet követni, egyszer valahol megadja az FSR-t, aztán már csak a mutatócsökkentéses/növeléses indirekt címzéssel dolgozik. Legalább generálna valami kommentet hogy éppen mit csinál.
Persze ez a kód csak egy része, még csinál vagy 20 látszólag felesleges utasítást.

Az csak egy gond, hogy másol byte adatot... De miért kell ilyen idétlenül?

Ez csak 5 utasítés (movff két word -os), és csak egy ugrást tartalmaz. Nem függ a felhasználói kódtól (csak a darabszám), hanem a fordító teszi a kódba. Akkor miért nem használja a ciklusszervező utasításokat? Tömegével lehet a programokban. Miért csak az indító kódban van (egy azaz 1 db) decfsz, miért nincsenek a kódban incfsz, infsnz, dcfsnz, tstfsz és a komparálási utasítások? Egy 16 bites szám növelése (feltételezem, elég gyakori lehet)
ifsnz lowbzte,f
incf highbyte,f.
Nem volt elég idő az optimalizálás fejlesztésére (Revision A (July 1999)
Original data sheet for PIC18CXX2 family.)

Az a baj, hogy mikor a megszakítási vektrorról hívja meg a szubrutint, akkor előtte hajtja végre ezt a másolgatós dolgot.
De lehet megpróbálok rá valami okosságot kitalálni, végülis nem annyira sok idő.
Viszont ha időmilliomos leszek, áttérek ARM-re, az tuti.

A megszakítási rutin sok regisztert másol, mert ment (PRODH, PRODL). Ha véletlenül alacsony szintű a megszakítási rutin, akkor mentenie kell a WREG, STATUS, BSR regisztereket is. Ezeken kívül minden olyan változót mentenie kell, amit a megszakítási rutin felhasznál. A dokumentációjában olvasható, mit ment és hogyan adható meg, mit mentsen. Ha eljárást hív, akkor a paramétereket a stack -re (FSR2 indirekten) kell másolnia és (mivel a C ilyen) visszatérés után le kell bontania a stack -et.

Idézet:
„Viszont ha időmilliomos leszek, áttérek ARM-re, az tuti.”

Ezeket a feladatokat más kontroller / CPU is szorgalmasan végzi. Annyi lesz az eltérés, hogy nem fix regisztereket fog használni, hanem a stack -et (indirekt címzéssel) és gyorsabban másol majd.

Ez igaz, és kicsit butának is érzem magam, hogy sok évvel ezelőtt, mikor egy 18F-es PIC még a NASA-nál is high-tech lett volna, meg bírtak oldani sokkal bonyolultabb feladatokat sokkal egyszerűbb eszközökkel.