Fórum témák
» Több friss téma |
Szia, csatolom a ccs c leírását. Köszi előre is!
a #DEVICE ADC=10 sornak közvetlenül a # include sor alatt kell szerepelnie.
https://ccsinfo.com/forum/viewtopic.php?t=51744
Köszönöm úgy néz ki, hogy működni fog így !
Sziasztok, ismét a segítségetekre szorulnék ! PIC16F877-es PIC CCS-C compilerrel és MPLAB8.90-el dolgozva , úgy tűnik, hogy tele lett a memória... A fordításkor keletkezett hibaüzenetett csatolom.
Így még nem igazán jártam, lehet hogy csak az egyik lap lett tele és nem az egész pic memóriája? mit javasoltok , hogyan tovább? (Pl.: két pic-re bontsam szét a "feladatot"?) Köszi !
A 16F877 -nek 4 program memória lapja van: 0x0000-0x07FF, 0x0800 - 0x0FFF, 0x1000 - 0x17FF és 0x1800 - 0x1FFF
A kiírás szerint: 0. lap 0x0000 - 0x07FF lapon összesen 459 üres hely maradt 1. lap 0x0800 - 0x0FFF lapon összesen 6 2. lap 0x1000 - 0x17FF lapon összesen 800 üres hely maradt -- azaz ez a lap teljesen üres 3. lap 0x1800 - 0x1FFF lapon összesen 700 üres hely maradt. A fordító egy 0x83D (decimálisan 2109) egységnek nem talál helyet. Az az érzésem, hogy van egy olyan nagy eljárás, ami nem fér el egy lapon. Fel kellene darabolni több kisebb eljárásra, ami beférne a 2. és a 3. lapon levő szabad helyre. A hozzászólás módosítva: Feb 1, 2019
Én a 16F877-es projektjeimet átraktam 18F45k22-re.
Pin-pin kompatibilis. Kicsit kell csak változtatni a kódon, ha a fordító támogatja. A 877 tíz évvel ezelőtt jó volt, ma már kicsit olyan, mint ha moszkviccsal mennél nyaralni. Ezzel együtt persze be lehet rajta fejezni amit elkezdtél, de mint a mellékelt ábra mutatja, akkor neked kell ügyeskedned az erőforrások kiosztásával.
Köszi! Lalószínűleg ezen projektem után leteszem a moszkvicsot , kipróbálom majd azt a 18F45k22-őt, pedig a 16F-es olyan mint egy F16-os , de mára már az F16-osok is kifutó repülőgép típusok
Minek kellene átrakni, amikor a 16F877 több, mint fele (4953) üres?
Hali!
Hp41C-t kiegészítve, lehet akár nagy tömböd is, aminek kezdőértéket adsz... A konkrét progi ismerete nélkül nehéz megmondani. És még egy, azt a sok warning-ot én megoldanám, nem szeretem ha akár egy is van....
Kizárólag kényelmi okokból. Írtam, hogy megvalósítható ezen is. Viszont mint a mellékelt ábra mutatja, megoldást kell találni az architektúrából adódó korlátokra.
Fordításkor létre jön egy sta kiterjesztésű fájl. Azt érdemes kicsit átnézni. Látszik melyik függvény mekkora helyet foglal ... ha valamelyik túl nagy, azt fel lehet bontani rész feladatokra, és akkor be tudja tenni a maradék üres helyre...
Legyetek szívesek segítsetek. Legyetek elnézők velem szemben mert elég kezdő vagyok C-ben.
A lényeg hogy egy MikroC-re írt kétvezetékes karakteres LCD vezérlő driverét szeretném használni CCSC alatt. Sok a különbség a két nyelv között sajnos. Már 75 hibát sikerült elhárítanom, de ez most megfogott. A hibaüzenet: Attempt to create a pointer to a constant (próbáljon mutatót állítani a konstansra) A problémás függvény:
Ezt a függvényt hívja meg:
A fő programból így hívtam meg MikroC-ből korábban.
Becsatolom a drivert is. Softveres I2C-ről hardveresre átalakítva használtam MikroC alatt. Még annyit hogy a hard_i2c_lcd.c -t beolvasztottam a saját programomba, tehát nem #include-al használom mert az alábbi függvénnyel is problémája volt a CCS fordítónak:
Egy külföldi fórumon találtam ezt a beállítást.
#device PASS_STRINGS = IN_RAM A hibaüzenetek száma lecsökkent egyre, erre a sorra vonatkozóan. Can not set this option this far into the code. (ezt az opciót nem lehet használni a kódban)
Nem használtam még sem MikroC-t, sem CCSC-t, de ha 8 bites PIC-ről szól a történet (azt azért leírhatnád milyen típusú PIC-re írod) a fordítónak teljesen más kódot kell fordítania a RAM illetve ROM területen levő karaktertömb használatához. Írj külön ROM karaktertömb kezelő függvényeket hozzá. Pl.:
Lehet, hogy nem jó szintaktikával írtam, de kiindulási alapnak talán használható.
A PIC típusa 18F4520.
Gondolkodom azon amit javasolsz. A RAM-ban szeretném tárolni a karaktertömböket. Ezen a fórumon találtam a legutóbbi módosításomhoz az ötletet. A hozzászólás módosítva: Feb 17, 2019
A probléma megoldódni látszik. A mutató RAM-ba elhelyezésére utaló fordító utasítást előbbre hoztam a kódban. Eredetileg ott volt ahol most az üres hely van.
Be is égettem a programot a PIC-be. Egyelőre a megjelenített karakterek némelyike nem egyezik azzal, amit szeretnék látni. Szerintem túl gyors az I2C beállításom vagy az időzítéseket kell a driverben növelni. Legalább már nincs hibaüzenet
Lehet hogy RAM-ban szeretnéd tárolni, de a példasorod
Nem igazán vagyok még tisztában a mutatókkal. Szerencsére a RAM 14%-át használtam el eddig csak.
Jó lett az LCD-re történő kiíratás. Az időzítéseket növeltem 3us-ról 30us-re. Köszi a javaslatod, még végig kell gondolnom.
Sziasztok!
UART - DMA problémám van 33EP256MU806 PIC -en. DMA nélkül rendben megy a kommunikáció, a csomagok 95%-át hibátlanul megkapom, abban az 5%-ban van Receive Buffer Overrun, ilyenkor elveszik néhány csomag, ez így ok. Megpróbáltam DMA -hoz kötni a vételt, de valamit nagyon benéztem, mert alig jön értékelhető csomag. Mivel DMA nélkül jó, (csak nem marad másra ideje a PIC -nek) ezért gondolom az UART beállítások rendben vannak. A main-ben megpróbáltam FIFO elven kiolvasni a UART_ReceivedBuf[] -t, feltételezem itt rontok el valamit, de nem találom mit.
Miért kéne csökkentenem DMA_Data -t?
A 37. sorban DMA periféria által beállítjuk oda, ahová az utolsó adat érkezett. A for ciklusba pedig URB_P -vel addig körözünk a FIFO -ban, amíg ezt meg nem találjuk. (És mindig onnan kezdjük a körözést, ahol legutóbb abbahagytuk. A DMA elvileg folyamatosan pakolja az érkezett byte-okat UART_ReceivedBuf[32] -be. Ha elérte a 31. elemet, akkor felülírja a 0-at. Legalábbis ez volt a célom DMA beállítással. Lehet hogy itt nem stimmel valami? Mod.: Ja bocsánat, most látom, a for ciklus feje is más... A hozzászólás módosítva: Feb 19, 2019
Ezzel a verzióval az lesz a probléma, hogy - mivel nem tudom értesíteni DMA-t arról, hogy kiolvastam x adatot UART_ReceivedBuf[] ből- a DMA UART_ReceivedBuf[] írását ugyan ott fogja folytatni (DMA3STAL) ahol abbahagyta.
DMA3STAL -t FRM szerint nem tanácsos módosítani. Köszönöm hogy foglalkozol a problémával!
Azt a problémát próbáltam meg kijavítani, hogy "szemetet" olvas ki a DMA pufferből. Legyen a vett adatok száma 6, az első adat pl. a 28. helyen. Az eredeti megoldás szerint elkezdjük kiolvasni a 28., 29., 30., 31. helyről az adatot. Ezek után 0 -t írunk az URB_P -be. A for ciklus pedig addig megy, amíg URB_P != DMA_Data azaz 6 -ig. Összesen 10 adatot olvas ki a 6 helyett.
Idézet: „Legyen a vett adatok száma 6, az első adat pl. a 28. helyen.” Ekkor DMA_Data -ban 1 lesz. Idézet: „// DMA_Data 0-31 mutatja, hova érkezett az utolsó adat” Ha jól értelek... A hozzászólás módosítva: Feb 19, 2019
Üdv!
Elővettem egy régi projectet ammiben van egy karaktertömb: volatile unsigned int rxbuff[10]; Valamint van benne a következő memóriatörlés: memset(rxbuff,0,sizeof(rxbuff)); Ez régen lefordult figyelmeztetés nélkül. Most felraktam az új MPLabX-et (5.15) és a következő figyelmeztetést kapom. Idézet: „main.c:518:17: warning: passing argument 1 of 'memset' discards qualifiers from pointer target type c:\program files (x86)\microchip\xc16\v1.36\bin\bin\../..\include/string.h:16:15: note: expected 'void *' but argument is of type 'volatile unsigned int *'” Teljesen igaza van, de kell vele foglalkoznom? A hozzászólás módosítva: Máj 4, 2019
Én nem szeretem a warningokat se...
a memset paraméteréhez írj kényszerkonverziót (void *) szerintem
Üdv Mindenkinek!
Makróval küzdök. Valami hasonlót szeretnék elérni mint az arduinóban van, egy-egy libraryban lévő osztályban nincsenek fixen beépítve a pinek, hanem paraméterként lehet megadni. Régebben lényegében már megoldottam, de nem vagyok vele elégedett, mert plusz eljárásokkal van megoldva. Szeretném megoldani makróval. Adok egy kis mintát, hogyan indultam el. Egy gondom van, így nem tudom paraméterként átadni. typedef enum { // A regiszter rA0, rA1, ... // B regiszter rB0, rB1, ... } regPinName; // A regiszter #define _rrA0 IOPORT_A #define _rrA1 IOPORT_A ... // B regiszter #define _rrB0 IOPORT_B #define _rrB1 IOPORT_B ... // A regiszter #define _rA0 BIT_0 #define _rA1 BIT_1 ... // B regiszter #define _rB0 BIT_0 #define _rB1 BIT_1 ... #define mPORTSetBits(rx) PORTSetBits(_r ## rx, _ ## rx) int main(int argc, char** argv) { mPORTSetBits(rA2); // szépen kifejti: PORTSetBits(IOPORT_A, BIT_2); mPORTSetBits(rB4); // szépen kifejti: PORTSetBits(IOPORT_B, BIT_4); return 0; } void setPin(uint32_t rxb) { mPORTSetBits(rxb); // ez viszont nem műküdik: PORTSetBits(_rrxb, _rxb); } Tud valaki segíteni?
Az MPLab Code Configurator ezeket a makrókat hozta létre egy IO lábhoz.
Hogy miért jó neki, hogy minden egyes sort berak egy do-while közé, azt ne tőlem kérdezd meg, bár ha valaki tudja a választ az ossza meg velem is. Szóval ez egy generált file (részlet), ennél írhatsz szebbet is, jobbat is.
Elolvastam még egyszer a kérdésedet, azt hiszem nem arra válaszoltam A hozzászólás módosítva: Szept 11, 2019
|
Bejelentkezés
Hirdetés |