Reliability poll about gcc for 2560 - what things to avoid?

Log in or register to post comments
Go To Last Post
9 posts / 0 new
Author
Message
kbosak
kbosak's picture
Level: Hangaround
Joined: Wed. Jan 30, 2008
Posts: 168 View posts
Location: Wroclaw, Poland
#1
Posted by kbosak: Mon. Jul 6, 2009 - 12:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, I am migrating froim ATMEGA128 up, preferably to 2560.
I remember we were battling recently with the fact that the constructors for the static objects placed above the first 64k were called incorrectly. This bug has beed fixed only recently (a few months ago) despite the uC being quite old.

Now since the ATMEGA2560 is the only uC of the family with 256kB flash, and I need preferable around150kB flash when I join all modules needed, probably I am asking for trouble.
I have no options for using more uC: the footprint is crucial.

I would like to start a poll: how many of you have used more than 128kFlash of the code. Would you advise the migration as clean or not.

Tags:

Tools, Compilers and General Programming
Top
wek
wek's picture
Level: Raving Lunatic
Joined: Fri. Dec 16, 2005
Posts: 3271 View posts
Location: Bratislava, Slovakia
Posted by wek: Mon. Jul 6, 2009 - 12:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is that >128kB of CODE, or <128kB of code + large data?

JW

PS. Currently working on a 'M2561

Top
stu_san
stu_san's picture
Level: Raving Lunatic
Joined: Fri. Dec 30, 2005
Posts: 2327 View posts
Location: Fort Collins, CO USA
Posted by stu_san: Mon. Jul 6, 2009 - 02:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you check my posting for FreeRTOS for ATmega2560/1 you will find the biggest gotchas, with my workarounds. I find the code works better when all ISRs and function-pointer targets are in low memory. Keep in mind that all subroutine calls now put 3 bytes on the stack instead of 2. Watch the state of the EIND register if it is possible to generate an indirect call (this precludes the use of the "call prologue" mechanism for shortening code).

Make sure you find Carlos Lamas' morepgmspace.h file for accessing flash constants above the 64K Byte boundary. (This will be in avr-libc eventually (next rev?)) but is not in the currently released version of WinAVR.)

Otherwise, I've used GCC for my ATmega2560 for years now and the generated code and avr-libc has continually improved.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

Top
TFrancuz
TFrancuz's picture
Level: Resident
Joined: Fri. Jan 10, 2003
Posts: 574 View posts
Posted by TFrancuz: Mon. Jul 6, 2009 - 06:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will wait for avr-gcc 4.5 which will support memory sections. So at least some problems will disappear. Till this moment I will avoid devices with more then 128kB memory.
BTW, more than FLASH I need SRAM. It’s interesting why Atmel cannot put some more SRAM memory into their devices. Adding external SRAM is just a waste of PCB space, IO pins, and money.

Top
stu_san
stu_san's picture
Level: Raving Lunatic
Joined: Fri. Dec 30, 2005
Posts: 2327 View posts
Location: Fort Collins, CO USA
Posted by stu_san: Tue. Jul 7, 2009 - 02:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TFrancuz wrote:
BTW, more than FLASH I need SRAM. It’s interesting why Atmel cannot put some more SRAM memory into their devices. Adding external SRAM is just a waste of PCB space, IO pins, and money.
You might want to look at the Xmega series -- the 128A1 has 8K of SRAM.

I agree that it would be nice if Atmel would create chips with, say, 32K of SRAM. However, it is up to them to choose what they feel is the best mix of components for what they feel is the "sweet spot" of the market. If they put 32K of SRAM on small processors, the cost of the processor goes up. If only a small proportion of their users actually need that space, then they are in a sense leaving money on the table.

As for external SRAM being "a waste of PCB space, IO pins, and money", well, that depends on your application. If you choose an ARM, you not only would need the external SRAM, but also an external Flash (for some processors). You could also choose any number of 8051 derivatives. For my application, the external SRAM is a tiny fraction of the board space and cost of the board. You, of course, must choose for your application.

Engineering is always about trade-offs. As in architecture, creativity is most needed (and rewarded) when the landscape is restricted.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

Top
theusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39611 View posts
Location: Wisconsin USA
Posted by theusch: Tue. Jul 7, 2009 - 05:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Y'all must work in an entirely different world than I do. A Mega32-/Mega64-sized app is about a 6-month project for me. I've come fairly close to filling up a Mega64 a couple of times, say 70%, but those are "full featured" controls that tend to get feature bloat over the years, lots more display panels/menus/etc.

I've only felt "SRAM constrained" on a few Mega48 apps, but never really had to get down to byte-counting or shave stacks below a very comfortable level. Actually to the contrary, the 1k in a Mega8/88 is usually a vast wasteland, but came in real handy in full-blown ModbusRTU to be able to easily buffer a full 256+ byte frame or two.

I can see where it might be convenient, often the best approach, to grab a bigger AVR to dump say graphics fonts into the flash. And I might sing a different tune with a complex protocol stack. [My certified DeviceNET is 3/4 of a Mega162.] But I can't really envision one of my apps getting that big (128k+).

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
wek
wek's picture
Level: Raving Lunatic
Joined: Fri. Dec 16, 2005
Posts: 3271 View posts
Location: Bratislava, Slovakia
Posted by wek: Tue. Jul 7, 2009 - 05:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
But I can't really envision one of my apps getting that big (128k+).

Lucky you. I envy.

I somehow always end up in a project lasting for years and filling up every resource available on a board (and overflowing sometimes, resulting in various piggybacks and similar afterthoughts). Pure nightmare.

The few-kB applications just come in between as a welcome distraction.

JW

Top
kbosak
kbosak's picture
Level: Hangaround
Joined: Wed. Jan 30, 2008
Posts: 168 View posts
Location: Wroclaw, Poland
Posted by kbosak: Wed. Jul 8, 2009 - 03:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek wrote:
Is that >128kB of CODE, or <128kB of code + large data?

All I have is very intensive code.
Cross-calls, all pins used, floating point, probably all peripherals used, all timers used, no RTOS however.

Top
kbosak
kbosak's picture
Level: Hangaround
Joined: Wed. Jan 30, 2008
Posts: 168 View posts
Location: Wroclaw, Poland
Posted by kbosak: Wed. Jul 8, 2009 - 03:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

I've only felt "SRAM constrained" on a few Mega48 apps, but never really had to get down to byte-counting or shave stacks below a very comfortable level.

take GPS at 115kbaud, run your app at 32Hz and suddenly you realise you need 400byte circular buffer.
then you need hard realtime logging somewhere that requires another buffer because of EEPROM latencies. and it goes on. On enery USART I tend to waste 100 bytes at leas because there is always either a copy-paste console, command line, modem reception and decoding, parsing...

Top