Moving up from 128A4U to 256A3U, any catches? warnings?

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

I had very slowly been building up to about 50% in-use on my 128A4U program memory space. Then I got into a big patch of code with a lot of 64 bit math, and the second half of my memory disappeared very quickly: 

 

                Program Memory Usage     :    131424 bytes   94.4 % Full

                Data Memory Usage         :    4983 bytes   60.8 % Full

 

I can, with a couple days work, change out the 128A4U for a 256A3U on my circuit board, but is there any catch to doing that? Will it really double my data and program memory without any additional work?

 

(I realize the pinouts are entirely diff, that some special port functions may need to be juggled. I am only asking about memory usage and existing code on my part like accessing ___flash and such. Is all my 128A4U code totally compatible with the new big space in the 256A3U?)

 

Thanks!

Mike

 

 

 

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

One thing to check first, what optimization are you using? -Os might help if you are not using it at the moment.

 

Anyway, as for switching they are mostly compatible in terms of the peripherals. The main thing to watch out for is if you have .boot defined, because it will be at a different address. Otherwise the compiler will take care of all the memory related stuff.

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

Then I got into a big patch of code with a lot of 64 bit math

 

I have never used 64bit in GCC, but the 32bit is very big (-Os don't make lib code so it's about same size as -O2), so if the 64 bit is made the same way, some general functions that take pointers as arguments will be smaller.  

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

 

Thanks for your replies. I was doing astronomical calculations with doubles and found that it wasn't quite nailing down the positions of planets extremely well. 

 

My question is mostly "is it really a free lunch? Suddenly you have double the resources?" My concern comes from a several years old memory, I think it was about the 384 kb XMEGA's, that there was something where addressing wasn't the same and so it wasn't easy like flipping a switch.

 

Mike

 

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

The XMEGA range is pretty good about having a consistent set of peripherals. If they change anything they usually rename the registers or bits too, so your code will fail to compile and you will be prompted to fix it.

 

The memory size issue is less of a thing with XMEGA than with the older AVRs. The main thing is that if you have more than 64kb of data it gets tricky, but there are no issues with large amounts of code. The only thing to watch out for is the location of the bootloader section. You may need to move .boot, and if you jump in to the bootloader you may need to adjust the ENID register value. The parts are not binary compatible, but the compiler will sort everything out when you recompile.

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

I will add:

When you go from a 16 bit PC to a bigger, the code gets a tad slower (and bigger), and a bit more RAM are used for the stack.

Make sure that your lib's work with this.  

Last Edited: Tue. Feb 9, 2016 - 09:39 AM