ATMEGA 128 - how to use array located in both parts of memory

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am trying to make simple assembly program for Atmega 128 which send first 5 bytes from array to PORTA.

It works fine when all these bytes are located in same part of the program memory e.g.

.org 0x7000
ARRAY: .db 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF

or

.org 0x8000
ARRAY: .db 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF

but when array is located in both parts of memory e.g.

.org 0x7fff
ARRAY: .db 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF

then my program sends correctly only bytes located in first 32KB of memory.

 

I tried to use RAMPZ register and all other things I found on the internet but nothing works, so I thought that someone here will know how to do it.

Full code:

.include "m128def.inc"

ldi R20, 0xFF
out DDRA, R20

.DEF counter=R16
.DEF value=R17
ldi counter, 0x00

ldi zl,low(2*ROMTAB)
ldi zh,high(2*ROMTAB)	
ldi R20, byte3(2*ROMTAB)
out rampz, R20

Loop:
	elpm value, Z			
	out PORTA, value

	inc counter
	cpi counter, 0x05		
	breq End

	ADIW ZL,1
	rjmp Loop

End:

.org 0x7fff
ARRAY: .db 0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF

.EXIT

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When you cross the 32K boundary, the RAMPZ bit has to be cleared below that boundary and set above it, no? After all, that bit is part of the total address. So, you would need to test when the crossing occurs and apply that change, correctly at that point, wouldn't you? I do not think that ADIW extends to the 17th address bit (which is what RAMPZ0 is). Seems like it would be much  simpler if you could pad your table so that it was all below or all above the boundary.

 

Never confronted this situation so this is conjecture on my part.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Sun. May 8, 2016 - 11:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for your reply. I removed ADIW command and used incrementation (Z+) instead and now it's working.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So Z+ carries over to the 17th bit. Good to know.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to make it clear it's only ELPM Z+ that carry the bit over, all other instructions don't. (it's not a free 17th bit.)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Am I having a difficult time remembering my powers of 2 this morning, or isn't it the 16th bit that changes from 0 to 1 when 0x7fff is incremented to 0x800..?

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is the change from 0xffff to 0x10000. That chip has a 17 bit address space.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the confusion is that it has 16 bit word for code.  But when it's data it's 17 bit addresses of byte

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I always wrote ADIW (and SBIW) with both addresses, e.g. "adiw ZH:ZL, 1"

 

Can I leave out the "ZH:"?  I wonder if that was part of it being weird. 

 

S.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But when it's data it's 17 bit addresses of byte..

Stung by the word address versus byte address thing again...angry

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!