Szerintem nem is látod az eredményt, hiszen a kiszámolt 16 bites bináris értéket egy laza csuklómozdulattal ki akarod küldeni a soros porton, mintha az egy 8 bites ASCII karakterkód volna...

A képleteket nem tudom, hogy honnan vetted, így ellenőrizni sem tudom.

Az ADC kezelésben csúnya, hogy minden kiolvasásnál össze-vissza kapcsolgatsz mindent. Ehelyett inicializálásnál kellene egyszer beállítani az órajelet, a TRIS regisztereket, az üzemmódod, s kiolvasásnál már csak a csatornákat váltogasd, illetve a konverziót indítsd.

Az képletek eredményeként nekem 0 - 125 közötti értéket kéne adnia, ezért gondoltam, hogy így jó, ha csak ennyi van kiküldve. Bár ez felvet egy másik kérdést, hogy a 16 bites számomból a felső vagy alsó 8 bitet küldi ki?Szóval igazad van, ez így nem jó.
Képleteim:
höm és
hum
Az ADC-t kijavítottam, hogy könnyebben átlátható legyen.

Csatornaváltás után még kell várni "acquisition time"-nyit, hogy az A/D bemenetén lévő kapacitás az újonnan kiválasztott analóg bemenet feszültségszintjét át tudja venni. Ezt szokták úgy is csinálni, hogy az A/D mérés után közvetlenül átállítják a majd legközelebb mérendő csatornára az A/D-t, és csak ezután kezdik meg az aktuálisan mért érték feldolgozását.

Te, ha csak 0-125 lesz az eredmény, akkor miért nem elég a 8 bites felbontás ?

Igazad van, már leesett. Viszont akkor két részletben kell elküldened, ha már egy 16bites változóba teszed a mért értéket.

Sztem rosszul fogalmaztam, a mérés eredményeinek kell 0-125 közötti értéknek lennie legeslegvégén (bin to ascii átalakítás után). Ha majd szeretnék nemcsak egész értékeket mérni, hanem tizedes pontosságig, akkor biztos kelleni kell majd a 16 bitnek.
És ahogy írtátok a képletnél, ha el akarom kerülni a tizedesvesszőt, akkor át kell alakítgatni a képletet és ide kell a 16bit, na meg az ADC-hez is sztem.

Na, megnéztem a 16F946 adatlapjában, sajnos ezt írja:

Azaz alvás közben, aszinkron módban nem fog megtörténni a Compare mód által kiváltandó interrupt. Valószínűleg néztem én ezt annak idején, vagy ha nem is pont ezt, akkor azt, hogy mik azok, amik ki tudják alvásból billenteni a CPU-t, és amiatt nem is foglalkoztam a CCP modulos megoldással. Ha a PIC állandóan aktív lenne, akkor tényleg jó ötlet ez a special event triggeres Compare mód.

Én a fogyasztás minimalizálására törekedtem, mert egy elemről működő órát akartam építeni 3.5 digites LCD kijelzővel (18 mm számmagasság), ezért is használtam 16F946-ot. A dolog annyira jól sikerült, hogy 3 db AA elemről járatva 5-6 uA-es fogyasztást mérek az órán. Azóta belekerült még egy DS1821-es hőmérő lekezelése is a firmware-be, a szondát fél percenként kérdezi le, ami kb. 750 ms-os, kb. 1 mA-es áramcsúccsal jár, ezt elosztva 30 másodpercre még mindig csak 35-40 uA körüli az átlagáram.

A fura az, hogy ha mikor csak a 8bitet küldtem kis és most meg 16 bitet a tanácsaitokra hallgatva, az eredmény megegyezik..PIC hogy kezeli az MSB és LSB kérdést, milyen sorrendben küldhetünk?

Azt hiszem megvan, javítsatok ki ha rosszul gondolom. Szóval 16 bitet 8 bitenként küldöm, akkor először a 0-7 bitet küldjük, aztán jobbra eltoljuk a biteket és 8-15 küldjük és így is van a programban..

Igen, itt teljes mértékben a szoftverrel döntöd el, hogy milyen sorrendben és milyen darabolásban küldöd el az értékeket a soros vonalon.

Megjegyzem, a két 8 bites kód is elég nehezen "olvasható" ember által, esetleg ha hexa megjelenítést tud a terminál, amiben nézed, az egy fokkal jobb, de a programodba nem lenne nagy kunszt beleépíteni legalább egy hexa kiíratást, hogy a sima terminálon is olvasható eredményt kapj.

Sziasztok!
pár oldallal előbb felvetettem egy ötletet, az órával kapcsolatban.
És mielött mindenki félreértene mindent, nem 240 led lesz, hanem csak 132, és mátrix módban.
Az IC1 RA0-ás lábára megy a léptető, az "órát" meg valami másik, kisebb lábszámú IC vezérelné, az IC2-től (RC7) kapná a jelet.
Remélem ennyi infó elég!

Igen pont én is így akarom elvégezni, miután megkapom a mérés végén a bináris számom, azt szeretném átalakítani ascii kóddá, és így kiküldeni soroson a terminálnak..

Kiprobaltad mar, hogy mekkora fenyt ad a led-ed 500uA mellett? Amugy lehetne sokkal kevesebb szammal is LED-eket hajtani. Pl van egy trukkos kapcsolas, ahol egy port + meg egy pin segitsegevel 8 digites 7+1 szegmenses kijelzot meg lehet hajtani:

Bővebben: Link

és ennek mi az értelme?
Valamint én NEM digitálisat szeretnék!

Amennyiben MCP9700/9700A típusú hőmérőd van, akkor a hőmérséklet képlete jó, bár egyszerűbb alakban is írhattad volna:

temperature = 125*homer/256 - 50

Ebben az a frankó, hogy a 256-tel való osztás egy nyolc bites jobbratolással elintézhető... Előtte azért a "homer" erteket jó volna ellenőrizni!

A másik képleted szerintem rossz. Az adatlapból nekem úgy tűnik, hogy:

Rh = (Vout - 0,958)/0.0307 ebőla Vout=5*para/1024 feltételezéssel nekem az jön ki, hogy:

Rh = 0.1590492671*para - 31.20521173

Neked meg: (500*para - 81800)/3
Ez valami borzadály!

Itt is ellenőrizni kellene para értékét, mielőtt belemerülsz a képletekbe!

64 db LED 8 pin felhasznalasaval... A Te kapcsolasodban 60 db LED-hez elhasznalsz 16 pint es emiatt egy masik kontrollert is beteszel az aramkorodbe IO expanderkent.

Az, hogy ezt a 64 db LED-et hogyan helyezed ez az mar maganugy

Ha megszámolnád akkor az is 16 db kivezetés

Csak finoman a kiemelésekkel - főleg, ha nincs is igazad. Némileg korrigáltam.
-- kobold

Szerintem te meg nézd meg a betűjelöléseket mellettük, mielőtt trudnai-nak így válaszolsz, mert az bizony csak kilenc kivezetés.

OOPPPSSS!
Az egész viszavonva!
Bocsi mindenkinek

Elég lesz kevesebb szmájl is!

Norberto

Ezt nem ismertem, trükkös megoldás, köszi!

Steve

Egyébként ennek mi a működési elve?

http://en.wikipedia.org/wiki/Charlieplexing

Charlieplexing - Reduced Pin-Count LED Display Multiplexing

Topinak is van cikke hozzá: itt

Köszi a válaszod!

Igen MCP9700-es hőmérőm van, és hát a képletem, mint minden más nem a legegyszerűbb módon lett felírva(na de ez legyen a legkevesebb, fő hogy jó!).
Egy kis változtatás után, az ADC által mért értéket jól adja át a képlethez, ami jó eredményt is ad és megfelelő módon reagál ha melegítem.
Az Rh-s képletnél még nem jöttem rá, hogy hol írtam el, most ennek állok neki, de az tuti, hogy itt már az ADC-ből rossz érték jön ki.:S Ahogy számoltam itt binárisan 164=0% és 777=100% közti értéket kell, hogy kapjak, de 84-et ad...
Lenne ötletetek, hogy hol kezdjem a hibakeresést?
köszi

Hi-Tech C-ben unsigned char tipusú változót (dcc_data nevű változó a lenti kódban) hogyan célszerű megjelenítéshez binárissá konvertálni ?

magamtól ezt írtam, működik is:


csak arra gondoltam hátha van nektek jobb, szebb, hatékonyabb megoldásotok. Az is jó ha stringbe íródik be, mert van lcd_put_str(char Str[]) függvényem is.

Sokkal egyszerűbben szerintem nem lehet, esetleg az osztás helyett célszerűbb lenne >> operátort használni, meg a while(i) is elegendő, mivel a fordítónak minden 0-tól eltérő számot igaznak kell kezelnie (remélem legalább is)

Voltmérő

Köszi az ötletet. Átírtam, nem változott semmi, word-re ugyanakkora a program. Úgy látszik Hi-Tech jól optimalizál.

Úgy legyen. Nekem a C18-ast PIC18f1320-ast használva sajnos nem sikerült rávenni a BSR (lapválasztó) regiszter használatának mellőzésére, pedig ennek a chipnek csak egyetlen lapja van, mivel csak 256 byte RAM-ot tartalmaz.

Szia!

Megnéztem mit ad a voltmérő. A nyákon most 1,92 V-ot ad, amit ha megnézünk a szenzor karakterisztikáján, az majdnem 40%-as páratartalom, ezt beírjuk ebbe a képletbe Vout=5*para/1024, amit para-ra kifejezünk és beírjuk a képletedbe amit kiszámoltál (
Rh = 0.1590492671*para - 31.20521173), az csak 33%-t ad vissza, de ha beírjuk az általam felírtba ((para*5) - 818) / 3, akkor a helyiérték ugyan nem egyezik, de majdnem olyan érték jön ki (40%), mint amit az ábrából leolvasva kapnunk kellene.
Szóval valami valahol még nem jó..