Sziasztok!
PIC24 -en ha nem a near hanem a far területen (8kbyte fölött) lévő változót szeretnék megcímezni, akkor azt csak indirekt módon lehet. Eddig rendben.
Na de a fordító ez miért nem tudja? (XC16) Miért próbálja direkt címezni, amiből "Address Error Trap" lesz?

Ugye van erre valami kényelmesebb megoldás? Nem értem, hogy ha egyszer tudja a fordító hogy az adott változó a far-en van, miért nem indirekt címezi? Néhány [szögletes zárójelen] múlna..

C30-nál ez úgy működött, hogy a Build options / Project menüben az MPLAB C30 lapon a "Memory model" kategóriában át kellett állítani a Data Model opciót Large data model-re. (ennek eredményeképpen a fordítónak egy -mlarge-data fordítási opció fog átadódni).

Azért, mert az új projekt létrehozásánál az az alapbeállítás, hogy minden belefér a "near RAM"-ba. Az nem a fordító dolga, hogy a projektbeállításokat felülbírálja!

Itt is így működik, azzal kezdtem hogy átállítottam large-ra, mert különben nem is fordult.
Lehet hogy valamit az EDS környékén kell keresgélnem, de egyelőre még egy kukkot sem értek belőle. Olyan lehet ez, mintha visszatértünk volna a jó öreg BSR -hez? Váltogathatok bankokat?
Persze ettől a fordítót még mindig nem értem..

Kipróbáltam MPLAB v8.92 C30 párossal, tökéletesen lefut szimulátorban. Bár a disassemby szerint ugyan arra fordul mint X alatt.
8.92 C30:

XC16:

Szerintem XC16 jól teszi hogy elszáll, mert a MOV -al megcímezhető tartomány: File register address {0x0000...0x1FFF}
De még mindig nem jó... és nem értem...

Bocsi de Te írtad : "De én nem utasítással akarom feltölteni, hanem watchdogreset-tel"
Nem a fő ciklus számít ! A CLRWDT() nem csak a fő ciklusban lehet !
Bárhol ahol vársz időre vagy valamire vagy ciklusban csinálsz valamit tegyél be CLRWDT()-t;
A WDT időnél az a lényeg, hogy sose írj olyan kódot ami önmagában ciklusba fut, csak ha beteszel a ciklusba egy CLRWDT().
Timer ISR-be lehet tenni, de hülyeség. Ugyanis ha véletlenül végtelen ciklusba kerülsz az ISR akkor is bejön és nem indul újra a cucc.
Ahol időzítesz a ds18b20 1-W kommunikációban oda tegyél a ciklusba CLRWDT()-t.
Ha a PICC _delay_ms()-t használod akkor azt is tedd ciklisba :



Az a lényeg sosem álljon meg a kód, még ha egy bitre is vársz akkor is kell a törlés !
Egy 16x2-es LCD a két teljes sort 4 biten hajtva kevesebb mint 2 msec alatt írja ki !
Amikor az LCD-t visszakérdezed akkor is töröld !

Én így csinálom :

Szerintem ez így nem jó, mert ha valami miatt ( pl.zaj ) eltéved a program, akkor is olyan területre téved nagy valószínűséggel, ahol van WDT törlő utasítás! A WDT használatának pont az a lényege, hogy a folyamatosan ismétlődő hurokba tedd be egyszer és ne legyen a programodban un. blokkoló utasítás, különben elveszti a lényegét a védelem! Ennek a főhuroknak a futási idejénél kell egy kicsit nagyobbra beállítani a WDT túlcsordulási idejét!

Én is ezzel értek egyet. Ha mindenhova beleraknám a clrwdt-t, akkor aztán tényleg nem érne semmit. Tipikus példája ennek,amikor még hittem a beépített függvényekben. A HITECH C saját delay_ms függvényét használtam késleltetésre és az épített vezérlő telepítése után 3-4 hónappal szóltak, hogy megállt a cuccos. Erre kimegyek, nézem, hogy egy olyan helyen akadt meg a program, ahol nincs is clrwdt. Érdekesnek tartottam, hogy miért nem indul újra. Na erre megnéztem a disassembly kódot és találtam benne vagy 50 clrwdt utasítást, annak ellenére, hogy én csak 2-t írtam bele. Mint kiderült, a delay_ms függvény automatikusan belefordít egy clrwdt utasítást. Na azóta saját függvényeket használok. Visszatérve az eredeti problémafelvetésre, én csak azt szerettem volna megoldani, hogyha olyan helyre ugrik a program, ahova én nem írtam semmit, akkor induljon újra. Nem clrwdt-vel akarom feltölteni, mert akkor adtam a sz*rnak egy pofont.

Szia!

Puszta kíváncsiságból:
Hogyan találtad meg, hogy hol akadt el, ha 3-4 hónap folyamatos üzem során nem jött elő a hiba? Így elég sztochasztikus, és nehezen reprodukálható hibának tűnik

Mindel program lapot úgy töltünk fel, hogy a lap utolsó utasítása egy ugrás önmagára (minden program lapon), a többi pedig nop. Tegyük fel, hogy egy program lapon (page), olyan területre ér a program, ahol már nincs igazi program utasítás, csak a feltöltés. Ekkor a nop -okon végiglépkedve eljut a lap végére, ott a PCLATH -tól függően egy lap utolsó utasítására ugrik, de az ugyan az az ugrás. Ebből csak a Watchdog reset tudja kimozdítani.

Ha rájöttél, hogy hol fagyott le az nem véletlen volt !!!
Most megnéztem és a __delay_ms() nem fordít CLRWDT()-t....persze nincs kizárva, hogy változott !
Ha tényleg véletlenül eltéved a program (nem program hiba miatt) , ami 100 évenkét esetleg lehet és beugrik egy szubrutin közepére a lottó 5-el egyező az esély, hogy nem fagy le a cucc...ugyanis ekkor minden borul, mert elromlik a stack. Különösen igaz ez C programokra, ahol saját szoftveres stack-et készit, mert az eredeti nagyon kicsi !
Az lesz inkább valószínű, hogy valamelyik ds18b20 megdöglik.

A legvalószínűbb az, hogy a 1-Wire vonal sérül meg. A konverzió alatt alacsony ellenállással kell a vonalra a tápfeszültséget rákapcsolni. A hibás vonal túlterhelheti a tápegységet, ami rövid idejű feszültség csökkenést okozhat a PIC tápfeszültségén, ami a legrosszabb esetben nem okoz még resetet, de a program eltérülhet. BOR beállítás felülvizsgálata, a 1-Wire vonalnak külön tápegység, a vonal terhelésének figyelése, áramkorlátozás.

Teljesen jogos amit írsz. A parazita táp felejtős. A ds18b20 egyébként is nagyon gagyi.
Ipari környezetben komoly cuccban én sosem használnám.
Itt van egy topik abban olvastam, hogy valaki megvizsgált több mint 100 db-ot, abból csak 8 adta az ígért pontosságot. Volt pár ami nagyon durván eltért.

Vagy az ember nem tudott jól mérni, vagy amivel mért, az volt pontatlan. Fenntartásal kell kezelni az ilyen bejegyzéseket...

Mar tobb, mint 20 eve nem stack-en adjak at a parmetereket a fuggvenyeknek. Pontosabban nem mindet. A legtobb C fordito mar regiszterekben adja at az elso nehany parametert a fuggvenyeknek, a tobbit kenytelen stack-en (a 8 bites AVR gcc is, es a 16 meg 32 bites PIC gcc is). De speciel egy ARM-en 4..6 (?) darab max. 32 bites parameter siman elmegy regiszterekben. Az ARM még a fuggveny visszateresi cimet sem stack-re teszi, hanem egy erre dedikalt regiszterbe (lr). Aztan ha egy fuggveny tovabbi fuggvenyt hiv, akkor o maga elmenti az LR-t, de a CPU magatol nem stack-el. Pedig tudna, 32 bites az SP is. Az interrupt az mas, az elment magatol jopar regisztert, de az nem is baj, mert igen nagy valoszinuseggel az ISR is elmentene, de igy valamivel gyorsabb.

Idézet:
„Már tobb, mint 20 éve nem stack-en adjak at a parmetereket a fuggvenyeknek.”

Akkor több, mint húsz éve nem lehet rekurzív vagy reentráns eljárást írni. Az a link csak egy másik szoftvare stack. Ugyanis nem köthető meg, hogy a program eljárása ne hívjon további eljárásokat. Ekkor a dedikált regiszterek tartalmát és a visszatéséri címet mégiscsak a stack -re kell menteni (a link kezelése ugyan az a műveletsor). Persze, ha nincs további eljárás hívás, akkor az utolsó szint "mentése" elmarad. Reentráns eljárás esetében még a lokális változókat is a stack -en (link -en) kell lértehozni, nehogy a (bármikor lefutó) másik (sokadik) példány felülírja őket. A dedikált regiszter alkalmazása egy szinttel késlelteti a mentést, csak az utolsót hagyja el.

A fuggveny regiszterben kapja a bemeno parametert, es sokszor a lokalis valtozokat is abban tartja. Nincs ezzel semmi baj, es semmi gondja nincs a rekurzioval sem. Ha a fuggveny olyat csinal, ami elrontana a regiszter erteket (pl. onmagat vagy mas fuggvenyt meghiv), akkor elotte elmenti a regiszterek erteket. Eppen ez benne a zsenialis. Addig nem hasznal stack-et, amig nem szukseges, de ugyanugy megmarad a rekurzio lehetosege. Ezt nem en talaltam ki. 20 eve, amikor eloszor lattam ezt egy dos-os HD64180 C forditonal, akkor pont ugyanigy hitetlenkedtem, mint most te. Viszont azota nem is lattam mas megoldast. Irtam 16 bites PIC-hez is assembly beteteket, ott is pont igy mukodik.

Az a link regiszter meg nem masik stack, azt hidd el, hogy pont arra valo, amit irtam. Nem osszekeverendo a frame pointerrel, amit valoban szokas link regiszternek hivni mas architekturakon (m68k). Az ARM blx utasitas, ami a szubrutinhivasra valo, az a pc-t elmenti az lr-be es elugrik a megadott cimre. A return meg nem csinal mast, mint az lr regisztert atteszi a pc-be. Ha nekem nem hiszel, nezd meg az ARM manualt.

"Ha a fuggveny olyat csinal, ami elrontana a regiszter erteket (pl. onmagat vagy mas fuggvenyt meghiv), akkor elotte elmenti a regiszterek erteket."
No csak ?... és hová menti...csak nem egy stack-be ?
"Addig nem hasznal stack-et, amig nem szukseges"....csak utánna !!!
Most akkor van stack vagy nincs.....?!
Szerintem maradjunk annál, hogy van....mivel a regiszter készlet véges és vannak egymásba ágyazott függvények is...vagyis nem lehet megúszni !

Ekezet nelkul irok, de magyarul. Nem azt mondtam, hogy nincs stack, vagy, hogy nem hasznal stack-et, hanem azt, hogy csak akkor hasznalja, ha szukseges. Oriasi kulonbseg van a ketto kozott. Miert szolsz bele, ha nem erted, amit mondok?

A C nyelv eredetileg ugy volt kitalalva, hogy a fuggvenyek bemeno parametereit stack-en adtak at. Ez valtozott meg sok-sok evvel ezelott, mert rajott valaki, hogy teljesen felesleges egy erteket betolteni egy regiszterbe, majd letenni a stack-re, aztan meghivni egy fuggvenyt, ami sokszor azzal kezd, hogy felveszi egy regiszterbe a stack-rol. Nincs ebben semmi kulonleges.

Tényleg gyilkos vagy !!!
Értem amit írtál....de ki szól bele mibe ?
Eredeti felvetés az volt hogy netán jön az űrből egy kósza elektron amitől elromlik a PC, ettől meg elszáll a program mivel megborul a stack...
Te meg beszóltál, hogy nincs is stack ! Részemről befejezett a stack vita. Van és kész !!!

Gyerekek nem én találtam ki.
Bővebben: Link

Link javítva.
Használd a link gombot!
-moderátor-

Nem vagyok gyilkos. Egy legyet sem csapok agyon.
Te szoltal bele abba, amit Hp41C-nek mondtam.
Eloszor is nem szoltam be. Tudod, hogy ez mit jelent? Masodszor, pedig tovabbra is azt mondom, amit az elobb: nem azt mondtam, hogy nincs stack, hanem azt, hogy a mai C forditok nem hasznaljak feleslegesen a stack-et fuggveny parameter atadasra. Lehet, hogy a 8 bites PIC C fordito hasznalja, de 16 bites biztosan nem.

Ezzel én is egyetértek. Nekem 24 van egy buszra kötve (és kb 80 méter) és most nincs vele gond. Nyilván átírtam a teljes programot potyo segítségével egy régebbi hozzászólás alapján.

Akkor tudnál mondani még egy olyan szenzort, ami buszos, legalább 24 eszköz felfűzhető, PIC-re implementálható és olyan olcsó, mint a ds18b20? Egyébként én is azzal értek egyet, hogy parazita táp felejtős...

Még ez sem pontos: Backtracking: Válaszom // Zenetom problémája
Végülis egy konkrét 8 bites gép, megszakítási rutinjáról volt szó, ami kénytelen menteni a C fordító által paraméter átadáshoz használt regisztereit, mert a megszakítási rutin foat osztás C rutint hív. Ezen körülmények között még az ARM -nek is mentenie kell. ((( Egy szintű mentésre már igen régen volt gyors megoldás: Z80 -on exa, exx))) ^Z

exx és ex af,af' volt a z80-on. De a PC-t az is a stack-re tette call-nal.

Idézet:
„kénytelen menteni a C fordító által paraméter átadáshoz használt regisztereit”

Hohó! Mostmar a regisztert menti a stack-re? Mert az eredeti HSZ-ben ezt irtad:

Idézet:
„Ha eljárást hív, akkor a paramétereket a stack -re (FSR2 indirekten) kell másolnia”

En erre mondtam, hogy nem stack-en adja at a parametert a fuggvenynek. Mire te azt valaszoltad, hogy ha ez igy lenne, akkor nem lenne rekurzio. Marpedig igy van es van rekurzio is. Ha ugy ertetted (csak nem ugy irtad), ahogy most irod, miszerint a parameterek atadasara hasznalt regisztereket menti a stack-re, akkor egyre gondolunk.

Mellesleg, ha interruptban float osztast csinal valaki egy 8 bites mikrokontrolleren, akkor tenyleg jobb, ha nem beszelek bele.

Ebben tenyleg az a szomoru, hogy mindenkiben csak az marad meg, hogy en belepofazok es szetoffolom a topikot, es senki nem fogja ezutan sem tudni, hogy manapsag nem a stack-en adja at a parametereket a hivo a hivott fuggvenynek. Sem azt, hogy inerruptbol float muveletet vegezni rettentoen nem szerencses dolog.

Nem is Neked íratam...
A Z80 - két szet munkaregiszter tömb volt, az elsődleges és a másodlagos. Az exa (más nyelveken ex af, af') csak az akkumulátort és a flag regisztert cserélte a két szet között, az exx pedig a többit (), és nem használt stack -et.
Idézet a Z80 CPU User’s Manual -ból (UM008005-0205):

Idézet:
„EX AF, AF': Operation: AF ↔ AF'
EXX: Operation: (BC) ↔ (BC'), (DE) ↔ (DE'), (HL) ↔ (HL')”

A C18 paraméter átadása - átvétele, visszatérési érték kezelése:
Ld. Az MpLab C18 C Compiler User's Manualjából (DS51288F), 36.lap, 3.2 Calling Convensions... (Sajnos nem tudom idemásolni).
Mikrokentolleres körnzezetben soha nem hasynáltam float váltoyót, mindig ki tudtam találni más hatékonyabb megoldást. Itt is csak segítani szerettem volna. Befejeztem, ahogy az Odra1170 lyukszalagán volt: .end. finish filler

Aláírom, ez részemről valóban nagy butaság volt. Átrakom a főciklusba.
Ez egyúttal Hp41C-nek is szól.

Nézzétek el, sajnos utóbbi időkben eltávolodtam az elektrótól és programozástól.
De vissza akarok térni, csak a "sors" most valahogy ellene(m) dolgozik.

Igaz, nem nekem irtad, csak kozom van a dologhoz.
Tudom, hogy segiteni akarsz, segitesz is sokat, latom es tisztelem ezt a munkat. Egy muszaki kerdest vitattam, amihez tartom magam most is (modern C forditok parameteratadasa, rekurzio). Abban teljesen igazad van, hogy a C18 C fordito egy virtualis stack-en adja at a parametereket. Es nekem is igazam van abban, hogy a 8 bites AVR, es a tobbi, amit felsoroltam, az pedig regiszterekben adja at. Igazabol csak azert szoltam bele, mert az ARM-re is azt irtad, hogy stack-el mindent. De ugy erzem, hogy veled szemben nem engedtem meg magamnak tiszteletlen hangot. Ha megis, akkor termeszetesen elnezest kerek. Nem akarlak sem emberi mivoltodban, sem szakmailag kritizalni, kifogasolni. Egyetlen kerdesben nem ertettem veled egyet. Vegulis ez egy szakmai forum. Csak kit6263 forumtars reagalt a hozzad intezett valaszomra, amivel nagyon nem ertettem egyet (sem szakmailag, sem emberileg) es eldurvult a helyzet. Nem ez volt a cel, bocsanat. Ok, a float tenyleg kotekedes volt, de az nem is igazan neked szolt. Es szakmailag szinten megalapozott, ahogy te is mondtad.

A z80 utasitaskeszletet ismerem, tudom mit csinal, azon kezdtem 1982-ben, azon nottem fel, irtam ra C forditot 1992-ben, de az meg a stack-en adta at a parametereket... Es ezt most nem neked mondom

Dicséretes hozzáállás, részemről megy a pirospont! Bővebben: Link

A ket idezetbol az elsot nem tudom maskepp mondani. Egyszeru magyar mondat volt, amit kiforgatott kit6263. Az lehet, hogy ha csendben maradok, akkor mindenki jobban jar. Csak nem tudom szo nelkul hagyni az ilyesmit. Pedig nincs ertelme meg reagalni sem, tudom.

A masodik idezet valoban kicsit tragarra sikerult, de magamra mondtam, nem masokra. Max. masok szajaba adtam a mondatot, ez talan lehet serto. Ha ez a hangnem bant valakit, akkor bocsanat.