Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Honnan lehet lőni 24 bit bináris -> 8 digit BCD átalakító rutint?
Szia!
Elolvastam, de meg sem említi, hogy ha nem csak a Page0 -n van kód, akkor a megszakítási rutinnak a PCLATH-t is menteni, a saját lapjára állítani és visszaállítania kell. A saját lapra való állítás előtt tilos a goto és a call használata. A "0. lapra való regiszter mentés" a PCLATH beállítása előtt ugrik, ami visszamegy arra a lapra, ahonnan a megszakítási rutinba jött... Egy több lapot használó programban biztos kék halál lenne, ha a pic ismerné a színeket. :shocking:
Köszönöm!
De ahogy nézem az utasításokat ezek 16F-re vannak. Mondjuk nem nagy ügy átírni, meg találtam is benne pár hülyeséget (pl.: "MOVLW 3"???). Kijavítgattam:
A DIGIT1-DIGIT8 lennének gondolom a kimeneti regiszterek és talán a COUNT0-COUNT2 a bemenet? Mert semmit nem csinál a rutin... 
Szia!
Én másikat választottam, ez tetszőleges hosszúságra (2 BCD digitenkénti lépéssel) megírható:
És visszafelé:
Ahogy látszik pic18F-re átírtam őket. A temp változó címének alsó három bitje 0 kell legyen, bár egy kis további kódolással ez a megkötés is megszüntethető.
A hardveres pergésmentesítést megtaláltam. De a szoftvereset nem. Tudnál benne segíteni?
Szia!
A gomb lenyomva ad 0-t. Vegyél fel minden gombhoz egy adatbájtot. Egy ciklusban léptesd egyet balra a gombhoz tartozó adatot. A 0. bitre másold be a gomb bemeneti értékét. A léptetés után a 7. bitet állítsd 1-re. Eztán nézd meg, hogy az adat 0xC0 -e. Ha igen, akkor a pergés lezajlott, az utolsó 6 minta 0, hívd meg a gombhoz tartozó eljárást. Egyébként egy kis várakozás után menjen a ciklus elejére.
Hűűű ez sokkal jobban hangzik és ez már csinál is valamit! De persze nem azt amit kellene...
A bemeneti regiszterek ugye a TEMP+7, TEMP+6 és TEMP+5. A kimenet pedig a TEMP...TEMP+7. Így próbáltam de hatalmas számok jöttek ki, noha a végén 9-nél nem szabadna többnek lennie egyik regiszternek sem mert ugye BCD... Idézet: „A temp változó címének alsó három bitje 0 kell legyen” Lehet hogy ez a gond, mert nálam a TEMP változó a 020 és a 027 címek közt terül el a Watch ablak szerint. Bár itt a cím maga csupán három bites... nem értem...
Szia!
A kimeneti változókban helyiérték szerint TEMP+7:TEMP+6:TEMP+5 két - két decimális számjegy van (Pakolt BCD). Innen a nagobb helyiértékű a swapf TEMP+x,w és andlw 0x0F, az alacsonyabb az movf TEMP+x,w és andlw 0x0F utasításokkal olvasható ki. A TEMP nálam a 0x000 címen van. A kritikus művelet a ciklusoknál van, a kilépési feltételt egyszeű bitvizsgálattal oldották (oldom) meg: btfss FSR0L,2,A illetve btfss FSR0L,3,A - 0x20 címmel is mennie kell. Szerintem két oka lehet a hibának: a bemeneti oldalon helyiérték csere, vagy a kiolvasásnál valami elcímzés... Illetve FSR0 mentése a megszakításban - ha az ISR használja...
Hali!
Kösz, a Reset funkciót ismerem. A resetre vagy a Reset Device-re nem történik semmi. Sztem a fordítás körül lehet valami gond. Esetleg kitudnál segíteni a Hex file-vel, össze tudnám hasonlítani. Üdv.
Szia!
Átszabtam egy kicsit, de nem akar működni. 
A megszakítás (meg semmi más) nem nyúl az FSR2 mutatóhoz, direkt ezért írtam át az eredetileg FSR0-t FSR2-re, mert én az FSR0-t és az FSR1-et használom más célokra. Szerk.: A TEMP+4-et nem írtad hogy abban is pakolt BCD lenne, de gondolom csak elfelejtetted, hiszen akkor csak 6 digit lenne 8 helyett.
MEGVAN!
A pakolt BCD nem a TEMP+7, TEMP+6 és TEMP+5 regiszterekben van, hanem a TEMP+3, TEMP+2, TEMP+1 és TEMP. :yes:
Szia!
Bocsánat elírtam... Mentségem, hogy egy több hónapos programból szedtem ki - a frekvencia mérőból ... A bemeneti sort másoltam ki kimenetnek. Még egyszer bocsánat. Remélem működik.... A digitek kiíratásánál oldottam meg a pakolt BCD kettévágását:
Nagyon köszönöm! Így gondoltam. :worship:
Ma kipróbálom! Ha még így sem megy, akkor felhagyok a PIC programozással.  Csak vicceltem...
Olvasgattam az adatlapot és egyrészt megtudtam hogy a PLL a belső oszcillátorra is rákapcsolható, másrészt pedig hogy a belső oszcillátor nem csak 4MHz-en ketyeghet hanem 8MHz-en is. Szóval max 32MHz-en mehet a PIC külső kvarc nélkül ami azét jó mert három alkatrésszel több hely marad a nyákon és kb 60Ft-al kevesebb lesz az anyagköltség.
De nem vagyok benne teljesen biztos hogy hogyan tudom ezt beállítani. Így jó lesz? Az elején: Idézet: „config OSC = INTIO67” És az inicializáláskor: Idézet: „movlw b'01111110' ;8MHz movwf OSCCON bsf OSCTUNE, PLLEN ;PLL bekapcsolása”
Ja bocsánat elfelejtettem: még mindig PIC18F2523-al alkotok.
Sikerült rájönnöm, az előző hozzászólásomban írtak majdnem jók, csak annyi hogy az OSCCON regiszterbe b'01111110' helyett b'01111100'-t kellett írni. Elvileg most 32MHz-en megy.
Viszont most más problémám van: kb másfél órája túrom az adatlapot és az internetet hogy megértsem hogyan kellene felkonfigurálnom a CCP modult hogy 10 bites PWM-ként működjön a lehető legnagyobb frekvencián (hogy kisebb L-C integráló tag is elég legyen). De egyszerűen nem világos hogy mi és hogyan határozza meg a PWM frekvenciát... 
Szia!
A CCP PWM időalapja a Timer2. Ahhoz, hogy 10 bites legyen a felbontás és 1024 lépésben legyen állítható a kitöltés, a PR2 -nek (256-1) -nek kell lennie . Már csak a Timer2 előosztójának a megváltozása marad.
Szia!
Közben addig eljutottam, hogy a TMR2 előosztójának 1:1-nek kellene lennie (meg az utóosztónak is, de lehet hogy ez teljesen mindegy), a PR2-nek pedig d'255'-nek. Legalábbis talán. De a CCP1CON regiszter DCxB1 és DCxB0 bitjeibe elképzelésem sincs hogy mit kellene írni és az sem világos teljesen hogy magát a kitöltési tényezőt hova kell beírnom, az alsó nyolc bitet a CCPR1L-be, a felső kettőt pedig a CCPR1H regiszter alsó két bitjébe? Ja, és 32MHz-en megy a PIC (most már).
Szia!
CCP - PWM módhoz a CCPxCON regisztre CCPxM3..0 = 11xx. ECCP - PWM módhoz, ha a jel a P1A kimenet kell csak: a CCPxCON regisztre CCPxM3..0 = 1100 és P1M1..0=00. Magyarán mind a két modulnál egy kimenő jelhez a CCPxCON=0xC0 jó. A kitöltés felső 8 bitje a CCPRxL be, az alsó két bitje a CCPxCON DCxB1 és DCxB0 bitjeire írandó.
Üdv Picezők!
Orbitális szíváson vagyok túl megint, és ezt le kell írnom. Adott egy LCD rutin, saját kreálmány, használtam már sokszor 16F en. Tud 4 és 8 bites módot is, lehet konfigozni, hogy melyik porton, melyik nibble -t jasználja, stb. 18F45K22 -n viszont az Istennek se akart menni. Nem azokat a karaktereket írta, amiket küldtem. Azt tudni kell erről a pic tipusról, hogy ezt debugolni már nem lehet pk2 -vel. Proteus szimulátorban ez a konkerét pic nincs, csak egy hasonló, 18F45K20. Azzal a szimuláció pedig ment. Elővettem a próbapanelt, beraktam egy másik ugyanilyen picet, bekeötöm ott is 4 bites módban, nem megy ott se. Ok elővettem egy 18F4550 -et, azt támogatja a szim is, meg pk2 is. Viszont azon meg ment 4 biten is. Na ez már kezd érdekes lenni igaz ? Ekkor kezdtem gyanakodni, hogy mégsincs jól beállítva a port amin kommunikálok, ansel bitekre gondoltam, de akárhogy állítgattam nem volt jó. Bekötöm kínomban 8 bitesben, úgy meg megy. Kb 2 napig nézegettem az adatlapot, próbáltam minden perifériát letiltani ami az adott portlábakat használhatja, semmi eredmény. Debugolni meg nem lehet pk2 -vel. Na erre jött az ötlet, hogy felraktam a próbapanelre egy 7402 -t, csináltam belőle egy HW flipflopot, a picbe pedig írtam egy kis 1 soros C makrót, ami figyeli egy lábon a flipflopot, és csak akkor fut tovább a program, ha megváltozik az állapota. Be is raktam az lcd strobe részbe, hogy lássam miket küld az lcd nek. Ledeken figyeltem a 4 bites nibble-ket, és az RS -t. Na és itt derült ki, hogy karakter első nibble küldésekor nem állította át az RS -t 1 re. Igaz két egymás utáni utasitasban állítottam be a két bitet. Ebben az a fura, hogy 18F ben elvileg ugye a LAT regiszter pont arra szolgál, hogy ne legyen RMW hiba. Mégis 16F en futott a kód gond nélkül. Átrendeztem a kódot, hamarabb beállítom kicsit az RS-t, és később latchelem be az ugyanazon porton levő E lábbal. Persze mindezt a lat regiszterek piszkálásával teszem. Szóval érthetetlen számomra, hogy ez most mi. Miért megy 16F en, 18F4550 -en, és miért nem ment 18F45K22 -n.
Milyen sebességen járattad a 45K22 mikrovezérlőt? Nem lehet, hogy egyszerűen túl gyors volt a tempó, s nem tartottad be a TAS (RS vagy R/W - > E) "követési távolságot"?
Ez nem RMW, hanem "LCD adatlap ajánlásainak be nem tartása" probléma.
Alap belső osc, 16Mhz. De mondom , más picen ment, pl 20Mhz - 16F887 en. Ja és próbáltam persze lassabb órajelen is. De az sem segített. Csak az hogy nem billegtetem egymás után a lat biteket. Az E bit magasra állítása előtt álltam meg, és nem volt bekapcsolva egyáltalán a RS bit, holott be kellett volna neki. Tehát nem a magas órajel miatt nem volt ideje magas szintre mászni RS nek. Ezért is tudtam észrevenni szemmel , ledekkel.
Nemrég nálam volt egy olyan mókás dolog, hogy egy lineáris potit kötöttem tesztelésre (illetve tanulásra) A/D lábra, lcd-re írta ki 0-1023-ig az A/D értékét. Az érdekes csak az volt, hogy a poti csak logaritmikusan állította a feszültséget (először nagyon hirtelen, aztán pedig egyre kevésbé változott az érték). Multival rámértem, a feszültség is logaritmikusan változott. A poti pedig lineáris volt.
Aztán a programban mit találok.. 8jegy helyett véletlen 7-et írtam be a TRISB-re, így az a láb, amire volt kötve a poti, kimenet volt, és ennek hatására logaritmikusan változott a feszültség rajta   A pic és a láb is túlélte.. 18F4520ról van szó.
Ezt nem értem...
A PIC-et átültettem egy másik panelba, amin semmi lényes különbség egyébként nincsen. Az előző panelon még a PIC normálisan mért (Bővebben: Youtube), ugrálás nélkül. Most ugyan azzal a szoftverrel ugrál a kijelzés! Azon először külső 10MHz-es kvarcról ment PLL-el 40MHz-en, aztán kiforrasztottam a kvarcot és átállítottam hogy belső oszcillátorról ketyegjen PLL-el, 32MHz-en. Akkor is ugrálás nélkül mért. Az A/D FOSC/32-re és 2TAD-re volt állítva mindig. A PIC pedig PIC18F2523. Egyenlőre arra gondoltam hogy az FOSC és a TAD beállítások nem jók, noha eddig jó volt. Próbálgattam más értékeket de ugyan úgy ugrál. Szóval lehet hogy valami egészen más jellegű hibája van. Hardveresen teljesen hibátlannak tűnik a műszer, mert a referencia (a PIC külső referenciát kap) és a mérőjelek is teljesen stabilak. Szóval az ugrálás már a PIC-ben kell hogy "szülessen". Viszont ehhez csak az A/D konfigurációnak lehet köze. Az meg mint fentebb írtam eddig jó volt, meg most próbálgattam más értékeket is de nem lett jobb.  Szóval kezdek elkeseredni... bár negyed egy van és ilyen későn szoktam érdekes dolgokat alkotni... Ilyenkor reggelre mindig kitalálom a megoldást, adja Isten hogy most is így legyen.
Basszus, most kivételesen nem kellett reggelig várnom a megoldásra.
A műszer AC tápfeszről is megy, meg kaphat külső +-5V-ot is. Eddig az előző panelon +-5V DC-t kapott, most meg AC-ról hajtottam. Ha DC-t adok neki akkor ez is hibátlanul mér. Érdekes amúgy, mert megvannak a tápfeszek, stabilak meg minden... Na mindegy, most már tudom merre keressem a hibát.Már többször tapasztaltam amúgy hogy a PIC elég érzékeny a (táp)feszültségekre. Gondolok itt akár a tápfesz kötelező pufferolására stb... Vagy például attól is megbolondul ha negatív feszültséget kap valamelyik bemenetén. Ezzel is mennyit szenvedtem anno mire rájöttem.
Igen, olvastam, sajnos. Eléggé elszomorító hogy pl az ember vált egy nagyobb picre, és olyannal szembesül fejlesztés közben hogy ennek meg az ADC -je defektes. Nade ott még nem tartok, egyenlőre az alap rutinokat szeretném működésre bírni. Így tiszta fejjel visszagondolva a tegnapira, érdekes dolog ez. Lehet hogy a C fordító cseszett el valamit. Este majd rakok fel kódot, még jó hogy tudom reprodukálni a hibát. Ugyanis ha megállok a két bit billegtetés között, akkor is alacsony maradt az RS bit, és ennek semmilyen HW logika szerint nem lett volna szabad megtörténnie. Arra gyanakszom, hogy kétszer is beállítottam azt a bitet (feleslegesen persze, hiszen elég lett volna csak az első nibble előtt), és lehet hogy az elsőt kioptimalizálta a fordító.
Attila86: ez érdekes, mert ok hogy "zajos" a táp AC -ről, nade nem átlagolódik ki ? Idézet: „Attila86: ez érdekes, mert ok hogy "zajos" a táp AC -ről, nade nem átlagolódik ki ?” Mondom, nem zajos a táp AC-ról sem. A még érdekesebb az az, hogy a műszer elődjének táp része ugyan ilyen felépítésű, az mégsem ugrál. |
Bejelentkezés
Hirdetés |
