Fórum témák
» Több friss téma |
Helló! Lenne egy olyan bugyuta kérdésem, hogy 18F4550 en bootloader mellett hogyan kell a megszakítást definiálni assemblyben? Mert többféle képpen próbáltam, de nem sikerült
 próbáltam pl úgy hogy #define int hi_isr de így nem megy. Címnek 0x1008 at használtam. Üdv! Balage
Szia!
A magas priorítású megszakítás címe: 0x000008 (elég csak ennyit írni: 0x08). Vagyis ha magas prioritású megszakítás történik, a program ezen a címen folytatódik, amíg nem találkozik a RETFIE utasítással. Szerk.: bár azt nem tudom, hogy a bootload mennyire szól bele a megszakításba, ezért is vizsgálni kell mi hozta létre a megszakítást.
Idézet: Nézd meg a PICCOLO projekt include/p18_all.inc állományában!„18F4550 en bootloader mellett hogyan kell a megszakítást definiálni assemblyben?”
A "fill" makrók ahhoz hellenek, hogy a megszakítási vektorok a megfelelő (HID bootloader esetén 0x1008 és 0x1018) címre kerüljenek. Az RST szekció címét a common/PIC18f4550.lkr linker állomány definiálja. Az extern kezdetű sorok csak akkor kellenek, ha a kiszolgáló eljárások külön fájlban vannak!
Elhatároztam, hogy belekezdek a C18-ba, viszont már az alapoknál vakarom a fejem. Elvileg lennie kéne a telepítési mappában (C:\MCC18) egy "lkr" mappának, amiben vannak a linker fájlok. Viszont nekem a "C:\MCC18\LKR" mappában vannak linker fájlok, ráadásul ezeknek a fájloknak a végén szerepel egy "g" betű (pl.: 18f1320_g.lkr).
Ez jelent valamit, vagy használhatom ezeket a linker fájlokat?
Köszönöm! Ezzel már boldogulok!
 Üdv! Balage
újabban valamiért az "MCC18\bin\LKR" mappában vannak a linker állományok.
Az állományok nevében a "g" betű az általános (general) felhasználhatóságra utal. Ezeket kell használni. Korábban külön volt a debugoláshoz, most feltétes direktívákkal kezelik a DEBUG vagy RELEASE változat kezelését. A hibavadász módban ugyanis a debugoláshoz a memóriából le kell csípni egy kicsit.
Sziasztok!
Kezdő vagyok PIC terén és elakadtam már az elején a programozásnak. PIC24FJ128GA010-es családot szeretnék programozni, mely nekem egy PIC16-os próbapanelben van. Ez egy tesztáramkör. Mivel a 16 bites PIC-ek portjai 16 bitesek, ezért 16 bitesként kell címezni őket. A kérdésem az lenne, hogy a TRISx regiszter esetén a portokat 0xFF00 formában kell megadni, hogy a port alsó nyolc bitje kimenet legyen. Ez gondolom azt jelenti, hogy az A0-A7-ig kimenetnek programozom az iránybitet. De viszont láttam egy példában, hogy a port visszaolvasására használt LATx regiszter úgy van megadva, hogy 0x00FF. Ez mit jelent? Binárisan értem (0000 0000 1111 1111), de a visszaolvasást a portra vonatkozóan a jobb oldalról kell elindítani a TRISx-nél pedig balról? Nem értem. A másik kérdésem viszont az lenne, hogy eltudná-e magyarázni nekem valaki mint jelent az, hogy alsó meg felső bit? Köszönöm a választ! Üdv.
A LATx regisztereket írásra használják, míg a PORTx regisztereket olvasásra.
Nem véletlenül alsó- és felső byte (annak még értelme is lenne)? Az alsó az alacsonyabb címen levő byte, míg a felső a magasabb címen levő byte. A 16 bites kontrollerek adatbusza 16 bites, így egyszerre 2 byte-ot tud kezelni. Valahogyan ezeket pedig meg kell különböztetni (pl.: alsó és felső). Vagy esetleg MSB, LSB-re gondolsz? Előbbi a legmagasabb helyértékű bit, a másik meg a legalacsonyabb.
Javaslom, hogy nézz szét a honlapomon a PICkwik projektben! Bár én kis lábszámú PIC24HJ típust használok, te meg nagy lábszámó PIC24FJ típust, olyan egetverő különbség nincs az alapokban. Nálad több port van, az órajel frekvenciáját pedig csak négyszerezni lehet (8 MHz-ből 32 MHz lesz, az utasításciklusok frekvenciája ennek az utóbbinak a fele lesz: 16 MHz.
Milyen kártyát használsz? Ha Explorer16-ot, akkor a letölthető mintaprogramok között egy külön könyvtárban van néhány erre az áramkörre átdolgozott példa is.
PIC16F887-es processzort programozok MPLAB-ban, HTC compilert használva. Amíg csak assemblyben programoztam könnyen metn minden, de most hogy rátértem a C-re nem tudom miként kell beállítani a progmramot úgy, hogy működjkön is amit letöltök a chip-be:
Az alábbi problémám van:
Ezen programot HEX fájllá alakítva, majd letöltve a chip-be csupán a programozás idejére villannak fel az említett LED-ek - PORTD LED-jei. De csupán addig világítanak a LED-ek amíg a PICKit2 Busy jelzése villog, magyarán amíg programoz. A Konfigurációs biteket az MPLAB-->COnfigure-->COnfiguration Bits.... menüben állítom be, INTOSCIO oszcillátor beállításon, és Watch-dog timer kikapcsolt állapotban van, Power-up Timer engedélyezve van. GOndoltam arra, hogy a WDT kavar be, de mint említettem azzal nem lehet gond. Mi lehet a probléma, vagy mit kellene beállítanom, hogy működjön a program a felprogramozás után is?!?! Még az életben nem programoztam C-ben PIC-et szóval kicsit elveszve érzem magam...  Köszi a segítséget előre is!
Szia!
- Az MpLab ablakában fent, középen a Debug opciót állítsd át Release -re. - Ellenőrizd le, hogy a konfigurációs biteket valóban a kézi beállítás szerint programozta be. Indítsd el az MpLab -ot, a config meüben állítsd be a kontroller típusát. A programozóvan olvasd be a kontroller tartalmát. Nézd meg a beolvasott konfigurációs bitek állapotát.
A chip az be van állítva, viszont visszaolvasáskor a konfig bitek 3FE4 0700
AZ MPLAB-ban viszint a Configuration Bits... menüben: 3FE4 7FFF, amit már eleve sem értek, mert a Config2 regiszter hogy a viharba lehet 7FFF ha annak csupán a 8-9-10. bitje állítható. De ettől eltekintve kiolvasáskor azokat az értékeket kaptam amiket MPLAB-ban szövegesen kiírva állítgattam, majd adatlapban visszaellenőriztem. Nem értem mi lehet a gond :| Ha egyszer feltehetőleg beleírta a progit, hiszen egy pillanatig felvillant aminek kell... Egyéb ötlet esetleg?!?!
Szia!
A config2 visszaolvasott értéke biztosan hibás, ugyanis a program memória 14 bites, a maximális érték 0x3FFF lehet. Vagy a RB6 és RB7 vonalakon van valami probléma, vagy ezeket a lábakat kimenetre állítja a program igen rövid időn belül... Próbáltad már Use Vpp first programming entry móddal is kiolvasni a pic -et?
Köszi a segítséget, de már megoldódott a probléma.
AZ MCLR config beállítással volt a probléma, szerencsére megoldódott, és megy minden már. Meg is írtam az első programom, de ott meg ugyanaz az AD konvertáló programom ami assemblyben hibátlanul fut, C-ben megírva, ugyanazon regiszter beállításokkal semmit nem csinál.... szóval most megint valami más marhaságra kell rájönnöm.....
Köszönöm a választ! Az oldalon már jártam és nagyon hasznosnak találom.
Az Explorer 16-os Demo Board-ot használom, melyet ICD2-vel és ICD3-mal programozom, ugyanis megvan mind a két programozó hozzá. Most kezdtem el ismerkedni ezzel a témával és eléggé komolyan gondolom. Tehát haladni szeretnék vele, csak külön tanfolyamot erre nem találtam eddig, főleg hogy debreceni vagyok. Esetleg ha lenne valami lehetőség Debrecen környékén szívesen részt vennék rajta. A forrásprogramokat már nézegetem, de eddig még elég magas nekem! Üdv.
Idézet: Az elején kell kezdeni (mármint a PICkwik projekt nyitóoldalán. Aztán csak szépen, fokozatosan. Az ICD2/3-at egyelőre tedd félre, a demókártyával együtt! Az első 5 fejezethez csak az MPLAB szimulátora kell. „A forrásprogramokat már nézegetem, de eddig még elég magas nekem!”
Kedves Fórumozók
Azzal a kérdéssel fordulok hozzátok, lehet máshol már feltették ezt a kérdést, de ha egy pic-et szeretnék üzembe helyezni, ahhoz nekem feltétlenül szükségem van valamilyen kristályra? Vagy ilyen már van a pic-be integrálva? (elnézést, ha hülyeség, amit kérdezek)
Nem kell feltétlenül külső kristály ill. oszcillátor. Az IC-n belül van RC oszcillátor, amit használhatsz, ha nem szükséges a nagyon pontos frekvencia. A PIC adatlapjában van erről leírás.
Idézet: „Az a 25 ugye decimális. Jobb lenne .25 -öt írni.” Namost én ezidáig nem láttam programozási nyelvet, melyben 25 alatt ne decimális huszonötöt (=0x19=19h) értettünk volna, és ezidáig nem láttam olyan programozási nyelvet sem, melyben .25 alatt ne 0.25-öt (=1/4) értettünk volna, vagy lebegőpontos aritmetika hiányában ne szintaktikus hiba lett volna az eredmény, úgyhogy erre speciel hiába van ott a disassembly listing, magamtól nem biztos hogy rájöttem volna... ma mindenesetre eljutottam odáig, hogy .25-tel fordul a kód... majd egyszer meg is nézem mi az eredmény Addig is köszönöm a segítséget.
Na igen... Van néhány, amiben nincs.
A többségükben van. Idézet: „Namost én ezidáig nem láttam programozási nyelvet, melyben 25 alatt ne decimális huszonötöt (=0x19=19h) értettünk volna, és ezidáig nem láttam olyan programozási nyelvet sem, melyben .25 alatt ne 0.25-öt (=1/4) értettünk volna, vagy lebegőpontos aritmetika hiányában ne szintaktikus hiba lett volna az eredmény,” A magas szintű nyelveken a default számredszer mindig a 10 -es számrendszer. Az MpLab Assembly -nél (és még rengetegnél) a default számrendszer a hexadecimális. A Radix direktívával lehet módosítani. (radix - Specify Default Radix : ld. MpLab MPASM help.) Mivel egy program több állományból is állhat, ha nem adod meg a számrendszert, az utoljára végrehajtott radix beállítás szerintit használja. Mi van, ha mások írták a programod egy-két részét. Két választás lehetséges: - Minden állomány elején és minden include (stb.) után beállítod a radix -ot, és emlékezel, arra, hogy mi az utolsó beállított érték. - Minden többjegyű szám előtt megadod. Szerintem a második átláthatóbb, bár egy kicsit többet kell írni. A syntax highlight más színnel jelzi a számrendszert: default - fekete, decimális - zöld alapesetben. Továbbá, mivel a PIC -eknél még mincs assembly támogatás a lebegőpontos műveletekre, a tizedespontot a 10 -es számrendszer egyszerűsített megadásra használják. (a neve alapján - Decimal point). 0x64 = D'100' = .100 Melyiket gyorsabb írni?
Az alábbi két programban kérném segítségeteket.
Az RB1 láb analóg bemenetként egy hőszenzort érzékel és alakít át, majd teszi ki az eredményt - balra igazítva - a LED-sorra. Mindkettő ugyanazt csinálja (ná) csak egyik assemblyben a másik C-ben. A különbség az, hogy assemblyben gyönyörűen műklödik a progi, C-ben viszont nem. C-ben megírva és letöltve egy adott értéket tesz ki a LED sorra, de nem a konvertálás értékét. Olyan mintha lefagyna, de az nem lehet, mert ha pl villogót írok ugyanabba a programba akkor az működik. Ergó az adc_convert függvénybe is belép és ki is lép, de mégsem konvertál... Íme a asm-progi:
És a C-progi:
Tudom hosszú elolvasgatni, de ha valaki megteszi és segít annak előre is hálás vagyok.
Sziasztok!
Én is egy A/D átalakítóval küzdök, de elakadtam. Valahol ott lehet a hiba, hogy egy idő után megáll szerintem az átalakítás. Elmentettem miden átalakítás eredményét az eepromba, de mindig csak 0-kat kapok, és a beállított 10 helyett csak 2-4-et találok meg az adatmemóriában. Nem tudom mi lehet a gond. Segítségeteket szeretném kérni. Itt a kód:
Pas2PIC-kel fordítottam le mindig. Átellenőriztem (többször is), szerintem mindent a jó helyre kötöttem, tehát ez szerintem nem lehet probléma. Előre is köszönöm válaszotokat! Wabe
Watchdog timert is kapcsold ki a cfgword-ben!
Sziasztok, és szia Hp41C!
Köszönöm a segítséget, ma be tudtam írni a módosított programot, és működött.
Köszönöm a gyors választ, be fogom írni programba ezt a
módosítást!
Sziasztok egy olyan kérdésem lenne hogy van egy RC távom+vevöm és szeretnék hozzá épiteni egy motorszabályzót (kétmotorost), idáig sikerült egy kész projektet megépiteni és a hozzá lévö programot is beégetni, ez igy müködik is de az én problémám hogy nem találok olyan kapcsolást és programot ami müködne biztosra. Na az én problémám amivel hozzátok fordulok hogy a fenében értelmezi a pic a servojelet? Felteszem a progit hátha ti ki tudjátok bogozni mert nem értem hogy a fenébe lesz egy bejövö frekiböl kimenö feldolgozott freki. Ha valaki segitene azt megöszönném.
Üdv Kovács G
Sziasztok!
PIC18F2520-at PICKIT2-n keresztül C-ben programozgatok alap szinten. A bemenetek kezelésével bajlódok, lekérdezni már tudok lábat, de interrupt-ot is szeretnék használni. Tudna valaki segíteni, hogy egyáltalán melyik lábon lehet, és miként működik? köszi |
Bejelentkezés
Hirdetés |
