MSP430 512Bytes of RAM?

[poorchava]

Good rule to follow is that small and cheap microcontrollers are for simple tasks and power saving. More powerful and complex (not necesarily much more expensive) microcontrollers are for more demanding tasks. Unless you're planning to mass produce something, it doesn't matter if you overspecify you microcontroller. You invest an extra 2-3 bucks and you're pretty sure that you don't run into situations like "shit, no i/o left", "damn, i need 3 more cycles between interrupts", "damn, out of ram" etc. And situations mentioned above generally result in cutting your design's capabilities to fit hardware, redesigning the pcb or spending countless hours on optiomizing code to fit your device. What for? It's better to pay those extra two bucks.

[joseph.anand]

Atmel doesn't even use 4.7.x, which introduced some important changes, e.g. for placing data in flash memory.

I do not understand the need for having the latest version of GCC for microcontrollers (especially 8 and 16bit ones). Its not like I am running some CPU intensive computation on these devices.

Using the uC's flash memory as a substitute for RAM in a product is a very bad idea if the memory location is likely to see a lot of write operations. Unlike  RAM, flash memories are rated for a certain number of write cycles (typically around 1million or so). Its very easy to exhaust it when you. If I were Atmel I would intentionally disable the ability to place volatile data in flash memory.

[OndraSter]

.data section, not .bss+heap sections obviously are placed in flash.

On current GCCs on AVR you can force that with PROGMEM flag.

[nctnico]

There is a big advantage on knowing how to write your own ld linker scripts. You can also do nice things like reserving stack space and getting an error when you run out of ram.

[westfw]

The new flash-related feature allows READ-ONLY data ("const") to be accessed as variables from normal C code.  Since since the AVR has a separate address space for flash, this is a moderately big deal.  In older versions of the compiler you had to do your own address calculations and access the flash memory via function calls.  As far as I know, you can't write to flash variables from C;  flash requires a bunch of additional effort to be writable at all (run from bootloader section, have protection fuses set appropriately, flash to be written NOT in bootloader section, write a full "page" at a time, etc.)

However, you should be able to go from

Code: [Select]

struct {int a, b, c} PROGMEM foo = {0xdead, 0xbeef, 0xd00d};

int d = x + pgm_read_word(&foo.c);
to

Code: [Select]

struct {int a, b, c} PROGMEM foo = {0xdead, 0xbeef, 0xd00d};

int d = x + foo.c;
Which is a major simplification for traditional C programmers.  I've had to explain rather often that you can still use the compilers address calculations and data typing, rather than having to do something like

Code: [Select]

int d = x + pgm_read_word(((char *)&foo) + 2 * sizeof(int));