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
Atmel ATmega2561 is no better than PIC16F84
Started by ●April 11, 2006
Reply by ●April 12, 20062006-04-12
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
Reply by ●April 12, 20062006-04-12
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 aI'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.
Reply by ●April 12, 20062006-04-12
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
Reply by ●April 12, 20062006-04-12
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
Reply by ●April 12, 20062006-04-12
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.
Reply by ●April 12, 20062006-04-12
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 ErasmusA 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
Reply by ●April 12, 20062006-04-12
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
Reply by ●April 12, 20062006-04-12
> > 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.
Reply by ●April 12, 20062006-04-12
"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 BI'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