Reply by Przemek Klosowski February 12, 20132013-02-12
On Sun, 03 Feb 2013 17:06:30 -0500, Walter Banks wrote:
> In the small processors the amount of RAM requirements for code compiled > with a good compiler is typically 16% of ROM and for assembler typically > 20%. When we were doing studies on this a few years ago these numbers > were remarkably constant. > > (Before someone says it is application dependent, it is but so is the > selection of the processor application dependent) On the larger > processors these numbers don't hold as well.
OK, but how broad was your sample? I mean, I wouldn't be surprised if you had access to a wide selection of code samples (automotive, medical, data acquisition, white goods, audio, etc.). Was it as varied as that?
Reply by Jukka Marin February 12, 20132013-02-12
On 2013-02-08, Paul Rubin <no.email@nospam.invalid> wrote:
> Jukka Marin <jmarin@pyy.embedtronics.fi> writes: >> Freescale Kinetis X claims to have up to 4 MB FLASH and 512 kB SRAM. > > Thanks, this is kind of interesting. It was announced in 2011 but > doesn't appear to have actually shipped. There is some marketing stuff > for it on freescale.com but other stuff seems to have been taken down. > I wonder if the chip was cancelled.
It's been postponed, probably till 2014. Sad. -jm
Reply by Paul Rubin February 8, 20132013-02-08
Jukka Marin <jmarin@pyy.embedtronics.fi> writes:
> Freescale Kinetis X claims to have up to 4 MB FLASH and 512 kB SRAM.
Thanks, this is kind of interesting. It was announced in 2011 but doesn't appear to have actually shipped. There is some marketing stuff for it on freescale.com but other stuff seems to have been taken down. I wonder if the chip was cancelled. Anyway I think I understand the general picture by now, and the 192KB STM part is probably the best answer for the stuff I'm thinking of, mostly because of the low cost development boards (Discovery and Olimex). If 192kb isn't enough, 512kb probably isn't enough either. Next step past that would involve off-chip DRAM.
Reply by Spehro Pefhany February 8, 20132013-02-08
On Mon, 04 Feb 2013 09:41:05 -0500, the renowned rickman
<gnuarm@gmail.com> wrote:

>"Large microprocessors", isn't that like "jumbo shrimp"?
I think he really means "large microcontrollers", since he wants all the memory on-chip (or at least in one package). Best regards, Spehro Pefhany -- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
Reply by Spehro Pefhany February 7, 20132013-02-07
On Thu, 7 Feb 2013 14:45:33 +0000 (UTC), Jukka Marin
<jmarin@pyy.embedtronics.fi> wrote:

>On 2013-02-03, Paul Rubin <no.email@nospam.invalid> wrote: >> I notice that the ram capacity (ignore program flash for now, but it >> tends to basically be proportionate) of microcontrollers seems to grow >> fairly continuously (say in 2x jumps) from very small (a dozen or so >> bytes in an 8 bitter, lots of MSP430's in the 128 to 1k byte range, >> Cortex M0's with 4k, etc.), up to about 32k (Cortex M4). Above that >> there are a few chips with 64k or 128k, that are quite expensive, and >> above that not much is available til you get to external DRAM which on >> ready-made boards usually starts at 32 meg or even 64 meg (Olimex >> Olinuxino) or 512 meg (Raspberry Pi). So there is a big jump from 32k >> to 32 meg. It would be nice to have a low cost, single chip, 256k or 1 >> megabyte device but this doesn't seem to exist. > >Freescale Kinetis X claims to have up to 4 MB FLASH and 512 kB SRAM. > > -jm
Some TI Hercules and some Freescale have 256K of SRAM, and 337 or 516 "pins". Not cheap. NXP 43xx with 136K SRAM is not a bad choice. Easy interface to single chip 32MB external SDRAM, pretty low total cost (probably 5-10 in qty).
Reply by Jukka Marin February 7, 20132013-02-07
On 2013-02-03, Paul Rubin <no.email@nospam.invalid> wrote:
> I notice that the ram capacity (ignore program flash for now, but it > tends to basically be proportionate) of microcontrollers seems to grow > fairly continuously (say in 2x jumps) from very small (a dozen or so > bytes in an 8 bitter, lots of MSP430's in the 128 to 1k byte range, > Cortex M0's with 4k, etc.), up to about 32k (Cortex M4). Above that > there are a few chips with 64k or 128k, that are quite expensive, and > above that not much is available til you get to external DRAM which on > ready-made boards usually starts at 32 meg or even 64 meg (Olimex > Olinuxino) or 512 meg (Raspberry Pi). So there is a big jump from 32k > to 32 meg. It would be nice to have a low cost, single chip, 256k or 1 > megabyte device but this doesn't seem to exist.
Freescale Kinetis X claims to have up to 4 MB FLASH and 512 kB SRAM. -jm
Reply by Walter Banks February 4, 20132013-02-04

dp wrote:

> On Feb 4, 3:51 pm, Walter Banks <wal...@bytecraft.com> wrote: > > dp wrote: > > > On Feb 4, 4:39 am, Walter Banks <wal...@bytecraft.com> wrote: > > > > Jon Kirwan wrote: > > > > > > > So 16%/20% is great information for those making business > > > > > decisions about product placement and features. But not so > > > > > great when you face a task at hand. > > > > > > > Different things. > > > > > > > Jon > > > > > > I agree that the ratio is application dependent, but in the > > > > study we did the standard deviation of ram rom ratios > > > > used was surprisingly small. This was specifically for > > > > processors with 8 bit data paths. > > > > > I can imagine how on small processors the figures can be > > > consistent (though I find the assembly/C figures way too > > > close to be supporting this, i.e. they are so close it > > > looks things are as Jon suggests, one uses whatever > > > is available). > > > > The 16% compiled code and 20% handwritten ram/rom ratio > > have a simple explanation. Compilers are better at re-using > > variable space than hand written code can reasonably do. > > > > RAM re-use is an accounting problem something computers > > are good at. In HLL's it is redone for every compile. > > > > w.. > > Hmm, yes, I can see how this can be an important factor. > Less for my code as my global variables are not very reusable > and there is not much to be gained from variables on the > stack perhaps, but I don't really know. Then my code for > small 8 bit MCUs will likely not be an exception from what > you have observed. > Do you have a figure for the reuse ratio high/low level? > I mean from the same research you did? Quite interesting.
The standard deviation was around 1% and both were essentially normally distributed. w..
Reply by Walter Banks February 4, 20132013-02-04

Paul Rubin wrote:

> Walter Banks <walter@bytecraft.com> writes: > > The 16% compiled code and 20% handwritten ram/rom ratio > > have a simple explanation. Compilers are better at re-using > > variable space than hand written code can reasonably do. > > Another possibility is that assembly language programmers are more > likely than HLL programmers to use intricate code minimization schemes > and avoid boilerplate libraries, function prologues, etc.; so the > assembly programs may tend to have less code, while using about amount > of ram storage.
That would change the ram/rom statistics. It is something that we looked at. There is a style factor in the HLL vs asm coding that accounts for some of the differences and that is many (not all) HLL's maintain local variables on the stack which makes access to these variables more expensive in terms of code size. This would skew the statistics some except we also found that compiled code was smaller than similar assembly applications. (I don't want to start another asm vs HLL thread) In the end the Hll/assembler ram/rom ratios were essentially due to one factor ram accounting in a HLL. w.. .
Reply by Robert Wessel February 4, 20132013-02-04
On Mon, 04 Feb 2013 16:51:03 +0100, Hans-Bernhard Br&#4294967295;ker
<HBBroeker@t-online.de> wrote:

>On 04.02.2013 15:41, rickman wrote: >> "Large microprocessors", isn't that like "jumbo shrimp"? > >Not really. Given the evolution of the term, a "micro" processor is >really any device substantially smaller than your average dish washer. > >I've never heard of a good reason the evolution of terms didn't continue >further down to nano or pico processors --- but it didn't.
"Microprocessor" is usually taken to mean a CPU that fits on a single chip, although a few folks have fudged that a bit. As distinct from multi-chip designs. It's not clear what a "nano" or "pico" processor would be on that progression.
Reply by Paul Rubin February 4, 20132013-02-04
Walter Banks <walter@bytecraft.com> writes:
> The 16% compiled code and 20% handwritten ram/rom ratio > have a simple explanation. Compilers are better at re-using > variable space than hand written code can reasonably do.
Another possibility is that assembly language programmers are more likely than HLL programmers to use intricate code minimization schemes and avoid boilerplate libraries, function prologues, etc.; so the assembly programs may tend to have less code, while using about amount of ram storage.