Svenska ElektronikForumet

Hejsan har läst lite om dessa två C Compilers... Tycker Hi-tech verkar bra och tänkte testa med den nu när jag känner att jag bemästrar ASM tillräckligt för att börja med C... Det som fick mig att bestämma mig helt var när jag såg att det Hi-tide (IDE för hi-tech) fanns i en version för linux.. (baserad på eclipse)

Men till frågan... Har hittat en bok som heter "PICmicro MCU C® An introduction to programming The Microchip PIC in CCS C", och där förutsätter väl dom att man använder CCS, men är det någon skilland / hur mycket skillnad är det mellan dessa när det gäller koden man skriver? Såg någonstans någon som skrev om när han hade skrivit om kod från den ena till den andra och de fick mig att fundera lite...

C-kod för microcontrollers är ofta olika beroende på kompilator. Syntaxen för interrupt och bitvariabler brukar vara olika. Ibland har också variabelnamnet olika betydelse. En "int" kan vara 8 eller 16-bitar i olika C-kompilatorer för PIC16.

Okey då var det som jag misstänkte! Good to know...

I teorin och i en perfekt värld skall det inte skilja nånting kod som är skriven för en PC skall i princip kunna kompileras för en PIC också (sant med vissa begränsningar), håller själv på att portera kod, som kan kompileras till vilket system som helst.
Dock är det så att olika tillverkare har valt att implementera de sk hårdvaruextensionerna olika, dvs de delarna som involverar håedvaran direk på lite olika sätt, vilket är mycket dumt.
Nu vet jag inget om Hitech eller CCS, med MC18 (Microchip C18) implementerar portbitar så här: "PORTCbits.RC0" och WIZ-C så här: bRC0, gissar att Hitech och CCS har den tredje respektive fjärde varianten.
I övrigt "borde" koden vara identisk.

Programvara som är skriven för att vara porterbar brukar ha ett HW-Layer, med en bunt defines, just för att anpassa hårdvaru åtkomsten.
En annan sak som är synnerligen irriterande är div buggar och skönhetsfel, vilka får till resultat att vissa kod-sekvenser inte funkar som tänkt är.
Ett exempel är MC18 som inte varnar för ickeinkluderade bibliotek eller avsaknade typ-definitioner i macron.

Okey men kanske kan använda den boken iallafall för C-kodningen överlag? Och sen titta i hi-tech manualen när det inte funkar eller så.... TomasL vet du någon bra text/sida som beskriver det du gör? Känns att jag gärna skulle lära mig att skriva "portbar" kod från början och kanske någonstans där de beskriver det med HW-layer och så från början... Värt att fråga iallafall..

Kika på "freeRTOS" och freeMODBUS" så hittar du porterbar kod, känner inte till några beskrivningar hur man gör dock.

bearing
>En "int" kan vara 8 eller 16-bitar i olika C-kompilatorer för PIC16.

Inte bara C-kompilatorer för PIC16 är så .

C-standaden överlåter storleken på variabler nästan helt
till C-kompilatorer programerare.

Relativa storlekar anges endast "int" störe än "chr"
"double" störe än "float " m.m.

Fast om en "int" är 8 bitar kan den ju inte vara större än en "char" i 8-bitars miljö.

Det brukar ju även finnas variabeltyper med logiska namn, typ "uns8" "int16", fast där verkar det också vara olika. Finns även "u32", "i24" osv.

Enligt K&R "skall" en char vara "8-bitar" eller snarare, CITAT: " En enda byte, kapabel att lagra ett tecken av den lokala teckenuppsättningen", en int är ett heltal, och skall vara minst 16 bitar, kan iofs vara längre.
Så i princip, på en unicode maskin skall char vara 16 bitar (ett tecken är väl, vill jag minnas 16 bitar i unicode).

Kraven är att "short" och "int" är minst 16 bitar, samt att "long" är minst 32 bitar och att short inte är längre än int som i sin tur inte är längre än long.
Så
En Int kan vara 16 bitar, då är short 16 bitar och long minst 32 bitar (kan teoretiskt vara 16 bitar dock).
En int kan vara 32 bitar, då är short 16 bitar och long kan då i princip vara 32 bitar, men förmodligen snarare 64 bitar.
Dock är dessa normalt definerade i limits.h och float.h.

I CC5X gäller följande:

char - 8 bit unsigned
int - 8 bit signed
long - 16 bit signed

Tror det är hårdkodat i kompilatorn.

Det är ju synnerlligen ickekompatibelt, och väldigt icke standard.
Hur i h-e kan de konstruera en C-kompilator som inte ens följer de grundläggande rekommendationerna i ANSI-C?

Nja... int i C är avsedd som en "strövariabel" som är avsedd att överföra enkla värden (SANT/FALSK) i det format som passar processorn bäst, är det alltså en 8-bitars med 8-bitars minne är en int 8-bitars, är det en 16-bitars processor där en 8-bitars variabel ville medföra noll-fyllning i MSB är den på 16 bit osv.

Jag har gjort det enkelt för mig, jag har en fil ("MyDef.h") som anger typedef på BYTE, WORD, DWORD som jag kallar in i mina projekt, är det kompilerspecifika definitioner använder jag den "flagga" som finns i nästan alla kompilatorer, i min BCB6 är det "__BORLANDC__", i Fujitsuns fall är det "__COMPILER_FCC907__" osv, då kan man göra samma definitioner till olika kompilatorer och slutresultatet är att man i programmeringsskedet använder exakt samma definitioner oavsett vilken kompiler man använder och sedan får samma resultat, att t.ex. en int (som man ju kan döpa om till den egna definition "INT") ger samma storlek oavsett vilken kompiler man använder.

CC5X avviker rätt mycket från ANSI-C, fast ska optimera koden bäst av PIC16-kompilatorerna.

Enligt ANSI-C och K&R

int: ett Heltal, som oftast speglar den naturliga heltalsstorleken hos värddatorn

vidare

....int är den naturliga storleken för en viss maskin.
....... int är antingen 16 eller 32 bitar

Icecap, du tänker på BOOL som antar värdena SANT eller Falskt dvs 1 eller 0.

bearing, detta skapar då jätteproblem, om du skall byta målprocessor eller utvecklingsmiljö.