AVR-Chat

John, Paul,

> Hi Paul,
> 
> This untried, but pretty sure that I would go for:
> 
> //assume that we have 16 blocks of 256 in the array...
> LDS r16,step  //this one 0-255?
> LDS r17,num   //this one 0-15?
> CLR r18	
> LDI r30,LOW(array)
> LDI r31,HIGH(array)
> ADD r30,r16
> ADC r31,r17
> LPM r18,r30
> OUT PORTD,r18
> 
> /*...and can be two cycles quicker if you dedicate a
>    permanent pointer to 'step' and 'num' sequentially in SRAM:
> 	LD  r16,X
> 	LDD r17,X+1
>   */

Actually, it can be faster still.  

 LDS  r30,step  //this one 0-255?
 LDS  r31,num   //this one 0-15?
 SUBI r30,LOW(-array)
 SBCI r31,HIGH(-array)
 LPM  r18,r30
 OUT  PORTD,r18

Assuming you align your array on a 256-byte boundary, we can drop one
instruction:

 LDS  r30,step  //this one 0-255?
 LDS  r31,num   //this one 0-15?
 SUBI r31,HIGH(-array)
 LPM  r18,r30
 OUT  PORTD,r18

If, however, you need a true C solution, you can use something like:

static const __code char *table[256] = (void *)0x4000;
// or whatever your compiler required for telling it about a pointer to
code space at 0x4000

Then you can write:

char c = table[y][x];

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, and (soon) Atmel AVR processors

Paul/John,

Thanks, I've got enough to be going on with, I'll check out both and have a
play.
As for the C soloution, I tried, it doesn't compile to tight enough code,
SPEED is of the essence for this need.

Paul

Paul,

> Assuming you align your array on a 256-byte boundary, we can drop one
> instruction:

you mean like ;-

.ORG 0x0200 <data><data>....

Rather than;-

.ORG 0x0201 <data><data>.....

That shouldn't be too hard, I just need to make sure its above the are where
the code is.
Cheers

Paul

Paul,

Corrected a few things, heres the corrected version

 MOV  r30,step  //this one 0-255?
 MOV  r31,num   //this one 0-15?
 SUBI r31,HIGH(-array)
 LPM  r18,Z
 OUT  PORTD,r18

As far as I can see, this is the shortest I can get it.

Whilst Im on the subject,
Is there any way of skipping if minus?

I can do a BRMI, just wondered

Paul

Paul/Anyone

in this code,

>  MOV  r30,step  //this one 0-255?
>  MOV  r31,num   //this one 0-15?
>  SUBI r31,HIGH(-array)
>  LPM  r18,Z
>  OUT  PORTD,r18

whilst running the simulator, r31 and r30 don't seem to pick up the correct
address (0x0200)
even though I have at the end of my code (only very short)

.ORG 0200
.EQU array=0x00,0x01,0x02, etc ,etc (yeah, I know they're lame values but
its good for a test)

Any thoughts as to what I'm doing wrong?

Paul

Larry,

> How about changing the code:
> 
> mov r30, step
> ldi r31, high(array)
> add r31, num
> lpm r18, z
> out portd, r18

nope, same thing..
Could it be the simulator doesn't work properly?

Paul

How about changing the code:

mov	r30, step
ldi	r31, high(array)
add	r31, num
lpm	r18, z
out	portd, r18

-----Original Message-----
From: Paul Maddox [mailto:P.Maddox@signal.qinetiq.com]
Sent: Thursday, December 02, 2004 6:02 AM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] Reading from flash in Assembly



Paul/Anyone

in this code,

>  MOV  r30,step  //this one 0-255?
>  MOV  r31,num   //this one 0-15?
>  SUBI r31,HIGH(-array)
>  LPM  r18,Z
>  OUT  PORTD,r18

whilst running the simulator, r31 and r30 don't seem to pick up the correct
address (0x0200)
even though I have at the end of my code (only very short)

.ORG 0200
.EQU array=0x00,0x01,0x02, etc ,etc (yeah, I know they're lame values but
its good for a test)

Any thoughts as to what I'm doing wrong?

Paul






 
Yahoo! Groups Links

Larry,

Ok,

Made some changes, I wondered if I should be use .db instead of .EQU=, tried
that, same thing.

I've been stepping through it, boring or what...
But all seems well, except for this line ;-

lpm r18, z

At this point r18, only contains 0xFF and never changes (though Z does
change).
Perhaps its a limitation of the Simulator thing?
Anyway, I'll try it tonight on an AVR :-)

Paul

> nope, same thing..
> Could it be the simulator doesn't work properly?
You need to multiply the base address by two.

My usual way is:
	ldi,	zl,	low(base_addy*2)
	ldi,	zh,	high(base_addy*2)
	add		...etc.


Richard
---
"Iz dana u dan ona dolazi i odlazi u talasima"
   http://www.van-gogh.co.yu/

At 04:49 PM 2/12/04 -0000, you wrote:
>
>Made some changes, I wondered if I should be use .db instead of .EQU=, tried
>that, same thing.
>

.db puts the data in physically into the flash, .equ does NOT. So your
array MUST be made up by the define byte directive.

ORG 0200	;make it 0x0200 to be safe

array:		;assign a label
.db	0x00,0x01,0x02			;, etc ,etc

	ldi	xl,low(array*2)
	ldi	xh,high(array*2)	;x now points to the start of array

	add	xl,step			;I presume that step and num  are registers
	adc	xh,num			;x now should point to your data..(may need to multiply
somewhere)
	
	LPM  				;data in r0 or  LPM  r18,Z
...................				

ORG 0200	;make it 0x0200 to be safe

array:		;assign a label
.db	0x00,0x01,0x02			;, etc ,etc


>  MOV  r30,step  //this one 0-255?
>  MOV  r31,num   //this one 0-15?
>  SUBI r31,HIGH(-array)
>  LPM  r18,Z
>  OUT  PORTD,r18


Regards

John Samperi

******************************************************
                        Ampertronics Pty. Ltd.
  11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
         Tel. (02) 9674-6495       Fax (02) 9674-8745
               Email: samperi@ampertronics.com.au
                 Website  http://www.ampertronics.com.au
* Electronic Design   * Custom Products   * Contract Assembly
******************************************************

Which chip are you using?  lpm Rx, Z is only supported on newer mega chips.

If the right address is in Z and the chip supports the instruction, then if
you are only getting 0xFF is because there is no data at that location.

Cheers!

-----Original Message-----
From: Paul Maddox

Larry,

Ok,

Made some changes, I wondered if I should be use .db instead of .EQU=, tried
that, same thing.

I've been stepping through it, boring or what...
But all seems well, except for this line ;-

lpm r18, z

At this point r18, only contains 0xFF and never changes (though Z does
change).
Perhaps its a limitation of the Simulator thing?
Anyway, I'll try it tonight on an AVR :-)

Pa

Larry,

> Which chip are you using?  lpm Rx, Z is only supported on newer mega
chips.

Soprry, should've said, its a Mega16.

> If the right address is in Z and the chip supports the instruction, then
if
> you are only getting 0xFF is because there is no data at that location.

Looks like I should be shifting the address left once before using it for
some reason (thanks John/Richard/Beaver) I'll give that a go, though I don't
understand quite why.

Paul

All,

Ok, and the final soloution is ;-

mov r30, step
ldi r31, high(array<<1)
add r31, num
lpm r18, z
out portd, r18

As I'm only using Bytes not Words, I didn't need to left shift the ZL (r30)
value.

Thanks to everyone for helping :-)

Paul

Paul -

The reason is that the low bit is used as a byte indicator.
Bit = 0 gets low byte in 16 bit word and 1 gets high byte
in the word.

Jim


On Fri, 3 Dec 2004 10:33:46 -0000
 "Paul Maddox" <P.Maddox@signal.qinetiq.com> wrote:
> 
> 
> 
> 
> 
> Larry,
> 
> > Which chip are you using?  lpm Rx, Z is only
> supported on newer mega
> chips.
> 
> Soprry, should've said, its a Mega16.
> 
> > If the right address is in Z and the chip supports
> the instruction, then
> if
> > you are only getting 0xFF is because there is no
> data at that location.
> 
> Looks like I should be shifting the address left once
> before using it for
> some reason (thanks John/Richard/Beaver) I'll give that a
> go, though I don't
> understand quite why.
> 
> Paul
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Yahoo! Groups Sponsor
> 
> 
>   ADVERTISEMENT 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Yahoo! Groups Links
> 
> To visit your group on the web, go
> to:http://groups.yahoo.com/group/AVR-Chat/ 
> To unsubscribe from this group, send an email
> to:AVR-Chat-unsubscribe@yahoogroups.com 
> Your use of Yahoo! Groups is subject to the Yahoo! Terms
> of Service.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

---------------------------------------------------------------
The Think Different Store
http://www.thinkdifferentstore.com/
For All Your Mac Gear
---------------------------------------------------------------

At 11:10 AM 12/3/2004, Jim Wagner wrote:


>Paul -
>
>The reason is that the low bit is used as a byte indicator.
>Bit = 0 gets low byte in 16 bit word and 1 gets high byte
>in the word.

It all becomes clear, when you remember that program space is 16 bit words.
ZH       ZL
XXXXXXXX XXXXXXXY ; y = word select
XXXXXXXX XXXXXXX0 ; X = address

So load Z with (AddressOfData*2) and then
ld      TEMP,Z+ till you hit the end (null terminated or length count)

Foo.. LPM, then LD Z+ or ADIW ZL,1
Insufficient caffiene error.

At 10:54 AM 3/12/04 -0000, you wrote:
>
>Ok, and the final soloution is ;-
>
>mov r30, step
>ldi r31, high(array<<1)
>add r31, num
>lpm r18, z
>out portd, r18
>
>As I'm only using Bytes not Words, I didn't need to left shift the ZL (r30)
>value.

But DOES IT WORK? :-) The flash is in 2 byte lots (16 bit) that is the reason
you need to multiply by 2 to get to the address.

What happens if the data is the 2nd byte of the array? It seems to me that
you need at least 1 multiplication and 2 16 bit additions to get it working
anywhere in  flash. If the above works well I have to redo some of my
code that gets the data from a character set lookup table (224 rows, 7
columns).

I don't quite understand how it would work... but then again I may have it
all wrong as I don't have the original post anymore.

Regards

John Samperi

******************************************************
                        Ampertronics Pty. Ltd.
  11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
         Tel. (02) 9674-6495       Fax (02) 9674-8745
               Email: samperi@ampertronics.com.au
                 Website  http://www.ampertronics.com.au
* Electronic Design   * Custom Products   * Contract Assembly
******************************************************

It depends, John: if you use GCC you can BYTE align stuff in FLASH and then
you need the BYTE address, which, as it happens, is what GCC provides.
Other tools, notably the Atmel Assembler, doesn't allow you to BYTE align
stuff in flash.  You need to align stuff on WORD (even) addresses.  However,
the LPM instruction will happily take BYTE addresses and fetch the correct
byte into your destination register.

So, if in the example, the array was WORD aligned (which it was), then
nothing more needs to be done than the left shift (x2) + the BYTE offset of
the data the user is interested in.  The LPM instruction takes care of
everything else.

Cheers!

-----Original Message-----
From: John Samperi [mailto:samperi@ampertronics.com.au]
Sent: Friday, December 03, 2004 3:33 PM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] Reading from flash in Assembly



At 10:54 AM 3/12/04 -0000, you wrote:
>
>Ok, and the final soloution is ;-
>
>mov r30, step
>ldi r31, high(array<<1)
>add r31, num
>lpm r18, z
>out portd, r18
>
>As I'm only using Bytes not Words, I didn't need to left shift the ZL (r30)
>value.

But DOES IT WORK? :-) The flash is in 2 byte lots (16 bit) that is the
reason
you need to multiply by 2 to get to the address.

What happens if the data is the 2nd byte of the array? It seems to me that
you need at least 1 multiplication and 2 16 bit additions to get it working
anywhere in  flash. If the above works well I have to redo some of my
code that gets the data from a character set lookup table (224 rows, 7
columns).

I don't quite understand how it would work... but then again I may have it
all wrong as I don't have the original post anymore.

Regards

John Samperi

******************************************************
                        Ampertronics Pty. Ltd.
  11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
         Tel. (02) 9674-6495       Fax (02) 9674-8745
               Email: samperi@ampertronics.com.au
                 Website  http://www.ampertronics.com.au
* Electronic Design   * Custom Products   * Contract Assembly
******************************************************





Yahoo! Groups Links

At 06:32 PM 12/3/2004, John Samperi wrote:


>At 10:54 AM 3/12/04 -0000, you wrote:
> >
> >Ok, and the final soloution is ;-
> >
> >mov r30, step
> >ldi r31, high(array<<1)
> >add r31, num
> >lpm r18, z
> >out portd, r18
> >
> >As I'm only using Bytes not Words, I didn't need to left shift the ZL (r30)
> >value.
>
>But DOES IT WORK? :-) The flash is in 2 byte lots (16 bit) that is the reason
>you need to multiply by 2 to get to the address.

Doesn't look entirely sane to me..

 >mov r30, step
 >ldi r31, high(array<<1)

Not sure what step is, but we are now pointing at high(Array*2)+Step

 >add r31, num

Ok, adding offset, but this assumes that Step + num will never be > 255.

 >lpm r18, z
 >out portd, r18

Conventional..


What I would do, is this:

ldi     zl,low(Array*2) ;Point at the array
ldi     zh,high(Array*2)

clr     TEMP2 ;or any suitable register
add     zl,step         ;16 bit op
adc     zh,TEMP2

add     zl,num          ;16 bit op
adc     zh,TEMP2

lpm     r18,z
out     portd,r18

But I'm not sure how step is used here, so the first 16 bit add might not 
really be the right thing.

At 06:48 PM 3/12/04 -0500, you wrote:

OK this is what I do to get the data from a character generator
look up table (an array of 224 rows x 7 bytes wide).

;r16 has the character we want to get the data for 0x20-0xff
good_char:
	subi	r16,' '	;Multiplier LSB		(this just deducts 32 (0x20) from the number)
	clr	r17	;Multiplier MSB		(as there is no data for char 0-31 or control chars)

	ldi	r18,7	;Multiplicand LSB, 7 bytes each char
	clr	r19	;Multiplicand MSB	
	rcall	mpy16u	;Find offset in CHAR_GEN table	
			;of first row results in r18 and r19

	push	zl	;push z as this routine happens during ints
	push	zh

	clr	zh
	mov	zl,rownum 	;Load z with row_num
	add	zl,r18		;Add offset results
	adc	zh,r19
	ldi	r16,low(CHAR_GEN*2)
	ldi	r17,high(CHAR_GEN*2)

	add	zl,r16	;Add char gen start address
	adc	zh,r17

	lpm		;Go and get CG char into r0

	pop	zh	;restore z
	pop	zl
	ret

As you can see it's a LOT longer that what you have but it has been working
for many years, if anyone can shorten it I would be grateful :-))

Regards

John Samperi

******************************************************
                        Ampertronics Pty. Ltd.
  11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
         Tel. (02) 9674-6495       Fax (02) 9674-8745
               Email: samperi@ampertronics.com.au
                 Website  http://www.ampertronics.com.au
* Electronic Design   * Custom Products   * Contract Assembly
******************************************************

>
>         rcall   mpy16u  ;Find offset in CHAR_GEN table
>                         ;of first row results in r18 and r19

Can you sacrifice rom space, to put the addresses on a binary boundary?
Then this part becomes a few ROLs.

>         push    zl      ;push z as this routine happens during ints
>         push    zh

Do your ints not preserve z?  Which spends more time, saving it here, or in 
the ints that need it?

>         clr     zh
>         mov     zl,rownum       ;Load z with row_num
>         add     zl,r18          ;Add offset results
>         adc     zh,r19
>         ldi     r16,low(CHAR_GEN*2)
>         ldi     r17,high(CHAR_GEN*2)


Saving one un-needed clear.

ldi     zl,low(Char_Gen*2)
ldi     zh,high(Char_Gen*2)
add     zl,rownum
adc     zh,zero         ;(optionally clear rownum after using it, and add 
it here.)
                         ;I keep a register called zero zeroed to speed up 
these ops.
add     zl,R18  ;as before.
adc     zh,R19  ;


>         pop     zh      ;restore z
>         pop     zl

Have the ints save Z, and don't save/restore it here.

>As you can see it's a LOT longer that what you have but it has been working
>for many years, if anyone can shorten it I would be grateful :-))

At 07:27 PM 3/12/04 -0500, you wrote:
>>         rcall   mpy16u  ;Find offset in CHAR_GEN table
>>                         ;of first row results in r18 and r19
>Can you sacrifice rom space, to put the addresses on a binary boundary?
>Then this part becomes a few ROLs.

don't quite understand. I'm putting 2 chars (7 bytes each next to each other
or 14 bytes) to save rom space. I guess I could just add a zero byte at the
end
of each set * instead of 7), this will use up 224 bytes and make each
chararcter 
data 8 bytes long.

But I still need to multiply the value of the char (say 41hex for the char A)
by the number of bytes that each char needs (7 or 8) to get to the data for
the
first scan row and then add the row offset to get the pixels for that row.


>>         push    zl      ;push z as this routine happens during ints
>>         push    zh
>
>Do your ints not preserve z?  Which spends more time, saving it here, or in 
>the ints that need it?

I think it does, maybe I need to use Z for something else and need to
preserve it in the same int. I'll have another look.

Anyway...thanks for the tips..but we were trying to help Paul :-))

It's good to let someone else look at what one does as one can get
too involved with getting the stuff to work to see the errors of his ways.





Regards

John Samperi

******************************************************
                        Ampertronics Pty. Ltd.
  11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
         Tel. (02) 9674-6495       Fax (02) 9674-8745
               Email: samperi@ampertronics.com.au
                 Website  http://www.ampertronics.com.au
* Electronic Design   * Custom Products   * Contract Assembly
******************************************************

Trading space for speed.
Now you don't need to call the mult, just ROL it.

>But I still need to multiply the value of the char (say 41hex for the char A)
>by the number of bytes that each char needs (7 or 8) to get to the data for
>the first scan row and then add the row offset to get the pixels for that row.
>
>
> >>         push    zl      ;push z as this routine happens during ints
> >>         push    zh
> >
> >Do your ints not preserve z?  Which spends more time, saving it here, or in
> >the ints that need it?
>
>I think it does, maybe I need to use Z for something else and need to
>preserve it in the same int. I'll have another look.
>
>Anyway...thanks for the tips..but we were trying to help Paul :-))

We are all in the same boat full of holes.
It's nice sometimes, to have someone else helping you bail.
:)

Is anyone aware of problems around changing the Xdiv regiseter in the M128?

We've been doing this for a while, with code like this:

ldi	TEMP,127
out	xdiv,temp
nop


Now, I just discovered an app note from atmel that says that you need to do 
the following:

cli
ldi	temp,127
out	xdiv,temp
nop
nop
nop
nop
nop
nop
nop
nop
sei

They say that nop is the only safe instruction to execute after the xdiv, 
and that you need at least eight nops after the xdiv before you can execute 
normal code.

When did this info become available?

How about this bit of optimized code? I believe the following properly
emulates your original code.

	push	R30
	push	R31		; push Z
	clr	R17		; R17:16 = character offset
	mov	R30, R16	; R17:16 -> Z
	mov	R31, R17
	add	R30, R30	; Z + Z = 2x
	adc	R31, R31
	add	R30, R16	; Z + R17:16 = 3x
	adc	R31, R17
	add	R30, R30	; Z + Z = 6x
	adc	R31, R31
	add	R30, R16	; Z + R17:16 = 7x
	adc	R31, R17
	add	R30, rownum	; Add in row offset
	adc	R31, R17	; this has 0x00 in it.
	; Add in char gen base offset adjusted for the lack of
	; data below character 32
	subi	R30, low(-((CHAR_GEN*2) - (' '*7)))
	sbci	R31, high(-((CHAR_GEN*2) - (' '*7)))
	lpm
	pop	R31
	pop	R30
	ret

-----Original Message-----
From: John Samperi [mailto:samperi@ampertronics.com.au]
Sent: Friday, December 03, 2004 4:17 PM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] Reading from flash in Assembly



At 06:48 PM 3/12/04 -0500, you wrote:

OK this is what I do to get the data from a character generator
look up table (an array of 224 rows x 7 bytes wide).

;r16 has the character we want to get the data for 0x20-0xff
good_char:
	subi	r16,' '	;Multiplier LSB		(this just deducts 32 (0x20) from the number)
	clr	r17	;Multiplier MSB		(as there is no data for char 0-31 or control
chars)

	ldi	r18,7	;Multiplicand LSB, 7 bytes each char
	clr	r19	;Multiplicand MSB
	rcall	mpy16u	;Find offset in CHAR_GEN table
			;of first row results in r18 and r19

	push	zl	;push z as this routine happens during ints
	push	zh

	clr	zh
	mov	zl,rownum 	;Load z with row_num
	add	zl,r18		;Add offset results
	adc	zh,r19
	ldi	r16,low(CHAR_GEN*2)
	ldi	r17,high(CHAR_GEN*2)

	add	zl,r16	;Add char gen start address
	adc	zh,r17

	lpm		;Go and get CG char into r0

	pop	zh	;restore z
	pop	zl
	ret

As you can see it's a LOT longer that what you have but it has been working
for many years, if anyone can shorten it I would be grateful :-))

Regards

John Samperi

At 06:19 PM 3/12/04 -0800, you wrote:
>
>How about this bit of optimized code? I believe the following properly
>emulates your original code.
>

Thanks Larry

I'm doing some work on a new PCB (the old one had a PIC in it..yuck...)
so that all my display types run a Mega8, I will try your change, it should
be a lot faster because it doesn't need the multiply routine. Even though 
2 instruction longer it will save the space of the Multiply routine which is
quite longish (Atmel app note) and only used there if I remember correclty. 

But now I just realised that the mega8 has an on chip multiplier so it can 
be made even shorter!! Just need to have some conditional assembly to
use the multiply routine when using the ICE200 (90S8535 mode) and the
on chip multiplier when running the mega8. 

That's what you get when you discuss things with other people!

Regards

John Samperi

******************************************************
                        Ampertronics Pty. Ltd.
  11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
         Tel. (02) 9674-6495       Fax (02) 9674-8745
               Email: samperi@ampertronics.com.au
                 Website  http://www.ampertronics.com.au
* Electronic Design   * Custom Products   * Contract Assembly
******************************************************

Has nobody but me run into this issue?

At 05:05 PM 5/12/04 -0500, you wrote:
>Has nobody but me run into this issue?
>

Sorry David....I really love to have another "issue" to
solve :-)) but as i only have the ICE200 to work with
I haven't used any of those opcodes yet as they are not 
supported in the devices that the ICE handles.

Regards

John Samperi

******************************************************
                        Ampertronics Pty. Ltd.
  11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
         Tel. (02) 9674-6495       Fax (02) 9674-8745
               Email: samperi@ampertronics.com.au
                 Website  http://www.ampertronics.com.au
* Electronic Design   * Custom Products   * Contract Assembly
******************************************************

At 05:25 PM 12/5/2004, John Samperi wrote:


>At 05:05 PM 5/12/04 -0500, you wrote:
> >Has nobody but me run into this issue?
> >
>
>Sorry David....I really love to have another "issue" to
>solve :-)) but as i only have the ICE200 to work with
>I haven't used any of those opcodes yet as they are not
>supported in the devices that the ICE handles.

Well, the good news is that the recommended handling, with 8 nops and ints 
disabled, seems to work pretty nicely. Of course up to friday, I was 
unaware of any need for this.

John,

> But DOES IT WORK? :-) The flash is in 2 byte lots (16 bit) that is the
reason
> you need to multiply by 2 to get to the address.

yes, it works fine..
Thats why I don't understand it.
I understand abotu things being stored as 'words' in the AVR, but I don't
see why I only have to multiply the upper byte (ZH) not the lower byte (ZL).

> What happens if the data is the 2nd byte of the array? It seems to me that
> you need at least 1 multiplication and 2 16 bit additions to get it
working
> anywhere in  flash. If the above works well I have to redo some of my
> code that gets the data from a character set lookup table (224 rows, 7
> columns).

I use a '.db 0xnn,0xnn' table for mine and as I say, in the simulator ir
works and on the actual chip, it works.

Paul

Dave,

> Doesn't look entirely sane to me..

me neither, but does what I want, fetchs a BYTE from a lookuptable in memory
(on a page boundry I should add).

> Not sure what step is, but we are now pointing at high(Array*2)+Step

yep, Start of my table (array) and a certain number of bytes into it (step)

> Ok, adding offset, but this assumes that Step + num will never be > 255.

Huh?
The 'num' represents the table, there are 16 tables, each of 256 bytes.
so what I have is a value from -

(High(Array*2)+num)*256)+step

don't forget I add the tabel number to the 'upper byte'.

> What I would do, is this:
>
> ldi     zl,low(Array*2) ;Point at the array
> ldi     zh,high(Array*2)
>
> clr     TEMP2 ;or any suitable register
> add     zl,step         ;16 bit op
> adc     zh,TEMP2
>
> add     zl,num          ;16 bit op
> adc     zh,TEMP2

What that gives me is ;- (high(Array*2)*256)+step+num
errr, thats not going to do what I need, 'num' is a table number, as I say,
each table is 256 bytes long.

and you're right 'num' will never be more than 255, and neither will 'step'.

Paul

At 08:52 AM 6/12/04 -0000, you wrote:
>
>John,
>yes, it works fine..
>Thats why I don't understand it.

As long as you are a happy customer...we are also happy :-))



Regards

John Samperi

******************************************************
                        Ampertronics Pty. Ltd.
  11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
         Tel. (02) 9674-6495       Fax (02) 9674-8745
               Email: samperi@ampertronics.com.au
                 Website  http://www.ampertronics.com.au
* Electronic Design   * Custom Products   * Contract Assembly
******************************************************

John,

> As long as you are a happy customer...we are also happy :-))

yeah, very happy :-)

Paul