Porting some code from Mega16 to Mega644
UDR0 is now in extended i/o so the in command won't work - despite the datasheet using the in command for its examples.
Had me worried for a bit :-(
Porting some code from Mega16 to Mega644
UDR0 is now in extended i/o so the in command won't work - despite the datasheet using the in command for its examples.
Had me worried for a bit :-(
Using c it works. Using assembler, maybe not?
The latest datasheet for that device is over 4 years old. It's unlikely that Atmel will ever release a new version with corrections, but it's maybe a nice idea to let them know about it. Open a ticket with Atmel support.
Also, post your findings here:
https://www.avrfreaks.net/forum/avr-errata-unpublished-and-other-gotchas?page=all
Using c it works. Using assembler, maybe not?
The compiler is clever enough to know when LDS/STS or IN/OUT need to be used. I'm not!
But it's not really the compiler. It just implements a generic rule (use in/out if address is below 0x5f and subtract 0x20 from that address). It's the addresses in the device defining .h files that ultimately defines what is used. If you are writing in Asm then the same info comes from the def.inc files as long as you use the LOAD/STORE macros from AVR001 they should adapt in the same way the compiler does.
And IIRC there are macros for making the decision for you..
But OP's point is about the datasheet code examples. [without looking at them] I'd guess >>they<< did not use LOAD/STORE.
That said, if I'm doing an AVR model port I lay the I/O register map side-by-side using migration app note as a guide, and highlight all the differences, and then see how it might affect my code. And I'd think that would be even more important if there is ASM involved as the compiler might address some of the differences.
I checked and the datasheet is wrong, (as alway Atmel don't care there are always many cut and paste errors in the datasheets.)
Bob say :
Using c it works. Using assembler, maybe not?
yes it make the correct logic code, but because of bigger and slower code the program may not work.
Seems more like a retro-fix which Atmel used to try to absolve itself of actually writing correct examples :-/
+1
But it's not really the compiler. It just implements a generic rule (use in/out if address is below 0x5f and subtract 0x20 from that address). It's the addresses in the device defining .h files that ultimately defines what is used. If you are writing in Asm then the same info comes from the def.inc files as long as you use the LOAD/STORE macros from AVR001 they should adapt in the same way the compiler does.
Macros? Atmel-supplied macros! >GASP<
That's almost as bad as using C! They might be inefficient!
I only use my own carefully-polished macros. I tell you, if I had my way I'd be programming one byte at a time with a hex keypad!
Seriously though, I'm one of the sad crew who find the doing (and understanding when to use the right instruction) more interesting than teh end result. To me a programming challenge is like a crossword and using shortcuts feels like peeping at the answers.
Now, where's my hair shirt?
Neil
P.S. is the spell checker rigged? It offered 'well-supported' as a correction for a mis-spelt version of Atmel-supplied.
P.P.S. It must have a sense of humour - it's now offering 'oatmeal' for 'Atmel'
oatmeal is probably a healthier choice.
I'm not sure what you guys are running, but if I were you I'd keep it under close watch. You know what they say: "keep your friends close, keep your spell checker even closer"…
Hell, are you even sure it's not posting on your behalf when you're not watching?
Hell, are you even sure it's not posting on your behalf when you're not watching?
Are you Siri-us?
They might be inefficient!
I only use my own carefully-polished macros.
Just for the record AVR001 is here:
http://www.atmel.com/Images/doc2...
with the associated .zip file here:
http://www.atmel.com/images/AVR0...
The LOAD/STORE macros are the simplest thing in the entire file:
;********************************************************* ;* Byte access anywhere in IO or lower $FF of data space ;* STORE - Store register in IO or data space ;* LOAD - Load register from IO or data space ;********************************************************* .MACRO STORE ;Arguments: Address, Register .if @0>0x3F sts @0, @1 .else out @0, @1 .endif .ENDMACRO .MACRO LOAD ;Arguments: Register, Address .if @1>0x3F lds @0, @1 .else in @0, @1 .endif .ENDMACRO
Good luck with "polishing" those any further ;-)
(I do often wonder why this stuff came as an afterthought and isn't simply supplied with the assembler anyway - perhaps even making then psudeo-ops so you could use them without even a .include?)
Then you can't count time and code size.
And in some situations you would us LDD or simple LD (where X,Y or Z point on start of HW block)
Doesn't the assembler produce a listing file (with macros expanded) then? I would have thought you'd be able to use that for cycle counting if necessary. (actually it'd be kind of nice if it annotated each opcode with the cycles for the chosen model of AVR!)
(I do often wonder why this stuff came as an afterthought and isn't simply supplied with the assembler anyway - perhaps even making then psudeo-ops so you could use them without even a .include?)
Agreed. Why not have simple pseudo ops like addi x,n = subi x,-n
Why not have simple pseudo ops like addi x,n = subi x,-n
Stub_Mandrel wrote:
Why not have simple pseudo ops like addi x,n = subi x,-n
I have a theory. Assembler programmers are masochists. Give them a macro that makes them more miserable and they would go for it.
Why not have simple pseudo ops like addi x,n = subi x,-n
I prefer my "asm" macros to look like this..
int a,b,c; c = a + b;
WARNING: a and b have not been initialized.
WARNING: a and b have not been initialized
Oh, my error I omitted this part of the code:
int a,b,c; void some_func(void) { c = a + b; }
so, actually, yes they have been initialised
(unless you are using a DSP compiler from TI - don't ask!)
I have a theory. Assembler programmers are masochists. Give them a macro that makes them more miserable and they would go for it.
Quite. If I used C I would have to beat myself with a hazel switch then run naked through a nettle patch each time my code ran without errors.