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?

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!)

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!

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...

Rendben, köszönöm a hozzászólásod, sokat segítettél, kipróbálom ezt is!

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!

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.

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.

Köszi! Ez hasznos info volt.

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).

Letöltöttem egy másik generátort (PicLoops v2.2), amivel generáltam jól működő időzítőrutinokat.

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?

Szia!

Már 8.73a -nál jár az MpLab... Egy frissítést megér...

Annak pedig ott kell lennie. Nekem meg mindig a 8.30-as van fent es benne vannak a 24-esek C30-al...

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...

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...

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.

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

Watt! Te mit értesz időzítés alatt? Hogy definiálod azt a szót hogy "időzítés"?

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.

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!

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...

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...

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.

Ezért nem szoktam elkapkodni az új verziókat. Jelenleg a 8.6-al dolgozom...

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.

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?

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.

É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:

És ezzel:

jónak kellene lennie, de nem.

Szia!

T1CON regiszter SOSCEN bitje...