Tack för länkarna.
12F1xxx och 16F1xxx är ju betydligt förbättrade, men en del trassel med segmentering fortfarande.
Kan ju liksom 18F vara ett alternativ, eftersom kod från 12F/16F går lättare att skriva om, än till AVR.
ny på AVR
Re: ny på AVR
> ...men en del trassel med segmentering fortfarande.
Jo, minnet är fortfarande uppdelat i pages (nu 32 st istället för 4).
Men å andra sidan så är det genom nya instruktioner mindre problem
(och overhead) med det. Det finns dessutom en "linear data memory"
vilket ger en "rak" och kontinuerlig åtkomst till all RAM i processorn utan
banker eller liknande. Man kan t.ex skapa en buffer och köra auto
inc/decr med FSR registren över valfri del av *hela* minnet.
Sen så finns det alltid 16 bytes som en "unbanked" för de data som
man vill ha snabbast access till (ungefär som tidigare).
Viktigare är att alla instruktioner fungerar på exakt samma sätt mot
alla register och minnesadresser. Det finns andra arkitekturer där
vissa saker bara fungerar mot vissa adresser o.s.v, t.ex så
fungerar en del instruktioner som t.ex bit- set/clear operationer
bara ibland (mot vissa adressareor). Det är ett mycket större
"trassel" som inte går att komma runt utan att flytta runt sina
data mellan olika adresser. Men det är klart, de som är vana vid
att alltid göra det, upplever inte det heller som något problem...
Jo, minnet är fortfarande uppdelat i pages (nu 32 st istället för 4).
Men å andra sidan så är det genom nya instruktioner mindre problem
(och overhead) med det. Det finns dessutom en "linear data memory"
vilket ger en "rak" och kontinuerlig åtkomst till all RAM i processorn utan
banker eller liknande. Man kan t.ex skapa en buffer och köra auto
inc/decr med FSR registren över valfri del av *hela* minnet.
Sen så finns det alltid 16 bytes som en "unbanked" för de data som
man vill ha snabbast access till (ungefär som tidigare).
Viktigare är att alla instruktioner fungerar på exakt samma sätt mot
alla register och minnesadresser. Det finns andra arkitekturer där
vissa saker bara fungerar mot vissa adresser o.s.v, t.ex så
fungerar en del instruktioner som t.ex bit- set/clear operationer
bara ibland (mot vissa adressareor). Det är ett mycket större
"trassel" som inte går att komma runt utan att flytta runt sina
data mellan olika adresser. Men det är klart, de som är vana vid
att alltid göra det, upplever inte det heller som något problem...
Re: ny på AVR
Jag ska kolla på AVR, se om om fördelarna som "lyser" uppväger ev. nackdelar som kanske dyker upp.
Jag hittade en informativ sida för nybörjare på AVR:
http://www.avr-asm-tutorial.net/avr_en/ ... index.html
På den sidan hittade jag också ett program som genererar (mall) asm-filer:
http://www.avr-asm-download.de/avr_head.zip
Man anger processortyp och respektive .inc -fil, så får man en fil som man ha som grund vid
programmering.
Jag har nu lyckats assemblera och stega program i AVRstudio, behöver läsa på om instruktionsuppsättningen.
Jag hittade en informativ sida för nybörjare på AVR:
http://www.avr-asm-tutorial.net/avr_en/ ... index.html
På den sidan hittade jag också ett program som genererar (mall) asm-filer:
http://www.avr-asm-download.de/avr_head.zip
Man anger processortyp och respektive .inc -fil, så får man en fil som man ha som grund vid
programmering.
Jag har nu lyckats assemblera och stega program i AVRstudio, behöver läsa på om instruktionsuppsättningen.
Re: ny på AVR
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.
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.
Re: ny på AVR
Tack för intressant inlägg Sodjan, återkommer till denna tråd senare, hinner inte göra så mycket för tillfället.
-
Swech
- EF Sponsor
- Inlägg: 4750
- Blev medlem: 6 november 2006, 21:43:35
- Ort: Munkedal, Sverige (Sweden)
- Kontakt:
Re: ny på AVR
Följande kod initierar en AVR oavsett vart portar mm befinner sig i adressrymden.
Notera även att det är bara att lägga in fler portar och specialregister i listan. Inga
andra ställen behöver ändras så länge som listan avslutas med VOID.
Swech
Notera även att det är bara att lägga in fler portar och specialregister i listan. Inga
andra ställen behöver ändras så länge som listan avslutas med VOID.
Kod: Markera allt
.EQU VOID = -1
;--------------------------
; INIT PROC IO REGS
;--------------------------
INIT_REGS:
LDI ZL,LOW(INIT_LIST*2)
LDI ZH,HIGH(INIT_LIST*2)
INIT_L1:
LPM XL,Z+ ;XL:=REG INDEX NR OR 0
CPI XL,VOID ;VOID?
BREQ INIT_REG_DONE ;YES
LDI XH,0 ;CLEAR TOP X
CPI XL,$40 ;REG ADR > 64?
BRSH INIT_REG_SK1 ; YES, IT IS ABS DEFINED
SUBI XL,256-32 ;ELSE ADD 32 AS REGBASE
INIT_REG_SK1:
LPM R0,Z+ ;R0:=VALUE TO INIT WITH
ST X,R0 ;SAVE INIT VALUE
RJMP INIT_L1 ;AGAIN
INIT_REG_DONE:
RET ;OK
INIT_LIST:
; IO REG, DATA
.DB DDRA,DIR_A ;PORT A
.DB PORTA,DATA_A
.DB DDRB,DIR_B ;PORT B
.DB PORTB,DATA_B
.DB DDRC,DIR_C ;PORT B
.DB PORTC,DATA_C
.DB DDRD,DIR_D ;PORT D
.DB PORTD,DATA_D
.DW VOID
Swech
Re: ny på AVR
Har börjat kolla igen på AVR, så jag återupptar denna gamla tråd.
I pic-assembler kan man använda #define för att byta ut text mot en symbol, så här:
#define StartKnapp PORTA, 3
Sen kan man använda "StartKnapp" i en instruktion, t.ex så här:
btfss StartKnapp
och det tolkas då som
btfss PORTA, 3
Jag har försökt göra liknande i AVR, AtmelStudio 6.
Denna rad funkar:
ldd r21, y+7
Jag skulle vilja skriva:
.def var_a = y+1
ldd r21, var_a
Jag vill alltså att var_a byts ut textmässigt mot "y+1".
Får inte det att funka, får assembleringsfel för raden med def:
Invalid register
syntax error, unexpected '+'
Jag har provat med .equ och .set, men funkar inte i heller.
Någon som vet om det går att göra ?
I pic-assembler kan man använda #define för att byta ut text mot en symbol, så här:
#define StartKnapp PORTA, 3
Sen kan man använda "StartKnapp" i en instruktion, t.ex så här:
btfss StartKnapp
och det tolkas då som
btfss PORTA, 3
Jag har försökt göra liknande i AVR, AtmelStudio 6.
Denna rad funkar:
ldd r21, y+7
Jag skulle vilja skriva:
.def var_a = y+1
ldd r21, var_a
Jag vill alltså att var_a byts ut textmässigt mot "y+1".
Får inte det att funka, får assembleringsfel för raden med def:
Invalid register
syntax error, unexpected '+'
Jag har provat med .equ och .set, men funkar inte i heller.
Någon som vet om det går att göra ?
Re: ny på AVR
Kan du, förrutom själva felmeddelandet, se hur raden ser ut
efter att var_a har "bytts ut", så att säga ? D.v.s hur ser raden
ut som assemblern klagar på ? Kan du få en listfil eller liknande ?
efter att var_a har "bytts ut", så att säga ? D.v.s hur ser raden
ut som assemblern klagar på ? Kan du få en listfil eller liknande ?
Re: ny på AVR
Använd #define istället .def så ska det gå bra.
.def är från en tidigare assembler version och finns kvar p.g.a bakåt kompilatet.
.def är från en tidigare assembler version och finns kvar p.g.a bakåt kompilatet.
Re: ny på AVR
sodjan,
Tyvärr skapas det ingen list-fil när där är fel.
exile,
Innan tittade jag i hjälpen under Assembler directives, men nu hittade jag #define under AVR Assembler Preprocessor.
Det funkar som jag tänkte med #define, så tack för tipset!
Tyvärr skapas det ingen list-fil när där är fel.
exile,
Innan tittade jag i hjälpen under Assembler directives, men nu hittade jag #define under AVR Assembler Preprocessor.
Det funkar som jag tänkte med #define, så tack för tipset!
Re: ny på AVR
> sodjan,
> Tyvärr skapas det ingen list-fil när där är fel.
Det har jag väldigt svårt att tro!
Det är ju just då som man behöver den...
> Tyvärr skapas det ingen list-fil när där är fel.
Det har jag väldigt svårt att tro!
Det är ju just då som man behöver den...
Re: ny på AVR
Det skapas en fil med ändelsen .lss och den innehåller följande: (då felet finns i asm-filen)
Kod: Markera allt
AVRASM ver. 2.1.51 P:\PROGRAM\AVR\pt-test-1\pt-test-1\pt-test-1.asm Tue Jul 24 07:25:11 2012
[builtin](2): Including file 'C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRAssembler\2.1.51.46\AvrAssembler/Include\tn861def.inc'
P:\PROGRAM\AVR\pt-test-1\pt-test-1\pt-test-1.asm(9): Including file 'C:\Program Files (x86)\Atmel\Atmel Studio 6.0\extensions\Atmel\AVRAssembler\2.1.51.46\AvrAssembler/Include\tn861def.inc'
P:\PROGRAM\AVR\pt-test-1\pt-test-1\pt-test-1.asm(238): error: Invalid register
P:\PROGRAM\AVR\pt-test-1\pt-test-1\pt-test-1.asm(238): error: syntax error, unexpected '+'
