Svenska ElektronikForumet

absolut... omröstning!

Synd att de inte hade samma kodexempel i alla stilar... det blir inte direkt lätt att jämföra läsbarhet då.

Så någon (no no, inte jag!) borde skriva ett mycket kort program och sedan göra ett antal likadana kopior med olika stil, så kan vi rösta ...

Jag kör hårt med Whitesmiths style och en omröstning är ung. som att rösta på vad som smakar bäst: kaffe, te, choklad. Det är mig totalt likgiltigt vad ni andra röstar, jag gillar ÄNDÅ vad jag gillar varför en omröstning är total onödig.

Självklart är den onödig! Det är bara för nöjet att få rösta, bråka med de andra om hur de röstade fel osv... dev. ren underhållning. ungefär på samma nivå som detta.

Lite mer än ren underhållning. Ett klart utslag kanske frälser människor från att trilla ner i Whitesmiths-stilen

haha
Jag tror jag ligger närmast K&R style.

Ett stort JAtill K&R style, men usch och fy till Whitesmiths och GNU.
Whitesmiths style och GNU style borde förbjudas enligt lag!

Jag kör med Allman style eftersom jag vant mig vid det i Visual Studio och tycker det ser bäst ut.

Nåja... ska vi fortsätta tjata om stilar får det bli en ny tråd. Nu mer om C...

Det är svårt att simulera program som innehåller test av flaggor som inte stöds av simulatorn och med fördröjningar överallt som gör att simuleringen tar flera minuter... så jag har lagt in följande i början av programmet: När jag ska programmera kretsen så sätter jag bara // framför första raden så går programmet som önskat.

Intressanta upptäckter kring optimering av kod

Tog mitt mest komplexa program, tog bort alla "delay" och körde det med olika optimeringar. Trodde att det skulle gå fortare att köra koden i processorn om den var optimerad, men för det mesta blev det tvärt om: optimeringen påverkade bara kodstorleken positivt:
Det går väldigt långsamt när optimerigen är påslagen. Os tar mer än 4 gånger så lång tid att köra än -O1
Nu är det inte den perfekta koden att testa på, då UART:en tar en fix tid att sända. Jag skickar ca 80 tecken, vilket borde ta 47 mS - alltså den mesta tiden i ooptimerad kod. Resten av programmet manipulerar en himla massa data ... Vad sjutton den sysslar med när den är optimerad som tar sån tid ska jag försöka ta reda på...

Måste vara någon bugg i de senare optimeringarna. Minns att jag läst någonstans att avr-gcc-optimeringen över en viss nivå har buggar.

Verkar vara något fel på simulatorn. Den ger toklånga tider första gången man kör den efter att ha kompilerat om (fast bara ibland ). Nästa gång blir det mer normala tider. Så min statistik ovan var alltså felaktig. Dock stämmer ju kodstorleken. -O3 gör om alla "enkla" funktioner till kodsnuttar istället - och mitt program består nästan bara av massor av små funktioner... därför sväller koden.

Bra att höra. Kan ju hända att den som skrev om buggarna själv gjorde samma misstag, eller helt enkelt hade kodat fel (utan volatile där det behövs, o.s.v.).

Varför tar det lång tid? någon loop som går runt?

Eftersom det var svårt att upprepa det hela så tröttnade jag på att försöka kolla orsaken. Jag nöjer mig med att tiderna blev "normala" när simulatorn väl fungerade som den skulle.

Vilken simulator använder du? Hur mäter du tiderna?

AVR Studio4.16 med "AVR simulator 1, 0, 2, 1". Det finns en "AVR simulator 2" också, men den är ännu sämre i vissa lägen (saknar vissa funktioner). Det var en allvarlig bugg i AVR Studio 4.17 så jag behöll 4.16. Men jag har hört att det har kommit en 4.18, orkar bara inte krångla med att avinstallera / installera igen.