Atmel ATmega2561 is no better than PIC16F84

So I've finally got my precious samples of ATmega2561. With 256Kbytes
of Flash I should be able to store massive look-up tables, but wait a
minute the Flash memory is segmented into 64Kbyte lumps. The data sheet
states:

"For ELPM/SPM instructions, the Z-pointer is a concatenation of RAMPZ,
ZH, and ZL"

But is that really true? I find that I have the following instruction:

ELPM Rd,Z+

which loads register Rd from the program memory pointed to by the
24-bit concatenated Z pointer described so eloquently above. However I
find that the post increment only deals with ZH & ZL. The most
significant 8-bits in RAMPZ are not incremented when the ZH/ZL
combination wraps around and tables must not cross a 64K boundary.

Ok, I suppose the 16F84 only had 256 byte pages but that was a long
time ago and I we have progressed a little since then, but clearly not
as much as I thought.

-- 
John B

John B wrote:
> So I've finally got my precious samples of ATmega2561. With 256Kbytes
> of Flash I should be able to store massive look-up tables, but wait a
> minute the Flash memory is segmented into 64Kbyte lumps. The data sheet
> states:
> 
> "For ELPM/SPM instructions, the Z-pointer is a concatenation of RAMPZ,
> ZH, and ZL"
> 
> But is that really true? I find that I have the following instruction:
> 
> ELPM Rd,Z+
> 
> which loads register Rd from the program memory pointed to by the
> 24-bit concatenated Z pointer described so eloquently above. However I
> find that the post increment only deals with ZH & ZL. The most
> significant 8-bits in RAMPZ are not incremented when the ZH/ZL
> combination wraps around and tables must not cross a 64K boundary.
> 
> Ok, I suppose the 16F84 only had 256 byte pages but that was a long
> time ago and I we have progressed a little since then, but clearly not
> as much as I thought.


If you need to have address arithmetic for a range of
over 64 kbytes, you'd be much better off using a
32 bit controller instead, e.g. some of the ARM
variants.

-- 

Tauno Voipio
tauno voipio (at) iki fi

John B wrote:
> So I've finally got my precious samples of ATmega2561. With 256Kbytes
> of Flash I should be able to store massive look-up tables, but wait a

I'm curious, can you describe the requirement that led to choosing this
part? I started to look at these biggie parts because of a vague
internal mental process that went something like this: current code on
mega128, already own the tools, 256K memory would help me with some
expansion requirements.

Looking at the prices (and this applies to my homebrew projects as well
as my day-job stuff) moving to a single-chip ARM solution seemed to be
much better sense. I could get 512K flash and a 40MHz ARM core for the
price of a mega2561. Even allowing for the poorer code density on ARM,
I'd be ahead of the game.

larwe scrobe on the papyrus:

> 
> John B wrote:
> > So I've finally got my precious samples of ATmega2561. With
> > 256Kbytes of Flash I should be able to store massive look-up
> > tables, but wait a
> 
> I'm curious, can you describe the requirement that led to choosing
> this part? I started to look at these biggie parts because of a vague
> internal mental process that went something like this: current code on
> mega128, already own the tools, 256K memory would help me with some
> expansion requirements.
>

Yes all of those, but the big plus is that it's a no-brainer to upgrade
from the mega128 to the mega2561. The same PCB can be used, so there
are no new NRE charges and no additional hardware debug time.

  
> Looking at the prices (and this applies to my homebrew projects as
> well as my day-job stuff) moving to a single-chip ARM solution seemed
> to be much better sense. I could get 512K flash and a 40MHz ARM core
> for the price of a mega2561. Even allowing for the poorer code
> density on ARM, I'd be ahead of the game.

I totally agree, and if Atmel had only brought out the mega2560 I would
go the same way. As long as the chip isn't packaged in BGA, then even
homebrew is possible. Just out of interest what ARM tools do you use?

-- 
John B

On Wed, 12 Apr 2006 05:56:32 GMT, Tauno Voipio
<tauno.voipio@INVALIDiki.fi> wrote:

>John B wrote:
>> So I've finally got my precious samples of ATmega2561. With 256Kbytes
>> of Flash I should be able to store massive look-up tables, but wait a
>> minute the Flash memory is segmented into 64Kbyte lumps. The data sheet
>> states:
>> 
>> "For ELPM/SPM instructions, the Z-pointer is a concatenation of RAMPZ,
>> ZH, and ZL"
>> 
>> But is that really true? I find that I have the following instruction:
>> 
>> ELPM Rd,Z+
>> 
>> which loads register Rd from the program memory pointed to by the
>> 24-bit concatenated Z pointer described so eloquently above. However I
>> find that the post increment only deals with ZH & ZL. The most
>> significant 8-bits in RAMPZ are not incremented when the ZH/ZL
>> combination wraps around and tables must not cross a 64K boundary.
>> 
>> Ok, I suppose the 16F84 only had 256 byte pages but that was a long
>> time ago and I we have progressed a little since then, but clearly not
>> as much as I thought.
>
>
>If you need to have address arithmetic for a range of
>over 64 kbytes, you'd be much better off using a
>32 bit controller instead, e.g. some of the ARM
>variants.

I agree that the 32bit route is the better way, but if you have to
stick to the AVR, then use a 32bit integer as your "pointer".
Translate this to RAMPZ, Z when you need to use it. Not as clean 
as using a true pointer.

Regards
  Anton Erasmus

John B wrote:

> Yes all of those, but the big plus is that it's a no-brainer to upgrade
> from the mega128 to the mega2561. The same PCB can be used, so there
> are no new NRE charges and no additional hardware debug time.

Well, not for you maybe... I have EMI/EMC and ESD considerations to
worry about, plus third-party regulatory issues. Changing the micro
means about three weeks of qual time and potentially a long time in
queue for regulatory approval.

> go the same way. As long as the chip isn't packaged in BGA, then even
> homebrew is possible. Just out of interest what ARM tools do you use?

As a global rule, I use gcc by preference where a port is available and
there are no special considerations that mandate the use of a different
toolchain. I currently use a Macraigor wiggler for ARM development but
will likely be migrating to a different solution in the near future.

My ARM projects to date have mostly been on the extreme high end,
running a full-blown OS where I can do hosted debugging. So the JTAG is
used basically for board bring-up; once the hearbeat is there I use
software tools to debug the app layer.

Anton Erasmus scrobe on the papyrus:

.
.
.
> I agree that the 32bit route is the better way, but if you have to
> stick to the AVR, then use a 32bit integer as your "pointer".
> Translate this to RAMPZ, Z when you need to use it. Not as clean 
> as using a true pointer.
> 
> Regards
>   Anton Erasmus

A good solution, but it would require some assembler. Unless I can
convince my C compiler vendor that he needs to enable me to access data
blocks in Flash that cross a 64K boundary, using that method.

I would be interested to hear what someone from Atmel has to say in the
defence of this mega256x feature.

-- 
John B

larwe scrobe on the papyrus:

> 
> John B wrote:
> 
> > Yes all of those, but the big plus is that it's a no-brainer to
> > upgrade from the mega128 to the mega2561. The same PCB can be used,
> > so there are no new NRE charges and no additional hardware debug
> > time.
> 
> Well, not for you maybe... I have EMI/EMC and ESD considerations to
> worry about, plus third-party regulatory issues. Changing the micro
> means about three weeks of qual time and potentially a long time in
> queue for regulatory approval.

Luckily I don't have those problems as I am retired and only do
one-off's nowadays. :-)

> 
> > go the same way. As long as the chip isn't packaged in BGA, then
> > even homebrew is possible. Just out of interest what ARM tools do
> > you use?
> 
> As a global rule, I use gcc by preference where a port is available
> and there are no special considerations that mandate the use of a
> different toolchain. I currently use a Macraigor wiggler for ARM
> development but will likely be migrating to a different solution in
> the near future.

ARM7 is something I want to investigate as I haven't used it since the
Arm2.5 which was in the Acorn Archimedes that I owned about 12 years
ago!!! So I'll get a copy of gcc and try it, probably with the mega2561
first to get a handle on the tools.

> 
> My ARM projects to date have mostly been on the extreme high end,
> running a full-blown OS where I can do hosted debugging. So the JTAG
> is used basically for board bring-up; once the hearbeat is there I use
> software tools to debug the app layer.

I don't think I'll be going there, I can live without the stress of a
project like that. After all summer is supposed to be on its way and
the rain must stop soon surely.


Thanks, and good luck.

-- 
John B

> > Well, not for you maybe... I have EMI/EMC and ESD considerations to
> > worry about, plus third-party regulatory issues. Changing the micro
>
> Luckily I don't have those problems as I am retired and only do
> one-off's nowadays. :-)

I have some of these problems even on my one-offs :( The submarine
project for instance.

> ARM7 is something I want to investigate as I haven't used it since the
> Arm2.5 which was in the Acorn Archimedes that I owned about 12 years

:) I loved the Archie from the moment I played Virus. I was so thrilled
to get a copy of Virus for the Amiga.

> ago!!! So I'll get a copy of gcc and try it, probably with the mega2561
> first to get a handle on the tools.

avrgcc is kind of the gcc experience "lite". There's rather a lot of
extra magic grafted on, mainly in avr-libc, in order to support
interrupts and so forth in C.

If you're working with small ARM parts, hit Olimex's site for cheap
tools. I love that place.

> project like that. After all summer is supposed to be on its way and
> the rain must stop soon surely.

*sigh* I loathe summer. I have a little clock I built on my wall here,
counting down days, hours, minutes and seconds until winter
(12/21/2006, 19:22 UT). Can't wait for the first snow to come.

"John B" <spamj_baraclough@blockerzetnet.co.uk> wrote in message
news:4a4kstFquf15U1@individual.net...
> Anton Erasmus scrobe on the papyrus:
>
> .
> .
> .
> > I agree that the 32bit route is the better way, but if you have to
> > stick to the AVR, then use a 32bit integer as your "pointer".
> > Translate this to RAMPZ, Z when you need to use it. Not as clean
> > as using a true pointer.
> >
> > Regards
> >   Anton Erasmus
>
> A good solution, but it would require some assembler. Unless I can
> convince my C compiler vendor that he needs to enable me to access data
> blocks in Flash that cross a 64K boundary, using that method.

Have you tried using an index instead of a pointer? Your compiler may
already do what you want.

> I would be interested to hear what someone from Atmel has to say in the
> defence of this mega256x feature.
>
> -- 
> John B

I'm curious why you need a single 64k+ lookup table. I've used LUT
approximations with one or more derivatives (see Jack Crenshaw's
book/articles) to reach 24-bit accuracy in a few hundred *bytes* (including
the code to evaluate the series). A 64k table seems like a huge waste of
space.

Bob