PIC32 USB SK, LCC-kortet och 4,3" Display

[tmst]

Vi använder Demoboard PIC32 USB SK, LCC-kortet och 4,3" Display frå Microchip.
Vi håller nu på att migrerat ett Pic24 program till Pic32:an, efter att gjort drygt
halva jobbet inser vi att koden blir 240kB fullt optimerad och 440kB ej optimerad.
Vi använder MPLABX samt XC32 är detta normalt eller blir resultatet bättre om
man använder den gamla MPLAB8 ide'n eller C32 kompilatorn???

[Icecap]

Hur mycket optimeringen ger beror helt på programmets struktur, vilken optimering som väljs osv.

Så min bedömning är att det låter skapligt möjligt och att en äldre kompiler knappast gör någon större skillnad.

[TomasL]

Vi använder Demoboard PIC32 USB SK, LCC-kortet och 4,3" Display frå Microchip.
Vi håller nu på att migrerat ett Pic24 program till Pic32:an, efter att gjort drygt
halva jobbet inser vi att koden blir 240kB fullt optimerad och 440kB ej optimerad.
Vi använder MPLABX samt XC32 är detta normalt eller blir resultatet bättre om
man använder den gamla MPLAB8 ide'n eller C32 kompilatorn???

Hmm, hur i helsike får ni ihop det till den mängden kod.

Vi har grafik (QVGA, 320x240), IP-Stack Webserver, RTOS, Modbus, FAT mm, vi fyller inte ens halva processorn, vad jag vill minnas, med o-optimerad kod.

[tmst]

Jo man kan undra hur koden blivit så stor!

Vi har ett meny system med ca: 120 olika meny lägen realiserat enligt Microchips
teknik med (enum och case snurror) som man använder i sina demoprojekt.
vi använder 2 com-portar samt USB både i host och device mode
De texter och grafiska bilder vi använder ligger i det externa flash minnet

Vår ursprungliga projekt i Pic24:an kan idag utökas med mer kod trots att vi
använder full optimering. I och med detta är systemet svårt att underhålla då det nu är ganska
svårt att debugga (vi har inte gjort projektet i egen regi från början utan vi ska ta över det nu)

Frågan nu är att det faktum att vi byter från 16 till 32 bitars system kan få en sådan här effekt?
Sedan är det väl bra med en effektiv optimering, men det skapar problem då debug funktionen inte
fungerar med optimerad kod, eller kan det var någon missuppfatning bakom redovisat resonemang?

Det vi ser är att man inte använder sig av lib filer, kan man skapa sådana här själv och göra dem med
full optimering medan andra källkods filer körs utan optimering?

[TomasL]

Det är helt korrekt att man inte kan debugga optimerad kod.

Nu vet jag iofs inte hur mycket US drar, men jag tror att ni får kika närmare på er kod, framför allt menyerna kanske.

Beroende på hur menyerna ser ut och fungerar, svårt att veta, vi har väl nått liknande i vårt system. dock ligger våra texter i ROM.

[Icecap]

"... att vi byter från 16 till 32 bitars system kan få en sådan här effekt?"
Vilken effekt? Code-bloating?

[sodjan]

> ...att koden blir 240kB fullt optimerad och 440kB ej optimerad.
> ...det faktum att vi byter från 16 till 32 bitars system kan få en sådan här effekt?

Hela diskussionen blir lite ointressant om vi inte vet hur stor
koden var/är i PIC24'an.

Och ja, kod växer generellt mer eller mindre vid större native ordlängd.
Exakt hur mycket är svårt att säga, men upp till en dubblering mätt
i "bytes" är inte onormalt. Och det är inte "code-bloating" i sig.

[Rick81]

Enda sättet att svara på vad det är som tar mycket plats är att kolla i hur kompilator hur fördelat olika funktioner flashet. Det brukar gå att hitta i .map filen som kompilatorn bygger.

[henkebenke]

Misstänker att du har en hel del pekare till dina strängar. Beroende på hur adressrymden skiljer sig från PIC24 till PIC32 (har ingen aning) och minnesmodell som används så kan kodstorleken dra iväg ordentligt. Men för att reda ut det behöver man känna till hur kompilatorn fungerar. Sen behöver inte optimering göra att koden blir totalt odebugbar, men det beror på kvaliteten på kompilatorn.

[tmst]

Från Sodjan
> ...att koden blir 240kB fullt optimerad och 440kB ej optimerad.
> ...det faktum att vi byter från 16 till 32 bitars system kan få en sådan här effekt?

Hela diskussionen blir lite ointressant om vi inte vet hur stor
koden var/är i PIC24'an.

Visst är det så !!
koden Pic24:an ej optimerat kan jag ej se då denna inte får plats!
Enda sättet att få in koden är att optimera med max inställningen "s"
och då har vi ca: 10-15 kB kvar av pic24:ans 256kB

[sodjan]

OK.

Vad är det som har växt i så fall?
Som jag läser det nu är koden alltså:
Ca 240 KB i PIC24
Ca 240 KB i PIC32

Jag fattar nada...

[Mupp]

Känner för att lägga näsan i blöt...

...
efter att gjort drygt halva jobbet inser vi att koden blir 240kB fullt optimerad och 440kB ej optimerad.
...

[Icecap]

Nu är det jag inte riktigt fattar vad problemet är. µC'n ska uppgraderas av någon anledning, programmet får plats om det optimeras nog - så vad är problemet?
* Ska det läggas till funktioner och minnet då inte räcker till?
- Välj då en processor med mer minne. Finns det ingen med mer minne har ni vald fel från början.

Rent generellt är det så att en µC exekverar minst ett programord åt gången. Är det en 16 bit µC är minsta programord på 2 bytes, är det en 32 bit µC är minsta programord på 4 bytes. En "rak översättning" betyder alltså att själva programmet blir dubblat räknat i bytes, detta är anledningen till att Microchip anger programminne dels som bytes men även som programord.

Har man alltså en 16 bit µC med 256k programord betyder det att programminnet är på 512kB. Att byta ut till en 32 bit µC och fortfarande välja en modell med 512kB gör ju plötsligt att programorden "bara" är 128k, alltså effektivt en halvering av plats för <program>. Konstanter är nog ganska likt till byte-storleken skulle jag tro.