Fórum témák

» Több friss téma
Fórum » PIC programozása C nyelven, C-Compiler
Lapozás: OK   142 / 153
(#) cross51 válasza lóri hozzászólására (») Nov 21, 2018 /
 
Elsőként amiken érdemes elgondolkozni
- van-e olyan időkritikus rész amit assembly-ben kell írni
- okoz--e problémát a C-ből adódó nagyobb memória igény

Gondolom munkáról van szó, ahol általánosságban elmondható mindent a lehető legrövidebb idő alatt kell fejleszteni.
Ha az előző 2 kérdésre nem a válasz akkor alapvetően tök mindegy milyen jó/... a C fordító mert nem vagy (futási) időhöz kötve és ha pl nem elég a 16 k akkor biztos hogy van 32k verzió is belőle.
(absztrakt példa mindegy hogy a printf 1ms vagy 10ms alatt fut le)

Bár a 8 bites PIC-ekre amíg 1 db core register (WREG) van addig nem tudom lehet-e optimális C fordítót írni.
Én a 32 bitet pártolom mert ott nem kell semmiben szűkölködni van C++ (ezért kezdtem el használni) és pár problémától mindenképpen megszabadít ami 8 biten van.
(és ha az ér is kritikus akkor ott vannak az 32MM-ek amik elég olcsók és eddigiek alapján számomra használhatóak voltak)

+ egy ámblokk gondolat a megszakítások jó szervezése nagy fegyver lehet.
(#) lóri válasza lóri hozzászólására (») Nov 21, 2018 /
 
Vagy, ti mit használnátok, ha most kezdenétek?
(#) lóri válasza cross51 hozzászólására (») Nov 21, 2018 /
 
Köszönöm. Írtátok, hogy a ccs jobb, de fizetős. Az jólehet, vagy ilyen mezei mp-s fordító is elég? Akkor az assembly nem olyan jó?
(#) icserny válasza lóri hozzászólására (») Nov 21, 2018 /
 
Nem árultad el, hogy milyen kategóriájú mikrovezérlőről van szó. Akkor milyen választ vársz?

A C fordítók közül olyat célszerű választani, amelynek a perifériakönyvtára forráskódban is rendelkezésre áll: ellenőrizhető, debugolható, szükség esetén javítható vagy módosítható.

Némelyik Third Party fejlesztői környezet nem támogatja a Microchip programozó/nyomkövető eszközöket. Nálam ez kizáró ok lenne...

Ha munkáról van szó, akkor a gyári fordítót célszerű választani, s ha komolyabb volumenű fejlesztésről van szó, akkor az optimalizált fordítót is célszerű lehet megvenni.

Lehet, hogy nem a PIC az ideális választás, de ez már messzire vezető kérdés lenne...
(#) Hp41C válasza lóri hozzászólására (») Nov 21, 2018 /
 
Mekkora a feladat?
Assembly -t kezdetnek, LED villogtatás, kapcsoló nyomógomb kezelés stb kipróbálására ajánlom. Nem kell átolvasni egy új programnyelv könyvét, az egész könyvtár leírását. Az első lépések gyorsan megtehetők az adatlap (és az errata) alapján. Nagyobb feladatok is megoldhatók vele, de a fejlesztéshez több idő kell.
Kisebb - nagyobb feladatra lehet használni a C -t és a könyvtárait. Itt inkább a korlátok elérésekor jönnek a problémák. A feladathoz kinézett (esetleg már beépített kontroller) határait hamar el lehet érni. A program méretének csökkentése sok időt fog elvinni.
Egyes részfeladatok megoldása (USB, Ethernet, stb) gyorsabb a C -ben.
A kiválasztásnál sok-sok szempontot kell figyelembe venni:
A kontroller tápfeszültsége és a környezet: 5V vagy 3.3V.
Egyes modulokat (USB, Ethernet, Can), tokozásokat és a tápfeszültséget figyelembe véve mekkora a típusválaszték.
Pl. 16F1 sorozatban, ami befér 4k -ba assembly -ben, az csak 8k -ra fér be XC8 optimalizálva és nem fér be 16k -ba sem XC8 free verziójával.
(#) usane válasza lóri hozzászólására (») Nov 21, 2018 /
 
Előttem már mindent leírtak ami a választáshoz kell, de egy kis összefoglaló.
-CCS C: nem ismerem túlzottan, állítólag fizetős, de biztos van ingyenes is. Saját függvényei vannak ha jól emlékszem. Nem tudom 32 bitesekhez mennyire naprakész.

-Mikroc: Szintén alig ismerem, állítólag elég stabil, saját függvényi vannak amik nem nagyon hozzáférhetőek. Valamint emlékeim szerint szintén fizetős.

-C18: Az XC8 "elődje". Előnye, hogy sok példaprogram található hozzá, legtöbben szerintem ezt használják akik C-znek. Vannak saját függvényei, de ha ismered a működést könnyedén írható egyéni is. Anno fizetős volt, beszerezhető a tört is.

-XC8: A hivatalos MC fordító. Ez is fizetős, de ingyenesen is működik roszabb optimalizálással.
Nem nagyon dicsérik, de ha nem kell időkritikus dolgot létrehoznod már elég jól kipofozták.
Előnye, ha akarsz MC-s forrásokat használni akkor ezzel kompatibilis.
A 16 és 32 bitesekhez má elég jó az XC is, de aki C18-al 8 bitzik az a 32-esekhez inkább a C30-at használja. Valamint ha értesz c++-hoz az is van

Ha munkához kell, mint icserny fórumtárs írta az XC fordítók javasoltak.
(#) Elektro.on válasza usane hozzászólására (») Nov 21, 2018 /
 
A MikroC 2k fordításig ingyenes.
(#) usane válasza Elektro.on hozzászólására (») Nov 21, 2018 /
 
Ami seperc alatt átléphető, de köszönöm a kiegészítést.
(#) usane hozzászólása Jan 19, 2019 /
 
Üdv!

Van valaki aki otthon van az MC-s string függvényekben?
XC16-ról lenne szó.
1. kérdés, hogy az itoa() és társai a tizedes jelet ponttal vagy vesszővel használkák?
2. Az itoa() és a strcat() közül melyik megbízhatóbb, optimálisabb? (sebesség, memóriaigény stb)?

Van egy 12 bites előjeles float változóm aminek az alsó 4 bitje a tört rész. Ezt szeretném "string"-é alakítani ez a kérdések lényege. Használjam az itoa()-t vagy alakítsam át a először ASCII-ra a számjegyeket és fűzzem össze strcat()-al?
(#) killbill válasza usane hozzászólására (») Jan 19, 2019 /
 
Az itoa() nem használ tizedes pontot, mivel "int to ascii". Csak egészekkel dolgozik. sprintf() is megfontolando, ha számít a kód (forrás) tömörsége.
(#) usane válasza killbill hozzászólására (») Jan 19, 2019 /
 
Ok. Nem itoa,csak azt is fontolgattam az ASCII átalakítás helyett azért maradt a fejemben, de van ftoa is az XC16-ban azt hiszem. Épp az sprintf()-et szeretném elkerülni. Nem tudom mennyi memóriát használna el, de nem a legnagyobb PIC-et vettem.

Szerk: Megnéztem, a manual szerint nincs ftoa(). Akkor az tárgytalan, tehát marad a strcat() és ASCII alakítás vagy itoa().
A hozzászólás módosítva: Jan 19, 2019
(#) killbill válasza usane hozzászólására (») Jan 19, 2019 /
 
A törted pontosan milyen formában is van? Az alsó 4 bit tört rész. Ez mit jelent? Hogy a legalsó bit 1/16-od (0.0625)?
(#) usane válasza killbill hozzászólására (») Jan 19, 2019 /
 
Pontosan.
Egészen konkrétan a DS18B20 hőmérséklet értéke.
A hozzászólás módosítva: Jan 19, 2019
(#) Hp41C válasza usane hozzászólására (») Jan 19, 2019 /
 
Miért nem küldöd át 1/16 fokban mérve egészként?
(#) killbill válasza usane hozzászólására (») Jan 19, 2019 /
 
Akkor két itoa(). Az strcat() elkerülhető, ha tudod, hogy az egész rész milyen hosszú. Még mindig "olcsóbb" egy strlen(), mint egy strcat(). De írhatsz saját itoa()-t is, ami után a tizedespontot és a tört részt folytatólag tudod letenni. Akkor nem kell strcat() meg strlen() sem. Nem teszteltem, de valoszinuleg mukodik:
  1. static char *ptr;
  2.  
  3. tortkiiras(int num, char *buffer)
  4. {
  5. char *dp;
  6. int egesz, tort;
  7.  
  8.  egesz = num >> 4;
  9.  tort    = num & 15;
  10.  
  11.  ptr = buffer;
  12.  dnum(egesz);
  13.  dp = ptr;
  14.  dnum((tort + 16) * 625);
  15.  *dp = '.';
  16.  *ptr = 0;
  17. }
  18.  
  19. dnum(int num)
  20. {
  21.    if(num > 9)
  22.       dnum(num / 10);
  23.  
  24.   *ptr++= num % 10 + '0';
  25. }
(#) usane válasza Hp41C hozzászólására (») Jan 19, 2019 /
 
Ezt kifejtenéd? Nem igazán értem mire gondolsz, bár kicsit már fáradt vagyok.
(#) usane válasza killbill hozzászólására (») Jan 19, 2019 /
 
Szuper. Kipróbálom, köszönöm.
A másik esetben az strcat-et, miért is hagyhatom el?
(#) killbill válasza usane hozzászólására (») Jan 19, 2019 /
 
Idézet:
„Szuper. Kipróbálom, köszönöm.”
Az előjellel nem foglalkozik, de azt a legelejére be lehet írni.
Idézet:
„A másik esetben az strcat-et, miért is hagyhatom el?”
Az strcat() úgy fűz össze két string-et, hogy először megkeresi az első str. végét, majd odamásolja a második string-et. A te esetedben, ha először lerakatod a bufferbe az egesz részt (itoa), akkor ha egy strlen() segítségével megkeresed a bufferben a szöveg végét, akkor a tizedespontot meg a tört részt irathatod egyből a megfelelő helyre a bufferben, így nem kell másolni, nem kell az strcat(). Az én megoldásomban a ptr változóban benne van a szöveg végének címe, ezért keresni sem kell.
(#) usane válasza killbill hozzászólására (») Jan 19, 2019 /
 
Köszönöm.
(#) usane hozzászólása Jan 22, 2019 /
 
Üdv!

XC16 kérdés.
Az XC16 makrós interrupt definiálása nem tudja a PSV modelt megadni? Az XC32-ben meg lehet adni ebben nem?
Ha igen, hogy kell? Nem találtam meg.
Vagy lehet nem a makróval kéne játszanom, hanem megadni a függvényeset abban benne van.

szerk: Lehet abban sem, de az nem adott rá figyelmeztetést, ez meg ad.
warning: _U2RXInterrupt PSV model not specified for '_U2RXInterrupt';
assuming 'auto_psv' this may affect latency
A hozzászólás módosítva: Jan 22, 2019
(#) Hp41C válasza usane hozzászólására (») Jan 22, 2019 /
 
(#) usane válasza Hp41C hozzászólására (») Jan 22, 2019 /
 
Ezzel nincs bajom:

void __attribute__((__interrupt__, no_auto_psv )) _U2RXInterrupt()

Ennél nyafog a fordító, hogy nincs megadva a PSV model:

void _ISR _U2RXInterrupt()

De végülis nem számír, átírtam az attribútumosra, scak kiváncsi voltam meg leheet-e adni a makrónál is.
(#) usane hozzászólása Jan 23, 2019 /
 
Újabb problémával küzködök.

Van egy x karakteres bufferem ami volatile, mert megszakítás is kezeli.
pl: volatile unsigned char buff[10];
Az egyes elemű karaktert át akarom rakni egy változóba.
unsigned char var;
var = buff[1]; <- ez lenne a cél.
Elvileg belekerül mert ha az értékadás után elküldöm UART-on akkor látszik, hogy benne van viszont a változóval végzett vizsgálat nem reagál a változtatásra.
if(var>=10)... nem működik.
Mit bénázok el?
(#) foxi63 válasza usane hozzászólására (») Jan 23, 2019 /
 
Szia!
Ha a var változót még az adott függvényen belül vizsgálod, akkor mennie kell, de ha már ebből a függvényből kiléptél, az is elveszik(elveszhet).Látni kéne a függvényt.
(#) Kovidivi válasza usane hozzászólására (») Jan 23, 2019 /
 
Írasd ki soros porton a var-ban tárolt értéket! Serial.println(var,DEC);. Ascii táblázat alapján láthatod, ha pl. enter van benne, vagy soremelés, bármi. Ekkor tudni fogod, hogy a fogadó fv.-ed jól működik-e.
(#) superuser válasza usane hozzászólására (») Jan 23, 2019 /
 
Tipikus probléma lehet egy változó többszörös deklarációja.
Egyébként ilyenekre találták ki többek között a debuggert.
(#) usane válasza superuser hozzászólására (») Jan 24, 2019 /
 
Nem szoktam ilyet elkövetni, mármint többszörös deklarációt.
A debugger meg nem tökéletes a bejövő jelek miatt, egyébként is jobban szeretem hardveresen debuggolni.
Viszont már tudom mi a hiba, csak még azt nem hogy adóoldali, vagy vevőoldali-e.
A változóval semmi baj, az UART van kicsit leterhelve, csak még nem tudom melyik oldalt. Ha csak ezt a funkciót működtetem akkor szépen átveszi a változót, de ha bekapcsolom a többi UART-os funkviót akkor ez nem tehát lehet a másik oldal a hibás.
(#) spgabor hozzászólása Jan 27, 2019 /
 
Sziasztok!

Bocsánat előre is az OFF-ért. Tud valaki esetleg segíteni EEPROM-ból kinyert adat visszafejtéssel kapcsolatban? Nem szemetelem ide a problémám, csak linkelem. Ha esetleg valaki jártas ilyen témában, légyszi a frissen nyitott topicomba segítsen
.

Köszönöm előre is!

Üdv:
spgabor
A hozzászólás módosítva: Jan 27, 2019
(#) Jani_80 hozzászólása Jan 31, 2019 /
 
Sziasztok! Segítséget szeretnék kérni AD-vel kapcsolatban. A körülmények: PIC16F877-es PIC, CCS-C compilerrel és MPLAB 8.90-el dolgozom. A " Read_ADC() " fügvényt használnám , 10 bites AD értékre lenne szükségem, de csak 8 bit-es AD értékhez tudok hozzájutni, pedig a CCS C fordító helpjét is tanulmányoztam, az ott írt paraméterezéseket is próbáltam de pl. a "#device ADC=10" -es paraméterezést pedig nem fogadja el a fordító. Szóval tanácstalan vagyok.

Valaki tudna egy egyszerű kódot ide bemasolni, ami ezekhez a korülményekhez passzol és 10 bited ad vissza az AD?
Körülmények: PIC16F877-es PIC, CCS-C compilerrel és MPLAB 8.90-el. Köszönöm szépen!
A hozzászólás módosítva: Jan 31, 2019
(#) superuser válasza Jani_80 hozzászólására (») Jan 31, 2019 /
 
Nem használok ccs-t, de ha csatolod a fordító leírását, szívesen ránézek. Jó esetben az eljárásoknak van normális dokumentációjuk, el kell olvasni és meg lehet válaszolni a kérdést.
Következő: »»   142 / 153
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem