Bästa C-komiplatorn (PIC)

[haardhandske]

Hej!
Jag är lite nyfiken på vad ni andra tycker om C-kompilatorer som finns på marknaden. Jag har just beställt C-kompilatorn av Mikroe efter lite vånda. Jag har kört en gammal version tidigare och jag gillar hela upplägget med den men tycker att den varit lite buggig. Det främsta alternativet är väl Microchip's kompilator även om det säkert finns 100 till att välja på.
Så, är det någon som testat eller kör Mikroe C V5.30? Bu eller Bä, tips, fallgropar, oacceptabla buggar, bättre kopilatorer? Kort sagt: "Vad tycker ni?"

[AndersG]

Definiera "bästa"

[haardhandske]

Ja, eftersom jag bad om era åsikter... så måste jag väl ge er fritt spelrum att definera "bästa" också. Vad jag menar är:

Lättanvänd (Bra dokumentation pch gränssnitt)
Buggfri
Bra "community" och support
"Tweak"-bar

[AndersG]

Gratisversionen av Microchips C-kompilator då. Gratis är gott.

[TomasL]

Ja, MPLAB-C18/24/32 är bra.

[LHelge]

Jag röstar också på Microchips kompilatorer. De jag använt är Microchips C30 och Mikroelectronica MikroC för dspic och pic32, men det är framför allt för att jag tycker att Mikroes IDE är kass. Själva kompilatorn kan jag inte uttala mig om. MPLAB känns 90-tal men är inte alls lika buggig, och vad jag sett av MPLAB X så verkar den vara trevlig, trots att den har Eclipse i botten.

[sodjan]

> "Tweak"-bar

Och vad fasen är det mer specifikt ?

Men, idag så får man nog ha bra anledningar för att *inte* köra de
som Microchip levererar, så du kan ju börja med att tala om varför
du inte vill/kan använda dom så att vi vet vad du saknar hos dom.

> Jag har just beställt C-kompilatorn...

Ja, men då så, då har du ju redan valt.

[Icecap]

Min erfarenhet med MikroE är att den är fin att se på och lätt att använda, kvaliteten på koden den genererar är däremot ganska tveksam.

Mestendels fungerar den helt OK men jag har upplevd fel som är helt oförklarliga och som har ställd till det ganska mycket. Felet bestod sannolikt i att det blev skrivit till fel register, alltså en sorts "Banksel"-fel. Jag löste problemet med en Quick-&-dirty lösning och har inte forskat mer i det pga. tidsbrist.

[haardhandske]

så du kan ju börja med att tala om varför
du inte vill/kan använda dom så att vi vet vad du saknar hos dom..

När jag kastade mig in i det här för 1 och ett halvt år sedan, så letade jag runt efter bästa lösningen. Jag började med Microchip och labbade lite men tyckte den var lite svår att komma igång med. När jag senare stötte på en snygg skapelse i form av ett multitaskingsystem för PIC (OSA, http://www.pic24.ru) som jag har för mig inte stödde MikroChip vid tidpunkt, vilket den gör nu såg jag, blev det gratisversionen av Mikroe i stället.

Ja, men då så, då har du ju redan valt

Nu var jag i behov av ICD-debugging (kanske för att Mikroe är buggig) kändes det även denna gång mer lättilgängligt från mikroe. Ja, jag har gjort mitt val, men man kan väl alltid ändra sig om man blir frälst...

[sodjan]

Helt OK...

Mitt intryck av Mikroelektronika är ungefär som Icecap's, mycket
"yta" men en del konstigheter under ytan. Bl.a så har deras
dokumentation alltid varit lite sisådär. Ytlig och det saknas
viktiga detaljer om man kör fast. Däremot så har de så vitt jag
förstår ett bra "community" med bl.a ett aktivt forum. Men ett
första snabbt positivt intryck driver ju säkert på deras affärer...

> ...i form av ett multitaskingsystem för PIC

Ja, det finns en del som tror att det är en hjälp.
Men snart inser man nog att mest skymmer sikten.

[haardhandske]

Ja det finns dem som inte tror att det hjälper också

Det där med oförklarliga fel har jag också upplevt. Jag får återkomma med en rapport när jag provat senaste versionen. Vem vet, kanske är det bättre kvalitet, kanske jag byter till MicroChip.

[Icecap]

Just PIC16 & PIC18 är väl knappast det rätta att köra ett RTOS på! RTOS har sin rätt till vissa saker och många program man gör som utnyttjar interrupten ordentligt är ju de-facto en sorts RTOS.

Jag har varit igång med att använda ett RTOS och det stöp på sin struktur och det onödiga i det hela, jag hade redan löst alla de saker med lite interrupthantering och sekvensstyrning.

[sodjan]

Om man kollar sidan för den RTOS som det länkades till så var det ca 90 us för ett
"teask-switch" mellan två task vid 4 task i applikationen och 20 Mhz på en 16F628.
Alltså ca 400 instruktioner, det kan vara en ganska lång tid, beroende på vad man
håller på med. Men som ett teoretiskt experiment så kanske det hela kan vara intressant.

Och det ökade linjärt med antalat task, vid 8 tasks med samma uppsättning för övrigt
så blir det alltså ca 180 us (ca 800 instruktions cykler) för ett task-switch.

[haardhandske]

Ja det beror ju lite på vad man vill uppnå. Ska det vara ett trimmat system där prestanda är avgörande kan man naturligtvis inte ödsla med kraft på det sättet. Fördelen är annars att man kan isolera varje typ av bearbetning utan att behöva ta hänsyn till alla andra processer som pågår vilket kan göra koden både kompakt och lätt att underhålla. Jag har pillat med en krets för att samla in temperaturer mm och mellanlagra det på minneskretsar för att sedan skicka upp det till min dator. Ingenting är speciellt tidskritiskt ur prestandaperspektiv. När timing är viktigt finns det funktioner för att stänga av task-switch.

[Icecap]

Den uppdelning är knappast speciellt svårt att uppnå även utan ett RTOS. Jag gör det mer eller mindre vid varje projekt av en viss komplexitet, alltså alla "större" än "hello world".

Men OK, det kan vara kul ur ett studiesynpunkt, det finns definitivt projekt där ett RTOS är en bra sak att använda.