Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Hy!
Valaki meg tudná mondani, hogy a 18F1826-nak melyik memóriacímen kezdődik az EEPROM memóriaterülete? Arra gondolok, hogy ASM-ben pl: 16F628-nál meg lehet adni programban az EEPROM tartalmat: ORG 0x2100 DT 0,1,2 Az adatlapban himölnek-hámolnak, de konkrét értéket nem találok a Data EEPROM and Flash Program memory control témakörben... Köszi előre is!
Feltételezem, hogy 18F1826 helyett 16F1826-ról van szó.
Legegyszerűbb megnézni a linker állományban (nálam régi MPLAB van fenn, az még nem ismeri ezt a típust), egy ehhez hasonló sort keress:
Szia!
A keresett sor az MpLab 8.56 16F826_g.lkr állományából:
A hex állományban való elhelyezéséről a programozási leírása 7.3 bekezdése szól: Idézet: „The physical address range of the 256 byte data memory is 0000h-00FFh. However, these addresses are logically mapped to address 1E000h-1E1FFh in the hex file. This provides a way of differentiating between the data and program memory locations in this range. The format for data memory storage is one data byte per address location, LSb aligned.”
Köszönöm,
igen elgépeltem 16F1826-ról van szó. a 16F1826_g.lkr fileban a következőt találtam: CODEPAGE NAME=.idlocs START=0x8000 END=0x8003 PROTECTED CODEPAGE NAME=.devid START=0x8006 END=0x8006 PROTECTED CODEPAGE NAME=.config START=0x8007 END=0x8008 PROTECTED //CODEPAGE NAME=eedata START=0xF000 END=0xF0FF PROTECTED CODEPAGE NAME=eedata START=0x02100 END=0x21FF PROTECTED ezek szerint 0x02100-nál kezdődik, de hiába írom ezt be a programba, mégsem látható PICkit2-ben az eeprom tartalom. Ha viszont az MPlab-ba a view-->EEPROM ablakba írom be az eeprom tartalmat, az viszont látszik a PICkit2-be (természeresen csak ha a file menüben exporttal kiexportálom a hex filet minden tartalommal együtt). Ilyenkor most mi lehet?
Szia!
A 0x2000- 0x7FFF tartományban is a program memória van.. Frissíteni kell az MpLab-ot... Az újfajta 16F-fel nagyon sok hiba volt még az előző verziókban (Nem lehetett 0x2000h fölött levő rutinok hívását szimulálni sem...) 16.-án tették fel a 8.56 verziót...
Köszi, akkor azt megnézem, jelenleg 8.53 van fennt...
Különben mi a véleményetek, mennyire érdemes ezekkel a 14bites enhanced verziókkal foglalkozni, mennyire fognak befutni a jövőben?
Ahogy látom a hagyományos 16F sorozatból elég soknak függesztik fel a gyártását, két évvel ezelőtt még közel 100tipust gyártottak, mára valami 45 félét csak, ezért gondoltam, hogy az enhanced tipusokkal fogom kiváltani a hagyományos architektúrájuakat,amennyiben megszünnek... Mit gondoltok vakvágány ez a sorozat, vagy van létjogosultsága, és várhatólag évekig gyártják majd?
Nehéz megjósolni, egyenlőre sok bennük a hiba. Az Errata-kat mindenkép olvasd el.
A stack mérete, a stack tetejének kezelhetősége kedvez a magas szintű programnyelvek fordítóinak, de hiányzik a push és a pop utasítás. Egyszerűbb a 8 bitnél hosszabb számokkal való műveletvégzés, és a tömbök kezelése. A jövőjük attól függ, lesz-e hatékony C fordító a családhoz. A 18F széria előnyös tulajdonságaiból nem mindent vettek át sajnos... Ami biztos, hogy egyre katasztrófálisabb a programozásuk ezeknek az eszközöknek. Ennek a 16F1826-nak 400 oldal a leírása, a 16F628-al összehasonlítva annak csak 196 oldal volt (úgy emlékszem). Valóban többet is tud, de én úgy érzem ez túl sok minden amit tud, erre nincs szükség (pl: oszcillátor modul. Ha más frekit szeretnék mint 4MHZ, akkor teszek rá külső kristályt....) Volt itt egy érdekesség is: Gondoltam minden egyes lefutáskor megváltoztatom egy bit értékét, hagyományos módon: BTFSS MPFLAG,0 BSF MPFLAG,0 BTFSC MPFLAG,0 BCF MPFLAG,0 Na, ez így nem működött... Szimulátorban sem akarta végrehajtani... ezt nem is tudomm, hogy miért. Mindenesetre csak így működik: MOVF MPFLAG,W XORLW .0 MOVWF MPFLAG Úgy érzem, hogy programozási szempontból még elég sok meglepetést fognak tartogatni... Jelenleg nem nagyon tetszik...  Sorry az OFF miatt...
Speciális alkalmazások esetén biztosan van létjogosultsága ezeknek is, de általános célra, tanulásra inkább a PIC 18 vagy a PIC24 sorozatot ajánlom.
Idézet: „Mindenesetre csak így működik: MOVF MPFLAG,W XORLW .0 MOVWF MPFLAG” Nem így akartad inkább írni?
Inkább így:
1. MOVLW 0 2. XORWF MPFLAG,F ? ( annyi különbséggel, hogy így a W-ben 0 marad! ) Steve
Szia!
A "xorwf valami,f", ha W = 0, csak a Z flag-et állítja, a valami címen az adat nem változik. Milyen egyszerű 18F -et "btg valami,0".
A PICCOLO projekt (Ismerkedés a PIC18 mikrovezérlőkkel) Assembly programozás haladóknak c. fejezetét kiegészítettem a makrózási lehetőségek rövid bemutatásával.
Az új fejezetrész tartalma: # Makrók használata o Kiterjesztett pontosságú értékadás makróhívással (macro1.asm) o Logika léptetés makróhívással (macro2.asm) o Címkék használata makrókban (div32_32u.asm) o Számozott címkék használata makrókban (for-next.asm) Az új fejezetrész mintaprogramjainak forráskódja egyelőre csak az esca.atomki.hu/PIC18/code/ch07/ címen érhetők el, új code_examples.zip kiadást lusta voltam készíteni. Az alábbi példák talán érzékeltetik, hogy miről van szó: Kiterjesztett pontosságú értékadás, léptetés, osztás
Szorzótábla kiszámítása (1x1 - től 10x10-ig) egymásba ágyazott FOR-NEXT ciklusok segítségével
Ahhoz képest, hogy assembly nyelven írt programról van szó, egész olvasmányosnak tűnik, nemde?
Aha, én azt hittem csak a nullát akarja leellenőrizni, bár arra jobb a MOVF VALAMI,F !
Steve
Igaz, elgépeltem a fórumban az XORLW .1
Valóban így két sorban is meg lehetett oldani, nekem három sorban sikerült...
Az nem gond, hogy eggyel több az utasítás. Egy kísérleti programnál ez lényegtelen.
A baj az, hogy ez az "előveszem, teszem-veszem, visszaírom" megközelítés elvileg hibás módszer. Mert mi van akkor, ha egy konkurens folyamat (pl. interrupt) módosítja a regiszter egy másik bitjét a kiolvasás és a visszaírás között (pl. 1-be állítja a 4. bitet)? Mi meg gondatlanul visszaállítjuk 0-ba, amikor a munkaregiszterben előállított tartalmat visszaírjuk a regiszterbe. Az aranyszabály az, hogy a munkaregiszterben csak a maszkot állítsuk elő, a regiszter módosítása pedig egyetlen lépésben, egy XOR utasítással történjen. Ez így - a konkurens folyamatok szemszögéből nézve - atomi művelet, mert programmegszakítás vagy taszkváltás nem tudja megzavarni. (a hardver szempontjából ez is RMW művelet, de ez most nem szempont...)
Sziasztok!
Szeretném egy komoly problémára felhívni a figyelmet! A PIC-ek MCLR/Vpp lába igen érzékeny túlfeszültségre(sztatikus, induktív). A tapasztalatok szerint ha nincs a lábon felhúzó ellenállás(10k), vagy ez ki van egészítve egy diódával(viszirányú áram korlátozása célból), akkor az MCLR lábra a Vpp lekapcsolásakor a vezetékek induktivitása miatt feszültségtüske kerülhet, ami a PIC halálát eredményezi. Én a 10k-t mindig beépítettem a céláramköreimbe és mindig ICSP módon(áramkörön belüli programozás) programoztam, ezért nálam soha nem jelentkezett ez a fajta halálozás. Akkor jött elő ez a probléma, amikor a WLPT_mini programozókat foglalatos, vagy lengő foglalatos módban kezdték használni a fórumtársak. Sajnos ezt nagyon nehéz kivédeni, miután úgy gondolom, hogy ez az alkatrész nem az égető áramkör része. Sokan úgy gondolhatják, hogy megoldás lehet, ha az égetőbe is betervezünk egy 10k-t felhúzónak. Sajnos ez nem minden esetben működik, mert ha a céláramkörben is van egy 10k(vagy kisebb), akkor a két ellenálláson már akkora áram folyhat, amit egy 78L05 már nem tud elnyelni, ami az 5V(Vdd) megemelkedéséhez vezethet a Vpp bekapcsolásakor. Az egyetlen megoldás, ami jó, hogy a 10k-t nem felejtjük el beépíteni(dióda nélkül)!
Üdv!
A programozóba építve egy 13V-os zener nem segítene ezen? (Esetleg az ICSP csati tüskéire forrasztva, vagy a DIP foglalatra, szóval a vezeték túloldalán.)
Végül is igen, én a PK2-re is tettem egyet, mert ott meg a programban nem bíztam, ami a Vpp-t szabályozza. A kapcsolt ICSP vonalban lenne a legjobb helye az égető panelen.
Persze, felmerül a kérdés, mi van akkor, ha lehúzom az ICSP csatlakozót az áramkörről? A láb akkor is lebegni fog(lehet elég csak hozzáérni jó kis pulóverben!). Végül én még is a 10k-ra szavazok a PIC-en, az úgy is kell.
Na igen, a felhúzó ellenállás fontos a működés szempontjából is. Régebben az egyik nyákomon meg volt szakadva a MCLR-nél, szóval lebegett, és hát elég sokáig tartott rájönnöm, mi okozza a másodpercenként többszöri reset-et. Szóval még a hálózati brummot is fel tudja szedni. Én is mindig ICSP-vel programozok, de azokon, akik foglalatban programoznak, talán segíthet nekik ez a megoldás. Feltéve ha a kapacitása nem zavar be az időzítéseknek.
Igen, bizonyos esetekben védene.
Arra is gondoltam, hogy talán egy 33...47k is megtenné, így nem okozna gondot az említett kapacitás, bár szerintem nem okozna bajt az sem. Itt nagyon kicsi töltést kellene megfogni, ami viszont éppen elég egy FET-nek a halálhoz...
Szia!
Zajosabb helyeken én is le szoktam menni 1-2K környékére, dióda nélkül. Nekem sem volt még egyszer sem gondom vele, talán mert az ICD2-mben 10A-es fet-ek kapcsolják a Vpp-t, amik egyben diódaként is működnek. Néha viszont MAX690-re bízom a MClr kezelését (természetesen jumperrel a programozhatóság miatt). Délután viszont azon gondolkodtam, hogy Microchip-nél miért nem szorítottak helyet a szilíciumlapon egy zenernek... 
Sziasztok!
Egy régebbi 16F886 kontroller programjában kellett (ismét) hibát keresnem, és meglepődve tapasztalom, hogy az MpSim verziók (a 8.53 és 8.56 MpLab csomagban) nem jó kezelik az UART adás megszakítás bitjét (PIR1,TXIF). Állandóan buffer felülírást jeleznek, pedig beprogramozva a soros kapcsolat rendben működik. A régebben bemért, ellenőrött rutinokba nem nyúltam bele.
Az adatlap szerint a TXREG írásának törölni kellene a PIR1,TXIF bitet, de az utasítás után megállítva a szimulációt, a PIR1,TXIF bitje 1. (A bank beállítást ellenőriztem - beprogramozva működik.)
Vártál utána? Az adatlap szerint nem törlődik azonnal:
Idézet: „The TXIF flag bit is not cleared immediately upon writing TXREG. TXIF becomes valid in the second instruction cycle following the write execution. Polling TXIF immediately following the TXREG write will return invalid results.”
Szia!
Köszönöm az ötletet, de kb 50 - 52 us-onként mindig ráfutott a megszakításra. Közben megtaláltam a hiba okát: A 16F886-ot a végsőkig kinőtte a program. A TXSTA két, a 8 bites aszinkron üzemmódban nem használt (TXSTA,CSRC ill. TXSTA Tx9D), bitjét felhasználtam. Amikor ezeket írom, a szimulátor azt érzékeli, mintha üzemmódot váltottam volna. A problémát a CSRC bit okozza, ami szinkron módban a master/slave üzemmód beállítására szolgál. Az adatlap azt mondja, hogy aszinkron módban "nem használt". Sajnos az előző szimulátorokkal (8.20 -ig visszamentem), mindegyik ugyanúgy működik, a forrásomban két verziót visszalépve, a hiba megszünt. További bővítés már 18F2x20 kontrollerbe fér csak bele. Még egyszer köszönöm... |
Bejelentkezés
Hirdetés |
