Hi 8)
How can I change Y+0.
ldd XL, Y+0 ldd XH, Y+1
To something like this.
ldd XL, deltaL ldd XH, deltaH
? :?
.set, .def or .equ do not work. .macro, can't figure out. :cry:
Hi 8)
How can I change Y+0.
ldd XL, Y+0 ldd XH, Y+1
To something like this.
ldd XL, deltaL ldd XH, deltaH
? :?
.set, .def or .equ do not work. .macro, can't figure out. :cry:
#define zippo Y+0 ... ldd r1,zippo
The preprocessor text substitution appears to work - at least it assembles without error.
This may not give you the flexibility you're looking for, however.
Hi 8)How can I change Y+0.
ldd XL, Y+0 ldd XH, Y+1To something like this.
ldd XL, deltaL ldd XH, deltaH? :?
.set, .def or .equ do not work. .macro, can't figure out. :cry:
.equ zonk=0 .equ zork=1 ldd r4, Y + zonk ldd r5, Y + zork
, which worked just fine
If Y+0 is always 'deltaL' then does this not imply that the value in Y is fixed? - so why bother with Y based indexing in the first place. Why not just?:
LDS XL, deltaL
I don't understand your claim that .equ doesn't work.
.equ zonk=Y+0
Does not work. I cannot name Y+q to one name. Not by using a macro either.
I just tried:.equ zonk=0 .equ zork=1 ldd r4, Y + zonk ldd r5, Y + zork, which worked just fine
Ok. :idea: I now use that, a name added. Because when you have a lot of the same lines you cannot see what is happening.
I use LDD, because takes 1 cycle, LDS takes 2 cycles. :evil:
I use LDD, because takes 1 cycle, LDS takes 2 cycles. [Evil or Very Mad]
Not by using a macro either.
My copy of the AVR Instruction Set says that
LDD (x) takes 2 cycles on a Mega, period. It takes 1 or 2 cycles on XMEGA (depending on whether X is pre-decremented or not).
LDD (Y) takes 2 cycles on a Mega, period. It takes 1 or 2 cycles on XMEGA (2 cycles if Y is pre-decremented or has an offset added).
LDS takes 2 cycles period.
So, what are you trying to accomplish? What chip are you using?
Jim
TANFL (There Ain't No Free Lunch)
And for that one cycle execution, it requires that you are accessing a variable in external RAM on the XMEAGA.
So first question is, what device are you running this under?
Further, it appears that the offset has to be fixed at compile time; the offset is embedded into the opcode, so it is not something that can be varied at runtime. Its not clear, but it sort of looks like you want to have variable offset.
Jim
As a guess, RES's latest crusade is aimed at >>run time<< "dynamic" addressing, which doesn't happen on an AVR and is confusing it with the >>assembly time<< syntax conventions.
Why not just use "Y + 0"? (and as that is redundant, use "Y"?)
And as noted, an SRAM read is 2 cycles except under exceptional circumstances.
So thefirst part of my post above was confusing, as both instructions actually take two cycles (for a SRAM read, and with no autoincrement). Should teach me to double check with the documentation, or else shut up. A closed mouth gathers no foot..
It would sure be nice to know what you're trying to do. Let me make a guess that it's something along the lines of the following code (borrowed from one of my posted projects). There's an array of structures, and I want to get to certain bytes of the selected structure, where "selected" means the Z register is pointing to the beginning of the particular entry.
; the packet manager uses the following, one per mouse .set packsize = 12 ; size of a packet def .set psts = 0 ; packet status .set perr = 1 ; packet error flag .set psize = 2 ; packet size .set pbytes = 3 ; number of bytes received .set phead = 4 ; buffer head save area .set preject = 5 ; packet reject count .set pready = 6 ; number of packets ready .set ptimer = 7 ; packet timer .set pbtimer = 8 ; packet byte timer .set ptrun = 9 ; flag if packet timer is running .set pbtrun = 10 ; flag if packet byte timer is running .set ptval = 11 ; timer value for packet timer ... pack: .byte 3 * packsize ; packet manager block ... ; load up Z to point at one of the 3 structures ; (pack, pack + packsize, or pack + 2 * packsize) it10: ldd r17,Z+ptrun ; packet timer status tst r17 breq it11 ; jump if not running ldd r17,Z+ptimer ; get current value
Ok. Let me explain. 8) (device=AT90PWM3 btw)
I try to save every cycle possible.(time critical)
When I use LD I have to set Y at 0x0100 (start of free SRAM space) first (cost time).
ldi YH, high(SRAM) ldi YL, low(SRAM) ld temp, Y+
When I use LDS it takes 2 cycles, and LDD 1 cycle (see AVR instruction set) So I use LDD.
I only have to set Y at init, can set e.g.
ldd temp, Y+4
No need for (pre)setting Y(SRAM) in the ISR.(can use movw, but then i have to use two extra registers, also critical)
Here's what I see in the datasheet:
LDD Rd,Y+q Load Indirect with Displacement Rdâ†(Y + q) None 2
2. LD instruction can load data from program memory since the flash is memory mapped. Loading data from the data memory
takes 1 clock cycle, and loading from the program memory takes 2 clock cycles. But if an interrupt occur (before the last
clock cycle) no additional clock cycles is necessary when loading from the program memory. Hence, the instruction takes
only 1 clock cycle to execute.
0856H–AVR–07/09
Looks like they have printed the same info twice under LD and LDD.
That note is for forms i and iii, which are the LD instruction (as it says in the text of the note). We're talking about the LDD instruction, which is form iv. The instruction set manual doesn't give the clock cycles for form iv (except for the XMega) for some odd reason, but the datasheet for the device does. It's 2.
I only have to set Y at init, can set e.g.
RES -
Is this for XMegas?
Jim Wagner
He slipped the device in earlier Jim. Easy to overlook:
(device=AT90PWM3 btw)
OK
Jim
Data sheet 4317I–AVR–01/08, for AT90PWM3, which I JUST downloaded from the Atmel website says that ALL versions of LD (LD, LDD, etc) ALL take two (2) cycles. See page 342.
There is no-where that says that any version of LDD does any different. Do a search for "LDD" in Acrobat Reader, and there is no reference to LDD that says that.
Jim
That note is for forms i and iii, which are the LD instruction (as it says in the text of the note). We're talking about the LDD instruction, which is form iv. The instruction set manual doesn't give the clock cycles for form iv (except for the XMega) for some odd reason, but the datasheet for the device does. It's 2.
Yes for the LD instruction. No info about the LDD, but in the header it says: LD (LDD) – Load Indirect From Data Space to Register using Index Z.
It seems like when you load data from SRAM with Z LDD takes 1 cycle?
Words: 1 (2 bytes)
Cycles: (i) 1(2)
(ii) 2
(iii) 3(2)
(2) Loading data from the data memory
takes 1 clock cycle, and loading from the program memory takes 2 clock cycles.
:roll: :?
The advantage of using Y+x addressing is that it saves flash space as it's only a 16 bit instruction while LDS/STS are 32 bit instructions.
ICCAVR uses this addressing mode to access local variables using its own software stack. Global or statics are addressed used LDS and take more Flash.
RES,
You appear to have access to documentation and a magic AVR that none of the rest of us have access to. Can you say EXACTLY which document you are quoting your "1 cycle" for any form of LD or LDD from. What is the section and page number.
You are either mis-reading it or it's a documentation error. Any AVR opcode that makes a read/write to SRAM is going to take at least 2 cycles.
Personally I'm looking at "8 bit AVR Instruction Set" Rev 0856E-AVR-11/05 and pages 83 to 88
Cliff
EDIT the fact that mine dated from 11/05 made me think there might be a new one and there is - the latest is 07/09 and has the addition of Xmega timings (which include 1 cycle memory instructions)
It's quite clearly in error because it has two sets of cycle counts. One set for "Xmega cycles". The implication of this is that the "Cycles" section is for traditional AVR. Yet the entry with 1 cycle has footnote (2) which says:
LD instruction can load data from program memory since the flash is memory mapped. Loading data from the data memory
takes 1 clock cycle, and loading from the program memory takes 2 clock cycles. But if an interrupt occur (before the last
clock cycle) no additional clock cycles is necessary when loading from the program memory. Hence, the instruction takes
only 1 clock cycle to execute.
LD instruction with pre-decrement can load data from program memory since the flash is memory mapped. Loading data
from the data memory takes 2 clock cycles, and loading from the program memory takes 3 clock cycles. But if an interrupt
occur (before the last clock cycle) no additional clock cycles is necessary when loading from the program memory. Hence,
the instruction takes only 1 clock cycle to execute
So this does look like a documentation error or at the very least an extreme confusion. I think I'll stick to the 11/05 version.
EDIT2: JayJay is right below - the 1 cycle confusion is relating solely to the Tiny10 when it's using LD to effectively LPM - something the traditional AVRs cannot do.
AVR8L cores (e.g. tiny10 and friends) have single cycle LDS instructions.
The instruction set as described in the AVRStudio help file lists LD r,Y+n as 2 cycles, just as LDS and STS. But I don't know if this does include the extra instruction fetch needed for address.
(device=AT90PWM3 btw)
Then LD, LDD, LDS all take 2 cycles, no matter how you swing a stick at it. ONLY the XMEGA offers a 1 cycles access, and that is ONLY if you are using, and accessing, external SRAM.
[edit]
The updated reference does indeed suggest one cycle, however the "program memory" part of that statement is key, as the only device that is possible on is the new tiny10 (and possibly other new tiny's) So I would suggest that the 1 cycle is only possible on the new tinys, not on your older 90PWM3. [which the device data sheet lists as taking 2 cycles for LD]
[edit #2]
missed the discussion above already pointing this out, also added the error to the unpublished errata sticky.
Ok. 8)