Nybörjare med AVR - försöker komma igång

[Johanb]

Visst är det en fin känsla även om det bara är en "Hello world"

[ronnylov]

Ja det var riktigt roligt!

Undrar vad nästa steg är? Får väl försöka skriva något eget litet program. Utforska det här med timers och avbrottsrutiner. Hur man använder ingångar och utgångar kan ju vara bra att kunna med. Jag har också skaffat mig en LCD-display som jag kan försöka skriva ut "Hello World!" till.

Bör man lära sig assembler också eller klarar man sig bra med bara C? Beror väl på vad man vill göra förstås men jag tänkte mer hur ni andra gör i praktiken.

Jag har ett projekt i tanke som jag så småningom ska föröka fixa. Det är att bygga en temperaturreglering till min golvvärme i hallen. Som det är nu är det bara en manuell strömbrytare med ON och OFF och ingen termostat så ibland blir det jättevarmt om man glömmer bort att stänga av den vid varmare väder eller så blir det jättekallt på vintern om man glömmer slå på den. Min AVR ska då styra något halvledarrelä i lämpliga intervaller för att reglera temperaturen. Detta är min motivation till att lära mig hur det hela fungerar. Visst kan man köpa något färdigt men jag vill lära mig göra det själv. Känns som jag kommit en bit på vägen bara att styra en lysdiod, därifrån är ju steget inte långt att styra halvledarreläet (är väl bara att koppla in det istället för lysdioden i princip). För det projektet lär jag knappast behöva assembler det är ju extremt långsamma förlopp som ska regleras.

[AndLi]

Du kommer klara dig bra med bara C, visst det kan vara bra med lite känsla för hur en µC funkar.. men det finns inget krav att kunna asm för att lyckas med C projekt. Tom rejält tidskritiska projekt(tidskrav på enstaka µs) går att få till med ren C.. Det handlar till mycket stor del hur du designar koden!

Jag blir förvånad om mitt inlägg inte kommer bli påhoppat och anses vara helt fel...

[jesse]

C är enklare. Och du lär dig processorn bra ändå. Även om du använder C så måste du ändå göra exakt samma saker som i assembler. Om du ska använda en perifer enhet eller en port (I/O) så gör du exakt samma saker:

Kod: Markera allt

;assembler kod - sätt PORTB:5 till etta:
in r16, PORTB  ; läs in tidigare värde på PORTB utgångar.
ori r16,0b00010000 ; bit 5 ettställs
out PORTB,r16 ;

och i C-kod:

Kod: Markera allt

PORTB |= 0b00010000; // sätt bit 5 till etta i PORTB

Det enda som skiljer är sättet att skriva det på.

Enda orsaken att använda assembler är om man är specifikt intresserad av hur man använder interna register, hur man adderar 16-bitars tal i en 8-bitars processor etc... Visserligen mycket lärorikt om man vill förstå det binära talsystemet och hur det är uppbyggt, men kan man det (vilket man bör kunna även om man ska jobba i C!) så ger inte assembler så mycket extra visdom.

Addera ett 16-bitars tal:

Kod: Markera allt

; assembler
; tal A finns i registren r20:r21 (låg : hög)
; tal B finns i registren r22:r23 (låg:hög)
; resultatet återfinns i A (r20:r21)
add r20,r22 ; addera först de låga byten
adc r21,r23 ; addera höga byten och ta med 'carry' från förra operationen

motsvarar i C:

Kod: Markera allt

uint16_t A;
uint16_t B;

A = A+ B;

Viktiga processoroperationen som används ofta i microcontrollers men mer sällan i 'vanliga' program är de bitvisa operatorerna samt shiftoperatorerna:

Kod: Markera allt

A = B | C; // bitvis eller (or)
A = B & C; // bitvis och (and)
A = B ^ C // bitvis exklusive eller (exor)
A = ~B; // bitvis icke (not) = inverterar alla bitar

// shift

A = B << 4 ; // shifta talet B 4 steg åt vänster
A = B >> C ; // shifta talet B, C steg åt höger

EDIT: skrivfel

[AndLi]

jesse: A = B << 4 ; // shifta talet B 5 steg åt vänster

Jag skulle vilja påstå att den skiftar det 4 steg åt vänster...

0b0000 0001 blir 0b0001 0000

[jesse]

hm.. ibland glömmer man korrekturläsa...
jag ändrar.

0x04 blir 0x40

[Johanb]

Du klarar dig nog fint med C, kör du fast kan du alltid läsa in dig på asm. Ett tips är att lära sig använda UART för debuggning, det är väldigt praktiskt att kunna skriva in tex UDRx=y; på strategiska ställen för att sedan kunna följa exekveringen i en serieterminal.

[ronnylov]

Då kör jag på C, det blir nog bra.

Man behöver väl någon adapter för att ansluta UART till datorns serieport? Kommer nog att använda min netbook en del när jag labbar (den är ju relativt portabel) och den har nog inte ens någon serieport. Men det kanske är något man kan bygga själv, UART till USB adapter? Annars finns det väl på ebay som allt annat misstänker jag.

[jesse]

>>> UDRx=y; på strategiska ställen

Det var inte så bra. Om du råkar utföra detta innan tecknet innan sänts färdigt så blir det ju kaos. Gör istället en liten funktion som väntar på att USART-enheten är klar först.

[Johanb]

jesse:
Ja det normala är en loop som tittar på om UDRx (UDREx) är redo för nytt tecken men nu var inte poängen att skriva ett komplett program utan bara att nämna kraften i att använda UART som debug-verktyg i brist på annan utdata.
För övrigt är det en bedömningsfråga, ibland vet man att det förflutit tillräcklig tid för att UDRx ska vara tömd, ibland har man inte skickat något innan, ibland har man bara skickat ett tecken innan vilket betyder att skift-registret plockat över det tecknet och att UDRx kan skrivas till igen så gott som omedelbart. Och för att ytterligare förtydliga så handlar det alltså inte om release-kod utan tex ifall man kör fast och inte riktigt vet om programmet tar vägen in i en rutin eller hoppar förbi, då går det väldigt fort att skriva in UDRx=y;, spara, "make program" och titta på resultatet.
Jag har tex vid flera tillfällen haft nytta av att enbart ha en enda UDRx=y i hela programmet som man flyttar runt tills man hittar felet.

[jesse]

Just vid debugging är det ju extra viktigt att det faktiskt fungerar, annars vet man ju inte om det var progrmmet eller debuggningen som inte fungerade. En funktion PutChar('x'); är ju inte svårare att skriva in än UDREx = 'x'; så vet man att det fungerar.

[Johanb]

Jaja, du gör såklart som du vill, jag vill ha så lite inverkan på programexekveringen som möjligt och med buffrad TX så vet jag att jag klarar två byte innan jag ens behöver fundera över om jag skriver sönder något. Enkelt, en enda instruktion = en cykel jämfört med kanske 20-30 cykler i enbart overhead vid funktionsanrop. Det kräver visserligen att man har koll på sin kod men det handlar inte om att skriva ett helt kommunikationsprotokoll utan enbart att få en indikation på hur långt programmet exekverar eller vilken väg det tar.
För övrigt är UDREx en flagga (bit) i ett UCSRxy-register och kan inte användas som du beskriver det.

[jesse]

Men vad bra - då har vi två olika sätt man kan debugga på, med sina för - och nackdelar. Bara för TS att välja, beroende på situatuon.

[Nerre]

En rätt stor fördel med C är att man slipper hålla reda på vilka register som är upptagna till vad. Kompilatorn håller reda på det själv och använder register i första hand och minne bara om registren inte räcker till.

Det går ju dessutom att skriva inline assembler i C om man behöver för tidskritiska grejer eller om det är nåt som är svårare att få ihop i C. Men det finns makron och sånt i C för AVR som jag tror klarar allt man behöver.

[ronnylov]

Är det MAX232 man ska koppla mellan UART på AVR och serieporten på datorn? I kombination med en USB-RS232 adapter om datorn inte har serieport?

Sökte lite på MAX232 och hittade en krets som heter MAX3232ECPE till priset av 45 kronor på electrokit. Är det sådana ni brukar använda? Eller duger det med en MAX232CPE för 8,95 kr från swechtrading? Fast den billigare varianten kräver 5V och den dyrare kan köra ner till 3 Volt? Skiljer ju en del i pris mellan dem. Antar att man väljer den dyrare om man kör batteridrift och vill ha det strömsnålt, eller om man har långa kablar och vill ha bra skydd mot överspänningar.

Något tips på vettig USB till RS232 adapter till min netbook? Den ska funka stabilt i Linux.

Är det så här den ska kopplas in?
http://homepage.hispeed.ch/peterfleury/avr-uart.html
Det går alltså åt några kondensatorer också?
Vilken typ av kondensatorer ska man ha i så fall, duger det med elektrolyt?

Hittade en annan beskrivning: http://creativeelectron.net/blog/2010/0 ... l-atmega8/
Här ser man ett samband mellan klockfrekvensen och baudrate. I så fall bör man alltså välja en kristall som ger rätt baud rate på serieporten?