Köszi a választ; maradok a "jól bevált" "mindhárom-ds-hőmérőnek-külön-szubrutin" elvnél. Mondjuk a programtár jó nagy, lazán belefér (...).

Holnap 4:30-kor kelek, csörög a pizsama. Jó éjszakát Mindenkinek!

Nagyon köszönöm válaszodat majd kipróbálom és szólok hogy jó lett-e .

Köszönöm a kódot.
Kipróbáltam PIC18F4550 mikrovezérlővel. Tökéletesen működik az időzítés. Átváltottam az PIC18F97J60 mikrovezérlőre (mert ennél a mikrovezérlőnél tapasztaltam a hibás időzítéseket) szomorúan láttam, hogy a delay_ms(1) futásának ideje csak pár us ideig tart megint. Visszaállítom a PIC18F4550 akkor jók az időzítések. Megtennéd hogy kipróbálod 18F97j60 mikrovezérlővel, hogy nálad milyen időzítéseket produkál a programod. Előre is köszönöm.

Kipróbáltam azzal is, és nem működik! Nem az időzítéssel van baj, hanem a for ciklus nem működik: egyszerűen átugorja a ciklusmagot, mintha lejárt volna a ciklus.

Nálam is pont ez a helyzet. Akkor vettem észre, mikor egy függvény (amiben több for ciklus is van) végrehajtási idejét szerettem volna megtudni. Gyanúsan kevés időnek tartottam. Megnézem, hogy az assembly kód is hibás vagy csak az MPLAB viccelődik. Elég idegesítő hiba Több MPLAB verziót kipróbáltam, de mindegyiknél ugyan ezt produkálta.

Nem volt időm tüzetesen a körmére nézni, de az assembly kódban nem láttam különbséget, csak annak a végrehajtásában. Úgy tűnt, hogy a for ciklus feltételvizsgálatában siklott rossz ágra: a Carry vizsgálatánál egy bc utasítással kiugrott a ciklusból, amikor szerintem még nem kellett volna..

Ezek szerint valószínű, hogy jó kódot fordít, csak nem jól szimulálja le... Nekem is van egy ilyen PIC, jó tudni ezt!

Ha a fordított kód valóban ugyanaz mindkét PIC típusnál (miért is lenne más, hisz ugyanaz a család, és itt nem periféria-beli különbségeket kell lekezelni...), akkor talán érdemes lenne egy lecsupaszított kódot csinálni, ami még produkálja a hibát. Talán még a Microchipnek is be lehetne jelenteni, ha egyértekműnek tűnik, hogy hiba.

Szerk: bocs, most látom, a lecsupaszítást megtetted. Azt nem vizsgáltad, hogy a for viselkedése függ-e a ciklusmag tartalmától?

Es igy nem mukodik?



(Lehet az overlay-el problemaik ha valami modon rekurzivan hivod meg ezt a fuggvenyt, vagy megszakitasbol, akkor vedd ki).

Optimalizalas is kozbe jatszhat, azt is probald meg allitgatni (hatha egyikkel jo).

Amugy nezdd meg, hogy csak a Delay-el csinalja-e ezt avagy ha pl LED billegtetest teszel bele akkor is?

Most találtam egy olyan összeállítást, ami jól szimulálja az időzítést és a for ciklust a PIC18F97J60-ra is:
MPLAB IDE v8.46
MPLAB C18 v3.35 Upgrade

Ezen a gépen a C18 fordító és tartozékai kivételesen a c:/MCC18 mappába lettek telepítve (nem tudom, hogy ennek van-e jelentősége)

A forráskód ebben a hozzászólásban található. A forrást kiegészítettem ennyivel (hogy ne kelljen a CONFOG-ot kézzel állítgatni): #pragma config WDT=OFF, XINST=OFF, DEBUG=OFF

Optimalizálás: DEBUG
Fordítás: normál (vagyis nem extended) módban

Vizsgáltam, s nem függött a ciklusmagtól. A kivonás, vagy a státuszbitek kezelése körül lehet valami gubanc. De most olyan gép előtt ülök, amin nem reprodukálható a hiba.

Ha az i változó int típusú, akkor teljesen megbolondul a szimuláció(nem áll meg a break-nél a ciklusmagban, valamint nem is hajtja végre a magban lévő utasításokat, viszont az i értéke növekszik.), ha char az i típusa, akkor mindent jól csinál. Én az n helyére literalt írtam(10-et).

Korrigálok: A magban lévő utasítás végrehajtódik, a kellő számossággal, de nem áll meg a magban a break hatására. A futási idő is rendben látszik...
Csatoltam egy képet is. Az a értéke helyesen 10 lett, de a szimuláció során nem állt meg az a=i; sornál egyszer sem.

Ismét korrigálok! Az a értéke nem lehetne 10! csak 9! Jópofa ez a SIM!

Közben a long-al is próbát tettem, azzal jó!

Sikerült ilyen érdekes értékeket kicsikarnom(kép). Ehhez előtte törölnöm kellett a GPRs memóriát. Ekkor az a=i; sorban is megállt a Break-nél a sim. Utána már csak átugrálta a ciklusmagokat, a=10 értéket hagyva a Watch ablakban maga után. Az i=0 volt ilyenkor. Ja és az időkkel is baj van, csak egy ciklusnyit számol ezután.

Figyi, az a==10 az elso ciklus utan -- ebol el arra kovetkeztetek, hogy mege a ciklus jo, 10-szer hajtodik vegre, csakhogy a break point a rakovetkezo "i=0" utan all be a for ciklus fejleceben, nem pedig a for ciklus elott. Vagy rosszul laom? Csak abbol ered ez, hogy nincs elotte az "a" inicializalva? Optimalizacio be van kapcsolva? (Azt nem szabadna, mert az ilyen butasagokat csinalhat a debuggolas kozben)

Sziasztok! Most próbálok egy pic 12f629 be progit rakni ledes villogóba. de ezt írja ki (melléklet). be akartam olvasni a hex fájlt.

Nincs optimalizálás, viszont extended módban minden újra jól működik!!!

Tedd fel a hex fájlt! (Nem felel meg az intel szabványnak, vagy valamit én néztem el...)

Ok, tehat magyaran a forditas is jo es a szimulacio is, max a torespontok vannak rossz helyen, legyen az lepesenkenti vegrehajtas avagy beallitott torespont.

Kipróbáltam a fenti kódot. Az MPLAB szimulátora az 1ms időzítést 7,04 us számolta. A PIC-ben a program rendesen fut 1ms időközönként változtatva az RJ0 lábat. Az MPLAB szimulátora viccelődik velünk de csak a for ciklusnál lépi át a ciklusmagot.

Állítsd be az extended módot.

Köszönöm. Az extended mód beállítása után az MPLAB szimulátora is helyesen működik.

Csak szólok: A C18 ingyenes változatában (a próbaidő leteltével?) nem támogatott az extended mód. Legalábbis hivatalosan...

ok a Vicsys oldaláról néztem el a kapcsolást és a picbe égetendő progit is.

Vedd ki a két utolsó, pontosvesszővel kezdődő sort a hex-ből és próbáld úgy! Szerintem csak az zavarja meg az égetőprogit,

Igaza van szilvanak, csatoltam.

Nem tudom amúgy, hogy az ilyen pontosvesszővel kezdődő sor szabályos komment-e ezekben a hex fileokban, de valószínűleg minden, nem kettősponttal kezdődő sort érdemes eldobni.

Nagyon köszönöm mindkettőtöknek és köszönöm, hogy kijavítottad Watt.

Nagyon köszönöm még egyszer elsőre sikerült beleöltenem a picbe. De van egy kis gondom amikor beleteszem az áramkörbe nem csinál semmit, a pic belerakása előtt leellenőriztem az 5 voltot és nem volt seholrövidzár. Beletettem a picet és bekapcsolom (FBI os villogo és 3-3 led van a kimenetén sorbakötve). amikor hozzáérek a réz felülethez a tranzisztorok körül világítanak. de a pic lábain az 5 volton kívül nem "találok' semmit.