Hej!
Tänkte höra ifall någon av er där ute testat SDCC för pic och hur det fungerar? enligt hemsidan så är arbetet "under utveckling" funderar bara på hurpass bra allt fungerar. Jag är nämligen lite sugen på att skippa C18 och hi-tech kompilatorerna pga för mycket strul.
http://sdcc.sourceforge.net/
SDCC till PIC?
SDCC till PIC?
Senast redigerad av blueint 12 juli 2010, 16:45:57, redigerad totalt 2 gånger.
Anledning: pic -> PIC
Anledning: pic -> PIC
Re: SDCC till PIC?
Frågan har ställt tidigare. Kolla sök-funktionen.
> Jag är nämligen lite sugen på att skippa C18 och hi-tech kompilatorerna pga för mycket strul.
Och köra SDCC istället för att det ger mindre strul ? Humor...
> Jag är nämligen lite sugen på att skippa C18 och hi-tech kompilatorerna pga för mycket strul.
Och köra SDCC istället för att det ger mindre strul ? Humor...
Re: SDCC till PIC?
Jag har letat men hittar bara inlägg som är 6mån gamla eller äldre. Ville ha lite uppdaterad info,men men.
Mplab C18 problemfri?
jag vet inte riktigt om du är sarkastisk eller inte men jag upplever stora brister i miljön både i mplab och C18..
Problem jag tampats med, för att nämna några:
- Projektfiler karchar
- Optimeringar som är vääädligt dåliga. Även den fulla versionen av C18 gör vansinniga översättnignar mellan C kod till asm. Det går att optimera koden för just C18 men då blir den lätt rörig och ej portabel till andra kompilatorer för andra architekturer.
- Varningar som dyker upp t.ex att man jämför en char med 0xFF och får varningen att det finns risk att man inte jämför av samma typ.
- Har lyckats kompilera utan varningar och fel när prototyp och funktion inte överensstämmer vilket resulterar i väädligt konstiga resultat.
- Hi-tech s kompilator optimerar bättre men hanterar inte funktionspekare på ett korrekt sätt, optimerar bort vad den tror är död kod och lyckas därefter inte länka ihop projektet.
- VDI, väldigt coolt användargränssnitt för att sätta upp perferienheter för vissa pic-processorer men proppfullt av buggar. Själv skulle jag inte ens släppt det som en Beta version ändå är det med i full-releasen.
- C18 mappar inte själv upp ram-minnet utan man måste själv hålla koll på sina 256byts sektioner i koden.
Därför letar jag efter alternativa kompilatorer och utvecklnigsmiljöer. Eclipse ligger väldigt bra till som utvecklingsverktyg det är bara en vettig kompilator som fattas.
Mplab C18 problemfri?
jag vet inte riktigt om du är sarkastisk eller inte men jag upplever stora brister i miljön både i mplab och C18..
Problem jag tampats med, för att nämna några:
- Projektfiler karchar
- Optimeringar som är vääädligt dåliga. Även den fulla versionen av C18 gör vansinniga översättnignar mellan C kod till asm. Det går att optimera koden för just C18 men då blir den lätt rörig och ej portabel till andra kompilatorer för andra architekturer.
- Varningar som dyker upp t.ex att man jämför en char med 0xFF och får varningen att det finns risk att man inte jämför av samma typ.
- Har lyckats kompilera utan varningar och fel när prototyp och funktion inte överensstämmer vilket resulterar i väädligt konstiga resultat.
- Hi-tech s kompilator optimerar bättre men hanterar inte funktionspekare på ett korrekt sätt, optimerar bort vad den tror är död kod och lyckas därefter inte länka ihop projektet.
- VDI, väldigt coolt användargränssnitt för att sätta upp perferienheter för vissa pic-processorer men proppfullt av buggar. Själv skulle jag inte ens släppt det som en Beta version ändå är det med i full-releasen.
- C18 mappar inte själv upp ram-minnet utan man måste själv hålla koll på sina 256byts sektioner i koden.
Därför letar jag efter alternativa kompilatorer och utvecklnigsmiljöer. Eclipse ligger väldigt bra till som utvecklingsverktyg det är bara en vettig kompilator som fattas.
-
jappelino_1
- Inlägg: 81
- Blev medlem: 13 april 2010, 14:40:04
- Ort: Stockholm
Re: SDCC till PIC?
Om kan tänka dig att byta CPU till tex en ARM och inte ska skriva så mycket kod så tycker jag att IARs gratisversion fungerar mycket bra.
Re: SDCC till PIC?
Renesa stödet är väl begränsat till en ms-win32 binär?
För AVR, ARM mm finns gcc och massa fria verktyg. Inte EOL när ms-win installationen är det eller supporten från tillverkaren tar slut.
För AVR, ARM mm finns gcc och massa fria verktyg. Inte EOL när ms-win installationen är det eller supporten från tillverkaren tar slut.
Re: SDCC till PIC?
KPIT GNU har kompiler till Renesas... Renesas egen kompiler är helt riktigt till Win32.
Re: SDCC till PIC?
Och KPIT GNU är öppen källkod + fri licens?
dangraf / TomasL, Vilket ms-win + utvecklar version kör ni?, det kanske kan förklara skillnaden i stabilitet mm.
dangraf / TomasL, Vilket ms-win + utvecklar version kör ni?, det kanske kan förklara skillnaden i stabilitet mm.
Re: SDCC till PIC?
Vista64/XPPro/XPHome/Vista32/WIN764, MPLAB/MCC18.
Inga stabilitetsproblem, huruvida kompilatorn tillverkar "konstig" kod har jag inte märkt.
Dock kör vi ingen optimering, då det inte går att debugga.
Förstår ej heller problemet med "optimering" och icke porterbar kod, vad är det som optimeras så koden inte blir porterbar?
Beträffande RAM, så är det väl inget som hindrar att man drar ihop hela RAM-Arean till en enda stor Area, då "slipper" man problemet att stora variabler eller structar inte får plats.
Så Nej, jag förstår ärligt talat inte problemet
Inga stabilitetsproblem, huruvida kompilatorn tillverkar "konstig" kod har jag inte märkt.
Dock kör vi ingen optimering, då det inte går att debugga.
Förstår ej heller problemet med "optimering" och icke porterbar kod, vad är det som optimeras så koden inte blir porterbar?
Beträffande RAM, så är det väl inget som hindrar att man drar ihop hela RAM-Arean till en enda stor Area, då "slipper" man problemet att stora variabler eller structar inte får plats.
Så Nej, jag förstår ärligt talat inte problemet
Re: SDCC till PIC?
Posta gärna ett par kodexempel där C18 och Hi-tech gör fel vid kompileringen, vore intressant att se!
Re: SDCC till PIC?
Det kom en hel del svar här ser jag
Jag funderar på att gå över till ARM faktiskt och testar lite fram och tillbaka med kompilatorer mm. Ska ta en titt på IARs gratis version, verkar intressant! Men i det projektet jag pysslar med är jag fast med 2st 18F och 1st 33F pic. Det var inte meningen att trampa någon på tårna genom att säga att jag inte gillar microchips utvecklingsmiljö.
Det finns stor risk att tråden börjar handla om ifall man gillar mplab +C18 eller inte samt hur man kan gå runt felen. Jag var mest ute efter att se om SDCC är ett alternativ men tyvärr verkar det inte vara så.
Det finns lite tidigare trådar som handlar om problem jag stött på som kan ses här för de som är nyfikna.
http://elektronikforumet.com/forum/view ... =7&t=42116
http://elektronikforumet.com/forum/view ... =7&t=39294
http://elektronikforumet.com/forum/view ... =7&t=32966
Angående att min kommentar att koden inte blir "portabel" vid optimering så syftar jag t.ex på shift-problemet i en tidigare tråd där jag t.ex vill shifta ett 32 bitars tal 8 eller 16 steg vilket tar kompilatorn nästan 100 klockcykler att utföra. Om man optimerar detta med pekare fungerar det på andra 8-bitars architekturer men man kan inte vara säker på att det fungerar på 16 eller 32 bitars. Det går även att skriva inline-assembler på de delar man vill optimera upp i tidskritiska men dessa delar kommer inte bli portabla och blir snabbt svårlästa.
systemet jag kör på har varit XP och Win 7 samt den senaste versionen av mplab och student-versionen av kompilatorn för tillfället.
Jag funderar på att gå över till ARM faktiskt och testar lite fram och tillbaka med kompilatorer mm. Ska ta en titt på IARs gratis version, verkar intressant! Men i det projektet jag pysslar med är jag fast med 2st 18F och 1st 33F pic. Det var inte meningen att trampa någon på tårna genom att säga att jag inte gillar microchips utvecklingsmiljö.
Det finns stor risk att tråden börjar handla om ifall man gillar mplab +C18 eller inte samt hur man kan gå runt felen. Jag var mest ute efter att se om SDCC är ett alternativ men tyvärr verkar det inte vara så.
Det finns lite tidigare trådar som handlar om problem jag stött på som kan ses här för de som är nyfikna.
http://elektronikforumet.com/forum/view ... =7&t=42116
http://elektronikforumet.com/forum/view ... =7&t=39294
http://elektronikforumet.com/forum/view ... =7&t=32966
Angående att min kommentar att koden inte blir "portabel" vid optimering så syftar jag t.ex på shift-problemet i en tidigare tråd där jag t.ex vill shifta ett 32 bitars tal 8 eller 16 steg vilket tar kompilatorn nästan 100 klockcykler att utföra. Om man optimerar detta med pekare fungerar det på andra 8-bitars architekturer men man kan inte vara säker på att det fungerar på 16 eller 32 bitars. Det går även att skriva inline-assembler på de delar man vill optimera upp i tidskritiska men dessa delar kommer inte bli portabla och blir snabbt svårlästa.
systemet jag kör på har varit XP och Win 7 samt den senaste versionen av mplab och student-versionen av kompilatorn för tillfället.
Re: SDCC till PIC?
32 bitars tal 8 eller 16 steg vilket tar kompilatorn nästan 100 klockcykler att
Tror sjutton det, det är ju en 8-bitars processor, det tar tid att göra saker med data som är större än den nativa ordlängden, spelar ingen roll vilken kompilator du har, det blir samma resultat oavsett.
32 bitar motsvarar 4 byte, vilket innebär att du skall utföra en skiftinstruktion på totalt 4 byte.
Det tar MINST 4 instruktioner att göra detta.
Skall du dessutom göra det 16 gånger, så blir den absolut minsta mängden instruktioner 16x4 vilket motsvarar 64 instruktioner, dessutom måste ju carryn kollas mellan varje skiftning, vilket läger på ytterligare 4 instruktioner, per skift, till detta kommer naturligtvis ett antal instruktioner som skall hantera carryn.
Om du tycker att kompilatorn är ineffektiv i detta läget, så har du fullständigt fel, fundera ut nått annat sätt att fixa det på, eller byt till 32-bitars miljö.
Btw, Menar du klockcykler eller instruktionscykler.
