Svenska ElektronikForumet

SDCC har varit alpha-status i säkert 15 år, och lär förbli det så länge ingen jobbar på detta, och SDCC har inte varit skapad specifik för just PIC utan en enkel kompilatorplattform där man kan ganska enkelt byta instruktionsuppsättning för olika CPU-familjer.

Men en C-miljö kräver mer än så, behöver assembler, lib-hanterar och länkare, bra interface mot debuggverktyg inklusive källkodsdebuggning. Det som skiljer sig mellan kommersiella C-kompilatorer specifikt för en MCU familj och generiska sådan (inklusive GCC, även om den i sig är väldigt optimerad för att vara en generisk kompilator) är optimeringsgraden och minneshanteringen allt ifrån stack till funktionsanrop, cache-optimeringar etc.

Det är mycket möda nedlagd på den delen i kommersiella kompilatorer avsedda för olika processorfamiljer.

Skall man till varje pris jobba i fri programvara så får man välja microkontrollerfamiljer som åtminstone har GCC som kompileringsplatform, gissningsvis AVR i det här fallet.

SDCC har jag också kollat på tidigare.
Kom fram till att den inte är bra.

Har kört htsoft Hi-Tech för PIC16 serien och är nöjd över den.
Visst den är dyr, men fungerar.

avrdude fungerar dessutom bra med den välkända tre motstånd-programmeraren (den finns beskriven på avrdude-länken). Det var så jag började min AVR-karriär.

avrdude och fem motstånd är vad jag använder!
Och det har fungerat så bra att jag inte sett något behov av något mer avancerat. Har felbränt 'fuses' en gång och kasserat en kapsel som eventuellt kunde räddats med en mer avancerad programmerare, det är allt.

Har brännt tusentals gånger, och i mitt aktuella projekt, servomotorstyrning, är jag uppe i 1867 bränningar av samma kapsel och har inte sett något problem hittils.

Vad vinner man egentligen med en mer avancerade brännare?
Hastighet? Tillförlitlighet? USB-kommunikation?

Jag kopierade programmeraren du skrev om här en gång, SvenW. Har fungerat bra. En gång brände jag fel fuses, men det kunde jag fixa genom att mata kretsen med klocka från en annan krets.

Datorn måste ha parallellport, det har inte min nya.

Flyttade bort offtopic-harangen till en egen tråd...

Pajn
>Låter ju inte så kul, eller är det det du manar med att källorna är föråldrade?

http://eis.comp.lancs.ac.uk/~martyn/sdcc_linux/

I "Test Application for pic18f252"

Använder #pragma stack 0x5ff

Skall skapa en stack område för C-kompilator,
i pic18f252 minersomräde.

Ej använbar nummera

Ur SDCC Manual 2.8.5 : 4.6.6 Pragmas

The PIC16 port currently supports the following pragmas:

stack
This forces the code generator to initialize the
stack & frame pointers at a specific address.
This is an ad hoc solution for cases where no
STACK directive is available in the linker script
or gplink is not instructed to create a stack section.

Example:

/* initializes stack of 100 bytes at RAM address 0x200 */

#pragma stack 0x200 100

Tidigare SDCC Manual > 2.8.5 hade mera om varför,
"#pragma stack 0x5ff". Inte skall användas.

Har linker script för SDCC 2.8.0 STACK directive ???
Ej undersök närmare men #pragma stack 0x5ff ger endast varnigsmedelande,
i stil med "används inte".

Installations beskrivnig av I/O biblotek på PC-datoren fungera ej...

http://www.freenet.org.nz/sdcc/

Utan någon närmare beskrivnig:

Använder en "bootloader".
Bootloader ladds med programerare först.
Övriga program laddas av"bootloader" utan programerare sedan.

Inga __CONFIG words i exempelcorden
Bootloader tillhanda håller alla hårdvaru inställnigar ???

Skriver egna Makefile, crt0 module, och linker script
Var det nödvändigt när detta skrivdes ?
Vilken version av SDCC var det ?


Några anledningar varför jag inte kan helt rekommder
någon av texterna, men de är de bästa jag har hittat....

Skall försöka att beskriva vad har fått att funger....
Men förvänta inga snabba svar..

Låt mig rekommendera B Knudsens C-kompilator CC5x (http://www.bknd.com/cc5x/) som finns i en gratis version och som fungerar med MPLAB från Microchip.

Och om sodjan skulle få för sig att svara: Just nu känns inte assembler som ett alternativ, men planen är att porta dit när jag kan använda pic:en ordentligt i ett mellannivåspråk (C)

C räknas väll till högnivåspråken, precis som C++, C#, BASIC, java med flera.

I princip, men nivåskillnaden mellan ASM och C är försumbar i jämförelse med nivån mellan C och C#.