Låter klart intressant om programmering i C ger bättre optimering av koden jämfört med PIC.jesse skrev:Atmel Studio 6 är antagligen "ungefär" lika bra, eftersom Atmel bara har en version oavsett om man är proffs eller inte, och den är gratis.jfri skrev:Är dom fria kompilatorerna till AVR lika bra som dom fulla registrerade motsvarigheterna för PIC ?Krille Krokodil skrev:Gå över till AVR.
Den stödjer även Atmels 32-bitars.
Dessa fria begränsade kompilatorer
Re: Dessa fria begränsade kompilatorer
Re: Dessa fria begränsade kompilatorer
Observera att ett program som tar mindre minne behöver inte bli snabbare. I värsta fall kan det bli tvärt om att optimering mot minnesstorlek medger sämre tidsegenskaper beroende på hur optimeringen sker.
Sedan kan jag tycka generellt att har man stora problem med minnesutrymmet används helt fel plattform för prototypen. Lösningen är inte längre bort än att byta mikrokontroller/system.
Sedan kan jag tycka generellt att har man stora problem med minnesutrymmet används helt fel plattform för prototypen. Lösningen är inte längre bort än att byta mikrokontroller/system.
Re: Dessa fria begränsade kompilatorer
Men efter vad jag läst här i tråden verkar det som om man kan få gratis optimering med Atmel Studio och AVR. Det är möjligt att den inte är lika bra som Microchips kommersiella versioner men är dom inte bättre än 40% reducering av kodstorlek. Om full MC hade kunnat ge 40% mindre hur många % mindre skulle då Atmel Studio kunna ge på liknande AVR och samma program?TomasL skrev:Om man har egenutvecklade optimeringsalgoritmer som exempelvis Microchip, är det väl inte konstigt att man vill ha betalt.
Samma gäller Microchips version av gcc, vill du ha full optimering mm, får du köpa den, nöjer du dig med gcc's normala optimering, så är det gratis, men de extra 50% eller vad det nu är kostar pengar.
Om du har sådana behov att optimera, har du gjort fel, antingen har du skrivit fruktansvärt dålig kod eller valt fel processor.
Btw, skrota de där gamla stenålderspicarna, och använd lite modernare i stället.
Hur skriver man fruktansvärt dålig kod i C?
De två PIC jag fn använder är 16F690 och 16F1938. Den senare är definitivt inte stenålder. Men jag kan inte programmera den direkt från MPLAB dp jag bara har PICkit 2.
Re: Dessa fria begränsade kompilatorer
> Hur skriver man fruktansvärt dålig kod i C?
Exakt på samma sätt som i vilket annat verktyg som helst.
Det är inget speciellt med C i det avseendet. Det går att
skriva dålig kod i vilket språk/verktyg som helst...
> Men efter vad jag läst här i tråden verkar det som om man kan få gratis optimering med Atmel Studio och AVR.
Begreppet "optimering" betyder inte alltid samma sak. Om du seriöst vill göra
jämförelser så måste du kolla dokumentationen och jämföra i detalj vilka
optimeringar som de olika verktygen erbjuder i sina olika versioner. Det är
meningslöst att bara säga att det ena verktyget "optimerar" och det andra
"optimerar inte". Det säger inte ett smack. Inte heller "gratis optimering".
> De två PIC jag fn använder är 16F690 och 16F1938. Den senare är definitivt inte stenålder.
De nya PIC16F1xxx är riktigt trevliga och vissa operationer går att göra riktigt effektiva
tack vara den rakare/renare arkitekturen och en del nyheter i "enhanged midrange" tack
vara t.ex "linear adressing" och nya indexregister och nya indexerade instruktioner.
I databladet ligger de nya instruktionerna under "C-compiler optimized", vad nu det betyder.
> Men jag kan inte programmera den direkt från MPLAB dp jag bara har PICkit 2.
Den stöds inte av den integrerade PICkit2 drivern i MPLAB, men det är inget problem.
Jag kör (just med 1938) med det fristående PICkit2 programmet uppsatt med
pollning av HEX filen, så ett klick på "make" räcker för att flasha om processorn.
> Observera att ett program som tar mindre minne behöver inte bli snabbare.
> I värsta fall kan det bli tvärt om att optimering mot minnesstorlek medger
> sämre tidsegenskaper beroende på hur optimeringen sker.
Inte bara i värsta fall, det är nog det vanliga. "Optimize for speed" ger normalt
större men snabbare program och "optimize for size" ger mindre men långsammare
program. För att generallisera lite...
> Låter klart intressant om programmering i C ger bättre optimering av koden jämfört med PIC.
Jag fattar inget av den där meningen. Vad menar du?
Exakt på samma sätt som i vilket annat verktyg som helst.
Det är inget speciellt med C i det avseendet. Det går att
skriva dålig kod i vilket språk/verktyg som helst...
> Men efter vad jag läst här i tråden verkar det som om man kan få gratis optimering med Atmel Studio och AVR.
Begreppet "optimering" betyder inte alltid samma sak. Om du seriöst vill göra
jämförelser så måste du kolla dokumentationen och jämföra i detalj vilka
optimeringar som de olika verktygen erbjuder i sina olika versioner. Det är
meningslöst att bara säga att det ena verktyget "optimerar" och det andra
"optimerar inte". Det säger inte ett smack. Inte heller "gratis optimering".
> De två PIC jag fn använder är 16F690 och 16F1938. Den senare är definitivt inte stenålder.
De nya PIC16F1xxx är riktigt trevliga och vissa operationer går att göra riktigt effektiva
tack vara den rakare/renare arkitekturen och en del nyheter i "enhanged midrange" tack
vara t.ex "linear adressing" och nya indexregister och nya indexerade instruktioner.
I databladet ligger de nya instruktionerna under "C-compiler optimized", vad nu det betyder.
> Men jag kan inte programmera den direkt från MPLAB dp jag bara har PICkit 2.
Den stöds inte av den integrerade PICkit2 drivern i MPLAB, men det är inget problem.
Jag kör (just med 1938) med det fristående PICkit2 programmet uppsatt med
pollning av HEX filen, så ett klick på "make" räcker för att flasha om processorn.
> Observera att ett program som tar mindre minne behöver inte bli snabbare.
> I värsta fall kan det bli tvärt om att optimering mot minnesstorlek medger
> sämre tidsegenskaper beroende på hur optimeringen sker.
Inte bara i värsta fall, det är nog det vanliga. "Optimize for speed" ger normalt
större men snabbare program och "optimize for size" ger mindre men långsammare
program. För att generallisera lite...
> Låter klart intressant om programmering i C ger bättre optimering av koden jämfört med PIC.
Jag fattar inget av den där meningen. Vad menar du?
Re: Dessa fria begränsade kompilatorer
>> Låter klart intressant om programmering i C ger bättre optimering av koden jämfört med PIC.
>Jag fattar inget av den där meningen. Vad menar du?
Om jag skulle använda en Atmel istället för PIC för att skriva ett program. Och därför använda Atmel Studio istället för MPLABX för C kodning. Då slipper jag den begränsning som ligger i den fria XC8 kompilatorn och förväntar mig då bättre optimering och mindre kodstorlek jämfört med PIC MPLABX+XC8 alternativet. I så fall låter det intressant.
>Jag fattar inget av den där meningen. Vad menar du?
Om jag skulle använda en Atmel istället för PIC för att skriva ett program. Och därför använda Atmel Studio istället för MPLABX för C kodning. Då slipper jag den begränsning som ligger i den fria XC8 kompilatorn och förväntar mig då bättre optimering och mindre kodstorlek jämfört med PIC MPLABX+XC8 alternativet. I så fall låter det intressant.
Re: Dessa fria begränsade kompilatorer
OK.
Men du kan kanske inte jämföra på det sättet.
Du vet ju inte om den "fria optimeringen" i XC8 är bättre eller
sämre än "gratisoptimeringen" i AVR-GCC. Antingen kollar man
dokumentationen eller så kör man ett antal rellevanta test-cases,
det senare är sannolikt nödvändigt för att ge något användbart.
Och ett sådant begrepp som "kodstorlek" är också svårt att jämföra
mellan olika arkitekturer.
Sen så är det ju lite inskrängt att välja hela arkitekturen enbart efter ett
sådant kriterium i alla fall. Beroende på vad du ska göra så kanske resultatet
beror mer på helt andra saker än eventuella optimeringar.
Man ska inte heller överdriva effekterna av automatiskt optimering, eller som
XC8 manualen uttrycker det, "Generally, the biggest gains to be made in terms
of speed of execution come from the algorithm used in a project". Så se till
att göra rätt saker i koden...
Men du kan kanske inte jämföra på det sättet.
Du vet ju inte om den "fria optimeringen" i XC8 är bättre eller
sämre än "gratisoptimeringen" i AVR-GCC. Antingen kollar man
dokumentationen eller så kör man ett antal rellevanta test-cases,
det senare är sannolikt nödvändigt för att ge något användbart.
Och ett sådant begrepp som "kodstorlek" är också svårt att jämföra
mellan olika arkitekturer.
Sen så är det ju lite inskrängt att välja hela arkitekturen enbart efter ett
sådant kriterium i alla fall. Beroende på vad du ska göra så kanske resultatet
beror mer på helt andra saker än eventuella optimeringar.
Man ska inte heller överdriva effekterna av automatiskt optimering, eller som
XC8 manualen uttrycker det, "Generally, the biggest gains to be made in terms
of speed of execution come from the algorithm used in a project". Så se till
att göra rätt saker i koden...
Re: Dessa fria begränsade kompilatorer
Det innebär väl att de instruktionerna riktar sig till kompilatorkonstruktörer primärt och inte till de som skriver assembler direkt. Vilket förstås i stort sett alltid ger snabbast kod till priset av långsam utveckling.sodjan skrev:De nya PIC16F1xxx är riktigt trevliga och vissa operationer går att göra riktigt effektiva tack vara den rakare/renare arkitekturen och en del nyheter i "enhanged midrange" tack vara t.ex "linear adressing" och nya indexregister och nya indexerade instruktioner. I databladet ligger de nya instruktionerna under "C-compiler optimized", vad nu det betyder.
En annan metod är att ställa in C-kompilatorn till att producera assemblerkod och sedan ändra i assemblerkoden för att få snabbare exekvering. Då man nyttjar att det oftast är kortare avsnitt som tar den mesta tiden.
Re: Dessa fria begränsade kompilatorer
Jag tror att en modern C-kompilator genererar bra mycket effektivare kod än vad de flesta kan åstadkomma med assembler när det handlar om mer avancerade saker än att tex blinka en LED. Om det gäller tidskritiska delar där det inte räcker med timers kan det vara motiverat att handknacka asm.
Re: Dessa fria begränsade kompilatorer
> Det innebär väl att de instruktionerna riktar sig till kompilatorkonstruktörer primärt och inte till de som skriver assembler direkt.
Det är mer en indelning i databladet än något annat. Det är inget speciellt
eller "svårt" med dessa tre nya instruktioner för att hantera index-registren.
Det är möjligt att de är användbara för funktionsanrop i C t.ex, jag vet inte.
Nu handlade inte min kommentar om just det om C specifikt, utan mer att de
nya PIC16F1xxx processorerna är trevliga som sådana...
Det är mer en indelning i databladet än något annat. Det är inget speciellt
eller "svårt" med dessa tre nya instruktioner för att hantera index-registren.
Det är möjligt att de är användbara för funktionsanrop i C t.ex, jag vet inte.
Nu handlade inte min kommentar om just det om C specifikt, utan mer att de
nya PIC16F1xxx processorerna är trevliga som sådana...
Re: Dessa fria begränsade kompilatorer
Har man gjort om de så att linjär addressering kan användas fullt ut nu?
Re: Dessa fria begränsade kompilatorer
Beror på din definition av "fullt ut". Men RTFM för hela bilden, t.ex :
http://ww1.microchip.com/downloads/en/D ... 41375A.pdf
"PIC1XF1XXX Software migration" eller kapitlet "3.6.2 LINEAR DATA MEMORY"
i ett datablad till en av modellerna :
http://ww1.microchip.com/downloads/en/D ... 41574B.pdf.
Hur de nya indexregistren och de nya indexinstruktionerna kan användas i ett
praktiskt exempel kan du se här : http://jescab2.dyndns.org/pub_docs/cds.zip.
Se t.ex allokeringen av en 384 byte buffer (out_buff, se "; 384 positioner för röd/grön data")
i RAM och kopieringen av data från flash till RAM, se "; Copy buffer data from flash to GPR."
http://ww1.microchip.com/downloads/en/D ... 41375A.pdf
"PIC1XF1XXX Software migration" eller kapitlet "3.6.2 LINEAR DATA MEMORY"
i ett datablad till en av modellerna :
http://ww1.microchip.com/downloads/en/D ... 41574B.pdf.
Hur de nya indexregistren och de nya indexinstruktionerna kan användas i ett
praktiskt exempel kan du se här : http://jescab2.dyndns.org/pub_docs/cds.zip.
Se t.ex allokeringen av en 384 byte buffer (out_buff, se "; 384 positioner för röd/grön data")
i RAM och kopieringen av data från flash till RAM, se "; Copy buffer data from flash to GPR."
Re: Dessa fria begränsade kompilatorer
Med C-optimering menar man väl att man liksom 18F-serien lagt till op-koder för hantering av stackar, vilket C gillar och använder sig av.
Re: Dessa fria begränsade kompilatorer
Jag vet inte hur relevant det här är, men när man installerar Atmel Studio så är den förinställd med en form av optimering som heter "Optimize for size" eller "-Os". Den ska optimera mest med avseende på kodstorlek men den optimerar också väldigt mycket med avseende på hastighet.
För skoj skull valde jag ett lite större projekt och testade att kompilera med de olika optimeringar som fanns, samt en kompilering helt utan optimering. Jag fick de här resultaten:
optimerad -Os:
Program: 35130 bytes (53.6% Full)
Optimize -O1:
Program: 38676 bytes (59.0% Full)
Otimize more -O2
Program: 38772 bytes (59.2% Full)
Optimize most -O3
Program: 82122 bytes (125.3% Full)
ingen optimering:
Program: 64974 bytes (99.1% Full)
Nu är jag inte expert på vad denna optimering gör, men -Os ska man använda om man har ont om flashminne. Vill man istället göra snabb kod tar man någon annan optimering. -O3 ser lite konstig ut - den ökar på kodstorleken med 25% ... antagligen optimerar den maximalt för hastighet. Och det kostar i utrymme.
-Os (som jag alltid använder och som ger snabb och bra kod) optimerar bort 46% av kodstorleken.
För skoj skull valde jag ett lite större projekt och testade att kompilera med de olika optimeringar som fanns, samt en kompilering helt utan optimering. Jag fick de här resultaten:
optimerad -Os:
Program: 35130 bytes (53.6% Full)
Optimize -O1:
Program: 38676 bytes (59.0% Full)
Otimize more -O2
Program: 38772 bytes (59.2% Full)
Optimize most -O3
Program: 82122 bytes (125.3% Full)
ingen optimering:
Program: 64974 bytes (99.1% Full)
Nu är jag inte expert på vad denna optimering gör, men -Os ska man använda om man har ont om flashminne. Vill man istället göra snabb kod tar man någon annan optimering. -O3 ser lite konstig ut - den ökar på kodstorleken med 25% ... antagligen optimerar den maximalt för hastighet. Och det kostar i utrymme.
-Os (som jag alltid använder och som ger snabb och bra kod) optimerar bort 46% av kodstorleken.
Re: Dessa fria begränsade kompilatorer
Vad betyder " n% Full" ?
Borde inte "ingen optimering" ger "100% Full" !?
Borde inte "ingen optimering" ger "100% Full" !?
Re: Dessa fria begränsade kompilatorer
Det ska nog tolkas som andel utnyttjat minne i processormodellen som projektet använde. Tyvärr får vi inte veta något om hur snabbt koden körs, kanske körs den tillräckligt snabbt i alla de olika optimeringsfallen?
För övrigt undrar jag vad syftet med tråden den här tråden var? Har trådskaparen problem med att få plats med koden i den cpu som valts?
För övrigt undrar jag vad syftet med tråden den här tråden var? Har trådskaparen problem med att få plats med koden i den cpu som valts?
