[AVR] Extern interrupt, men omvänd?

[E85]

Nej det blir inte samma men samma princip används när man räknar fast du byter ut OR mot AND:

00010101 & 00110110 blir

0 AND 0 = 0
0 AND 0 = 0
0 AND 1 = 0
1 AND 1 = 1
0 AND 0 = 0
1 AND 1 = 1
0 AND 1 = 0
1 AND 0 = 0

Alltså 00010101 & 00110110 = 00010100

[toffie]

Ja så dum jag är, när jag tänker på det så låter det ju inte helt fel
Men om vi kopplar det till MUX2 då, då blir det alltså pinne 2 och då blir det 00000100.
MUX2 är bara en "förkortning" för 00000100?

Ungefär som hex värdet 0x04?

Just uträkningarna kan jag väl göra i en vanlig C kompilator på datorn också? Så kanske jag kan testa och se vad som
händer där och om möjligt kanske lära mig det här

[E85]

Nope, det är där det börjar bli lite komplicerat. MUX2 är siffran 2 (0x02, 0b00000010) eftersom MUX2 är tredje biten i ADMUX-registret (börjar räkna från 0), så för att konvertera det så det går att göra en bitwise-operation skriver man (1 << MUX2) som är 0b00000100 (0x04). Vad du får pinne ifrån vet jag inte men det här har inget med pinnar att göra iaf.

[toffie]

Ah, jag tänkte på en "port", därför skrev jag pinne, lite fel av mig

Men börjar man inte räkna hex med 1? Dvs. 1, 2, 4, 8?
Eller gäller inte det för register, är det istället 0,1,2,3?

Jag får nog ta och läsa på mer om decimal, hex och binära tal.

1 << MUX2, det betyder ju att man flyttar värdet åt vänster inte sant? Det tror jag att jag läst någonstans.
Men betyder det att man flyttar med 1 steg då? Eller är det alltid 1 som ska stå där?

Går det även att göra tvärtom, >> så man flyttar åt höger?

[E85]

Det är ettan som står först du flyttar, alltså 0b00000001 skiftas MUX2 (2) steg till vänster.

[bos]

MUX2 är siffran 2 (0x02, 0b00000010) eftersom MUX2 är tredje biten i ADMUX-registret (börjar räkna från 0), så för att konvertera det så det går att göra en bitwise-operation skriver man (1 << MUX2) som är 0b00000100 (0x04).

Är det här det enda sättet i AVR att komma åt bitpositioner genom att göra såna obskyra operationer? Har inte AVR något för att testa enskilda bitar?

[Nerre]

Visst har AVR funktioner för att testa och manipulera enskilda bitar, det sätt att koda som är beskrivet här handlar ju om hur man jobbar med bitmaskar och är oftast betydligt mer flexibelt.

Ska du t.ex. sätta 3 bitar så är en AND-operation mycket snabbare än tre bitoperationer.

[Icecap]

Och sedan en liten fundering:
Som jag förstod var detta till ett larm (i någon form) och interrupt i all ära men det är fel att använda här!
Orsaken är att om larmet är utlöst och man startar processorn kommer detta interrupt sannolikt aldrig att utlösas, det är ju flanken som trigger och den har ju redan varit under strömavbrottet så att säga.

Detta betyder att man under uppstartsfasen ska polla signalen och reagera enl. detta värde varefter man aktiverar interrupten och min erfarenhet är att man inte använder interrupt på signaler man måste polla, det blir bara pannkaka av det.

[bos]

Ska du t.ex. sätta 3 bitar så är en AND-operation mycket snabbare än tre bitoperationer.

Javisst, men som det är skrivet tidigare i den här tråden:

Kod: Markera allt

// Enable ADC
ADCSRA = (1<<ADEN);

// Select ADC0
ADMUX |= (0<<MUX0);

Att hålla på med sånt där bitskiftande för en enda bit tycker iallafall jag sabbar läsbarheten fullkomligt. Det verkar dock vara kutymt och standard i AVR-världen att göra sådär så för "er" sitter det väl i ryggraden, men för min del är det på snudd till oläsligt.

[Nerre]

Fördelen med sån kod är att den alltid funkar, den är inte beroende av särskilda bitfunktioner.
Särskilt när man definierar konstanter är den väldigt praktisk.

[bos]

Är det du säger samma som att AVR-MCU:erna inte har hårdvaruoperationer för att testa/sätta bitar? Annars förstår jag inte vad du menar med att vara beroende av "särskilda bitfunktioner". Det låter som att du säger att de bitmanipulatorer AVR har är mjukvaruimplementerade, men jag kan förstås tolka dig fel.

[Nerre]

Jag pratar om portabel kod.

Sen är det så att AVR har olika instruktioner för var det är man vill ändra bitarna.

http://www.atmel.com/dyn/resources/prod ... oc0856.pdf

BCLR/BSET för SREG
SBI/CBI för I/O
SBR/CBR för register

[bos]

På så vis. SBR/CBR verkar dock kunna sätta/rensa flera bitar samtidigt, vilket de andra operanderna inte kan. Det är förstås lite smutt att kunna göra så i en enda instruktion utan att själv böka med bitmaskar, fast rent spontant känns det lite konstigt att det finns tre olika operander beroende på vad för bitar man ska sätta, samt att bara en av dem klarar multipla bitar. Å andra sidan, hade jag själv jobbat med AVR hade jag säkert tyckt annorlunda.

Tack för svaren iallafall, nu vet jag varför bitmaskningarna ser ut som de gör i C-kod för AVR.

[Nerre]

Det har antagligen att göra med RISC-arktitekturen att det är olika instruktioner beroende på vad man hanterar.

Men sådär ser bitmaskning nästan alltid ut när man kodar i C, det är inget som är unikt för AVR.

[sodjan]

bos, du får kolla en gång till på instruktionerna och AVR arkitekturen.
Du har inte förstått varför det ser ut som det gör. Det har med att
en AVR har lite olika grupper av register som beroende på var de ligger
adresseras olika och med olika instruktioner.

SBR/SBR så jobbar de bara mot register med adress 16-31.
SBI/CBI däremot jobbar enbart mot register med adress 0-31.
BCLR/BSET jobbar *enbart* mot SREG (STATUS-registret på en PIC).

För övriga register över adress 31 ("RAM") är jag osäker på om det
går att göra bit-operationer alls, tror inte det.

> Det har antagligen att göra med RISC-arktitekturen....

Absolut inte, det är ett *avsteg* från RISC tanken !

Det har med att de (Atmel) inte har lyckats få till en linjär och homogen
adressering av register och RAM. PIC är ett exempel på en RISC arkitektur
där det är mer homogent, och den är mer "RISC" eftersom det är
färre instruktioner totalt...

På en PIC är det t.ex alltid BCF/BSF som används för bit operationer helt
oberoende på vilket register eller adress i "RAM" som det gäller inkl
STATUS registret (alltså inga separata BCLR/BSET instruktioner).