MSP430 512Bytes of RAM? - Page 1
Forum section: electronics / general

author: FenderBender
author_rank: Super Contributor
timestamp: July 26, 2012, 01:20:44 am
content: 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.

author: free_electron
author_rank: Super Contributor
timestamp: July 26, 2012, 02:06:06 am
content: Depends on the compiler you use...Ive used 8051's with 256 bytes for years without running out of ram.

author: slateraptor
author_rank: Frequent Contributor
timestamp: July 26, 2012, 03:22:12 am
content: 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.

author: poorchava
author_rank: Super Contributor
timestamp: July 26, 2012, 10:47:54 pm
content: 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

author: slateraptor
author_rank: Frequent Contributor
timestamp: July 26, 2012, 11:57:53 pm
content: Quote from: poorchava on July 26, 2012, 10:47:54 pme.g. coding string literals for an external LCD as character arrays rather than exploiting onboard flash.

author: rsjsouza
author_rank: Super Contributor
timestamp: July 27, 2012, 12:25:02 am
content: 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.

author: poorchava
author_rank: Super Contributor
timestamp: July 27, 2012, 06:25:42 am
content: 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.

author: erupter
author_rank: Contributor
timestamp: July 27, 2012, 10:10:47 am
content: Quote from: FenderBender on July 26, 2012, 01:20:44 amHave 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

author: nctnico
author_rank: Super Contributor
timestamp: July 27, 2012, 01:38:39 pm
content: Quote from: FenderBender on July 26, 2012, 01:20:44 amJust 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.

author: T4P
author_rank: Super Contributor
timestamp: July 27, 2012, 03:40:40 pm
content: Quote from: erupter on July 27, 2012, 10:10:47 am... PIC32 DIP chips are really expensive, they start from 4$ ...Don't talk about PIC24 either, they are the same sort of evil....

author: erupter
author_rank: Contributor
timestamp: July 27, 2012, 03:59:44 pm
content: Quote from: DaveXRT on July 27, 2012, 03:40:40 pmWell if 4$ isexpensive...Ok, I've been stripped of all my weapons

author: Bloch
author_rank: Unknown
timestamp: July 27, 2012, 07:15:06 pm
content: Quote from: erupter on July 27, 2012, 03:59:44 pmIt sure isI can get 4 PIC12F675 (64 Bytes of Ram) for 4$

author: markus_b
author_rank: Regular Contributor
timestamp: July 27, 2012, 07:36:08 pm
content: Quote from: FenderBender on July 26, 2012, 01:20:44 amI 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.

author: T4P
author_rank: Super Contributor
timestamp: July 28, 2012, 05:01:59 am
content: Quote from: erupter on July 27, 2012, 03:59:44 pmWell 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)Quote from: markus_b on July 27, 2012, 07:36:08 pmCost differences and speed upgrades

author: kfishy
author_rank: Newbie
timestamp: July 28, 2012, 10:19:37 pm
content: Quote from: poorchava on July 27, 2012, 06:25:42 amNo 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

author: FenderBender
author_rank: Super Contributor
timestamp: July 28, 2012, 11:53:04 pm
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: July 29, 2012, 07:44:06 am
content: 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.

author: T4P
author_rank: Super Contributor
timestamp: July 29, 2012, 03:35:09 pm
content: 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

author: westfw
author_rank: Super Contributor
timestamp: July 29, 2012, 08:39:18 pm
content: QuoteAFAIK, 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" fromhttp://www.bknd.comand 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.)

author: Bored@Work
author_rank: Super Contributor
timestamp: July 29, 2012, 09:26:14 pm
content: Quote from: westfw on July 29, 2012, 08:39:18 pmNot 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 fromhttp://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 patcheshttp://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.

author: asbokid
author_rank: Regular Contributor
timestamp: July 30, 2012, 12:33:06 am
content: Not good to hear at all. It's so unfair when huge corporations abuse the benevolence of We the little people.

author: westfw
author_rank: Super Contributor
timestamp: July 30, 2012, 02:09:54 am
content: At least Atmel has someone charged with keeping contact with the open source community.QuoteOf 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.

author: rsjsouza
author_rank: Super Contributor
timestamp: July 31, 2012, 12:18:55 pm
content: Quote from: westfw on July 29, 2012, 08:39:18 pmThat is not true; I know that TI helps with the development of mspgcc for MSP430.

author: ColinB
author_rank: Contributor
timestamp: July 31, 2012, 01:59:57 pm
content: The best microcontroller for any project is really determined by specific application requirements, likelow power, esp. if battery powered (active CPU power, sleep power w/ 32.768 kHz crystal)wakeup time from sleep, if using power-saving modeslow costprocessing speed - general program flowprocessing speed - math (multiply, divide, 16/32 bit math)RAM and flash storage requirementsflexibility to swap out the MCU with other footprint-compatible parts with more or less memory etc.I/O peripheralstoolchain and code library supportinterrupt 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.

author: mrflibble
author_rank: Super Contributor
timestamp: August 04, 2012, 05:41:21 pm
content: Quote from: FenderBender on July 26, 2012, 01:20:44 amI'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.

author: poorchava
author_rank: Super Contributor
timestamp: August 04, 2012, 06:06:07 pm
content: 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.

author: joseph.anand
author_rank: Regular Contributor
timestamp: August 18, 2012, 04:05:45 pm
content: Quote from: Bored@Work on July 29, 2012, 09:26:14 pmI 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.

author: OndraSter
author_rank: Contributor
timestamp: August 19, 2012, 11:52:34 am
content: .data section, not .bss+heap sections obviously are placed in flash.On current GCCs on AVR you can force that with PROGMEM flag.

author: nctnico
author_rank: Super Contributor
timestamp: August 19, 2012, 09:26:58 pm
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: August 20, 2012, 04:51:25 am
content: 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 fromCode:struct {int a, b, c} PROGMEM foo = {0xdead, 0xbeef, 0xd00d};int d = x + pgm_read_word(&foo.c);toCode: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 likeCode:int d = x + pgm_read_word(((char *)&foo) + 2 * sizeof(int));