Fórum témák
» Több friss téma |
Idézet: A linker kerül bajba, amikor nem tudja elhelyezni a program kódját a rendelkezésére álló címtartományban. „Ha túl nagy lenne a prog akkor a fordító reklamál?”
Közben át néztem a p18F4550.h tényleg benne van nem kell saját igaz ott is ugyanaz amit én írtam
#define Nop() {_asm nop _endasm}
OK! Egyszerűsítve a lényeg hogy Total Commanderben nézve kb kétszer akkora lehet mint PIC program memóriája ha jól vettem ki.
Adva van a következő példaprogram (C18)
A 2. sor direkt van jelen esetben kiREMelve. A kérdés: hogyan lehetne rávenni a fordítót arra hogy hibát jelezzen a string.h hiánya miatt a memcpypgm2ram függvénynél? Csak egy "Warning [2058] call of function without prototype" üzenetet küld a fordító mert a header file hiánya miatt a változótípusokat nem megfelelően helyettesíti be, de valahogy az ilyen figyelmeztetésen könnyen át lehet szaladni anélkül hogy észrevenné az ember. Ha a "string.h"-t beinclude-olom (de szép magyar szó) akkor is küld figyelmeztetést "Warning [2054] suspicious pointer conversion" de így már persze helyesen működik. Valahogy nekem szimpatikusabb lenne a header-ek kötelező beillesztése, mint header nélkül működésképtelen kódot csinálni.
A 2054-es warningot kell megszuntetni es akkor nem lesz problema. Pl igy:
Ebben az esetben "Warning [2066] type qualifier mismatch in assignment" hibaüzenetet küld a fordító, a kód pedig ugyanúgy hibátlanul működik mind a "rom void *" nélkül.
A könyvtári függvényeket a lib/clib.lib file-ból szedi elő akkor is ha a projectbe nem tesszük be, sőt ha a "library search path"-ot nem állítjuk be akkor is lefordítja. Ez különben az összes könyvtári függvénnyel így van, én csak kiragadtam egyet a példa kedvéért. Idézet: Van ezzel egy olyan probléma is, hogy a saját projekt és a gyári library esetleg különböző memória memória modellt használ. Az optimális használathoz és a warningok megszüntetéséhez célszerű újrafordítani a gyári library-t. ITT írkáltam már ilyenekről. „A könyvtári függvényeket a lib/clib.lib file-ból szedi elő”
Köszi, megvizsgálom ezt a lehetőséget, így már érthető miért rakott akkor is 24bites rom mutatót a verembe a paraméterátadáskor ha small code model -t állítottam be. Gyakorlatilag semmi változás nem volt a small és a large code model között, pedig egy csomó helyet és processzor időt lehet nyerni ha elég a small model (nálam mindig elég a small, mert minden 8 bites pic-nek amit használok kisebb a kódmemóriája 64k-nál).
Sziasztok! Szeretnék segítséget kérni tőletek. Egy forrás fájlt kéne befordítani .hex-be. Sajnos én a PIC-ek ezen részéhez nem értek. A mikrokontroller típusa 18F2550 és HiTech C18-ban íródott. Előre is köszönöm a segítséget!
Üdv.:Travolta
Kellemes Karácsonyt!
Nagyon szépen köszönöm! Boldog Karácsonyt Neked is!
Még egyszer köszi az ötletet, közben az általam használt chipekhez meg is csináltam az újrafordítást, ráadásul a memória modellt is átállítottam "far"-ról "near"-ra. Így megszabadultam a felesleges warningoktól, ráadásul a kapott kód is kisebb és gyorsabb lesz. Az fordító include könyvtárában is 4 header file-ba bele kellett nyúlni a memória modell miatt, de így teljesen jó lett.
Szia , láttam a hozászólásodat EZT és érdekelne , hogy az a könyvet nekem is el tudnád e küldeni , meg még anyi , hogy ez ugye a 18x -be beletartozik a 18f széria is?
Üdvözlettel: Németh Tamás BÜÉK!!
Sziasztok!
Van egy problémám, remélem tudtuk benne segíteni. LCD-re szeretnék kiíratni szöveget. Betűket már ki tudok rakni, de szöveget nem. Idézet: „#include "piccolo_all.h" #include #define RS_HIGH()LATBbits.LATB5=1; #define RS_LOW()LATBbits.LATB5=0; #defineRW_HIGH()LATBbits.LATB6=1; #define RW_LOW()LATBbits.LATB6=0; #define E_HIGH()LATBbits.LATB7=1; #define E_LOW()LATBbits.LATB7=0; unsigned char pp[]; void epulse(void) { Delay10TCYx(2); E_HIGH(); Delay10TCYx(2); E_LOW(); Delay10TCYx(1); } void LCD_Cmd(unsigned char cmd) { unsigned char cmd_upper; char c; cmd_upper=cmd; c=cmd&0xF0; PORTD=c; RS_LOW(); epulse(); c=(cmd_upper&0x0F)<<4; PORTD=c; RS_LOW(); epulse(); Delay10KTCYx(6); } void LCD_Init(void) { TRISB=0b00000000;//Vezérlő lábak írásra állítása TRISD=0b00000000;//ADAT vonal írásra állítása Delay10KTCYx(60);//első várakozás min. 15ms RS_LOW();//első utasítás RW_LOW(); PORTD=0b00110000;//0x30 Delay10KTCYx(6);//5ms várakozás PORTD=0b00110000;//0x30 Delay10KTCYx(1); PORTD=0b00110000;//0x30 PORTD=0b00100000;//0x20 - 4 bites mód LCD_Cmd(0x28); LCD_Cmd(0x06); LCD_Cmd(0x0d); LCD_Cmd(0x01); } void LCD_Char(unsigned char Ch) { unsigned char ch_upper; char cr; ch_upper=Ch; cr=Ch&0xF0; PORTD=cr; RS_HIGH(); epulse(); cr=(ch_upper&0x0F)<<4; PORTD=cr; RS_HIGH(); epulse(); Delay10KTCYx(6); } void LCD_Text(unsigned char char_array[]) { pp[1]=char_array[1]; LCD_Char(pp[1]); } void main(void) { LCD_Init(); LCD_Cmd(0xc0); LCD_Char('K'); LCD_Cmd(0x80); LCD_Text('PROBA'); while (1) { TRISDbits.TRISD1=0; LATDbits.LATD1=1; } }” Az LCD_Text();-vel szeretnék szöveget kiíratni. Most egyenlőre a 'PROBA' nevű szövegből az első karakter szerettem volna kirakni az LCD_Cmd(); függvénnyel, de az LCD-n 'R' helyett 'L' jelenik meg. Nem értem miért? Remélem tudtok segíteni nekem Előre is köszönöm a segítségeteket. BUÉK!
1. LCD_Cmd()-vel ne akarj szöveget kiíratni, mert az az LCD vezérlőjének szóló parancsok kiküldésére való! Remélem, hogy csak elírás volt és az LCD_Char()-ral próbálkozol.
2. Szövegfüzér konstansok megadásához nem az aposztróf, hanem az idézőjel (gy.k.: macskaköröm) használandó. 3. Ha egy függvényt úgy írtál meg, hogy az adatmemóriából (egy tömbből) vegye elő a karaktereket, akkor az nem használható szövegkonstansok kiírására, mivel azokat a ROM-ba kerülnek, s annak kezeléséhez más típusú mutatókat kell deklarálni const rom módosítókkal. Nézegesd meg és hasonlítsd össze a C18 telepítési könyvtárban a "gyári" putsXLCD() és putrsXLCD() függvények forráskódját! Ezek alapján az LCD_Text() mellé írj egy másik függvényt, amelyik képes a ROM-ból elővenni a kiírandó szöveget.
Szia!
Megnéztem amit mondtál, de nem találom a problémát. Ha egy tömbhöz hozzáadok egy szöveget és még mutatót is használok pl.: "proba", akkor miért változik meg az értéke a karakternek és miért nem adja vissza a megfelelő betűt a tömbből?
Idézet: „Megnéztem amit mondtál, de nem találom a problémát.” Problémát már ne keress, mert azokat pontokba szedve felsoroltam neked! A probléma megértéséhez pedig mélyedj el egy kicsit a tömbkezelés rejtelmeibe (ezt addig folytasd, amíg a C fordító által generált gépi utasításokat is meg nem érted)! Idézet: Nem a karakter értéke változik meg, hanem a függvénynek átadott paraméter értelmezése lesz rossz: karakterkód mutatóként lesz használva, vagy fordítva. A múltkori hozzászólásomban már elmondtam, hogy mi a teendő ennek kivédésére. „miért változik meg az értéke a karakternek”
Sziasztok!
A következő programot írtam: #include _CONFIG1 (JTAGEN_OFF & FWDTEN_OFF ) _CONFIG2 ( FNOSC_PRI & POSCMOD_XT ) void vDelay (unsigned int uiTime ); int main (void) { AD1PCFG = 0xFFFF; //analóg bemenetek kikapcsolva TRISB = 0x0FFF;//RB12-15 kimenet LATB = 0x0000; TRISAbits.TRISA2 = 1;//RA2 láb bemenet //_TRISA2 = 1; while (1) { if ( _RA2==1 ) { LATB = 0xFFFF; } else { LATB = 0x0000; } } } Elvileg a programnak azt az egyszerű feladatot kellene ellátnia, hogy ha RA2 magas szinten van(nincs benyomva a nyomógomb), akkor az RB15-ön világít a led, ha benyomjuk az RA2-n lévő nyomógombot, a led elalszik( amíg el nem engedjük a nyomógombot). A probléma az hogy valamiért nem működik. Viszont ha a nyomógombot átkötöm RA0-ra, (és átírom a programba), akkor működik. Valaki tudja esetleg, hogy mi lehet az oka? Próbáltam RA3-as lábat is, ott se működött. Előre is köszi a választ!
POSCMOD_XT helyett POSCMOD_NONE-val próbálkozz! Szerintem az okozott problémát, hogy az oszcillátor funkciót nem tiltottad le az RA2 lábon.
és működik is...!
Köszönöm szépen a gyors segítséget! Üdv!
Sziasztok!
Nekem a következő problémám adódott: Építettem egy áramkört egy pic16f877-essel,ami max232-n keresztül tud kommunikálni. Az ic felprogramozását soros porton keresztül szeretném megoldani,de sajnos a mikroc "nem jó" hex fájlt generál a soros porti letöltőprogram(download.exe) számára. Tudja valaki hogy mikroc-ben hogy lehet ezt a hibát javítani? üdv.
Gondolom, a MikroC feltételezi, hogy a hozzá illő bootloadert és letöltő programot használod. Bővebben: Link
Idézet: Szerintem ez nem hiba, hanem inkompatibilitás. Sokféle bootloader létezik, ezek mind másképp csinálják. „Tudja valaki hogy mikroc-ben hogy lehet ezt a hibát javítani?”
Ez a mikrobootloader érdekelne.
Most próbáltam,de sajnos nem tud a pic-hez kapcsolódni. Ezzel programoztál már fel így 877-est? Ehhez van valami program amit be kell előre égetni a pic-be hogy fogalni tudja a soros adatokat? Idézet: Nem használok sem 877-est sem MikroC-t. Csak a Google keresőt, a lusta emberek helyett...„Ezzel programoztál már fel így 877-est?” Idézet: Kell, hogy legyen, mert minden bootloadernek ez az alapja. Az előző hozzászólásomban adott linken ezt írják a mikroBootloader használatához első lépéseként:„Ehhez van valami program amit be kell előre égetni a pic-be hogy fogalni tudja a soros adatokat?” "Load the PIC with the appropriate hex file using the conventional programming techniques (e.g. for PIC16F877A use p16f877a.hex)." - gondolom, ez a PIC-be égetendő bootloader. Nézz körül a MikroC telepítési könyvtárában, hogy nincs-e ott már valahol! De még valószínűbb, hogy neked kell lefordítanod, hiszen az órajel frekcenciájához és a soros port adatsebességéhez is lehet, hogy hozzá kell szabni.Bővebben: Link Idézet: „Ehhez van valami program amit be kell előre égetni a pic-be hogy fogalni tudja a soros adatokat?” Igen, ezt nevezik "bootloader"-nek...
Ha normálisan működne az icsp felület a pickit2-vel, akkor nem kellene más programozási megoldáson törnöm a fejem,de sajnos a pickit2 csak néha ismeri fel a 877-est.
Tudna nekem valaki segíteni abban, hogy levédett tartalmat hogy lehetne kiolvasni PIC12C508-ból ? Gondolom csak nagyon bonyolult módon, pl. lézerrel eltávolítani a felesleges PIC tetejét, majd megnézni a memóriát fizikailag, hogy merre állnap a "flip-flop-ok"... valami egyszerűbb dolog? Vagy írni kell rá saját programot ?
Az ICSP normálisan működik PK2-vel, Nálad lehet valami probléma ( inkább azt keresd meg és szüntesd meg ! ) !
Steve Idézet: Ez az egyeduli megoldas. Esetleg elektronmikroszkop „Vagy írni kell rá saját programot ?” 
Helló, van egy kis gondom.
Az ADC-m úgy tűnik, mintha 10 bit helyett 8-at kezelne. Konkrétan a 379-es sornál állítom meg a debuggolás közben és sehogy se érek el nagy értékeket. Az IC 18LF14K22, 3,3V 16MHz. Próbálkozom 10K potméterel, 3 lábú hőmérő iC-vel és 2 lábú 10K ellenállás hőmérővel is. Itt az egész kód, hogy nehogy kimaradjon valami.
|
Bejelentkezés
Hirdetés |
