MSP430 512Bytes of RAM?

[FenderBender]

I was planning on making a switch to MSP430 from Arduino and I was going through some of the specs and the standard DIP package has only 512B of memory. I never ran into RAM limitations with my Arduino, but it has 2KB.

Any one ever have problems with a low amount of memory? How big of a project can you do with only 512B? That's probably hard to answer...but...just your thoughts.

Thanks.

[free_electron]

Depends on the compiler you use...

Ive used 8051's with 256 bytes for years without running out of ram.

[slateraptor]

Chances are good that you won't run into internal RAM limitations for typical hobbyist projects. There are ways of getting around space limitations too, e.g. exploiting embedded flash, or integrating an external memory device like SPI RAM or an SD card.

[poorchava]

The way i see it applications which indeed need a lot of RAM memories are limited to either DSP or some implementations of standard protocols/stacks (like IP, USB, FAT-fs, MP3 encoding etc). In most other cases you can get away abusing flash memory's ability to reprogram at runtime. Of course it needs a bit more operations than writing 'x=3;' but is doable.

In most cases if you run out of ram it means that your FW is poorly designed

[slateraptor]

In most cases if you run out of ram it means that your FW is poorly designed

e.g. coding string literals for an external LCD as character arrays rather than exploiting onboard flash.

[rsjsouza]

One detail to save memory (and sometimes avoid headaches) is to pay close attention to the size of the "standard" C types... In MSP world, a char is 8 bits and an int is 16 (not sure how it is in Arduino, but this varies greatly from processor to processor).

I usually include the TI's compiler <stdint.h> and use its types uint8_t, uint16_t, etc. so you know exactly the size in bits of your variables.

[poorchava]

Good practices when you are lacking ram:
-use dynamic memory allocation (lists, heaps, stacks)
-use custom data structures to make the most use of the memory available
-use flag registers to store binary info
-make up your mind as to what will be variable and what will be constant. Put constants in flash
-use compiler options (eg. linker scripts, various IDE specific macros) to make sure that constants and variables are being put in the place where you want them to be.
-make use of precomputation. For example when you are converting a result from a sensor which has transfer characteristic given as a mathematical formula, you may want to compute possible measured value vs output signal combinations and store those as a lookup table in flash (extent to which this can be used depends on type of operation).
-avoid operations on floats/doubles
-avoid division operations. They take many registers, and therefore compiler may decide to put certain stuff into RAM to free up those needed registers prior to division.

[erupter]

I was planning on making a switch to MSP430 from Arduino and I was going through some of the specs and the standard DIP package has only 512B of memory. I never ran into RAM limitations with my Arduino, but it has 2KB.

Any one ever have problems with a low amount of memory? How big of a project can you do with only 512B? That's probably hard to answer...but...just your thoughts.

Thanks.

Have a look at microchip's DIP pic32s. 1series and 2series.
They should have lots of ROM and ram for your use.

Swiped on my Optimus2X with Tapas

[nctnico]

I was planning on making a switch to MSP430 from Arduino and I was going through some of the specs and the standard DIP package has only 512B of memory. I never ran into RAM limitations with my Arduino, but it has 2KB.

Any one ever have problems with a low amount of memory? How big of a project can you do with only 512B? That's probably hard to answer...but...just your thoughts.

Just get a chip with as much ram as possible. You can always try to save ram to shave a few pennies from the cost of a product. In most cases its not worth the effort (time=money spend versus savings). You want to build something, not fight for resources.

[T4P]

I was planning on making a switch to MSP430 from Arduino and I was going through some of the specs and the standard DIP package has only 512B of memory. I never ran into RAM limitations with my Arduino, but it has 2KB.

Any one ever have problems with a low amount of memory? How big of a project can you do with only 512B? That's probably hard to answer...but...just your thoughts.

Thanks.

Have a look at microchip's DIP pic32s. 1series and 2series.
They should have lots of ROM and ram for your use.

Swiped on my Optimus2X with Tapas

... PIC32 DIP chips are really expensive, they start from 4$ ...
Don't talk about PIC24 either, they are the same sort of evil....

[erupter]

... PIC32 DIP chips are really expensive, they start from 4$ ...
Don't talk about PIC24 either, they are the same sort of evil....

Well if 4$ is expensive...
Ok, I've been stripped of all my weapons 

[Bloch]

... PIC32 DIP chips are really expensive, they start from 4$ ...
Don't talk about PIC24 either, they are the same sort of evil....

Well if 4$ is expensive...
Ok, I've been stripped of all my weapons 

It sure is    I can get 4 PIC12F675 (64 Bytes of Ram) for 4$ 

[markus_b]

I was planning on making a switch to MSP430 from Arduino and I was going through some of the specs and the standard DIP package has only 512B of memory. I never ran into RAM limitations with my Arduino, but it has 2kB

I would think that going from an arduino to a MSP430 is more a side-grade than an upgrade. Why not using the same chips, sans the Arduino board ? You'll be able to reuse your Arduino skills and programming environment.
 

[T4P]

... PIC32 DIP chips are really expensive, they start from 4$ ...
Don't talk about PIC24 either, they are the same sort of evil....

Well if 4$ is expensive...
Ok, I've been stripped of all my weapons 

Well in comparison ...
Adding on top of that is the free compilers for PIC is just garbage, it doesn't optimize your code much.
If i wanted a 32bitter ... STM32 here i come (For prototyping uses just get a TQFP > DIP converter)

I was planning on making a switch to MSP430 from Arduino and I was going through some of the specs and the standard DIP package has only 512B of memory. I never ran into RAM limitations with my Arduino, but it has 2kB

I would think that going from an arduino to a MSP430 is more a side-grade than an upgrade. Why not using the same chips, sans the Arduino board ? You'll be able to reuse your Arduino skills and programming environment.
 

Cost differences and speed upgrades

[kfishy]

Good practices when you are lacking ram:
-use dynamic memory allocation (lists, heaps, stacks)

No no no... That's a Very Bad Idea when you're developing in a resource constrained environment such as microcontrollers. First of all, unless you're writing your own memory allocation algorithms, chances are the library malloc/new you're using is not deterministic, which means you cannot rely on it to allocate deterministically. Then, and a related point, if you're allocating/deallocating segments of different sizes, you'll run into the problem of heap fragmentation, which means that even though the system still has memory left, malloc fails because it cannot find any more contiguous "free" memory.

It's much better to use a static "heap" (like a fixed 256-bytes char array) or follow the Resource Acquisition is Initialization idiom.

Tony

[FenderBender]

Thanks. I'm not sure now. I might just stick to Arduino until I see a "real" need to switch to something else. Get better at Arduino.

[westfw]

There ARE msp430 chips with more than 512 bytes of RAM.  They just don't include the really cheap and easy-to-use (DIP) "Value line" chips that are included with the LaunchPad.

As others have said, 512bytes of RAM is a "meaningful" and useful amount, depending on what you're doing.

[T4P]

Unless it's a PIC compiler, the free compilers really suck at optimization ( or should i say ZERO optimization? )
Well then, that said MSP430's compilers are decent

[westfw]

the [PIC] free compilers really suck at optimization

AFAIK, this is only true of the 8-bit PIC compilers from Microchip.  The 16bit (pic24) and 32bit (pic32) free compilers are gcc based and have "typical" optimization.  And there are third party compilers for the 8bit PICs that have free versions (usually code size limited) that do decent code generation; I've used "cc5x" from http://www.bknd.com and been happy with it.

As for free msp430 compilers, there is a version of gcc that is being actively developed.  This is not the same as "TI supporting open source", because I don't think there is active cooperation from TI.  (OTOH, there isn't active opposition, either.  I believe that the current version uses TI-authored include files for chip definition stuff, which TI could nix if they wanted to.)  (Atmel does some active support of avr-gcc.  OTOH, Atmel doesn't document their debug protocols, while TI apparently does.  Vendors are weird.)

[Bored@Work]

(Atmel does some active support of avr-gcc.

Not really. Atmel maintains their own gcc fork which they ship with Studio, and, if you know where to find it, stand-alone. They even use their own version numbering, not the official gcc version numbering. Atmel's codebase is based on some older gcc release (currently something like 4.6.x, which they call something like 3.4.x, to confuse people).

Atmel doesn't even use 4.7.x, which introduced some important changes, e.g. for placing data in flash memory. And official gcc development has already reached 4.8.x.

Initially it took some pressure from the community to make Atmel fulfil their GPL obligations by releasing their changes to gcc. And some more pressure to get obviously missing things. These days you can either get old patches from http://distribute.atmel.no/tools/opensource/ (that stuff is outdated) or register with Atmel to get what they claim are the current patches.

It is hard to verify if they indeed released all their changes, but try your luck with the patches http://www.atmel.com/Images/avr8-gnu-toolchain-3.4.0.663-source.zip (that link should bypass their pointless registration).

Non of these patches are really useful for the 4.7 or 4.8 codebase.

[asbokid]

Not good to hear at all.  It's so unfair when huge corporations abuse the benevolence of We the little people.

[westfw]

At least Atmel has someone charged with keeping contact with the open source community.

Atmel doesn't even use 4.7.x, which introduced some important changes ... And official gcc development has already reached 4.8.x.

Of course, the "gcc team" supporting AVR is very tiny too, and spends a lot of time trying to fix avr-related things that end up broken because of the actions and philosophies of the greater gcc community (who doesn't much care about 8bit microcontrollers.)  One reason that Arduino is stuck back at gcc version 4.3 is that most of the official gcc releases since then have been catastrophically broken (for AVR) in one way or another.

And it's probably a mistake to consider Atmel a "huge corporation"; one of the things you eventually realize about chip companies is that the number of people they have actually writing microcontroller or tools software for a particular chip is ... quite small.  I expect that Atmel has more people maintaining their web pages than they have working on gcc.

[rsjsouza]

As for free msp430 compilers, there is a version of gcc that is being actively developed.  This is not the same as "TI supporting open source", because I don't think there is active cooperation from TI.

That is not true; I know that TI helps with the development of mspgcc for MSP430.

[ColinB]

The best microcontroller for any project is really determined by specific application requirements, like

• low power, esp. if battery powered (active CPU power, sleep power w/ 32.768 kHz crystal)
• wakeup time from sleep, if using power-saving modes
• low cost
• processing speed - general program flow
• processing speed - math (multiply, divide, 16/32 bit math)
• RAM and flash storage requirements
• flexibility to swap out the MCU with other footprint-compatible parts with more or less memory etc.
• I/O peripherals
• toolchain and code library support
• interrupt handling capability (e.g., MSP430/AVR is much better than PIC 8-bit)

Personally, I think MSP430 gets almost everything right.  PIC has a lot of options because there are so many parts, and Microchip has an outstanding record of maintaining long-term supply for parts; however, the lack of a decent free compiler for the 8-bitters and the single interrupt (or two-interrupt for PIC18) make it less somewhat less attractive.  AVR is a bit cleaner architecture than PIC in some ways, but there is less flexibility in each package to scale up and down the range (contrast with e.g., 8-bit PIC in 28-pin SSOP/SOIC/DIP where you can go from cheapo PIC16 up to a decently big PIC18 w/ 128KB flash).  ARM Cortex-M3/M0 is a great option and is a super clean architecture, but for battery-powered applications that need very low average power, you have to spend several dollars to get a part (e.g., STM32L or Energy Micro EFM32); the cheapest $1.00 to $2.00 processors can't touch the MSP430's low power.

In all, the MSP430 Value Line is really awesome.  Great clean architecture that makes compact code, with a powerful and totally free compiler (gcc).  I just wish there was a footprint-compatible option with more than 512 bytes of RAM.  You have to just up to QFN/QFP packages in the MSP430F5 line to get more RAM, and then there is no compatible low-cost (e.g., $1.00) option.  The problem is that at the start of a project, you might not know for certain how much RAM you'll need, as requirements ALWAYS change during a project.

[mrflibble]

I was planning on making a switch to MSP430 from Arduino and I was going through some of the specs and the standard DIP package has only 512B of memory. I never ran into RAM limitations with my Arduino, but it has 2KB.

Any one ever have problems with a low amount of memory? How big of a project can you do with only 512B? That's probably hard to answer...but...just your thoughts.

Thanks.

I'd say it mostly depends on your applications and also to some degree on your tools. For the simple stuff that I do on a msp430 I've never ran into memory related problems. Just don't do any large DSP tasks on it.

[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));