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.

Vagy, ti mit használnátok, ha most kezdenétek?

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ó?

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...

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.

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.

A MikroC 2k fordításig ingyenes.

Ami seperc alatt átléphető, de köszönöm a kiegészítést.

Ü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?

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.

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 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)?

Pontosan.
Egészen konkrétan a DS18B20 hőmérséklet értéke.

Miért nem küldöd át 1/16 fokban mérve egészként?

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:

Ezt kifejtenéd? Nem igazán értem mire gondolsz, bár kicsit már fáradt vagyok.

Szuper. Kipróbálom, köszönöm.
A másik esetben az strcat-et, miért is hagyhatom el?

Az előjellel nem foglalkozik, de azt a legelejére be lehet írni.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.

Köszönöm.

Ü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

PIC24 PSV and Interrupt

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.

Ú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?

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.

Í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.

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.

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.

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

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!

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.