Hi all.. I realize that bigger is better, but some microcontrollers have very small RAM sizes available -- one that I'm looking at (not a pic) has only 2k and I see nobody complaining about needing more on their support forums.. If I'm going to program in C, I'd assume any run-time stack data would eat into that 2k (or similar for other parts) along with global data items not marked as const or similar to direct the compiler/linker to put them into flash.. Is there anything else that might contribute to low-ram situations? Obviously malloc (if available) would come from that as well.. Any others?

Have you had any issues with using μC's with little RAM and did you find yourself looking for more next time?

Just curious...

 

Global variables, stack, and heap (malloc) pretty much covers it.

I would venture to say that most 8-bit microcontroller apps are very small, and that limits their complexity. Usually malloc isn't even used, so it's just global variables and stack.

I more often run out of program space than RAM. Of course, it all depends on the type of application. The RAM-to-code ratio isn't a universal constant.

There are some obvious use cases where RAM is at a premium, e.g. recording audio samples at reasonable fidelity. But in those cases you have a good chance of knowing before writing a single line of code that that's going to be a concern, and you can easily plan for it.

You should be able to at least estimate your RAM requirements from the project requirements. It's much harder to estimate program size ahead of time.

 

Thanks for the input.. I guess I wasn't too far off.. I also figured that most people are probably not using malloc in embedded apps..

 

Is there anything else that might contribute to low-ram situations?

Try to maximize use of local vars so that the compiler can re-use the RAM.
Watch what you do in interrupt routines. If an IRQ service uses arithmetic routines for example, the context switch will have to context-store lots of temp regs etc. Best to note that the IRQ happened and do the grunt work in the main code.
Try to pick a variant of the chip that has some compatible part with more RAM that you can migrate to if necessary so that you are not stuck. I actually do it in the reverse; develop on the biggest memory variant of a family that has smaller members. You won't run out of RAM/ROM/Tcycs until you are way deep into the project.

Other than that, looks like you've covered most of the bases.

 

Since I own this thread.. , I think I'll steer it in a slightly different direction.. With all of you having developed various embedded devices, what development environments have stuck out as the best thought out in terms of :

• IDE (development environment) -- editor, debugger, and everything in between (programming, code templates/helpers, call-trees, etc) -- basically anything that would help to make your development tasks easier.
• hardware simplicity / elegance -- in how it integrates with the IDE/dev environment..
• debugging capabilities (jtag or similar) -- ability of IDE to completely control CPU remotely via cable -- provide for breakpoints,watchpoints, debug into interrupt handlers,etc
• Good support whether via community 'help' or company sponsored.

I realize that some of the results may be skewed a bit since some platforms (e.g. pic) will be more pervasive in terms of use (e.g. Microchip),etc.. Overall, I don't care what mfg here -- whether it be Zilog, STM, Microchip, Freescale, etc.. Overall, I guess I'd like a microcontroller + IDE that is well thought out, easy to develop for (no wierd quirks/work-arounds and the like), flat address/RAM space if possible (I gather some parts have funny bank switching needs), etc..

P.S. I should note that I'm not specifically tied to any particular programming language -- whether it be C, C++, Forth, Pascal, Modula-2, etc.. I've written code in many programming languages over the years but would prefer to avoid assembly at this point but most anything else is open..

 

I have used CodeWarrior from Metrowerks (now owned by Freescale) extensively with Freescale products
and IAR Embedded Workbench for everything else.
Both products are superb, no complaints.

 

RAM size has secondary importance since you can always use external RAM chips. Parallel or serial.

And 2K is a lot of RAM!

No there is no malloc used for 8-bit PICs and it would be highly unusual for any other 8-bit chip.

8bit PICs can have 2,8,16 or 32 stack levels. They don't use a software stack by default. And no, typical programs for these chips won't need 2K stack space.

I have for instance added a 2K external RAM chip to PIC 16F59. Since the RAM is banked into 16-byte pieces! But only 256 bytes are addressable (one 8bit port is used for that).

 

IDE (development environment) -- editor, debugger, and everything in between (programming, code templates/helpers, call-trees, etc)

Honestly, I only use all that stuff for PC/mobile development. I've found that apps on 8-bit machines, a few kilobytes of code tops, it's not even worth the bother. I use Notepad. I type "make" to compile, upload to the chip, and re-run.

debugging capabilities (jtag or similar)

For debugging on 8-bitters I can usually get away with a single LED connected to the chip to display status. For tricky cases I have a logic analyzer--those things are awesome. I'm not opposed to JTAG and that sort of thing. I just personally haven't needed to go that far. But I've been writing code for decades.

I started with AVR chips and just stuck with them. The architecture is very straightforward.

 

Honestly, I only use all that stuff for PC/mobile development. I've found that apps on 8-bit machines, a few kilobytes of code tops, it's not even worth the bother. I use Notepad. I type "make" to compile, upload to the chip, and re-run.

A few years ago I played with a data logger based on the arduino platform.. It worked great until you started getting to the limits of what it could deal with code-size wise.. When it started acting wonky it would have been nice to have a JTAG or similar debugger but all I had was a lousy LCD 2 line screen to do printf()'s with and an LEd or two.. I would have loved to had a full-on debugger at my beck-n-call.. But I resorted to commenting blocks of code out trying to figure out what was wrong -- eventually just figuring I was running out of space (although the freeware IDE didn't complain).. So, I'd rather have something a bit better at this point.