Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Köszönöm!
Már csak azt nem értem hogy akkor miért lehet kapni külön is "analóg front end" néven alkatrészt. (lásd előző linkem)
Ezek azért nem teljesen 'mezei' áramkörök
 Nem néztem a Microchip választékot, de gondolom mindegyiknek van valami extra funkciója. Amiket én láttam azok között volt pl. printer portra dugható (A/Dátalakító), direkt rádiós kapcsolatra (csak tekercsekt kellett rádugni) képes..stb.Tehát nem feltétlen PIC mellé készülnek.
Én is így tudnám elképzelni, de sajnos nem jó a logika, miután - ez az A/D - is Front End-es és nem értem miért. Esetleg ha jobban érted az angolt, mint én, ki tudod venni az adatlapból mitől lesz ez az ami?
Talán azért, mert az eleje analog, a vége digitális? Egy delta sigma, vagy más digitális elven mérő A/D-re rá lehet sütni, hogy végig digitális... Idézet: Az "Analóg-front end" név takarja mindazon analóg áramköröket, amelyek a mérendő analóg jel bemenete és az ADC bemenete között vannak. Az általad példának említett új mikrovezérlő blokkvázlatában például az szerepel, hogy 16/24 bites delta-sigma ADC (előre gondoltam, hogy felkelti az majd az érdeklődésédet... „Mi az az "analóg front end periféria"?” ) PGA-val. Itt a PGA (ami bizonyára Programmable Gain Amplifier-t jelent) az analóg front-end, ami lehetővé teszi pl. a méréshatár váltását. Az adatlap pedig a két PGA-n kívül valami fáziskompenzációs áramkört is emleget. Ami az ADC-k után van (nagysebességű SPI) már nyilvánvalóan nem értendő bele az analóg front-end fogalmába. Idézet: Ezt azért jó volna már frissíteni, mert abban a fő verziószám is más (emiatt nehezen tudunk szót érteni), abban talán még az interruptos kezelés is komplikáltabb (a lekérdezéses mód az alapértelmezett), s a főprogram felépítése is más. „Valami 1.3-as verzió elvileg”
Üdv!
MCP2200-as USB-soros átalakítóval ismerkednék, rendeltem a chipcadtől,hétfőn fog megérkezni. Letöltöttem a drivert,a configurációs szoftvert, és a window xp-re feltettem a service pack3-at. A configurációs programot a telepítés után sem tudtam elindítani, annyi hibával áll le, hogy "error executing program". Mi lehet a baj? Köszönöm a segítséget előre is!
Szia!
.NET 3.5- ös framework telepítve van a gépeden?
Pontos időzítőt szeretnék csinálni valamely 18F sorozatbeli PIC Timer -jével.
Valahol azt olvastam hogy a TIMER0 kevésbé pontos, ezért inkább a TIMER1 et javasolják. Ez igaz lehet? Mi az oka? Akár a TIMER1 is lehetne programozás szempontjából jó választás, de sajna ekkor elvesztek 2 fontos C portbeli lábat az adatlap szerint: (pedig a PIC alap órajelét szeretném használni, így nem lesz másik quarc) Idézet: „When Timer1 is enabled, the RC1/T1OSI and RC0/T1OSO/T13CKI pins become inputs. This means the values of TRISC<1:0> are ignored and the pins are read as ‘0’.”
A PIC időzítői/számlálói egyformán "pontosak". Ami pontosabb lehet, az Timer1 oszcillátora (órakvarccal) - a rendszer órajeléhez képest. Ha erről lemondtál, akkor mindegy, hogy mivel számolsz.
Szia!
Szerintem nem magáról a timer-ek pontosságáról van itt szó, hanem a velük megvalósítható alapórajel (1 Hz, 0.5 Hz) pontosságáról. - Timer0 használatának két problémája van: Előosztó nélkül 256 - tal ill. 65536 -tal tudja osztani a belső órajelet (Fosc/4), aminek pontos időzítéshez 256 -tal vagy 65536 -tal oszthatónak kellene lennie - ha egyszerű programot szeretnénk. Ha írjuk a TMR0 regisztereit, akkor valamennyi időre leáll a számlálás. Előosztóval az osztási szám növelhetó, de csak 2 hatványaival, és még egy probléma bejön, az előosztó törlődik a TMR0 regiszterek írásakor. Egy kicsit bonyolultabb algoritmussal pontos időzítés is megvalósítható. - Timer 1 és 3 használatánál akkor van probléma, ha a regisztereket írjuk is ld. Timer1_errata. A timer1 külső órajellel működtethető sleep üzemmódban. - Timer2: talán a legjobb választás, mivel nem csak 2 hatványaival tud osztani, így pl 250, 500, 1000, 4000 osztás is beállítható. Egyetlen hátránya van - nem működik sleep üzemmódban. Idézet: A többi sem fog működni, mivel nem akar külön oszcillátort...„Egyetlen hátránya van - nem működik sleep üzemmódban.” Egyébként jó választásnak tűnik a 10.24 MHz-es kristály, mert 4xPLL módban (igen minimális túlhajtással), 2^16-szoros leosztással "kerek" megszakítási frekvenciát lehet vele előállítani.
Timer1-re szoktak rakni un. ora kvartz-ot, ami tipikusan 32768 Hz-es. Ezzel 2s-es megszakitast lehet elerni, ill trukkozesekkel 1s vagy 0.5s vagy mas ertek is elerheto. Az ora pontossaga nyilvan a kristalytol fog fuggeni, Lehet olyat csinalni ami par honap alatt kesik vagy siet 1mp-et szobahomersekleten.
Ha semmilyen aron nem szeretnel kulso kristalyt, akkor mindegy mit csinalsz -- illetve kerdes mit jelent nalad a 'pontos' kifejezes, mivel ez nem egy mernoki megfogalmazas, ez jelentheti azt is, hogy 'kb 1 masodperc, de az sem baj ha 1.2...'
Szia!
Sajnos ott van az a Fosc/4 osztás minden timer előtt, amit a PLL engedélyezése kikompenzál. Ekkor a kontroller 10.24 MHz -en jár, ami 16384 * 625 = 2^14 * 5^4.
Órakvarc nélkül soha nem fogsz tudni pontos órát építeni, de még az órakvarccal is csak egy bizonyos pontosságot lehet elérni.
Én már túl léptem a PIC-ben megvalósítandó órán, mert nem éri meg a fáradságot, inkább olyan RTC-t (pl. r2025x) használok, amiben benne van a nagypontosságú kvarc és az egész óra. 2 vezetéken lehet vele kommunikálni.
Hello!
Köszi a választ. Most nézem, legutóbbi verzió: 2.7a  Nem is csoda ha vannak változások. Egyenlőre leszedem és meglesem, hogy mit lehetne vele kezdeni mert még mindig SDCC-vel szeretném használni. Ennek egyébként nem az az oka, hogy Linux alatt vagyok bár kétség kívül nagy +, hogy azt is támogatja. Az az igazság, hogy azért használom mert szeretem az nyílt forráskódú progikat.
.net 3.5 nincs a gépen.... nem is tudtam ,hogy kellene
Felteszem, és meglátjuk... köszi a tippet!
Igazad van! Akkor Timer0-t 8 bites módban és 1:64 arányú előosztással kell használni.
Persze, a timer pontossága erősen függ az órajel pontosságától. Ez világos.
Nekem nem a klasszikus óra-perc-másodperc előállítása kell, hanem egy folyamatot szeretnék indítani előre meghatározott (de változtatható idejű) pontos! időközönként. Más szóval kicsi legyen a jitter. A Timer0 -t 16 bites módban használnám, így eléggé kicsi lépésközzel tudám módosítgatni az időzítéseket. Még előosztót sem kellene váltanom, maradna fix 1:1 ben. Ha jól gondolom a Timer működését akkor a Timer inicializálásakor kell a TMR0H-TMR0L regisztereket kezdőértékre feltölteni, majd órajelet számolva FFFF után túlcsordul, megszakítás keletkezik. A megszakítás kiszolgáló rutinban ujra fel kell tölteni a TMR0H-TMR0L regisztereket a kívánt értékre, hogy onnan ismét kezdődjön a számolás. Ez szinkronban van azzal amit írtál: a Timer0 "hibájáról": Idézet: „Ha írjuk a TMR0 regisztereit, akkor valamennyi időre leáll a számlálás” Szerintem ez engem nem fog zavarni, mert minden esetben ugyanannyi időre fog állni a számlálás. Ez időzítési hibát nem fog okozni gondolom. A TMR reg kezdőértékének korrigálásával a helyes időzítés beállítható. Azonban mire gondolsz, amikor azt írod, hogy: Idézet: „Előosztó nélkül 256 - tal ill. 65536 -tal tudja osztani a belső órajelet (Fosc/4)” Én ilyent nem olvastam sehol. Tiszta ügy elenne a compare módot használni, amely egy előre megadott érték esetén túlcsoldul, nem kell állandóan újrairni, de sajnos az a Timer1 modult használja, ehhez pedig elfogy a C portról 2 Pin.
Én is készítettem régebben órát. Én 3.2768 Mhz - es kristályt használtam TMR megszakítással. Az óra pontossága nagyon függött a hőmérséklettől, viszont állandó hőmérsékleten nagyjából állandó volt a hiba, amit tudtam korrigálni. Akkor volt gond ha változott a hőmérséklet. Ha valahogy tudtam volna állandó hőmérsékletet biztosítani (+-1 fok). elég pontos lett volna. Persze akkor sem atomóra de kinek mi a pontos.
Szia!
Úgy értettem, hogy nem módosítjuk a TMR0 regisztereit... Idézet: „If the TMR0L register is written, the increment is inhibited for the following two instruction cycles. The user can work around this by writing an adjusted value to the TMR0L register. ... When assigned to the Timer0 module, all instructions writing to the TMR0L register (e.g., CLRF TMR0, MOVWF TMR0, BSF TMR0, x....etc.) will clear the prescaler count. ... A write to the high byte of Timer0 must also take place through the TMR0H buffer register. Timer0 high byte is updated with the contents of TMR0H when a write occurs to TMR0L. This allows all 16-bits of Timer0 to be updated at once.” Timer1 és 3: Ha a belső utasítás órajelet számlálja, a T1 oszcillátor letiltható, a külső órajel bemenet nem használt, a két RC láb ki- / bementeként használható. A CCP modul a Timer3 értékét is tudja figyelni, nem is kell törölni a timer regisztereit - elég beírni az új egyezéshez tartozó értéket... Idézet: „When the Timer1 oscillator is enabled (T1OSCEN is set), the RC1/T1OSI and RC0/T1OSO/T1CKI pins become inputs. That is, the TRISC<1:0> value is ignored, and the pins are read as ‘0’.”
ha csak órajel pontosság kell, használj TXCO -t.
Az ilyen kvarcok különösen hőstabilak, igaz eléggé drágák.
Épp most gondolkoztam hogy a megszakítások nem nem teszik tönkre az eepromot? Mert ha az ember ASM nyelven ír picre programot és megszakítást tesz bele akkor a megszakítás előtt el kell menteni a STATUS és a WORK regiszter adatait az eeprom-ba. Ez nem teszi tönkre a pic-et?
Hali!
Szerintem nem az eepromba mentődnek ilyenkor az adatok, (sőt, biztos vagyok benne), de mindjárt utánanézek.
Hát persze..
Idézet: „ A PIC18 mikrovezérlőben egy programmegszakítási kérelem érvényesülésekor a következő dolgok történnek: * a CPU befejezi annak az utasításnak a végrehajtását, amelynek során a programmegszakítási kérelem (valamelyik interrupt flag bebillenése) történt * a hardveres veremtárban elmentésre kerül a PC programszámláló értéke (a visszatérési cím), s az árnyékregiszterekbe átmásolódik a BSR, WREG és a STATUS regiszterek értéke. * a PC programszámláló beáll a beérkezett programmegszakítási kérelem prioritásához tartozó, előre meghatározott címre (amit interrupt vektornak nevezünk), ami azt eredményezi, hogy a program futása eltérül, az interrupt vektornál folytatódik. ” Bővebben: Link
Hali
Nem tudom hol lattal ilyen peldat, de altalaban mindenki a RAM-ba menti az adatokat. Azert sem jo megoldas, mert az EEPROM irasa sok idot vesz igenybe.
Udv Vili
Elnézést. Én még amikor próbálkoztam ASM-el akkor a netröl szedtem le példa pogikat és ott úgy volt. Akkor nem szóltam.
No elkezdtem összehasonlító módban megírni a programomat. van róla elég jó leírás itt
Látszólag érthető lépések után rendkívül fura működést tapasztalok.
megszakítás kerek 5 msec onként jönnek ( Foszc= 48 MHz) bárhova állítom az egyezőségi szintet. Ha Timer1 osztóját állítom az hatással van a megszakítások gyakoriságára, tehát Timer1 számlálóm működik, és az hajtja meg a modult. Azonban MPLAB szimulátor szerint amint megkapja a literál értékét a CCP4CON regiszter rögtön utánna megjön a megszakítás flag, és elmegy interruptra. Onnan kitörölni sem lehet bcf PIR3,CCP4IF utasítással sem, így körbenjár a megszakítás kiszolgáló rész. Ez milyért van?
Mielőtt mélyebben belemennék az elemezgetésbe:
- Melyik PIC18 -as eszközre készül a program? Lehet, hogy nem fontos, de talán ... - Elsőre minek priorizálni a megszakításokat, ha elvileg csak egy megszakításod van? Ráadásul minek figyelni a kiváltó bitet? Úgyis csak az az egy megszakítás következhet be. ( Elvileg. ) - A megszakítási rendszert esztétikusabb ott elindítani, ahol már minden be van hozzá állítva, tehát a közvetlenül "goto a" sorod előtt.
Véletlenül botlottam az alábbi oldalba:A példa a timer1 megszakítással 1ms időzítést mutat be, lekérdezhet...tővel. Érdemes megtanulmányozni a megszakítási rendszer indításának folyamatát.
|
Bejelentkezés
Hirdetés |
