Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
hát igen az volt az egyik gond, hogy nem méretarányos ez a fránya memory map. A 15. bankot kétszer akkorának mutatja, mint az összes többit, így a felét (ahol a le nem képzett SFR és az Access RAM határvonala van) már a végének láttam..
Abból jöttem rá, hogy a bank15 is 0xFF hosszú és ott van kiirva az ábra bal olalán alul. Így már világos hogy (ha jól gondolom) hogy milyért jó a BSR -el lévő kód, hiszen a bank15 ben vagyunk TRISC esetén is. Már csak az a kérdés valójában mire jóaz access bank, ha lényegében minden SFR megvan a bank15 ben, sőt még azok is, amik eseteg nem fértek bele. (pl. UCFG) Talán azért, mert így együtt lehet kezelni őket az accessben bankváltás nélkül a gyakran használt változókkal?
Idézet: Aranyos, de az OSCCON regiszter bekapcsolás (POR) utáni alapértelmezett beállása: IRCF=110, azaz 4 MHz! „amikor a PIC-et kiválasztottam, alapból a 8 MHz-et állította.”
Szóval akkor mikroPascal, a mikroelektronika szoftverje nem?
Ha project-et hozol létre akkor a második lépésben nem azt kérdezi meg hogy mennyi legyen a PIC frekvenciája, amin ketyegjen, hanem azt hogy mennyire van beállítva, hogy az időzítések jók legyenek. A kettő különböző dolog. A PIC frekvenciáját a configgal tudod beállítani, mondjuk a project menü -> Edit project menüpontban. A programban pedig jobb oldalt a Project Settings-ben ha kinyitod, ott tudod átírni az időzítésekhez tartózó frekit.
Értem.
Átállítottam 4-re, így jó. Köszi.
még ha erre kaphatnék választ megköszönném:
Idézet: „Már csak az a kérdés valójában mire jóaz access bank, ha lényegében minden SFR megvan a bank15 ben, sőt még azok is, amik eseteg nem fértek bele az Access be. (pl. UCFG-UEIE, stb.) Talán azért, mert így együtt lehet kezelni az accessben az SFR -et bankváltás nélkül a gyakran használt változókkal?”
Arra jó, hogy hatékonyabb lehet vele a program, mert nem kell állandóan lapozgatni...
Tehát jól gondolom, hogy a regiszterek szempontjából közömbös, hogy access be vannek szervezve, (mert mindegyik a 15. bankban van, váltani úgysem kellene), s csupán az általános regiszterekkel vagyó együttműködés miatt paraktikus használni az Access -t?
Sziasztok!
Pergésmentesítéses módszereket próbálgatok, ez megszakít biz. időközönként, és ha ennek a tízszerese letelt, akkor enged csak újabb kapcsolást. A problémám: nem tudom, mitől függően 1-2, talán néha 3 ki/bekapcsolást enged, aztán megáll az egész.
Bocs a hosszú kódért, de nem tudom, melyik részével van baj. Max letörli valaki, ha túl hosszú Köszi előre is!
Tegnap végre kézbevehettem a 2 hete megrendelt SURE Electronics DB-DP113 PIC18F4520 demókártyát. Az ICSP kivezetésekre már én raktam be a tüskesort, gyárilag csak üres lyukak vannak.
Az eredeti kiírásban 2x16 karakteres kijelző szerepelt, ehhez képest meglepetés, hogy 2x20 karakterest szállítottak. A kijelző reflexiós típusú (nincs háttérvilágítás). Az negatívum, hogy 20 MHz-es kvarccal szerelték a panelt, így a PLL-t nem lehet használni, s nem lehet 40 MHz-en futtatni. Emiatt a végtelen ciklus sokkal lassabban fut le...  A kártya jellemzői: - PIC18F4520 mikrovezérlő, 20 MHz-en - 3 db nyomógomb (MCLR, RA4 éa RB0) - 4 db piros LED (RB0..RB3) és 1 db zöld LED (power) - USB- UART átalakító (CP2102) amin lehet kommunikálni - 4 számjegyű 7-szegmenses kijelző - 2x20 karakteres LCD kijelző ("levehető ajtós") - Piezo buzzer ("picergő") - I2C hőmérő - I2C EEPROM - Műveleti erősítős PWM integrátor (kontrasztszabályozónak van bekötve, de nincs értelme...) Egy hétig még akciós az ára a gyártónál (gondolom, ehhez igazodnak az E-bay árak is...). Már fut rajta az AN1310-es bootloader, és gőzerővel készül a PICula projekt tananyag és támogatói programcsomag.... Végső soron akár ugyanúgy is lehet használni, mint a PICCOLO projekt áramköreit, csak itt a PIC-en kívül van az USB. Az AN1310-zel meghajtva 614400 bit/s volt a legnagyobb sebesség, amelyen még kapcsolódni tudott a PIC bootloadere, ekkor 0.6 s alatt olvasta be a teljes 32 kB program memóriát a PC-be. Üzemszerűen eddig csak 56 kbit/s-on használtam, a rövid tesztprogramok letöltése így is kellemesen gyors (és kényelmesebb, mint a PICkit2-vel történő programozás).
Talán úgy a legjobb elképzelni ezt, hogy az access terület csak egy ablak a memóriabankokból kialakított speciális, 256 byte méretű nézetre.
A memóriabankok 0-tól 15-ig vannak számozva, az összes regiszternek (beleértve a speciális funkciós regisztereket is) 12 bites címe van. A regisztereket megcímző utasításokban a regisztercím 8 bites, valamint egy bit jelzi, hogy a 8 bites címet bankolt módon kell-e értelmezni, vagy access terület elérésére vonatkozóan. - Bankolt elérésnél a 12 bites regisztercím az utasításban lévő 8 bitet a BSR-ben található 4 bittel kiegészítve alakul ki. Ezzel a módszerrel bármely regiszter elérhető. - Ha "access" a címzésmód, akkor a BSR értékétől függetlenül a fent említett "nézet"-ben lévő regiszterek lesznek megcímezve, méghozzá úgy, hogy a 8 bites címtől függően a felső 4 bitbe 0000 vagy 1111 kerül. Ha a 8 bites cím kisebb egy értéknél, akkor 0000, egyébként 1111. Ez a határérték PIC-től is függ, de általában 0x60 vagy 0x80. Ha a határérték 0x60, akkor access eléréssel csak a 0x000-0x05F és 0xF60-0xFFF regiszterek érhetők el, viszont a BSR aktuális tartalmától teljesen függetlenül. Az, hogy egy regisztert milyen módon címzel meg, a PIC-et nem érdekli, a lényeg az, hogy a cím összerakásának a végén helyes regiszterhez forduljon. Nyilván olyan SFR-eket nem lehet "access" címzéssel elérni, amik nem a 15. lapon vannak, vagy ugyan ott vannak, de az access határvonaltól kisebb a címűk alsó 8 bitje. Az ilyen SFR-eket muszáj bankolt eléréssel használni.
Hirtelen átfutottam a kódot, de nagyon nem mélyedtem az elemzésébe bele. Pár feltűnő dolgot láttam, amit át kellene dolgoznod:
1. A $-os goto-kat érdemes lenne rendes címkére ugró utasításokkal helyettesíteni és kitenni a címkéket. Így nem is biztos, hogy oda ugrik, ahova gondolod, ráadásul ha véletlenül beszúrsz vagy elveszel utasításokat azon a környéken, akkor könnyen rossz lesz a mostani érték a $ mellett. 2. A megszakításokat nem így kellene kezelni. A (midrange) PIC egy megszakításvektort ismer, minden megszakítás erre ugrik, és itt kell majd a megszakítást kiváltó októl függően mást és mást csinálni. Ez az irány látszik is a programodban, de a megvalósítás nem jó. A megszakításrutin legelején kell menteni, és a legvégén visszaállítani a fontos regisztereket, majd RETFIE-vel visszatérni. A Te kódodban call-lal vannak meghívva a periférialekezelők, és azokból jössz ki RETFIE-vel, ez teljesen rossz így, ráadásul a megszakításrutin a mentések előtt már vizsgálgat. 3. A megszakításban továbbá nem szabad a GIE-t állítgatni, ezt megcsinálja a hardver. A perifériát lekezelő rutinban az adott perifériára jellemző nyugtázásokat meg kell csinálni (pl. interrupt flag visszaállítása, PORT-ból olvasás, vagy esetleg más, ez a kiváltó októl függ). 4. A megszakításból sosem ugrunk ki GOTO-val a főprogram valamely részébe.
Tisztában vagyok vele, hogy ez egy tegnapi beszélgetés volt...
A tapasztalatom szerint az ACCESS BANK elérés alapértelmezett, ha az utasítások végére nem is írom ki. Assemblyben íródott PIC16F690-es programomat emiatt néhány óra alatt sikerült áttennem 18F14K20-ra, ami a ki-bemenetek tekintetében azonos tok, belül azonban a fejlettebb vezérlő található. Az áttérést éppen az ACCESS BANK megoldás segítette. A legnagyobb módosítás az volt, hogy a "banksel" utasításokat kivehettem a programból.
Szia!
Azért nem ennyire egyszerű: - Vannak olyan utasítások, amik más státusz biteket is állítanak: pl. incf/decf a 16F -en csak a Z-t, 18F -en a C-t és a Z-t is állítja. - A shiftelési utasítások másként érhetők el: a 16F rrf/rlf utasítása rrcf/rlcf a 18F -en. Egy makro ugyan értelmezi a rrf/rlf -et is. Ezek az utasítások a N bitet is állítják. - Az utasítások 2 (4) bájton tárolódnak, a program memória címzése byte címeket használ. A kiszámított ugrásnál figyelni kell rá. Az ugrótáblában a 16F -en használt return és a goto mérete a 18F -en eltér, az utóbbi helyett bra -t használva 2 byte/eset lehet a táblát használni. - A kiszámított ugrálnál a táblázat hosszára jobban kell ügyelni (2 - 4 cím / tétel), a 256 -os limit byte-ban értendő. A PCL olvasássával a PCLATU, PCLATH feltölthető - sajnos az addwf PCL,f nem tölti fel... - Nincs FSR regiszter, helyette a 12 bites FSR0H:FSR0L, FSR1H:FSR1L, FSR2H:FSR2L használható, érdemes a sokféle címzést lehetőséget kihasználni:
A címmódosító lehetőségek a 12 bites FSRx -et növelik, csökkentik. - A megszakítási rendszert mindenképen át kell gondolni... - Érdemes még egy kicsit foglalkozni a programmal, kihasználni a feltételes ugrásokat (bz, bnc, bn,...), a két byte-os ugrás bra, két byte-os szubrutin hívás rcall, a 8 bitnél nagyobb számok kezelésénél az addwfc, subwfb, subfwb utasításokat (kezelik a C/B bitet),valamint az infsnz, dcfsnz, tstfsz utasításokat. A w regiszter WREG néven címezhető:
- Ha a retlw -ket alkalmazó ugrótáblázatok helyett a TBLRD* utasítással kezeljük a táblázatokat (szövegeket) fele akkora méretben tárolhatjuk őket - egy sorba mindig páros számú adatot adjunk meg, a fordító a páratlan számú adat esetén hozzátesz egy 0 -t. Van néhány buktató is: - Elfelejtettük a 16F programjában kiírni a w/f mezőt, a 18F -en megadjuk az A (access) címzést: Az A értéke 0, az f/w mező default értéke 1, ennek következtében hibás utasítás fordul:
- Ne használjuk a movff utasítást WREG és STATUS módosítására, rengeteg 18F kontroller a nem módosított értéket menti a hw regiszterekbe megszakítás beérkezésekor, a retfie fast rossz értéket állít vissza.
Sziasztok!
Az optokapu RB1/INT1 lábon segített, megszüntek a kéretlen megszakítások, tegnap du. órákat tudtunk autózni vele. Viszont kétszer sikerült úgy lefagyasztani a pic-et, hogy csak a táp-elvétel segített rajta. Most ezt keresem, csak nagyon nehéz produkálni a hibát.. valószínű hogy valam végtelen ciklusba kerülök, és előtte kikapcsolom a WDT-t.  Táp ügyben: tudtok a 7805 -el (D2pak) láb és funciókompatibilis, de jobb minőségű stab. ic-t, vagy muszáj kapcsolóüzeműre átterveznem a zavarvédelem miatt?
Köszi a választ, átmódosítottam a programot:
0x04-től: - w, status elmentése - ellenőrzöm, milyen megsz. van gotoval ugrok a megfelelő rutinra, majd onnan gotoval visszajövök - w, status visszaállítása - retfie. Kiszedtem a GIE piszkálgatását is, de ugyanaz a probléma továbbra is fennáll. Mi lehet az oka? Olyan előfordulhat, hogy elindul egy megszakítás (pl tmr0), és közben megszakít a gomb tökéletlen érintkezése?
Szilva szerintem nem arra gondolt hogy goto-val ugorj a megszakítás kezelő rutinra és onnan vissza, hanem a CALL - RETFIE páros helyett CALL - RETURN -al, és RETFIE csak a legvégén. Persze ez még szerintem nem fogja megoldani a problámádat.
Mégvalami.. bár nem emlékszem pontosan hogy ez hogyan volt 16F-eknél, de ha jól látom a főprogramban bankot váltasz, és közben jöhet a megszakítás, akkor azt is el kell mentened hogy melyik bankban vagy, majd átlépni abba amiben a megszakítást akarod kezelni, és a végén visszaállítani úgy mint w-t és status-t.
Szerk:  Nem jól láttam, nem váltasz bankot a főprogramban.
Segítség!
Azt hiszem elbaltáztam a PK2-met. Nem tudom mi az a gomb rajta, de rajta volt az ujjam, amikor csatlakoztattam az USB-re. villogni kezdett rajta a Busy lámpa, és mivel nem hagyta abba, leúztam. Aztán vissza, és most nem ismeri meg a pk2 program.
hát amikor nekem villogott a piros, akkor csak a pk2 progi segítségével újra kellett rá telepítenem az "operációs rendszert" (firmwaret)
Megvan a hiba: A megszakításkezelésnél, amikor ellenőrzöm, mi kérte a megszakítást, a végén ha az ellenőrzöttek egyike sem kérte, a főprogramra ugyrottam, pedig a változók visszaállítása részre kellett vola mennem, és így nem hajtódott végre a retfie sem, letiltva hagyva így a gie-t. Mostmár profin működik
és örülök, hogy rávezettél a rendes megszakításkezelés felépítésére.
Úgy tűnik, nekem más volt a gond.
Kiszellőztettem az agyam, és újra próbáltam. Akkor minden rendben volt. De ha már hozzákezdtem, én is utánanéztem kicsit. Az általad javasolt művelet eredménye az lett, hogy a pk2 program azt írta failed. Azért ennyiben nem hagytam a dolgot, úgyhogy a kézikönyvben alkalmazott Mplab-os verziót próbáltam. Ezzel sikerült is frissíteni, és utána a pk2 programot is. Így már minden működik.
Sziasztok...
Kérdésem az lenne, hogy lehet USART-al Break és Mark After Break jelet csinálni? DMX512-es adót próbálok meg jelenleg készíteni, van egy 4 csatornás dimmer, annak van egy állapot LED-je, és akkor fogja rendesen a csomagot, ha villog, de sajnos a villogás abba marad, a csatorna állapotot eldobja, így azt feltételezem, hogy rossz a csomag eleje vagy vége... Az első indításnál a beírt értékekre álnak be a lámpák, jelen esetben az első 30%-on, a második 100%-on, a 3-dik 0%-on a 4-dik meg 60% körüli értéket felveszi... Én erre gyanakszok, hátha van valakinek tapasztalata, megoldása  Előre is köszönöm
Ez nem PIC kérdés, miért nem kérdezed meg a DMX topicban?
Egyébként az USART egy szabványos soros port illesztő, a DMX más szabvány szerint működik, ha jól tudom. Lehet, hogy meg lehet oldani trükközéssel, de ez inkább DMX kommunikációban járatos emberkék tudják és ha van megoldás, az általános USART megoldás lesz, nem PIC specifikus.
Van még mit tanulnom.
Most próbálom reprodukálni a debounce progit. (sajna csak asm-ben van meg) Ott tartok, hogy megértettem a program lépéseit, bár azt nem tudom, hogy ha csak a D porton levő ledeket kapcsolom be a RB0-ra kötött gombbal, akkor miért kell az A portot inputnak állítani, és miért törlöm a display-t, ha nincs is. De a leginkább azt kéne megértenem, hogy hogyan állítom be az RB0-t digitális bemenetre. Az ANSELH 0-bitjét kellene 0-ra állítanom? Ha az adatlapot (887) olvasom, akkor a B port első hat kapuja lehet analóg, és ez a fölső bájtja a regiszternek az alsó pedig az A port. Jól értelmezem? akkor talán ezért kell állítani az A-t. De minek a display?
Már tavaly májusban ajánlottam neked az AN1076 alkalmazási mintapéldát. Abban a 3. ábra és a fölötte lévő magyarázat mutatja, hogy a 92-176 us hosszúságú Break jelet nem az UART küldi, hanem az UART TX vonalat a kívánt időtartamra földre húzzák a PIC RC5 lábával. Majd, ha az időzítés letelt, az RC5 láb tristate állapotba kapcsolásával engedik az UART adását.
Nagyon fontos, hogy a lehúzott vonalra az UART Tx egy áramkorlátozó ellenálláson keresztül kapcsolódjon, nehogy túlterhelődjön a PIC kimenete. Én az ábrán látott 100 Ohm-nál nagyobb elllenállást tennék, hiszen úgyis csak az RS-485 meghajtót kell vezérelni vele.
Igen, olvastam, de azaz igazság, hogy nem vettem figyelembe a MikroPascal nyelvi program korlátait...
A DMX-es topic-ba már írtam, ugyan azt a problémát már megoldottam, Register szintjén mentem bele a történetbe, és megértettem, hogy amit a MikroPascal nyújt, az csak ilyen kiegészítő, hisz bármely Registert egyszerűen tudok változtatni... Így is, hisz inicializáltam az USART portot a beépített kóddal, majd Register szintjén átállítottam a sebességet, és odáig eljutottam, hogy a csatorna kis ideig megy, utánna eldobja... Am, most, hogy elmondtad, mit tesz ott a 100Ohm-os ellenállás, és azt a portot mire használja épp, már értem. Épp most csináltam meg a módosítást, tényleg működik, most már csak egy pici gond van, mivel villog az első csatorna valamiért Köszönöm a segítséget...
Sziasztok!
Adott egy 32 bites pic, amivel jelet szeretnék generálni. A kimenetet szeretném analóggá tenni, ezt DAC-rel végzem. A pic-nek 3 szóba jöhető kimenete van, amihez csatlakoztathatom a DAC-ot: - i2c - spi - 16 bites párhozamos port. Melyiket érdemes használni a három közül? (És miért azt?) Kösz. Sz.G. ps: a leggyorsabb, leghatékonyabb kapcsolat kellene |
Bejelentkezés
Hirdetés |
