Svenska ElektronikForumet

Jag antar att du har en hel del annan kod också? För enbart 1-wire-rutinerna kan inte uppta 2kB minne, eller hur?

Eftersom du är rätt ny på C så finns det säkert en hel del som går att skriva effektivare.

En DS18S20 handlar ju om temperaturer, och är man lite ovan vid
C och microcontrollers är det ganska lätt att lägga värdet
i en float, vilket brukar få koden att svälla en del...

Inge aning om det är det, bara en tanke...

Jag har ju LCD-grejor också, och därmed ett gäng delaysaker, inte så mycket annat.

Har inte skrivit koden för att konvertera värdet man får till riktig temperatur, så jag har ingen float. Det är bara för att läsa av och LCD-grejorna.

Du kan kolla på den asm-kod som genereras och se om det är något som tar väldigt stor plats.

Jag skrev samma som du gör, dvs ds1820 och lcd till en at90s2313 i assembler för länge sen, och det tog inte stor plats så det måste vara något som inte kompileras som du tänkt.

Nej det är lite skumt, det tycks som att även den enklaste av funktioner tar onödigt stor plats så fort man ska skriva i C.
Börjar ångra att jag övergav assembler.

Låter som ett problem jag stötte på för ett tag sedan. Använde några flyttal för att specificera en delay (_delay_ms använder float, dumt nog!).
Så länge jag använde konstanter gick det bra, men försökte jag ge mig på en liten simpel dividering i koden, så stenvägra programmeringen av kretsen fungera (avrdude). Kompileringen gick dock toppen, konstigt nog, trots att rätt uC angavs!

Sedan SKA inte C generera onödigt mycket kod, så det måste nästan bero på något annat...

Mvh
speakman

Kör du med någon optimering påslagen, t ex "-Os"?

Du får gärna ge ett exempel på C-kod och motsvarande Asm-kod som du tycker blir för stor.

Jag har gjort en cykeldator i C till en AT90S2313 som visade hastighet, klocka, tidtagarur och temperatur (DS18S20) på en LCD-display. Det programmet tog 1.7kB. Och då går det säkert att optimera ännu mycket mera.

Oh, yes. Optimering kan vara bra också .
Den var inte på by default. Nu blir hex-filen för tillfället bara 1900B.

Det har väll inte så mycket med att göra att kompilatorn (i princip vilken
som helst, C, Pascal eller Basic från vilken tillverkare som helst)
genererar "onödigt mycket" kod. Den genererar oftast den kod som
"behövs" för att göra det som begärs av programmeraren.

Det har mer att göra med att man som programmerare (speciellt om
man är lite ovan med 3GL och microcontrollers) inte riktigt förstår
vilka konsekvenser det får när man gör val mellan olika sätt
att skriva koden. Det som ser lätt och "naturligt" ut i 3GL språket
(och som inte hade varit något problem på en annan plattform
som t.ex en PC), t.ex att köra en float där det igentligen inte behövs,
kan få oanade effekter...

Om man håller sig till 8/16 bitars integer variabler och undviker
allt för "tunga" funktioner, kanske kör lite direkt register manipulation
istället för färdiga funktioner o.s.v, så kan även C/Pascal/Basic bli
rellativt kompakta.