Svenska ElektronikForumet

Tjena.
Jag har hållit på med PIC'ar nu ett bra tag (änsålänge bara med 12F, 16F och 18F, så jag har planer på att testa PIC32 också ), och nu fick jag låna en Orangutan X2 (Som är i princip ett väldigt välutrustat labbkort för AVR). Det består av en AtMega644 och en slavprocessor (AtMega168) som är färdigprogrammerad, så att man skickar instruktioner via SPI till den (Den fungerar även som programmerare över USB via en USB-RS232 krets), och sen finns där en 4*20 raders LCD (HD44780) samt en H-brygga, 2 * 30A. Så nu tänkte jag börja labba med den, men först läste jag lite manualer, och några tuturials för AVR... Efter ett tag kom jag fram till att i tutorialerna ställde dem inte enskilda bitar på utgångarna med read-write-modify instruktioner, utan med eget hemmagjort krafs (dvs. använda logiska operatorer som bitwise AND, OR m.m.) som dem lade in som funktioner eller macron (då krävdes två macron för varje IO pinne...). Så jag tänkte "Då är det bara för att man ska lära sig grunderna först..." och började googla på det. Då kom jag in på AVR-freaks (heter den väll?) där någon hade ställt exakt den frågan. Då hade han fått till svar att det var så man skulle göra (med logiska operatorer). Vid detta tillfället hade jag börjat tycka att AVR va helt okej, men när jag fick reda på detta tänkte jag "Vilket skräp!! Sånt mög kan man ju inte hålla på med.." .

Men efter lite letande i databladet för AtMega644 hittade jag detta:

All AVR ports have true Read-Modify-Write functionality when used as general digital I/O ports.
This means that the direction of one port pin can be changed without unintentionally changing
the direction of any other pin with the SBI and CBI instructions. The same applies when changing
drive value (if configured as output) or enabling/disabling of pull-up resistors (if configured as
input).

Är det jag som är korkad (helkorkad!) eller är detta samma sak som BSF och BCF för PIC? Varför påstår dem då något annat på AVR forumet?? Är det bara på IO pinnarna (och sakerna nämnda i quoten) som man kan använda dem instruktionerna på?

Mvh. (förvirrad) Danne...

Nä det är inte du som är korkad!

En gång i tiden hade inte alla processorer operationer för att hantera bitvis manipulation utan man ändrade hela porten med hjälp av logiska operationer. Det finns väl fortfarande tillfällen när det är fördelaktigare att manipulera hela porten än att ändra bit för bit.

Om detta va ett sånt fall du råkade ut för eller om det var någon av den gamla skolan som inte hängt med i svängarna låter jag vara osagt. AVR-freaks är ju ett forum som alla andra forum och allt som sägs där är väl inte alla ggr heltäckande. Men det finns mycket bra information om AVR där normalt sett.

Det är ett bök med en del instruktioner eftersom de inte verkar på alla adresser utan i vissa fall bara på register och portar. Vågar inte jämföra med PIC då jag inte är bekanta med dessa.

I t.e.x http://www.atmel.com/dyn/resources/prod ... oc2466.pdf står det att:

The CBI and SBI instructions work with registers $00 to $1F only

> This means that the direction of one port pin can be changed without
> unintentionally changing the direction of any other pin with the SBI and CBI instructions.

Det är samma sak som att göra BCF/BSF mot TRISx registren.

> The same applies when changing drive value (if configured as output)

Samma sak som BCF/BSF mot PORTx (eller LATx på PIC18) registren.

Du får kolla lite närmare, notera att på AVR så fungerar inte alla instruktioner
(t.ex SBI/CBI) mot alla register (som du är van av från PIC), utan vissa instruktioner
fungerar bara mot vissa adress-areor. Sen att samma register kan ligga innanför
eller utanför denna area mellan olika AVR modeller gör att det inte gäller generellt.

Jag minns inte exakt hur det var med SBI/CBI, men det kan mycket väl vara så att
dessa bara fungera mot ett sub-set av registren och mot de andra finns det ingen
motsvarande "bit-instruktion", så där får du läsa sannolikt registret, ändra biten och
skriva tillbaka.

Det finns macron dokumenterade i AVR assembler manualen som automatiskt lägger
in den alternativa instruktionen som fungerar mot "de andra" registren. Men det var
(om jag minns rätt) inte för just SBI/CBI...

EDIT: Som Mr M just han imellan med...

Man kan generellt säga att alla portar både ingångar PINx och utgångar PORTx samt riktning DDRx
finns i dessa understa 32 adresser. Det brukar därför inte vara något problem
att kunna köra dessa instruktioner då man oftast kör mot just portarna.

Du behöver inte heller vara rädd för att portarna kan ställa om sig som de kan (kunde) på PIC eftersom
ugångar och ingångar på en port har separata register / adresser. Jag vet att förr
kunde man få problem om man körde en read modify write på PIC då den vid read läste av portens
värde och kunde därför modifiera pinnen av misstag. (Yttre last ställde om pinnen)
Detta har man kanske rättat till på PIC nuförtiden?

Du kan också glömma bort allt vad bankar heter eftersom det inte finns.
Titta även på X,Y och inte minst Z registret. Dessa är också kul och nyttiga.

Ytterligare ett råd. Det finns 32 register, motsvarande endast 1 st W hos PIC
Var inte rädd för att använda flera i samma subrutin. Har sett exempel där man
i det närmaste sliter ut stackars R16 medans alla andra register förblir oanvända.


Swech

I det aktuella fallet där någon på forumet hade problem så har jag för mig
att det var ett controll-register till ADC eller kanske USART som hade flyttats
över gränsen vid bute av AVR modell och som fixk koden att krasha. Jag minns
dock inte om det var just CBI/SBI eller om det var någon annan instruktion
med samma begränsning.

> Jag vet att förr kunde man få problem om man körde en read modify write på PIC...
> Detta har man kanske rättat till på PIC nuförtiden?

På PIC18 finns separata register ("output latch", LATx) som kommer runt detta.
Så även på den nya serien PIC16 som kommer under våren (?). Det här är bara
ett problem under speciella omständigheter och uppträder ganska sällan.

> Ytterligare ett råd. Det finns 32 register, motsvarande endast 1 st W hos PIC

Men å andra sidan så fungerar hela PIC'en minne i princip som AVR'ens 16 "register"
(inte fullt ut, men i stort). Det "RAM" som finns i AVR är mera som ett separat extraminne,
d.v.s att man inte kan använda "register" och "RAM" på samma sätt. På PIC kan man använda
alla instruktioner över hela minnet. Om du har en PIC med ett par 100 byte RAM så fungerar
alltid t.ex bit-instruktioner mot *hela* minnet, inte bara adresserna $00 - $1F...

Skit samma, det finns olikheter i arkitekturen, och det är bara att läsa på.
I slutänden uppnår man sannolikt samma resultat i alla fall...

på AVR så fungerar inte alla instruktioner
(t.ex SBI/CBI) mot alla register (som du är van av från PIC), utan vissa instruktioner
fungerar bara mot vissa adress-areor

Nu gillar jag inte AVR längre...

Nu ska jag sova!

> Nu gillar jag inte AVR längre...

Nja, så hårt får du inte ta det. De är säkert väldigt bra på *något*...

Det finns en dokument hos Atmel (doc0856) som ganska bra visar skillanderna mellan olika adresseringar :
http://www.atmel.com/atmel/acrobat/doc0856.pdf

"Register Addressing", vanligast och fungerar mot de lägsta 32 adresserna.
Här finns de flesta vanliga instruktioner, logiska, bit-test, shift/rotate, aritmetiska o.s.v

"I/O Direct Addressing", fungerar mot de lägsta 64 adresserna.
Här finns *visa* logiska instruktioner (CBI/SBI t.ex)) men t.ex inte shift/rotate/add/sub/and/or o.s.v.

"Data Addressing", fungerar mot hela "RAM" minnet (och är alltid en 2 words instruction).
Här finns i princip bara "load/store" instruktioner. D.v.s att man alltid måste "flytta ner" värden
från adresser > 63 (decimalt) till register för att göra någonting med dom. "The extended I/O memory from
address 64 to 255 can only be reached by data addressing, not I/O addressing."
(Och här är väl skillnaden mot PIC som störst, på en PIC fungerar som sagt alla instruktioner mot *alla* adresser...)

Man måste tänka på olika sätt beroende på familj. Om man vill skriva program på AVR på
samma sätt som på PIC så blir det besvärligt, (och vice versa)
På en PIC lägger man t.ex. loopräknare i RAM och kan köra INC /DEC mm direkt mot dessa.
Försöker man göra samma sak på AVR så blir det stopp eftersom RAM inte är tänkt att användas så.
Men man har istället sina 32 register som man kan ha till loopräknare.

Anledningen att AVR är som den är ibland är att den är optimerad för användning av högnivåspråk (eller C iallafall). PIC ter sig nog lite enklare att koda med assembler vilket kanske är att föredra när man ska lära sig arkitekturen, men kan man den redan hyfsat så saknar man inte mycket på C-nivå.

Därför skiljer det sig nog också i vilken "modell" man kodar mellan AVR och PIC. Men att båda i princip är likvärdiga har vi redan avhandlat för många gånger.

Studerar man instruktionerna i dokumentet som var länkat till ovan, så står det ju exakt vad som händer. Dock finns det en funktion i själva portarna som inte framgår av det dokumentet: normalt används registret PINx för att läsa av ingångarna, t.ex. IN r16,PINB. Menman kan använda PIN för att toggla utgångarna också!

Så istället för:
kan man skriva enbart: Risken med att först läsa av en port och sedan skicka tillbaka samma värde kan vara ödesdigert om porten innehåller ingångar som har aktiverade pull-up-motstånd - om man läser in värdet på en sådan ingång och den råkar vara noll - och du skriver det till den bit som är programmerad som ingång så avaktiveras pull-up motståndet vilket kan ge märkliga effekter!

(när man konfigurerar en ingång ställer man först DDRx till '0', sedan kan man aktivera pull-up motståndet genom att ge ut en etta på PORTx)

Krångligt? När man väl lärt sig är det inga problem. AVR är kul.

Det är bara de modernaste kretsarna som kan toggla med hjälp av PIN-registret.

jesse, Hur kan en "OUT" toggla?, den skriver väl bara värderna som man angett till utgången och inget annat?

Han skriver till ingången. Istället för att lägga in ett Toggle-register har Atmel gjort att ingångarna, som tidigare bara var läsbara, är skrivbara och alltså togglar utgången.

Det var ju genomskådligt och bra.... eller något.

Nåväl, kan ju vara bra när man ska blinka en LED.