Från PIC till AVR - Bit instruktioner...

[bearing]

Förmodligen beror det på att de har ont om register som SBI/CBI/OUT/IN fungerar på.

[squiz3r]

Det var krångligare än vad jag trodde att gå från PIC till AVR!! Blir väll att fortsätta läsa i manualer...

Är det någon som har koll på vad motsvarande kommando för CBI och SBI är i C? (Använder AVRstudio med WinAVR).

[bearing]

Kod: Markera allt

    PORTB |=  (1<<5); // SBI PORTB, 5
    PORTB &= ~(1<<3); // CBI PORTB, 3

Med den här metoden behöver du inte tänka på om registret hanteras av SBI/CBI; om det inte gör det genereras LOAD, AND/OR, STORE-instruktioner istället.

[blueint]

Hur gör man ifall man vill sätta en bit till ett specifikt värde i assembler på AVR ..?
Krävs det att porten är "output" mode, och först därefter kan man sätta biten?, hoppas dessa inställningar är per bit och inte per port (8-bit).

Verkar som den bästa strategin är assembler för små PIC, och C för AVR.
Brytpunkten går någonstans vid 20 SEK inkl moms. Då AVR inte har något att konkurrera med i det prissegmentet. En hake med C är annars att det tar mer plats vilket kräver mer flash utrymmer, som kräver dyrare MCU.

[bearing]

Varför läser du inte bara i databladet?
SBI och CBI heter instruktionerna...
Det finns tre register som har med varje port att göra. PORTx, PINx och DDRx har jag för mig att det hette. Jag orkar inte förklara något som enkelt går att läsa om i databladet.

En 8-pins liten AVR kostar bara 10 kr.

[blueint]

Har mest hållt mig till kraftfullare maskiner och FPGA. Mest kollat vilka möjligheter som finns med MCU.

[sodjan]

> Krävs det att porten är "output" mode, och först därefter kan man sätta biten?

Av det som har skrivits tidigare så tolkar jag det som så att om porten/pinnen
är satt som "input" så kommer en skrivning till pinnen istället att påverka
den inbyggda pullup'en (i de fall där det finns sådan).

> hoppas dessa inställningar är per bit och inte per port (8-bit).

SBI/CBI påverkar så klart bara den bit som man anger.
Det vore ju väldigt märklingt annars...

[speakman]

En hake med C är annars att det tar mer plats vilket kräver mer flash utrymmer, som kräver dyrare MCU.

Det skulle jag absolut inte hålla med om. Skillnaden lär snarare vara försumbar då C i sig är rätt hårdvarunära (inga onödiga abstraktioner att täcka upp för) samt att kompilatorerna är ruskigt duktiga på att optimera koden (för hastighet eller för storlek, you choose).

Skulle det nångång krävas en extremt optimerad rutin så är det inline assembler som gäller för min del. Det är dock ytterst få tillfällen såna behov har uppstått.

[Nerre]

Ja när jag började försöka lära mig lite AVR så började jag med assembler. Sen på skoj så testade jag ju att skriva samma program i C. Första kompileringen blev det mycket större, men så insåg jag att den makefil jag utgått från inte hade nån optimering påslagen.

När jag slog på optimering så blev den kompilerade C-koden KORTARE än den assemblerkod jag hade skrivit. Kompilatorn gjorde nämligen ett par smartare manövrar än jag. Jag fick sätta den på lite lagom optimering för att få samma storlek på koden som när jag skrev det i assembler.


Då var det visserligen ett rätt simpelt program, det blinkade en lysdiod med en viss frekvens och räknade fyrabitars binär räknare på fyra lysdioder med en annan frekvens (dubbla timers och interrupt alltså).

Men just det att kompilatorn kan göra optimeringar "efter hand" så att säga. Kompilatorn kan ju se hur variablerna används och därmed kan den enkelt avgöra vilka av variablerna som är lämpligast att lägga i register. Kodar man i assembler så måste man ju i princip välja innan man börja vilka man vill ha i register och vilka som ska ligga i RAM. Och gör man lite ändringar i programmet så optimerar kompilatorn annorlunda nästa kompilering (eftersom variablerna används annorlunda).

Många kompilatorer kan ju också ta hänsyn till pipeline-designen och göra operation "i fel ordning" för att snabba upp. Visst kan man göra sånt i assembler, men det är inte alltid man ser var det skulle gå att göra. Kompilatorn gör inga såna missar.

[jesse]

>Krävs det att porten är "output" mode, och först därefter kan man sätta biten?

Nej, du kan sätta biten först och sedan sätta riktningen på porten. Alla portar nollställs vide reset (jag talar nu om I/O), dvs. DDRx och PORTx gör pinnarna till input utan pull-up. Om du då vill börja med att ha en etta ut bör du inte först göra porten till utgång -då får du ju en nolla ut innan du hinner sätta ettan. (den varar ju bara en mikrosekund eller så, men ändå).

[SvenW]

Håller med Nerre om att optimeringen i C på AVR är ruskigt effektiv.
Jag kan inte heller skriva assembler som är lika effektiv som optimerad C. Men det är lurigt att köra debuggern på ett optimerat program. Den kan stryka hela programmet bara för att man glömt sätta en enda liten utgång!
Men den stora skillnaden är när programmet blir stort. Ett assemblerprogram på över hundra rader och det blir tvärstopp i huvudet. Man kommer inte vidare. Vet inte om det är individuellt, det kanske finns programmerare som klarar detta, men inte jag!

[Nerre]

Den kan stryka hela programmet bara för att man glömt sätta en enda liten utgång!

Jo, nåt liknande råkade jag ut. En variabel kom inte med alls. Jag minns inte exakt varför, men den blev helt enkelt bortoptimerad för att den inte behövdes. Jag tror det kan ha varit så att den räknade upp en av interruptrutin, men interruptrutinen ser kompilatorn som att det är en funktion som aldrig körs, så den tyckte att variabeln var ju noll hela tiden och då kunde den använda noll-registret istället.

Jag hade alltså troligen glömt deklarera den som volatile.

[sodjan]

> Nej, du kan sätta biten först och sedan sätta riktningen på porten.

Det stämmer inte med vad som tidigare har både skrivits i tråden och citerats
från AVR datablad. I alla fall inte på alla AVR modeller.

> Det skulle jag absolut inte hålla med om [att C program alltid tar större plats än motsvaranmde i ASM...]

Inte jag heller, men...

> Skillnaden lär snarare vara försumbar då C i sig är rätt hårdvarunära...

Det förutsätter dock att man *skriver* hårdvarunära kod och undviker färdiga lib'ar
som länkar in "onödig" kod. printf() är väl det typiska exemplet på detta.

[Nerre]

Men vem använder printf() på en AVR? Det förutsätter ju först och främst att det finns en definierad stdout, och det gör det väl knappast om man inte har kodat en?


Sen vet jag att jag just har läst i nåt datablad just detta att om man ska ha en utgång hög så ska man sätta värdet först och sen riktningen, just för att den inte skall vara låg ett kort ögonblick.

Visst, att skriva 1 på den när den är ingång kanske aktiverar pull-up. Och vad gör pull-up? Jo, det gör att ingången blir hög om den inte lastas med nåt.

[Swech]

Men den stora skillnaden är när programmet blir stort. Ett assemblerprogram på över hundra rader och det blir tvärstopp i huvudet. Man kommer inte vidare. Vet inte om det är individuellt, det kanske finns programmerare som klarar detta, men inte jag!

Det går om det är bra struktur.
Programmet jag pysslar med idag är över 4000 rader assembler.
Men då skall man kommentera bra och inte hålla på med en massa trix
som man inte fattar efteråt. Det som tar längst tid är att underhålla program,
inte att skriva dem....

Swech