Sziasztok!
Olyan régen foglalkoztam Pic-cel. Most nem emlékszem az miért van hogy egy A/D átalakítás során a poti teljes hosszában 4x megy fel teljesen.? kb olyan négy voltról megy és minden voltnál maximum és előről a következő voltig??

Hány bites ADC? Nem lehet, hogy csak az alsó nyolc bittel foglalkozol?

Kb. 120 Ft.
Az MCP9700A jól elvan hosszú vezetékekkel.

10 bites jobbra van igazítva

16F -eken az ADRESH más bankban lehet.

18f25k50,belső oszcillátor. C- ben van írva , nem én bankolok.

kb ennyi az egész. Egy már létező panelen lévő Pic-et használok. Nem a lábkioszásnak megfelelő helyiértéken vannak a hozzájuk tartozó bitek. Ezért vannak az if-ek.

Ha az A/D 10 bites, akkor 10 LED kell a kijelzéshez. A 25. sorba írd be:

A led -eket valakinek ki is kellene kapcsoni:

stb...

Már kezdtem bepánikolni. De megint teljes figyelmetlenség az oka mindennek. Köszönöm.

Ez csak egy próba. És a Port törlése ezért van benne.

Ritkán használom a C-t. Ezt elmagyaráznátok? Mit csinál az egyenlőségben a dupla egyenlő?
Ez a szintaktika nem rémlik.

A C nyelvben minden kifejezésnek értéke van, így a ((result & 2) == 2) -nek is: true vagy false, ami t egy boot típusú változónak értékül lehet adni.
Jól olvasható, de nem javaslom a használatát, mivel a bit beállítása / törlése művelet helyett egy rakás léptetés és xor, and, xor műveletsorra fordul.
Hatása annyi, mint a következő sornak, ami sokkal rövidebb kódra fordul:
if ((result & 2) == 2) led10 = 1; else led10 = 0;
C -ben a dupla egyenlőség jellel jelőlik az egyenlőség vizsgálatát.

Az NTC ellenállása nagyon nem lineárisa hőmérséklet függvényében, nézz meg egy adatlapot. Komoly matematikai műveletek (és mikrokontroller) nélkül csak nagyon durva eredményeket lehet kinyerni.

Az MCP9700 Vout-ját fel kell húzni mint a DS18b20-nak? Avagy csak simán beköt a portba?

Értem. Utána nézek. Akkor ha normál hőmérsékleteket akarok mérni akkor mit használjak? Pl -30 tól +200 ig. Kb 5öt 6ot kötnék fel egy PICre

Nem kell felhuzni sehova Egy analog feszultseget ad ami 0 C-nel 500 mV, 100 C-nel 1500 mV. Viszont kell kozvetlen a tapra 100 nF kondi, es ha hosszabb vezeteket hasznalsz, akkor a kimenettel sorba egy 1 kohm ellenallas, mert kulonben gerjed. A homerseklet tartomanya -40 - +150 C tehat magasabb homersekleten nem lehet hasznalni, de a NTC-t sem. magasabb homersekletre hoelemet, vagy Pt100 (Pt1000) erzekelot ajanlott alkalmazni. Ha rakattintasz a MCP9700A szovegre, letoltheted az adatlapjat.

Ok! Köszi! Tanakodom....

Értem. Én is ifes helyettesítésre gondoltam, csak így nem ismertem.
Köszönöm a magyarázatot.

Hello,

Mik azok a makrók pontosan? Láttam pár programnál, valamint a 7 szegmenses kijelzőknél találkoztam a maszkolással. Ez mit takar pontosan, miért szükséges? THX

A makrókba gyakran ismétlődő kódrészt szokás írni. Pl a bankváltáshoz meghatározott biteket kell, egybe vagy nullába állítani. Pl ha két bit kombinációja kell ami ugye lehet 00 11 01 10 akkor a megfelelő kombinációt berakod egy makróba és azután csak a makró nevét kell a programba beírni.

Szia!
tudomány
Itt nagyon sok minden megtalálható. A Makró nyelv is.
Talán egy példa: 16 bites adat betöltése regiszterbe:
L16 macro xx, yy ;xx 16 bites szám yy egy regiszter neve
movlw xx ;csak az alsó 8 bitet tölti be
movwf yy
movlw xx>>8 ;csak a felső 8 bitet tölti be
movwf yy+1
endm

a programban csak ezt kell írnod : L16 65535 , reg1
ekkor be is töltődik sz adott szám a reg 1,be
De ez csak egy példa számtalan sok lehetőség van tulajdonképp javítja a program átláthatóságát,
A maszkolás pedig nem más, mint egy adott regiszter 8 bitjéből 1 vagy több bit megváltoztatása anélkül, hogy a többi megváltozna. Bevett szokás, hogy logikai és kapcsolattal kikapcsolod az adott bitet, és a keletkezett feltétel szerint logikai vagy kapcsolattal 1-re állítod.(vagy nem)

Srácok, rázzatok egy kicsit gatyába...
Még mindig PIC18F4550, MPLAB + C18.
És még mindig az időzítés...
1mp-t szeretnék kiszámolni és megadni egy timer-nek..
Ezen elven haladok:
Ciklusidő == 1/(48000000/4) == 8,333333333333333e-8
Ez átfordítva, ha minden igaz így néz ki: 0,0000000833 == 83,3ns
Remélem eddig stimmel minden...
Na most akkor tudjuk, hogy 48MHz-nél 1 ciklus idő 83,3ns-ig tart.
Ha ebből szeretnék egy másodpercet hogyan folytassam a számolást?

Még mindig egy delay-t szeretnék készíteni ami tud minimum 1s-t, 1ms-t...
A gyári beépített időzítések működését nem igazán értem és az elvileg Delay1KTCYx(12) 1ms-a sem állja meg a helyét..
Előre is köszi..

Fenébe már megint elszállt a módosításom...
Szóval, tovább gondolva a dolgot:
83,3ns * 12000-el az már egy nagyon közeli értéket ad.
Pontosan 0,996ms-ot, nyilván ezt már 1000-el szorozva ki is jön az 1 másodperc.
Timer0-át használok egy megszakításhoz.
A megszakításon belül vannak utasítások köztük nagyon rövid 0,1ms alatti késleltetések.
Úgy tudom, hogy ha egy utasítás kiértékelése hosszabb időt is vesz igénybe mint a 2 timer megszakítás közt eltett idő, akkor is független mindentől, megszakít és elkezdi ismét a megszakításon belüli utasítások kiértékelését.
A baj csak az, hogy lemértem és 25mp-nél már 45ms-et mérek.
Tehát valahol elcsúszik a program.., a kérdés az, hogy miért és mitől?

Sajnos ennél a kontrollernél nem így van. Akkor nincs még probléma, ha néha egy kiszolgálás hosszabb, mint egy timer időköz, hiszen amikor vége a kiszolgálásnak, egyből újra belép. Ez csak akkor igaz, ha a kérés okát a kiszolgálás legelején töröljük. Ha a kiszolgálás ideje ennél nagyobb vagy ha a kiszolgálás végén van a törlés, elveszhet kérés.

Ha pontos 1 másodpercet akarsz akkor inkább léptesd a timert egy 32,768 kHz-e kvarccal, Ezt leosztod 256-tal, majd 128-cal akkor pont 1 másodpercet kapsz.

Nem kell túl pontos 1mp, de azért közel annyi kellene, hogy mérhető legyen.
Ezek a mérések is csak egy maximum 1-255mp-ig tartó tartomány szóval nem a folyamatos, napszaki idő mérésre kellene..

Hp41C: tehát ha jól értem amit írsz, akkor ameddig a kiszolgálás (megszakításon belüli utasítások) véget nem ér addig késik, várakozik az újabb megszakítás?
Mert ez akkor megmagyarázná az idő csúszását...

Bár akkor sem értem, vegyünk egy példát:

Tehát itt a megszakítás 333ms-enként történik és 80ms-ig tartja a LED-et bekapcsolva.
Az mp++-al pedig növeljük a másodperceket, 3 timer lefutása 1mp lesz.
Tehát ez lenne a szisztéma és ez csúszik szét nekem 25mp-nél 45-öt mérek..

Szerintem úgy érti, hogy a megszakítás bitet törölni kell, és ezt legtöbbször a kiszolgálás végén szoktuk. Ha ezalatt(vagyis a kiszolgálás alatt) ujabb megszakítás jönne az elveszik. viszont ha az elején törlöd és utána szolgálod ki a megszakítást, akkor a kiszolgálás alatt, ha újabb megszakításod érkezik nem fog elveszni. Nem tudom így érthető-e.

Egy kis segítségre lenne szükségem... Riasztó projektben vagyok, aminek a lelke egy 16f887-es mikrokontroller. A fejlesztő környezetem: MicroC for PIC 8-as verzió (ezzel írom, és fordíttatom a C kódot), MPLab-bal és egy PIC Kit 3 klónnal égetem a Pickbe. Minden tutin működik egészen addig, amíg a programom (Used Ram) nem éri el az 50 % -ot. Utána az írt progi teljesen szétesik ( hülyeségeket csinál), közben hiba üzenet a fordítótól nincs (csak "warning messure"). Warning messure általában egy char tömb nevét jelöli meg, nem tudom, hogy ez számíthat-e? Próbáltam régebbi MicroC for PIC-cel is, a helyzet ugyanaz. Valakinek valami ötlet? Kellene még az a 180 bájt az LCD-hez. Minden segítséget köszönök.

Nem biztos, hogy jól értem.
Nézzük csak:
Jelenleg a megszakítás végén törlöm timer0-t, így:
Tehát, ha ezt a törlést a megszakítás elejére teszem, akkor azt úgy fogja értelmezni a program, hogy már lefutott és indíthatja akkor is az újabb timer megszakítást, ha az előző még nem ért véget.
Ilyenkor amit még előzőleg nem végzet el az abbamarad és elkezdi újból a kiértékelést és ameddig eljut addig jut...
Így értitek? Vagy inkább pont az ellenkezőjét?
Ha nem végez a kiszolgálás és ismét megszakítás keletkezik akkor párhuzamosan fog futni a kettő és az adatok nem vesznek el..
Ez utóbbival csak akkor van gond, ha túl sok elmaradás van mert akkor elég jól bekeveredhet nem?

Nem egészen jól gondolod. Ha a megszakítási időköz 333ms, abba belefér 80ms várakozás. Nem fogja késleltetni a következő megszakítás bekövetkezését, nem akkumulálódik. Nem ajánlott így megoldani a problémát, mert 333ms -enként 80 ms CPU idő elvész.
Az akkumulálódást a timer átállítása okozza. A kérés beérkezése és a kiszolgálásban a timer írása között eltelhet egy kis idő, ami alatt a timer lépked előre. Inkább hozzáadással kellene dolgozni, bár a byte -os műveleteknél a 0xF7 hozzáadása okozhat problémát....
Nem így kellene megcsinálni.... A fenti rutin a CPU idejének 24% -t elfecsérli a delay -eben.
Inkább a timer2 (vagy hasonló timer) felhasználásával kellene előállítani egy sokkal kisebb időnként beérkező megszakítást. Mondjuk 1 ms -enként.
Az 1 másodperces időzítéshez 1000 lefutásonként be kell állítani egy bitet. a főprogram időnként (1 sec -en belüli) vizsgálja a bitet, ha 1, akkor törli és elvégzi a hozzá rendel műveleteket.
A LED -et bekapcsolja a kiszolgáló rutin, ha a == 1 és emellett egy változóba beírja, hogy 80 lefutás után kell kikapcsolni. Ezt a változót csökkenti a kiszolgáló rutin, ha >0. Ha a csökkentéssel elérte a 0 -t, kikapcsolja a LED -et.
Igaz, hogy 1 ms -enként egy kicsit több időbe kerül a kiszolgálás, de nem kell a timert állítani, és nem kell kivárni semilyen időzítést sem. A többlet legyen 10us. Ez csak 1% CPU idő veszteség.