Fórum témák

» Több friss téma
Fórum » PIC - Miértek, hogyanok haladóknak
Lapozás: OK   994 / 1319
(#) smrtln válasza watt hozzászólására (») Júl 7, 2011 /
 
trudnai: akkor a mekszakítás átírom swapf-os és buffer-es megoldádsra kiprobálom úgy is

watt: a két PIC között 433,92 MHz-es adó-vevő modulokkal továbbítom és veszem az adatokat (kb 10 m-es távolságot probáltam ki velük, akkor ugyan így működik), most kiprobáltam úgy hogy egy darab vezetékkel vannak összekötve, akkor is így működnek

ezek így vannak?
vételi regisztert ezzel törlöm: MOVF RCREG,W
USART-ot pedig ezzel tudom kikapcsolni: BCF PIE1,RCIE
az RCIF-et nem kell törölni?
(#) watt válasza smrtln hozzászólására (») Júl 7, 2011 /
 
A vételi regisztert nem törlöd, hanem pont az RCIF-et.
Az RCIE a megszakítást engedélyezi.
Az USART modult a SPEN bit kapcsolja be-ki.

Ha kábellel kötöd össze, akkor az nem lehet 10cm-nél hosszabb. Jó lenne tudni pontosan mi jut át, ha 0x55-öt küldesz pl. (Mondatot kezd nagybetűvel! Köszi!)
(#) smrtln válasza watt hozzászólására (») Júl 7, 2011 /
 
Rendben, köszönöm a segítséget mindkettőtöknek, megpróbálom módosítani a programot a leírtak szerint, majd még jelenkezek később mire jutottam!
(#) Hp41C válasza smrtln hozzászólására (») Júl 7, 2011 / 1
 
Szia!

1 - A 16F -en az RCREG kolvasása törli a RCIF -et, a TXREG írása törli a TXIF -et, de van egy kis késésük.
2 - Az RCSTA és a RCREG egy fifo kimenete, karakterenként egyszer szabad kiolvasni az RCSTA - RCREG sorrendben. Az RCREG olvasása lépteti a fifo -t.
3 - Ha a kiolvasott RCSTA érték szerint ráfutás és/vagy keretezési hiba történt, az uart egységet alaphelyzetbe kell állítani (SPEN = 0 majd SPEN = 1) és ki kell olvasni az RCREG regisztert is.

Egy körforgó fifo tárat ajánlok, amiben elfér 2 távirat legalább. Az adást és a vételt is megszakításosan kezeld. A vételi megszakítás kezelje le a hibát, ha van, a hibátlan karaktert tegye be a vételi tárba, állítsa a mutatót, növelje a tárban levő karakterek számát. Az adási megszakítás olvassa ki az adási tárolóból a küldendő karaktert, állítsa a mutatót, írja be a TXREG -be, csökkentse az adandó karakterek számát. Ha nincs több adandó karakter, tiltsa le az adási megszakítást.

Készíts egy kiolvasó rutint a vételi tárolóhoz, ha nincs vett karakter jelezze a hívójának, ha van vegye ki a tárból, állítsa a mutatót, csökkentse a karakter számlálót, adja át a kivett karaktert a hívónak.
Az berakó rutin is hasonlóan készíthető el: Ha van hely a tárban, tegye be a karaktert az adási tárba, állítsa a mutatót, növelje az adandó karakterek számát és engedélyezze az adási megszakítást.
Az alábbi dologra kell ügyeli ezeknél a rutinoknál:
Vétel: előbb kivenni, aztán csökkenteni a darabszámot.
Adási: előbb betenni, aztán növelni a darabszámot.
A növelét és a csökkentést un. promitív művelettel kell megcsinálni - a művelet közben a megszakítás nem juthat érvényre. A legegyszerűbben egyetlen utasítással (incf valami,f / decf valami,f) oldható meg.

A főprogram csak a kiolvasó rutint hivogassa, ha a táviratot dolgozza fel, csak a berakó rutint hivogassa a válasz elküldése során. A többi menni fog...

A tárak méretét a táviratok hosszához kell igazítani, a sebeséget pedig a feldolgozási időhöz...
(#) smrtln válasza Hp41C hozzászólására (») Júl 7, 2011 /
 
Rendben, köszönöm a hozzászólásod, sokat segítettél, kipróbálom ezt is!
(#) levi18 válasza Attila86 hozzászólására (») Júl 7, 2011 /
 
Szia!
Elnézést, lehet, hogy hülye kérdés, de a tristate (TRISx)
bitek az adott pwm-kimenetekhez be vannak állítva?
Üdv!
(#) michael67 válasza Hp41C hozzászólására (») Júl 7, 2011 /
 
Hali!

Érdekes a téma, ezért lenne két kérdésem:
Ráfutás esetén nem elegendő a RCSTA -> CREN bitjét törölni és utána beállítani? Illetve keret hibánál elegendő RCREG-et kiolvasni és veszni hagyni? Ezeket a microchip "p16_tiri.asm" minta progijában láttam.
(#) Hp41C válasza michael67 hozzászólására (») Júl 7, 2011 /
 
Szia!

Egy 18F252 -vel kimértem: Az Rx láb lebegett, hiba esetén az uart-ot letiltottam és újraengedélyeztem. A programom csiga lassúsággal ment előre, mivel állandóan a megszakítási rutint hajtotta végre. A lebegő Rx láb sok hibát okozott az uart vételben, a tiltás és az újraengedályezés nem törölte a megszakítás kérést (RXIF). Ezt a bitet az RCREG kiolvasása törli csak.
(#) michael67 válasza Hp41C hozzászólására (») Júl 7, 2011 /
 
Köszi! Ez hasznos info volt.
(#) trudnai válasza Attila86 hozzászólására (») Júl 8, 2011 /
 
Tudom tudom, de mondom hogy ezt nem én írtam hanem generáltam.

Ertem, ezek szerint az a generator amit hasznalsz nem a 18F-re lett kitalalva es igy vagy nem azt kell hasznalni vagy a kodot generalas utan at kell irni (avagy mint 3. lehetoseg nem 18F-et hasznalni, hanem amire a generator eloallitja a kodot).
(#) Attila86 válasza trudnai hozzászólására (») Júl 8, 2011 /
 
Letöltöttem egy másik generátort (PicLoops v2.2), amivel generáltam jól működő időzítőrutinokat.
(#) Stefan hozzászólása Júl 8, 2011 /
 
Sziasztok!
PIC24F szeriára szeretnék fordítani.
MPLAB v8.40 már fent volt.
Felraktam a legújabb MC30 as fordítót, de a device list még mindig nem tartalmazza a 24 es sorozatot.
Project/Set lang tool locations/C30/Executables-nél az elérési utak jók.
Van valakinek ötlete mit rontottam el?
(#) Hp41C válasza Stefan hozzászólására (») Júl 8, 2011 /
 
Szia!

Már 8.73a -nál jár az MpLab... Egy frissítést megér...
(#) trudnai válasza Stefan hozzászólására (») Júl 8, 2011 /
 
Annak pedig ott kell lennie. Nekem meg mindig a 8.30-as van fent es benne vannak a 24-esek C30-al...
(#) watt válasza Attila86 hozzászólására (») Júl 8, 2011 /
 
Attila, minek szórakozol ezekkel az időzítős szutykokkal? Pofon egyszerű írni egy ilyen rutint és a szimulátorban le tudod ellenőrizni a pontos időt is. Mellesleg megjegyzem, hogy ezek nem is időzítők, hanem várakoztatók, azaz ezalatt más nem történhet, még megszakítás sem, mert akkor elromlik a várakozási idő! Ez nem jó megközelítése a dolognak. Időzíteni számlálókkal szoktunk...
(#) Attila86 válasza watt hozzászólására (») Júl 8, 2011 /
 
Watt, minden eddigi áramkörömben ilyen időzítéseket használtam különböző célokra. Hogy melyek ezek?
- Az LCD kijelző vezérlése, mégpedig hogy az adatlapban meghatározott ideig kapja az utasításokat az LCD.
- A külső D/A átalakító vezérlése, mégpedig hogy az adatlapban meghatározott ideig kapja az utasításokat a D/A.
- Bekapcsoláskor a tápfeszültségek stabil beállásának kivárása.
- A bekapcsolás után megjelenő szövegek közti időzítés.


Tudom hogy ezen időzítések alatt a PIC nem tud semmi mást csinálni (kivéve megszakítás), de a felsorolást látva nem is kell. Ahol valamiféle időzítés-szerűségre van szükség és közben mégis dolgozni is kellene, azt másképp szoktam megoldani.
Azt is tudom hogyha az időzítés ideje alatt érkezik megszakítás akkor annak ideje kitolódik a megszakítás lekezelésének idejével. Ezért vagy olyan dolgokat időzítek így amiknél ez nem probléma, vagy az időzítés idejére letiltom a megszakításokat. Olyan pedig nem fordul nálam elő hogy így viszont a megszakítás késleltetése gondot okozhasson. Eddig mindig úgy találtam ki a programocskáim struktúráját hogy ne legyen ilyesmi probléma.

De szoktam én számlálókkal is időzíteni! Általában folyamatosan ismétlődő eseményeket, mondjuk mintavételezést, kijelző-frissítéseket, D/A frissítést...
(#) watt válasza Attila86 hozzászólására (») Júl 8, 2011 /
 
Oké-oké, értem én, semmi gond! Viszont ez még mindig nem időzítés, hanem várakozás... Persze nem ezen akarok filozofálni, de megtévesztő, hogy várakozási rutinokkal "időzít" valaki. Egyből hosszabb időkre gondol valaki.
(#) mate_x hozzászólása Júl 8, 2011 /
 
Helló!

A következő problémába ütköztem bele:
Mikrobasicben a Log paranccsal, azaz a természetes logaritmussal játszadoztam. Alapból működik is, szépen kijelzi az értéket a pic, amit kell neki, de ha a program mérete ~50% fölé növekszik, akkor nem működik a funkció. Ez mitől van? Nem értem, mitől lehet ez.
A választ előre is köszönöm.

Üdv, mate_x
(#) Zsora válasza watt hozzászólására (») Júl 8, 2011 /
 
Watt! Te mit értesz időzítés alatt? Hogy definiálod azt a szót hogy "időzítés"?
(#) watt válasza Zsora hozzászólására (») Júl 8, 2011 /
 
Részben leírtam már mit értek várakozás alatt. Az időzítés nem befolyásolja lényegesen a program többi szálát, a várakozás viszont tétlenkedést jelent, azaz erőforrás pazarlást.
(#) Stefan válasza Hp41C hozzászólására (») Júl 8, 2011 /
 
Frissítés megoldotta...

trudnai: Én sem értem mi volt a baj, C30 readme szerint 8.10 kell neki legalább...
A lényeg, hogy mostmár megy.

Köszi srácok!
(#) Hp41C válasza Stefan hozzászólására (») Júl 8, 2011 /
 
Szia!

Néha történnek furcs dolgok a MicroChip háza táján is. Most pl. az MpLab 8.73 -at visszavonták 16 bites debuggolási problémák miatt. Néhány nap múlva megjelent a 8.73a, de itt vannak problémák... Pl. a EEProm ablakban furcsa menüpont szövegek jelennek meg, amikor formátumot szeretnék beállítani. Viszont a 8.70 -nel nem sikerült 24FC512 -re 8 bites eeprom kódot fordítanom a parancssori kapcsolóval, a 8.73a -val megy...
(#) Hp41C válasza mate_x hozzászólására (») Júl 8, 2011 /
 
Szia!
Milyen kontrollerre fordítasz? Véletlenül nem kerül táblázatod programlap határra? - Bár erre a fordítónak kellene ügyelnie...
(#) icserny válasza Stefan hozzászólására (») Júl 9, 2011 /
 
Jó volt az eredeti telepítés sorrendje? (előbb MPLAB,utána a fordító)

Azt telepítetted, amit kellett? (pl. PIC24-hez való fordító helyett dsPIC-hez való fordítót - csak tudnám, minek bontja szét időnként a Microchip?)

Ilyenen okokat tudok elképzelni.
(#) watt válasza Hp41C hozzászólására (») Júl 9, 2011 /
 
Ezért nem szoktam elkapkodni az új verziókat. Jelenleg a 8.6-al dolgozom...
(#) mate_x válasza Hp41C hozzászólására (») Júl 9, 2011 /
 
Szia!

Nem tudom mi a fene történt, de most működik .
Lehet, hogy csak egy újraindítás kellett a fordítónak.
(#) Attila86 hozzászólása Júl 9, 2011 /
 
A CCP modulok problémáit egy kicsit félretettem és inkább a 2*16-os LCD-be próbálok életet lehelni. Nem akar semmit se csinálni ezért méricskéltem és arra jutottam hogy az LCD 5. és 6. bitjein stabil H szint van attól függetlenül hogy ezekre a lábakra milyen szintet állítok be. Az LCD 5. bitje az RC0-ra, a 6. bit pedig az RC6-ra van kötve közvetlen. (PIC18F26K80-ról van szó.) Kimértem hogy nincs-e esetleg valami zárlat a nyákon amitől táp kerülhet is, de nincs. A többi két bit (négy bitesen vezérlek most) és az RS illetve EN lábak rendesen követik a debuggerben az állítgatásokat, csak az RC0 és RC1 lábak nem. Természetesen a TRISC regiszterben ezek a lábak kimenetként vannak konfigurálva. Van valami ötletetek?
(#) watt válasza Attila86 hozzászólására (») Júl 9, 2011 /
 
Mindig meg kell nézni egy használni kívánt láb esetében, hogy milyen belső perifériák vannak hozzá rendelve és azokat le kell tiltani akkor is, ha netán az adatlapból az tűnne ki, hogy a kezdő értéke a beállító biteknek tiltaná őket. Akkor pláne, ha nem a számunkra megfelelő értékekkel élednek. Segít a keresésben a PIC lábkiosztását taglaló táblázat, vagy a rajza a lábkiosztásnak.
(#) Attila86 válasza watt hozzászólására (») Júl 9, 2011 /
 
Én is erre gyanakszom. Az RC1-en SOSCI, az RC2-n SOSCO van, szerintem ez lesz a jelenség forrása. Kerestem, de egyenlőre nem találtam az adatlapban a megoldást hogyan kell kikapcsolni ezen lábakon az oszcillátor dolgokat. Vagyis szerintem ezzel:
  1. config  FOSC    =       INTIO2

És ezzel:
  1. PIC_INICIALIZÁLÁS
  2. ;       Órajel konfigurációja:
  3.         movlw   b'01011100'     ;4MHz
  4.         movwf   OSCCON
  5.         bcf             OSCTUNE, PLLEN  ;PLL kikapcsolása

jónak kellene lennie, de nem.
(#) Hp41C válasza Attila86 hozzászólására (») Júl 9, 2011 /
 
Szia!

T1CON regiszter SOSCEN bitje...
Következő: »»   994 / 1319
Bejelentkezés

Belépés

Hirdetés
XDT.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem