Det största skillnaden är att AVR arkitekturen är mer splittrad och uppdelad
i olika roller/funktioner. En kompilator tar så klart hand om detta och det
är väl därför som AVR generellt inte anses speciellt "assembler-vänlig".
Om du har för avsikt att fortsätta med mindre applikationer till största
delen skriva i assembler, och du redan är "inkörd" på PIC arkitekturen,
så har jag väldigt svårt att se vad du vinner med ett byte till AVR.
Det som processorerna *i sig* kan göra skiljer inte något nämnvärt.
Om du däremot tänker att till största delen gå över till programmering i C
så är det kanske så att AVR har fler och kanske bättre alternativ
när det gäller fria/billiga kompilator alternativ.
Så de punkter som jag har sammanställt nedan fokuserar på själva AVR
arkitekturen och gäller naturligstvis alltid men de är sannolikt mer "intressanta"
för den som programmerar i assembler än för den som programmerar i C...
En sak som du först kommer att se (speciellt om du kommer från PIC
arkitekturen) är hur "minnet" är uppdelat på olika sätt. När man kommer
från en PIC som har (t.ex) 256 bytes "RAM", så är man van vid att
alla instruktioner fungerar utan undantag mot *hela* minnet. D.v.s alla
inc/dec, bit set/clear, bit test o.s.v. fungerar oavsett
var data
ligger i processorn.
Så är det inte i en AVR. Större delen av minnet ("SRAM") kan man i
princip inte göra mycket mer än att skriva och läsa till/från. Man måste
kopiera data till ett av de 32 "Register" för att göra något med datat
som inkluderar ALU-enheten.
Sen så är registerna i sig uppdelade i två halvor där flera instruktioner
(de flesta "---I" instruktioner med en konstant) fungerar bara mot R16-R31.
Utöver uppdelningen i "SRAM" resp "Register" så har du även "Ports" med
lite egna egenheter, de har t.ex egna "move" instruktioner (IN och OUT).
De har även egna bit set/clear instruktioner SBI/CBI, vilka inte är samma som
bit set/clear mot register SBR/CBR (varför göra det enkelt?). Dock kan
SBI/CBI enbart användas för vissa "portar" (med adress under hex"20",
igen, varför göra det enkelt?). Som sagt, en PIC har inte denna updelning,
alla register/RAM/kontrollregister o.s.v tillhör samma adressrymd och
alla instruktioner fungerar likadant mot allt oavsett vad det är.
Det var en tråd för något år sedan där någon hade flyttat AVR kod från
en processor till en annan och USART rutierna hade lagt av. Han använde
SBI/CBI för att konfigurera USART'en och i den ena låg USART'ens kontroll
register under hex'20' och på den andra över hex'20' och alltså la det av.
Som sagt, en PIC har inte denna updelning, alla register/RAM/kontrollregister
o.s.v tillhör samma adressrymd och alla instruktioner fungerar likadant mot
allt oavsett vad det är.
Sen så, om du vill använda index (pekare) mot SRAM, så används R26-R31
till detta (x, y och z) (PIC har separata dedikerade indexregister som inte
ligger i RAM). Om du använder alla indexregister så har du alltså 10 register
kvar (R16-R25) som kan använda alla ALU operationer direkt (igen, på en
PIC så kan alltså *hela* minnet användas till allt och av alla instruktioner).
Notera också att vid indexerad adressering så är allt man kan göra "Load"
och "Store" mellan det som x, y eller z "paker på" och ett register och det
använder speciella instruktioner (LD och ST) som enbart är för index-access.
(PIC kan dels göra alla operationer inkl add/sub, shift/rot, bit set/clr o.s.v.
direkt med indexerad adressering, dels av samma instruktioner "som vanligt".)
Uppdelning i "SRAM", "Register" och "Ports" är mer "hugget i sten" än den "bankning"
som brukar framföras som PIC'ars största problem. Men bankningen i en PIC fungerar
hela tiden likadant mot hela minnet och det finns enkla metoder att hantera det.
Det begränsar inte funktionalliteten för olika delar av minnet på något sätt (så
som t.ex SRAM/Regs/Ports uppdelningen i en AVR gör).
Om nu bankningen verkligen hade varit ett jätteproblem så hade de ju
knappast ökat antalet banker från 4 till 32 i nya PICs...
Slutligen så finns det en del fördelar i AVR arkitekturen som t.ex vektoriserade
interrupt. Du får väl som om det väger tillräckligt tungt.