Tech Support > Computer Hardware > Microprocessors > Atmel ATmega2561 is no better than PIC16F84
Atmel ATmega2561 is no better than PIC16F84
Posted by John B on April 12th, 2006


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

Posted by Tauno Voipio on April 12th, 2006


John B wrote:

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

Posted by larwe on April 12th, 2006



John B wrote:
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.


Posted by John B on April 12th, 2006


larwe scrobe on the papyrus:

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.


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

Posted by Anton Erasmus on April 12th, 2006


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

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


Posted by larwe on April 12th, 2006



John B wrote:

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.

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.


Posted by John B on April 12th, 2006


Anton Erasmus scrobe on the papyrus:

..
..
..
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

Posted by John B on April 12th, 2006


larwe scrobe on the papyrus:

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

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.

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

Posted by larwe on April 12th, 2006




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

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

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.

*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.


Posted by Bob on April 12th, 2006


"John B" <spamj_baraclough@blockerzetnet.co.uk> wrote in message
news:4a4kstFquf15U1@individual.net...
Have you tried using an index instead of a pointer? Your compiler may
already do what you want.

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



Posted by Coos Haak on April 12th, 2006


Op 12 Apr 2006 08:58:04 -0700 schreef larwe:

<snip>
<OT>
Ha, you don't have to wait _that_ long, it will be already in
the very early morning, at 0.22 UT.
'Sterrengids 2006' (our product, 90-6638-051-9) says so.
I'll look next week in Astronomical Tables of Jean Meeus to
be sure though.
</OT>

--
Seasons greetings, Coos

www.dekoepel.nl

Posted by Coos Haak on April 12th, 2006


Op Wed, 12 Apr 2006 19:10:14 +0200 schreef Coos Haak:

<OT>
We still have to wait a little longer, it's 22 december!
</OT>

--
Coos

Posted by John B on April 12th, 2006


Bob scrobe on the papyrus:

..
..
..
No I haven't but I will.

..
..
..
Well, I'll let you into a little secret, what I'm actually trying to do
is break the compiler that I use. The critical part is the 64K boundary
crossing and generating a big LUT ensures that happens. At the moment
I'm just using AVR Studio to see what happens, but when I find a fix
I'll try the real silicon. >:-}

I attended an Atmel seminar way back in November 2004 at which the
mega256x series was announced. I asked the question then, if this
problem would be fixed (it was the same in the mega128) and was assured
that it would be. It seems they were wrong.

--
John B

Posted by larwe on April 12th, 2006



Coos Haak wrote:

My source:

<http://aa.usno.navy.mil/data/docs/EarthSeasons.html>


Posted by Ulf Samuelsson on April 12th, 2006


"John B" <spamj_baraclough@blockerzetnet.co.uk> skrev i meddelandet
news:4a2rmgFr0022U1@individual.net...
According to the Instruction Set Reference Manual, it should increment.

"This instruction can address the entire Program memory space.
The Z-Pointer Register can either be left unchanged by the operation, or it
can be incremented.
The incrementation applies to the entire 24 bit concatenation of the RAMPZ
and Z-pointer register"

If it doesn't then I would say there is a bug in the core.

--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB



Posted by CBFalconer on April 13th, 2006


larwe wrote:
The proper cure for summer is to get out of NYC. Come up to Maine,
find fresh air, low humidity, fresh water, go swimming, etc. The
black flies are gone by July 4th.

If you really want it cold just do the swimming in the open ocean.
Otherwise stick to fresh water.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>



Posted by Uwe Bonnes on April 13th, 2006


CBFalconer <cbfalconer@yahoo.com> wrote:
What are these black flies?
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Posted by larwe on April 13th, 2006



CBFalconer wrote:

I think Siberia is more my style. I want someplace to live where I
can't see my neighbors, taxes are low, and the temps rarely or never go
above 60F.

Eeee. I wonder if those are the same things I'm thinking of... back
home in Australia there are some NASTY fly-shaped creatures that I
believe to be the physical manifestation of some kind of demon. Very
large (for flies), and bloodsucking. They'll go right into your feet
through the stitching holes in your shoes, and light clothing doesn't
deter them in the slightest. Unaffected by insect repellents, also.


Posted by Andrew M on April 13th, 2006



"larwe" <zwsdotcom@gmail.com> wrote in message
news:1144926121.030544.166620@i40g2000cwc.googlegr oups.com...

I believe the creature you're referring to is called a "taxation officer"
-Andrew M (in Oz)



Posted by larwe on April 13th, 2006



Andrew M wrote:

Hopefully not too many of those in Ballarat, which is approximately
where I saw these horrific beasts. We had a couple of acres there many
years ago, on which we put two red rattlers when they were being
decommissioned. (Someone stole them. How do you steal two 60-foot
railway carriages?)

Great place to spend time, except that the entire property was riddled
with mining survey holes a foot across and 30-60 feet deep. Mostly
overgrown with bracken, of course.



Similar Posts