Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
De figyu, ha ez jó eredményt ad nekem, amit már feljebb is írtam
para = (ADRESH<<8)+ADRESL; akkor miért akarjuk ezt erőltetni, mikor nem ezzel van gond? para =((unsigned long)ADRESH<<8) + ADRESL; leellenőriztem és para=para-400 -al nekem most 89, ami szerint para-ba jól belekerül az ADRESH és ADRESL értéke. vagy szereinted az a hiba és nem itt? humidity = 0.1590492671*para - 31.20521173;>>>>
Hogy ne mondja senki, hogy nem próbálkozok:
Elvileg a SendChar-ral (Ez biztosan működik) el kellene küldenie egy karaktert az LCD-nek, amit a soros porotn keresztül kap, de nem csinál semmit. (Hiba nélkül fordul. A paramétereket deklaráltam)
Idézet: „De figyu, ha ez jó eredményt ad nekem, amit már feljebb is írtam para = (ADRESH<<8)+ADRESL; akkor miért akarjuk ezt erőltetni, mikor nem ezzel van gond?” Ha szíveskednél elolvasni az assembly listát, akkor látnád, hogy a fenti sor mire fordul:
Ez gyakorlatilag a para = ADRESL; utasításnak felel meg, ADRESH pedig mintha ott sem volna. Csak ezért erőltettem, de felőlem hagyhatod így is...
Hm köszi most már értem, hogy miért írtad ezt annyiszor és beismerem, megint igazad volt
Hát nehezen de úgy tűnik Icserny kitartó munkájával sikerült megoldani ezt a hihetetlen problémát
Most nálam bent a szobában 25 fok van és 46% páratartalom Még1x köszi nagyon! És megőrít ez a fordító!
Én meg szenvedgetek magamban.
Azt hiszem, megvan a hiba. Nem állítottam be 9600 baud-ra. És nem is tudom, hogy hogy kell. Egy PIC16F690-em van, ami a beépített oszcillátorát használja. Ezt hogy kéne konfigolnom, hogy jó legyen? Mit csináljak, hogy a soros port 9600 baud-dal menjen? (A gond ott van, hogy nem tudom, háby herzen pörög a kristály és azt se, hogy hol tudom megnézni. De egy tapasztalt kolléga nézzen rá az assembly-kódomra is!)
Szia!
Idézet: „Mit csináljak, hogy a soros port 9600 baud-dal menjen?” BSF 0x03,RP0 BCF 0x03,RP1 BSF 0x98,BRGH ; SPBRG = 25; // Set 9600 baud for 4 MHz oscillator MOVLW .25 MOVWF SPBRG
Azt mi is nagyon jól látjuk, hogy csak ilyen kevés kondi van(írtam is), ezért mondtuk, hogy kell minden IC-re a lehető legközelebb a lábakhoz.
A nyák furatgalvanizált?
Most akkor mi a nyerő tipp? 1, 2 vagy X?
Hogy áll a páratartalom szenzor hőfokkompenzálása? Arra is van egy szép formula az adatlapban. Idézet: „A gond ott van, hogy nem tudom, hány herzen pörög a kristály” Ebből ne csinálj magadnak gondot! Nincs is kristály... A belső oszcillátor RC időzítésű (azért pontatlan).
Nyerő tipp az 1-es megoldás volt. Bár az X-en még gondolkozom
Páratartalom szenzor hőfokkompenzálásán pontosan mit értesz?
Azért remélem, annyit nem téved, hogy ezt ellehetetleníti.
Még mindig nem működik. Itt a kód:
Valami tipp vagy hiba?
Idézet: „Páratartalom szenzor hőfokkompenzálásán pontosan mit értesz?” A páratartalom-érzékelőd kimenő feszültsége - sajnálatos módon - a hőmérséklettől is függ. Ezért, ha már úgyis méred a hőmérsékletet, akkor korrekcióba lehetne venni.További részletek az adatlapon.
esetleg még egy verzió:
Idézet: „Valami tipp vagy hiba?” Nem értem, hogy miért szenvedsz programmegszakítással, amíg anélkül sem működik? Egyébként meg nem szeretek vég nélküli, bcf status,rp0 meg bsf status,rp1 utasításokkal tűzdelt assembly listákat olvasni. Biztosan a lustaság teszi, de ha egy próbaprogramot gyorsan össze akarok ütni, akkor nálam így néz ki a soros port kezelése: utána meg: printf("formátum",változó); ... osz't jónapot.
Egész számokkal számolva különösen a számolások közben bekövetkező csonkolásokra nagyon kell figyelni. Ezért mindig az adott szóhosszon a maximálisan kifejezhető értékek közelébe kell pl. egy szorzatot "méretezni".
Ha a következő képlet kiszámolása a cél: hum = 0,1590492671 * para - 31.20521173 , akkor azt én egész számokkal a következő módon közelíteném meg: - a fenti képlet így is írható: hum = para / 6,28736 -31.20521173 - para értéke 0-1023 közti érték, mivel az a 10 bites A/D-ból származik - ebből következően 64-gyel megszorozva még éppen belefér az előjel nélküli 16 bites hosszba - ha para-t 64-gyel szorzom, akkor az osztót is ennyivel kellene szorozni, azaz hum = para * 64 / 402,39104 - 31,2 - ezt egészekre egyszerűsítve a következő adódik: hum = para * 64 / 402 - 31 Nomost ez a legutolsó már egész barátságos, a hum értéke (ha jól értettem, amit korábban írtál) egész százalékban lesz (0...100). Ha pl. tizedszázalékos felbontást akarsz, akkor az osztót tizedére csökkentve és az offsetet tízszeresére növelve (hum = para * 64 / 40 - 312 )a hum a tizedszázalékos érték tízszeresét fogja tartalmazni, természetesen egészekben (0...1000).
Nekem a kód asm-ben kell. A megszakításokkal meg nincs gondom. Általában vígan használom őket. Nem hiszem, hogy itt azzal lenne a gond. Inkább valami mással. Csak nem tudom, mivel...
A 690 adatlapjában nézd meg az oszcillátorról szóló fejezetet. Valahol egészen biztosan le van írva benne, hogy ha INTRC-t választasz ki a konfigurációban, akkor milyen frekvenciával indul RESET után. Lehet, hogy az oszcillátor frekvenciáját kiválasztó regiszter (OSCCON?) leírásában fogod megtalálni azt, hogy melyik bitállás a default a RESET után. Ha jól emlékszem, akkor egyébként 4MHz ez az érték.
A megszakításodban van egy sendchar, amit nem látok az idézett kódban. Ha esetleg az vár valamire, akkor az nem biztos, hogy túl jó ötlet a megszakításon belül. De persze könnyen lehet, hogy nem ez a baj.
Én így írnám:
Integer propagation-t talan be kellene allitani - nem tudom ki volt az aki kikapcsolta... Meg hat mikor megkerdeztem mi a teszt adat 485-t volt a valasz, en azt hittem szigetivan ledebuggolta vagy leszimulalta - na mindegy, csak faj, hogy egy ilyen piti problemaval ennyit kell kuzdeni
Ez nagyon tetszik . Azt hittem valami bonyolult kódot csinál belőle, de nem. A C18-as két movff-el megoldotta.
Az csak annyit csinál, hogy a work tartalmát elküldi egy LCD kijelzőre. Egy saját függvény, de érdektelen. A gond az, hogy nem lép be a megszakításba se...
Az egyébként normális, hogy a PIC TX lábán veszültséget mérek? (logikai 1-et ad ki.)
Aha. Nézem a 690 adatlapot, és nekem valahogy nagyon úgy tűnik, hogy nem egy lapon van pl. az RCSTA és a TXSTA, sőt a PIE1 sem a nulláson lakik. Magyarul nem is azokat a regisztereket írod, amelyikeket szeretnéd. Miért olyan nehéz a BANKSEL makrót használni?
Az igen, mert a soros vonal alapállapotban logikai 1. A start bit lesz egy logikai nullás bit.
Köszi, most már értem mire gondolsz
Köszi szépen Szilva, ez hasznos infó volt
Azt hiszem amugy az EUSART-tal rendelkezo PIC-eknel lehet invertalni, de kulon kell kerni - most csak halvanyan emlekszem ilyesmire, remelem nem irok marhasagot
Nem tudtam, hogy van ilyen. Igazad van. Ez is hiba volt. Köszi.
Átírtam. Most ilyen (csatolva). De valami még mindig nem jó... |
Bejelentkezés
Hirdetés |