Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Ez egy tökéletes megoldás(én is így szoktam, ha ez számít).
Érdekes, hogy sok tökéletes megoldás van csak a többi programrésztől függ, hogy az-e. Ha jól együttműködik, akkor tökéletes! 
köszi, megnéztem: 134us telt el a 2 megszakítás között
mellékelem a kapcsolódó forrást Idézet: „megnéztem: 134us telt el a 2 megszakítás között” És Te mit szertnél, mennyi legyen? (mert ez így nem mond semmit nekünk.)
mondjuk 500us
 azt hittem ezzel már lehet vmit kezdeni, h mit mire változtassak, mert így olyan mintha sötétben tapogatóznék
Amit beírtál időt(134uS), az kb megfelel a 48/4/8/256 osztásnak, amit írtál. Ezek szerint 8bites módban használod a Timer?
8 bites módban túl gyakori a megszakítás. A legalacsonyabb freki 183,105..Hz, ami nem valami baráti. Ha beállítod 16bitesre, akkor 48M/4/256/46875 pont egy hertz-et kapsz, és 0,00002133 sec-enként tudod hangolni az órát.
Ezzel a sorral rontod el az órád pontosságát:
Idézet: „nem értettem, hogy miért a config előtt indítja a konvertálást,” Nem tudom én sem, hogy miért. Egy biztos a CCS eredeti ds1621 drivere is ebben a sorendben írja, és így működik is. Idézet: Nem a datah-ból, a data-ből kell elvenni!„a kiírásnál miért kell kivonni a datah-ból 256-ot?” Amint látod, a datah változó egész típusú, előjel nélkül. Ez kerül a lebegőpontos data-be, tehát abban pozitv számként jelenik meg. Pl. ha a hőmérséklet értéke a -25, akkor az ugye kettes komplemensként így néz ki (így jön a ds1621-től): 11100111, ami ha nem előjeles értéknek vesszük 231-et jelent, ezért a lebegőpontos szám is 231.00... lesz. Láthatod, hogy a tényleges értéket úgy kaphatjuk meg, ha ebből elveszünk 256-ot (231-256=-25). Hát ezért. 4,7 k-s ellenállások helyett, annak környékéről is választhatsz, ahogy a magyar leírásban is benne van.
Azóta egy kicsit behatóbban átnéztem a kódodat, és több sebből vérzik, mint ahogy az is, amit én írtam, hogy kellene megcsinálni. Írtam egy rutint, ami úgy néz ki, jól működik, pontosan egy másodpercenként hajtja végre a seconds++ sort. Az Init() részben így állítsd be a Timer0-t: T0CON=0b10001000;
Ha nem világos valami benne, akkor majd később válaszolok a kérdésekre, illetve leírom majd azt is, hogy mik voltak a problémák. Most el kell mennem.
Közben én is nézegettem ezt a lebegőpontos data-t és arra jutottam, ha előjeles egésznek definiálom a datah-t, akkor a lebegőpontos is az lesz, és fölösleges a 256 kivonása, mert egyből a helyes érték jelenik meg!
 (Csak augusztus óta próbálkozom C-ben, de majd belejövök.)
köszi szépen, 1órája fut pontosan
az osztót úgy néz ki végig hibásan számoltam, nem vontam ki a kompenzálást néhány dolgot tényleg nem értek: miért kell megállítani a timert? a 17. sorban az if nem tiszta, hogy miért kell éselni 256-al a cf-t, nem elég csak simán hozzáadni a kompenzálást? initkor a timer mennyiről induljon? kompenzálásról v 0áról? benne felejtettem a kezdet konstanst ami 85, de így is jónak tűnik így gyorsabb a kód, ha hexában vannak a számok? MPi-c: köszi, így már értem én simán double típusú változóba mentem, elvileg stimmelnie kell így az előjelnek van magyar ds1621 leírás? a Kandó jegyzetre gondolsz? abban csak fél oldal a ds1621 ről szóló rész, ha van komolyabb, honnan lehet hozzájutni? azt vágom, h ack-val kell jelezni a sikeres byte fogadásokat, csak azt nem, h az MCC18ban lévő SWAckI2C() az küldi v fogadja az ackt? vagy az i2c megvalósításban már eleve benne van? meg a doksiban lévő pl is zavaros, control byteokat küld (0xA0) minden start után a picc-ben állítani kell, hogy a pic master vagy slave, itt nem? persze lehet, h csak az ellenállás miatt nem műxik, majd egy hét múlva kiderül Idézet: „miért kell megállítani a timert?” Azért, mert ha közben fut a Timer, akkor előfordulhat, hogy a TMR0L túlcsordul a cf=TMR0L és a TMR0L= (unsigned char) cf; sorok végrehajtása között, és akkor ez a túlcsordulás nincs lekezelve, mert a TMR0H csak akkor olvasódik ki a hardverből, amikor a TMR0L-t olvassuk (ezért nemis lehet az említett két sort megcserélni, mégha látszólag semmi közük sincs egymáshoz). Idézet: Képzeld el a következő helyzetet: amikor erre a részre ráfut a kontroller, akkor a TMR0L értéke 0xE0. Ha ehhez hozzáadnád a KOMPENZALAS alsó bájtját, akkor az összeg már nem fér el egy bájton. Ha nem fér el egy bájton, akkor a TMR0H értékét meg kell növelni 1-el, és ennek felismerésére van az ÉS 256 művelet. Ezzel tulajdonképpen a cf 8. bitjét ellenőrizzük le.„a 17. sorban az if nem tiszta, hogy miért kell éselni 256-al a cf-t, nem elég csak simán hozzáadni a kompenzálást?” Idézet: „initkor a timer mennyiről induljon?” Mindegy, csak arra hat ki, hogy indulás után mennyi idő múlva jön az első megszakítás. Utána úgysem számít, hogy mi volt initkor. Idézet: „így gyorsabb a kód, ha hexában vannak a számok?” Nem gyorsabb, mert a fordító és a kontroller úgyis binárisan működik, csak egyszerűbb és átláthatóbb a bináris vagy decimális helyett a hexadecimális forma. Amit az elején írtam, hogy nincs lekezelve a túlcsordulás, abból adódik egy hibalehetőség, ami csak most jutott eszembe. Ez a sor helyett:
Az I2C magyar leírására gondoltam, abban vannak táblázatok az ellenállások értékére.
A C18 kérdéseidet másra hagyom, a függvényeit nem ismerem és leírásom sincs azokról...
értem
nagyon szépen köszönöm a segítséged és a többiekét is! az idő számolás megvan, már 'csak' be kéne vhogy állítani, remélem menni fog egyedül is MPi-c: megkaphatnám azt a leírást?
megírtam a beállítást, nem bonyolítottam gombokkal
átraktam a cdc firmware-be a kódot és usbn keresztül kapja a másodperceket egész este bekapcsolva hagytam, reggelre sajna összeszedet (a változatosság kedvéért) kb 5 másodperc sietést átnéztem a kódot, jól másoltam át hogy lehet korrigálni?
Bocsi, van valami kulonleges oka, hogy nem hasznalsz masodlagos orajelnek kulso 32.768-as orakristalyt?
Nekem az egyszerubbnek tunne, mint itt bokazni a korrigalasokkal.
Sziasztok!
Megint elakadtam...A múltkori LCD s dolog működik ugyan, de valamiért 16 osával számol 255 ig, és egy teljes potifordításra kb 10 szer túlcsordul. Miért lehet ez? A múltkor mikor este próbáltam észre sem vettem, láttam hogy számokat ír ki nem egyéb karaktereket, azt hittem készen vagyok...hát nem. :no: Próbáltam már a a teljes tápfesz helyett külső referenciával variálni. Nincs eredmény. Valami osztás problémám lehet, de nem sikerül rájönnöm hogy mi. Az a rutin amit a konvertáláshoz használok önállóan működik, ha beírok neki egy "X" bináris vagy dec. számot, azt kiírja hibátlanul az LCD re. De ha már az ADC kimeneti értékét konvertálja akkor már 16 osával számol nem egyesével. Én azt szeretném hogy 0 - 10 ig számoljon a ref. 0 és max értéke között. Mi lehet a gond?
Ha tudod, hogy mondjuk x másodperc alatt szedte össze a sietést, akkor (60000*5/x)-el vedd kisebbre a KOMPENZALAST.
Az ADC-nek meg lehet adni, hogy jobbra vagy balra igazitsa a szamot. A tied valszeg balra igazitott.
Allitsd be 'right justified'-ra.
Bár szerintem jó helyen van mert helyiérték szerint helyes amit kiír az LCD re. A poti egyik állásában 000 a másikban 255. Csak az a gondom hogy miért 16 osával számol, és miért számol 11 X 255 ig mire a végére tekerem a potit?
Nem lehet, hogy nem jó oldalra igazítod az AD konverzió eredményét? Ezesetben ugyan elvileg négyszer csordulna túl, de ki tudja. Mindenesetre jó lenne látni a kódot!
Akkor mi is a problema?
Mit ertesz azalatt, hogy szamol? A potmeter/ADC feladata, hogy az allast megjelenitse, vagyis hol van jelenleg a tekerogomb. Ha a ket vegallas jo, akkor az igazitas is megfelel. Ez esetben mashol keresd a hibat. Mi is lesz belole?
A KOMPENZALAS értéke helyett, (15B0) szerintem 15A0 -t szerettél volna írni.
Pillanat mert most meg úgy belenyúltam valamibe hogy egyáltalán nem megy...
 |
Bejelentkezés
Hirdetés |
