Most csak struktúrálisan futottam át, de igen, erről van szó.
Az a 750ms várakozás eléggé csúnya, inkább egy timer megszakításban időzíts, és ha lejár egy jelzőt beállítva a fő ciklusban folytatódhat a kiolvasás.
Van parancs, ami ellenőrzi a konverzió elkészültét, ezt időzítés helyett lehet használni, szintén timer megszakításban rápillantva egy kiválasztott ds-re.
Így lesz időd kijelezni, gombot vizsgálni stb.

Értem, megpróbálom. Azt hiszem ami ellenőrzi a konverzió elkészültét, az az, hogy amíg a ds dolgozik, addíg 0-t kell visszaolvasni.
Ha végzett, akkor 1-et.
Szóval:

Ezt kellene belehelyezni a megszakítás rutinba.

Az utasítás stimmel, az eljárás nem. Nem szabad megszakításban várakozni. if-et kell tenni és jelzőt beállítani egy timer megszakításába. A jelzőt pedig a fő programciklusban vizsgálni és lekezelni.

Igen, teljesen igazad van. Meggondolatlanul kivágtam a régi ds függvényből és beillesztettem.
Húúú, azért lefárasztó tud ám lenni a programozás...

Idézet:
„Húúú, azért lefárasztó tud ám lenni a programozás...”

Az nemis annyira. Előtte végigondolni és eltervezni az egészet apró részletekig, na az, ami fárasztó inkább

Na meg amikor két napja nem megy valami, aztán rájössz, hogy hibás a panel, amit küldtek, és persze, hogy azért nem működik, mert rossz lábakra fut be az adat és az órajel. De persze ez előtt még rájössz, hogy az oszcilloszkóp kábele is törött, azért nem kapsz jelet még egy villogó led lábáról sem, nemhogy az órajellábról Ez történt kb. két hete...

Alapvetően az a gond, hogy késleltetést használsz, ha jól értem (delayxxx?). A késleltetést próbáld elfelejteni.

Én pl. általában úgy csinálom az ilyesmit, hogy a timer 1ms időalappal fut, és ott növelgetek különféle változókat, amik ha elérnek adott értéket, akkor bebillentem a hozzájuk tartozó flaget, és nullázom a változókat. A főprogramban pedig minden programrész figyeli a saját flagjét, ha az egyesbe váltott, akkor lefut a hozzá tartozó kód, visszabillenti nullába a flagjét, és várja, amíg ismét egyes nem lesz. Pl. esetedben csinálhatod azt, hogy az 1ms timer megszakításban növeled egy belső, static kétbájtos változó értékét, amikor elért 50000-re, akkor nullázod, és beállítod a kijelző flagjét. Ha a főprogram látja a kijelző flagjét bebillentve, akkor bemegy a saját rutinjába, ott egy belső számlálón billent egyet (ez a számláló jelzi majd, hogy melyik csoportot kell a kijelzőre kiírni), a számláló értékétől függően kiírja a kijelzőre a megfelelő hőmérsékleteket, nullázza a flaget, és kész is a saját dolgával. Csatoltam, úgy jobban olvasható.

Fúú írtam egy olyan f...a programot, hogy elszállt az egész eepromom.
Nem tudom mit csinált, de kitörölte az egészet, plusz az lcd-re is tiszta baromságokat írt ki.
Ajaj. Na jó, megfogadom potyo a tanácsodat és átszervezem az egészet.

Még annyit szeretnék kérdezni, hogy szerintetek érdemes az átlagolással foglalkozni?
Csak azért, mert néha észreveszem, hogy 2-3 naponta 1-2x valamelyik ds nem jól mér, és ha van kb 27 fok, akkor az egyik mérése 60-80 fok lesz, de utána egyből megjavul.
És crc hibát nem hoz.
Vagy a rutinban lehet a hiba?

Ha nem kell gyorsan mérni, akkor mérsz hatot, a legkisebbet és a legnagyobbat kidobod és a maradék négyet átlagolod. kb. 5sec lesz a mérési idő így. De nagyon fura, hogy crc hiba nélkül többet mér, mint amennyi van.

Na mostmár nagyon szép kis program lett, csak a soros port nem akar válaszolni.
Átnézné valaki, hogy mit rontok el?

Közben sikerült kijavítanom a hibákat, mostmár szépen küldi is az adatokat, csak annyi problémám maradt, hogyha nem jó parancsot kap a PIC akkor onnantól kezdve nem szakad meg a program soros adat fogadás esetén, pedig nem is tiltom le.
Kipróbáltam Pickit2-vel debugolás közben és ha pl. jn egy *73 akkor onnantól kezdve nem ugrik az isr függvény soros részére.
Van valakinek ötlete?

Szia!
Hibánál nem elég letiltani és újraengedélyezni a USART -ot, a hibás karaktert ki is kell olvasni. Különben a megszakításkérése nem törődik.

Szia!

Itt a cgetchar-ban kiolvasom.

De a putch -ban nem.

Az a baj, hogy nem akar megszakadni, miután nem a *71 vagy a *72 jött, hanem *7 és valami más. Ez után semmi.

Figyelmedbe ajánlom.

Egy tömör mintakód az interrupt kezelő algoritmusára:

Köszönöm a segítséget. Innen menni fog.

Ejha, ebben aztán minden benne van. Köszönöm szépen. Ám lenne vele egy kis gondom.
Az hogy eldobáljuk a puffer tartalmát, az mit jelent?
A másik, hogy
Nekem erre hibát hoz a fordító. Azt írja, hogy nem megfelelő eljárás.
A frameerr az egy változó?

Error [243] D:\Munka\Cseko\cseko_hom_logger_pic_130814\main_potyo.c; 81.1 inappropriate break/continue
Ezt kapom a fordítótól. Ha kiveszem a continue-t, akkor jó, csak az már ugye nem azt jelenti.

Az, hogy ami a pufferben van, azt ki kell olvasni, majd nem használni semmire. Ezt csinálja a belső while ciklus.
A frameerr egy változó, amibe el kell menteni az FERR bit értékét, mivel az a várakozó byte kiolvasása előtt valid, utána már a következő byte-ra vonatkozik. Ha az FERR igaz volt, akkor az adott byte valószínűleg hibás, ezért szintén el kell dobni (nem használni semmire).

Talán a külső while ciklust kihagytad, azért.

Igen, de az nem gond, hogy megszakításban van?

Szóval így?

Akár. De szerintem ha több byte-os üzeneteket akarsz küldözgetni, akkor
- valamivel jelezni kéne, hogy melyik az első byte (mondjuk pl. legfelső bit = 1 az első byte-ban, és = 0 a többiben),
- ha bármilyen hiba van (akár frame akár overrun), akkor a komplett aktuális több byte-os üzenet megy a levesbe, és várjuk a következő első byte-ot,
- a több byte-os üzenet végére kéne valami checksum-szerűség, ha az nem stimmel, akkor megintcsak megy a levesbe az egész üzenet.

Igen, valószínüleg LRC lesz benne. Csak itt megálltam, mert nem akart működni ez a dolog, de most már simán megy.
Elvileg a bejovo_puffer.hossz akkor van nullázva, ha jön egy *. Ez jelzi, hogy lekérdezés lesz.
Utána vár 2 karaktert és ha az első megegyezik a PIC címével, akkor a főprogramban kiértékeli, hogy mi a második karakter (ez mondja meg, mit kell csinálnia).
Ha a PIC cím nem egyezik meg, akkor a bejovo_puffer.hossz-t 1 be írom, vagyis addíg, míg újra nem nullázzuk a *-gal, addíg nem fog kiértékelni.

Okés, csak arra akartam utalni, hogy ha bármilyen hiba lép fel, akkor tudni lehet, hogy minimum egy byte nem érkezett meg jól, tehát az egész üzenet komplett használhatatlan.

Nagyon köszönöm a segítségedet. Rengeteget tanultam belőle!

Szia! A frameerr segédváltozóra miért van szükség?