Közbe megtaláltam a hibát. Ha valaki netalán ugyan ilyen piccel 18F4431 dolgozna, arra kell figyelni, hogy az ADCHS állítása minden előzőleg megadott beállítást töröl, így még az elején kell ezt beállítani. Adatlapban egy apró betűs rész figyelmeztet erre. Legalább is ez volt a fő hiba, meg van még pár apróság amit nem jól adtam meg.

Üdv,

Következő a problémám: Assigning to non ivalue IOCB4

Ez miatt nem engedi lefordítani a programot.



Az RBIE= 1 -nél valamint a GIE = 1 nél is ugyanezt írja ki, de ott áttudom fogalmazni az utasítást INTCON.F7 = 1 -re ( GIE-1 helyett) valamint INTCON.F3 = 1 (RBIE = 1 helyett).

Szóval valami más formában kéne megadni azt az utasítást, de nemtudom hogyan.

Az nem ivalue, hanem lvalue (gyk. LVALUE) lesz! Arról értesített a fordító, hogy olyan azonosítót írtál az értékadás baloldalára, ami számára nem értelmezhető változóként vagy regiszterként, vagyis nem tudja hová tenni az adatot.

Szemérmesen elhallgattad, hogy milyen fordítóról és mikrovezérlőről van szó, így csak általánosságban próbálok segíteni:

ANSEL, ANSELH, PORTB, TRISB regiszternevek, ezeknek a beírásával nincs gond (ezek "lvalue" típusú azonosítók).

RBIE, GIE pedig nem önálló egység, hanem egy-egy regiszterbit. Ezeket általában egy-egy struktúra elemeiként szokás dekalarálni (de a biztos módszer a megfelelő fejléc állomány megtekintése). Ezekre struktúranév.elemnév formában lehet hivatkozni, tehát INTCONbits.GIE=1 (vagy aminek deklarálta a gyártó a fordítóval telepített fejléc állományban).


C18 esetén például a PIC18F13k22.h fejléc állományban az INTCON regisztert kétféle struktúra uniójaként deklarálták az INTCON regiszter bitjeit:


Ennek megfelelően a GIE bitre kétféle módon is hivatkozhatunk:
INTCONbits.GIE vagy INTCONbits.GIEH.

Más fordítónál nyilván másképp csinálják a deklarálást (az INTCON.F7 hivatkozásod számomra ismeretlen címzésmód), de az aktuális fejléc állományból kisilabizálható.

Sziasztok!
Egy PIC16F1454-t programoznék assemblyben, de már az elején kifogott rajtam
Eddig ezt íram be a 8.86-os mplab-ba:
Sajnos nem fogadja el a fordító. Nézve a PIC adatlapját látom, hogy itt már két konfigurációs byte van, de ha CONFIG1-t írok akkor sem jó
Hogy a csudába kell beírni a config biteket ebbe a PIC-be?

Szia!
Így próbáld! De ez nem ehhez a PIC-hez való, írd át amit kell!

Szia!
Köszi a választ!
Nem jöttem volna rá, hogy így kell megadni :-O
Kiírtottam belőle azokat a részeket ami nálam nem szerpel, ezt kapom fordítás után hibaüzenetnek:
Error[133] C:\PIC_PROJECTEK\SPI\SPI.ASM 11 : Hex file format INHX32 required
Pedig a radixben ki van választva a hex

Közben megtaláltam.
Az F betűnél kellett átírni, nem a Radixot
Most már lefordul. Köszi szépen

A radix csak a forrasfile-ban megadott szamokra vonatkozik.
Ez a hibauzenet a fordito altal letrehozott .hex file formatumara.

Ha nem titikos akkor az egész forrást feltehetnéd mellékletben, mert így ki tudja mi a nem jó neki...

Még nincs más a forrásban
Közben megtaláltam.
Az F betűnél kellett átírni, nem a Radixot
Most már lefordul. Köszi szépen
De sajnálattal veszem észre, hogy ehhez a PIC-hez nincs mplab simulátor
Így nem lesz egyszerű. Lehet újabb verziókban már van?

Nem tudom melyik Mplab-ot használod, de a 8.92-ben tudja a simulator.

8.86-ot. Lehet frissítenem kell. Mégegyszer köszi a leírakat!

Azt tudod, hogy az MPLab MPASM könyvtárában megtalálhatók a template alkönyvtárak úgy abszolút, mint relokálható programok számára?

Szia!
Igen tudom. Első fordításkor meg is kérdezi a fordító, hogy milyen címre fordítsa le.
(remélem egyről beszélünk)

Igen. Feltettem a 8.92-t ebben már felkínálja a szimulátort!
Még egyszer köszi mindenkinek a segítséget!

A Project / Build Options / Project lapon, az MPLinker fülön a HEX File format keretben válaszd ki az INHX32 -őt.

Köszi neked is, de már megoldódott a probléma.
Én így választottam ki:
list P=16F1454, F=INHX32,R=HEX ; Processzor 16F1454
De megnéztem amit írtál és az van kiválasztva.

Bár 18F-hez vagyok szokva, de megéri asm-ben programozni ezt a PIC-et (16F1454), meg úgy általában a 16F-et.. ?
Rengeteg BANK van benne, és ha jól látom, itt muszáj bankolni.
Egyébként szerintem a Microchip egyre rosszabb irányba megy...

Az assembly vs C és társai örök vitatéma, de szerintem igen, mert ha spórolni kell az idővel és a memóriával az assembly-t nem nagyon lehet megszorítani. Egybként csak xxF1xxx-ben van ilyen sok bank, a régebbi típusokban csak 2-4, az még okos program szervezéssel kezelhető.

Most talán nem is az asm vs C miatt írtam (bár az asm közelebb áll a szívemhez), hanem mert szerintem rendkívül zavaró a bankváltogatás. Főleg ha az elmaradásából valamilyen hiba származik. Szóval én kicsit furcsának tartom, hogy 86ezer perifériát raknak egy tokba, aminek ráadásul a következménye, hogy bankolgatni kell. Jó, mondjuk nem hiába írják most már az adatlapokba az új PIC-eknél hogy "C Compiler Optimized Architecture". Mondjuk én inkább úgy értelmezem, hogy "Code Complicating Architecture"...
De részben azért írom ezt, mert nem akarom elfogadni, hogy ma már a C az "Isten".

Okoz is hibát, én is most hasonló PIC-en dolgozok, pedig nem is olyan nagy szám szerintem, nincs benne olyan sok periféria, de az is 32 bankban van szétszórva, nem is igazán értem, mert a legtöbb bankban csak néhány regiszter van.

Na igen, speciel ebben a PIC-ben nincs is sok periféira. A sok bankra meg biztos meg van az indok, de nem folytam ebbe bele, maradok a jól bevált 18F-nél. Bár azt is kezdik "elrontani"..

Ez nem jelenthet problémát, ha az assembler támogatását használod. Az "errorlevel +302" esetén szól, ha bankváltásra lehet szükség.
Ha szólt a bankváltás szükségessége miatt, akkor az ember "errorlevel -302" beírásával kikapcsolja, és sajátkezűleg bankot vált, beírja a megfelelő utasítást/makrót, majd visszakapcsolja az "errorlevel+302"-vel. Ez csak a program megírásakor jelent némi pluszmunkát, a későbbiekben már nincs dolgod vele.

Üdv!

PIC24-en le lehet valahogy tiltani a MCLR lábat?

Csak a HVP módon (is) programozhatók esetén : PIC24FxxKAyyyy, PIC24FVxxKAyyyy, PIC24FxxKMyyyy, PIC24FVxxKMyyyy

Urak!
Kellene egy kis segítség, mert teljesen kifogytam az ötletekből. Adott egy PIC16F1507. Egy órát csináltam vele, de a belső oszcillátorról járatva nagyon pontatlan. Először próbáltam azt, hogy maga a PIC a beslső órajelről jár és csak a Timer1-et hajtom egy 32,768 kHz-es kristályról, de ez nem ment. Ha jól néztem az adatlapban ez a PIC nem tud ilyet, de lehet, hogy tévedek. Viszont próbáltam 4 MHz-es külső kavicsról is, de el sem indul a program és nem tudom miért nem. A 2-3 lábon van a kavics, 2×22 pF a lábakon és a GND-n. A konfigban is az összes oszcillátorra vonatkozó beállítást végigpróbáltam, de semmi.
Van valakinek ötlete, hogy hol rontom el?

Szia!
Az adatlap szerint ebben a PIC-ben nincs olyan oszci, ami kvarcról tudna járni. Szóval ha nincs külső stabil órajeled, akkor ezzel a PIC-el nem érdemes órát csinálni.

Miért nem raksz mellé egy RTC-t (pl. DS3231)?

Hát ez egyre jobb és jobb lesz. Jól megszívattam magam ezzel a PIC-kel. Az adatlap 43. oldalán lévő ábra bal felső részén nem egy kristály van?

icserny: nem akartam plusz dolgokat beletenni az áramkörbe, a lehető legegyszerűbbre szerettem volna megcsinálni. Több PIC-nél használtam azt a megoldást, hogy a főprogram végrehajtása ment a belső órajelről, mert ott nem nagyon számít a pontosság, a Timer1 meg ment egy óra kristályról és máris megvolt egy elég pontos óra. De elméletileg 4MHz-es kristállyal is meg lehet csinálni, mert ha jól van beállítva a Timer1 akkor 0,5 másodpercenként ad megszakítást.
De ez itt úgy látom nem működik.

Az időmérés az a terület, ahol nagyon kis hiba (egy milliomodrésznyi eltérés, azaz 1 ppm) is bosszantó tud lenni, ha felhalmozódik. Ehhez viszonyítva a 20 ppm-es kvarc is kiábrándító eredményt ad (szoftveres kompenzációval kell ügyeskedni, hogy elfogadható eredményt kapjunk), a százalékos hibájú belső oszcillátor pedig nyilvánvalóan használhatatlan.

Persze, viszont ha jól tudom minden RTC ic-t is óra kvarc hajt, tehát a hiba ott is jelentkezhet. Vannak nyilvánvaló előnyei az RTC alkalmazásának, de számomra egyik sem nagyon releváns. Ezért lett volna jó normális kvarccal hajtani magát a PIC-et és abból lehetne egy viszonylag elfogadható megoldást kreálni. De továbbra sem értem, hogy ezt a PIC-et miért nem lehet külső kvarcról hajtani.