Itt vannak a parancsok:


De a konverziós parancs után nem kell külön parancsot kiadni, csak olvasni kell a portot, majd ha kész, kiolvasni a hőmérőt.
A flowcode makró blokkja után nem kell, mert benne van a késleltetés, inkább várakozás, ami elég gáz megoldás. Ha külön adod ki a konverziós parancsot és azonnal kiolvasod, akkor az nyílván rossz eredményt fog adni. Már megvan az tervem a megoldásra, hogy minden menjen és közben konvertáljon csak magában a hőmérő. Na most eszem!

Köszi! Megvan, működik C nélkül! Hamarosan felteszem a megoldást, mert ki kell szednem egy nagy programból és most el kell ugranom...

Csatoltam a megoldást.
Lényege, hogy a konverzió indítását a Timer0 megszakításban egy segédszámláló ütemezésében kezdem, kb. 1 sec-enként, majd utána a Timer0 megszakításában (183Hz) ellenőrzöm, hogy befejeződött-e. Ha igen, beállítok egy jelzőt, amit a fő ciklusban figyelek és ott történik meg a kiolvasás, formázás, kijelzés.
Az egészben egy jó dolog van, hogy ezt megengedi a Flowcode one wire blokkja, ami rossz, hogy még is készítettek nekünk egy olyan blokkot is, ami majd egy másodpercre megállítja a program futását és erről nem nagyon dicsekedtek.
Persze itt jön az a fő gondolat, amit ebben a topicban sem szabad elfelejteni, hogy ha valaki nem tud programozni az Flowcode-al sem fog tudni és könnyen összelapátol egy olyan folyamatot, ami használhatatlan...

Nem tudom, hogy megjegyzi-e a címet, amit előzőleg elküldtem, de nem is érdekes, mert utána csak olvasni kell a portot, ha nem nulla, akkor kész a konverzió.

Nekem ez már kínai. Pláne másik mikrovezérlő típus...

Mindegy milyen PIC, működnie kell.

Viszont a korábbi kódodban nem csak a kijelzés hibádzik, hanem a századok kiszámítása is. 90 századról ugrik egészre, holott 93 századról kéne. Tudod miért?

Nem foglalkoztam még mélyebben a dologgal. Az volt a cél, hogy elinduljon. Lássam, hogy az egész rendszer, programozás, letöltés, futtatás megy e.
20 éve ez az első pic projectem. Azelőtt még a parallax ASM volt c52 és 84 vezérlőkkel. Már rég elfelejtettem. Újrakezdő vagyok.

Miért?

Azt hittem tudom, de kiderült, hogy nem.

Annyi!
228000/9600=23,75
23*9600=220800
228000-220800=7200


Vagy

9600*0,75=7200

Túl gyors voltál!

Persze, hogy annyi, csak én belekeveredtem.

Naszóval, a 380 MOD 16 az 12. Ezt szorzod 6-al, akkor az 72
Ellenben ha 380*100=38000 MOD 1600 = 1200 /16 = 75 ami a helyes érték
Tehát kerekítési hibát szorzol, ami csak növekszik. Ezért először fel kell szorozni az alapot.

Ha valamit nem értesz a csatolt folyamattal kapcsolatban, nyugodtan kérdezz, nem túl bonyolult, csak a szervezés logikáját, indokát kell megérteni.

Később kipróbálom. Most a porszívót idomítom.

A megszakítás nekem idegen dolog.

Ezzel a MOD dologgal van még némi probléma, hogy csak kijelzésre jó. Összehasonlításhoz jobb lenne egy fixpontos szám. Ezt elő lehet állítani végül is, ha az egészeket szorzod 100-al és a MOD-al kiszámolt maradékot hozzáadod. Így pl. a 23,75 esetén 23*100+75=2375 lesz, amivel már lehet szabályzókörökben dolgozni...

Mivan, nem indul a porszívó!
Ennek véget kell vetni, összehozlak vele!
A megszakítás egy olyan szubrutin(elkülönített programrész), ami csak akkor hajtódik végre, ha egy megszakítási esemény ezt kéri. Ilyen a Timer0 túlcsordulása is. Ekkor a program megszakítja az éppen folyó dolgát(elmenti amit el kell, hogy emlékezzen hol ját) és elkezdi végrehajtani a megszakítási rutint. Amikor azzal végzett visszatér és folytatja tovább a következő megszakításig.
A megszakításban csak nagyon fontos dolgokat szabad végrehajtani, amik nagyon rövid idő alatt lefutnak. Ezért használunk jelzőket. A kijelzés, hosszabb számolás már a fő rutinban ráér. Persze vannak egyszerű számolások(nem lebegőpontosak) amiket ha fontos, még ott el lehet végezni, de ez ritkább és el kell tudni dönteni, hogy mennyire sűrgős.
Most mennem kell, 3/4 óra...

Float-ot nem a PIC-nek találták ki, csak nagyon indokolt esetben szabad használni, nemrég volt erre példa, hogy 3 számítás telenyomott egy 2000 szavas 16F-es PIC-et!

Nézd meg mekkora kódot fordít és milyen lassút!

Igen! Az csak a kijelzéshez jó. A folyamat irányítására ott van az a szám, amit a DS-ből beolvas a Get_Temp.
Ha temp=
352 az 22°C.
336 az 21°C.
320 az 20°C.

Ugye 1 °C 16 részre van osztva. Ezzel már lehet kereskedni.

De indul. Csak van az elején egy ilyen hosszú, ormányszerű izé. No azt kell elég sokat toszigálni előre, hátra.

Ezt így elméletben tudom is, csak még nem gyakoroltam.
Nem úgy mint a porszívózást.

Ha mínusz a szám akkor a kettes komplemensét kell képezni +1

temp=~temp+1

Ez a sor nem kell
2. temp2 = temp2 / 10

Mit számolgattok ilyen bőszen?

Nálam ez így néz ki:


Mínusz esetén 0-ból kivonom és előjelet rajzolok az LCD-re.

Még egy hasonló blokk van, ami érdekes dolgokat tud okozni, ha nem nézünk mögé. Ez a gomb kezelése. Azért elég tré megoldás, hogy a gombhoz beállított "időzítés" valóságban várakozás, ami szintén elfogadhatatlan egy jó programban.
Fontosnak látom ezt tudni és hanyagolni, helyette normális gombkezelést írni, amit tökéletesen támogat a környezet.

Ha valakinek van ötlete várom, mielőtt lelőném a poént, ti hogyan csinálnátok?
Feladat, hogy a gombok kezelése ne vegyen el időt a fő száltól, csak annyit amennyi feltétlenül szükséges, azaz emberi léptékkel észrevehetetlen. Ha a fő szál valami miatt megakadna(pl, LCD kjelzés, vagy egyébb időigényesebb számítás) akkor a gomb lenyomása ne vesszen kárba. Legyen prellmentesítés, beállíthatóan, valamint legyen egy késleltetett ismétlés is. (ha ez 13 blokkból megvan, akkor ügyesek vagytok! ) A gomb lenyomásának tényét kell megoldani, a gomb lenyomásához tartozó események lekezelése természetesen külön történet, ahhoz több blokk kell...

Később tovább léphetünk az ismétlési sebesség menet közbeni módosítására, hogy könnyebb legyen egy adott érték beállítása. Másik megoldás a helyiérték léptetése, de ez már a gombhoz tartozó esemény lekezelése...

Segítségként, Timer0, vagy más időzítő megszakítás szükséges hozzá.
Jó fejtörést!

Csupán a késleltetés nem oldja meg a felsorolt kívánalmakat.
A LED-ek azért jók, mert lehet szimulálni a kimenetet velük. Igaz, talán a Chip ablakban is követhető a láb állapota.
Ezekkel az átgondolatlan makrókkal az a baj, hogy képesek olyan program kialakítására rávenni azokat, akik nem látnak beléjük, ami nem fog működni, vagy nem jól. Itt aztán jön a roló...

Még annyit, hogy ha direkt használod a portokat, akkor be kell tudnod állítani az irányukat, ami C blokk nélkül bajos. Viszont megnéztem pár blokkot, igen lazán bánik a programmemóriával. A flowcode nem arról lesz híres, hogy tömör kódot fordít. Persze, lehet, hogy a hex fordító jól optimalizál!

Bocsi, most látom, hogy vannak Be és Kimenet deklaráló blokkok. Így kicsit más a menet. Hiába ezt még én is csak most tanulom!

Ezek a makrók átírhatók véglegesre.

Ezeknek a blokkoknak eleve nem így kéne létezniük. Viszont azt nem állítom, hogy könnyű lenne eleve jó megközelítéssel blokkokat gyártani! Elég komoly ellentmondás!

Akkor szerintem maradjunk annyiban, hogy ez a program a már nem kezdőknek való, akik hamarosan tovább lépnek a "C", majd asm felé.