large microprocessors?

[Paul Rubin]

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.

Is there some technical reason for this, or is it just a
market-determined thing? I know that desktop cpu's often have megabytes
of sram cache, so it's certainly technologically feasible to do
something similar with a smaller cpu.

Thanks.

[Robert Wessel]

On-chip ran is usually SRAM, and that's usually at least a factor of
six time less dense than DRAM, so large on-chip memories usually
require fairly large dies. And it's worse in practice since most
microcontrollers are not implemented in the latest processes, and DRAM
process are highly optimized for density, both of which multiply the
overhead.

Things like eDRAM are possible, but require considerable extra
processing in the fab, so are largely impossible from a cost
perspective for low cost devices.

Since external DRAMs are (mostly) commodity items, the price pressure
on the manufacturers are severe, leading to excellent price per bit.

Smaller external DRAMs are certainly possible, but there's not much of
a price break below 32MB or so.

I suspect we'll see stacked dies before too long, which would provide
the large capacity without the hassle of an external DRAM.

[Olaf Kaluza]

Paul Rubin <no.e...@nospam.invalid> wrote:

>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

Nope. Renesas SH7262 1024k. A very nice toy. Very powerful. .-)

>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.

It is existing. You did not search good enough.

But it is only need for a few application and so it is
expensive. (arround 10Euro for high volume, 20Euro if you buy a few)

This is my prototypboard:
http://www.criseis.ruhr.de/bilder/mp3_1.jpg

You see the advantage? The huge internal sram made it possible to use
this kind of controller on a selfmade twoside PCB.

Play some music:
http://www.criseis.ruhr.de/bilder/mp3_2.jpg

Good enought for playing 320kbit MP3 with libmad.

Olaf

[Paul Rubin]

Olaf Kaluza <ol...@criseis.ruhr.de> writes:
> Nope. Renesas SH7262 1024k. A very nice toy. Very powerful. .-)

Thanks. This appears to be an older and rather expensive part with a
not-so-common architecture (Hitachi SH2) but it's good to know about.

[Glenn]

Hi Paul

The newest (for me) is ARM with PoP memory with higher RAM/flash is
needed. But they might be a nightmare minimize solder ball defects. But
alternative to let the package sit beside the microprocessor is worse
because then more PCB copper layers are needed:

http://en.wikipedia.org/wiki/Package_on_package
Quote: "...
Two or more packages are installed atop each other, i.e. stacked, with a
standard interface to route signals between them. This allows higher
component density in devices, such as mobile phones, personal digital
assistants (PDA), and digital cameras.
..."

Example of PoP usage - only possible because ARM are so low-power:

http://beagleboard.org/

GTA04 GTA04A5 with 1GiB flash and 1GHz ARM:
http://projects.goldelico.com/p/gta04-main/
http://projects.goldelico.com/p/gta04-main/doc/

Manual and schematic for GTA04 revision A3...A5:
http://projects.goldelico.com/p/gta04-main/page/Manual/

Glenn

[Paul Rubin]

Glenn <glen...@gmail.com> writes:
> http://en.wikipedia.org/wiki/Package_on_package

Thanks, I remember seeing that on the original Beagleboard but
I was more interested in what was around on single chips.

> GTA04 GTA04A5 with 1GiB flash and 1GHz ARM:

Wow, cool, though too expensive for me to think about ;-). I like that
the Open Moko concept is still alive but I think it's better to have a
data-only device and a separate phone.

[upsid...@downunder.com]

On Sun, 03 Feb 2013 00:39:15 -0600, Robert Wessel
<robert...@yahoo.com> wrote:

>On-chip ran is usually SRAM, and that's usually at least a factor of
>six time less dense than DRAM, so large on-chip memories usually
>require fairly large dies. And it's worse in practice since most
>microcontrollers are not implemented in the latest processes, and DRAM
>process are highly optimized for density, both of which multiply the
>overhead.

Putting DRAM on chip would have some interesting architectural
features. Assuming 2 MiB DRAM = 16 Mib organized as 4096x4096 bits.
The 12 high order bit will activate a row and all the 4096 bits in the
column go through the column amplifiers back to the original cells. As
a side product, all the 4096 column bits (512 bytes) could be latched
in parallel, while a typical external DRAM uses a data selector to
select a few bits or few bytes before latched out to external pins.

With all column bits latched on-chip, this would act also as a cache
for "free", as long as the access is within the same 512 byte column.
To significantly reduce miss rates, use separate 512 byte latches for
data and instructions.

[Olaf Kaluza]

Paul Rubin <no.e...@nospam.invalid> wrote:

>Thanks. This appears to be an older and rather expensive part with a
>not-so-common architecture (Hitachi SH2) but it's good to know about.

It is an SH2A. This has some advantage over the old SH2. For example
16 register bank for a fast IRQ.

Olaf

[Robert Wessel]

You're basically describing fast-page-mode DRAM. The problem of
integrating DRAM onto a logic process remains, however.

OTOH, you could do the exactly same thing on an SRAM array if you
wanted.

[Stephen Pelc]

On Sat, 02 Feb 2013 22:17:29 -0800, Paul Rubin
<no.e...@nospam.invalid> wrote:

>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.

STM32F4xx have 192kb or 256kb RAM and 1Mb or more of Flash.
These are excellent Cortex-M4 devices.

Stephen

--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[Paul Rubin]

steph...@mpeforth.com (Stephen Pelc) writes:
> STM32F4xx have 192kb or 256kb RAM and 1Mb or more of Flash.
> These are excellent Cortex-M4 devices.

Thanks! I think I saw these before, but forgot about them. The STM32F4
Discovery board uses the STM32F407VGT6 which has 192kb of ram and a lot
of other cool stuff too. I just spent a while looking at the data
sheet. Memory protection, peripheral interfaces galore, 4k of
ultra-low-power backup SRAM, realtime clock, hardware RNG, what's not to
like? Wow! This thing can reach into areas where I had been thinking
of using a Linux board with DRAM.

I remember having some issue with the Discovery board, probably about
the toolchain, but as pure hardware goes it's pretty impressive.

[David Brown]

On 03/02/13 07:39, Robert Wessel wrote:
> On Sat, 02 Feb 2013 22:17:29 -0800, Paul Rubin
> <no.e...@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.

32-bit microcontrollers usually have significantly more ram than
8/16-bit microcontrollers in the same price class. But I haven't seen
many with more than 128 KB (Freescale's M4 series stops there) -
Freescale's MPC56xx PPC-based chips are the only ones I've used, and
they don't count as small or low-cost.

>>
>> Is there some technical reason for this, or is it just a
>> market-determined thing? I know that desktop cpu's often have megabytes
>> of sram cache, so it's certainly technologically feasible to do
>> something similar with a smaller cpu.
>
>
> On-chip ran is usually SRAM, and that's usually at least a factor of
> six time less dense than DRAM, so large on-chip memories usually
> require fairly large dies. And it's worse in practice since most
> microcontrollers are not implemented in the latest processes, and DRAM
> process are highly optimized for density, both of which multiply the
> overhead.
>

It's not actually a question of the "latest" processes, but the
"optimised" process. When making a chip design, you have a lot of
factors to consider - then number of layers, the types of layers, the
size of the geometry, etc. The layer stackups suited for DRAM, SRAM,
Flash, and low-power digital, high-speed digital, high accuracy
analogue, and low-power analogue are all different. So when a designer
wants to combine a large SRAM with a fast microcontroller on the same
die, he must choose between having the SRAM larger, slower, and more
expensive per bit - or having the microcontroller larger, slower, and
more power-consuming.

> Things like eDRAM are possible, but require considerable extra
> processing in the fab, so are largely impossible from a cost
> perspective for low cost devices.
>
> Since external DRAMs are (mostly) commodity items, the price pressure
> on the manufacturers are severe, leading to excellent price per bit.
>
> Smaller external DRAMs are certainly possible, but there's not much of
> a price break below 32MB or so.
>
> I suspect we'll see stacked dies before too long, which would provide
> the large capacity without the hassle of an external DRAM.
>

Stacked dies do exist, as do side-by-side multi-die chips. But they are
a lot more expensive to manufacture and test, and introduce big
challenges for power distribution on the die, and heat dissipation. It
is certainly a technology that is up-and-coming for memories (DRAM and
Flash), but in these chips you have multiple identical dies which makes
it much easier. I've seen articles about I/O standards and drivers
aimed at in-chip inter-die buses, but I won't hold my breath waiting for
them to appear in low-cost microcontrollers.

[upsid...@downunder.com]

On Sun, 03 Feb 2013 09:40:11 -0800, Paul Rubin
<no.e...@nospam.invalid> wrote:

>steph...@mpeforth.com (Stephen Pelc) writes:
>> STM32F4xx have 192kb or 256kb RAM and 1Mb or more of Flash.
>> These are excellent Cortex-M4 devices.
>
>Thanks! I think I saw these before, but forgot about them. The STM32F4
>Discovery board uses the STM32F407VGT6 which has 192kb of ram and a lot
>of other cool stuff too. I just spent a while looking at the data
>sheet. Memory protection, peripheral interfaces galore, 4k of
>ultra-low-power backup SRAM, realtime clock, hardware RNG, what's not to
>like?

Sounds like a PDP-11/34 on chip :-).

>Wow! This thing can reach into areas where I had been thinking
>of using a Linux board with DRAM.

192 KiB might be on the low side for Linux, but some older RSX-11 or
early Unixes style OSes would run fine in this amount of RAM. Of
course, these OSes were disk based, i.e. programs (and overlay
segments) were loaded from disk into core/RAM, thus some (shared)
Flash or even rotating disks might be needed for program storage.

But still it might be interesting to develop processor arrays, in
which tasks to be reconfigured much faster than burning Flash.

[Walter Banks]

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.

w..

[Jon Kirwan]

I think you addressed the caution I'd add. I'd just word it
differently.

When you go to a doctor because you are sick, it's not
appropriate for the doctor to immediately start out telling
you what the most likely cause of your illness is based upon
what is more likely based on everyone else who gets sick. The
doctor should listen to the symptoms (details) of your
situation. Even then, statistics don't help decide what you
have. It's always in the details. After the doctor determines
what you have, then your illness becomes part of the
statistics.

The only thing reason a doctor should be thinking about "most
probable" in your case should be about saving money in tests,
not in determining what you have. And statistics are most
useful when allocating annual budgets. Financial stuff. Not
in deciding cases. That should be based on the individual
facts of the situation.

Same thing with processor choices.

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

[j.m.gr...@gmail.com]

On Monday, February 4, 2013 11:06:30 AM UTC+13, 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.

Those numbers sound high for 8 bit micros ?

The mainstream 8051 families, come in around 3~6% of Max Code, at the Intel choices of 128:4096 and 256:8192 and the more modern 4096:65536

Or, are you saying the chips were only 33% code-full,(but used all RAM) and so lifted the RAM:code ratio ? ;)

32 bit micros tend to have larger RAM numbers, as they get quite lazy with bits and bytes.
Thus we see the NXP small 32 bit offerings with 25% ratio of RAM:CODE

The new Infineon variants have 16kB of RAM, which varies from 25% to 200%(!) of code.

[j.m.gr...@gmail.com]

On Sunday, February 3, 2013 8:06:59 PM UTC+13, Paul Rubin wrote:
>
> Thanks. This appears to be an older and rather expensive part with a
> not-so-common architecture (Hitachi SH2) but it's good to know about.

If you want something newer, then Nuvoton has a series of Stacked-die parts, they call ARM Video SoC, come in gull wing LQFP-128 / LQFP-64 parts.
See:
http://www.nuvoton.com/NuvotonMOSS/Community/ProductInfo.aspx?tp_GUID=66feb925-4931-4d99-938d-9a6f89fc0ac6

Choice of 16MB or 32MB Stacked RAM.
Some upcoming ones, even have ethernet MAC... (as well as USB).

-jg

[Walter Banks]

The numbers came from a study we did of several hundred embed
applications and reference designs. They are the used ram and
rom in the application. The applications we looked at were
specifically 8 bit data path processors. ROM was normalized to
bytes (Microchip PIC 14 bit mid range for example)

w..

[Walter Banks]

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.

w..

[Paul Rubin]

Walter Banks <wal...@bytecraft.com> writes:
> The numbers came from a study we did of several hundred embed
> applications and reference designs. They are the used ram and
> rom in the application. The applications we looked at were

> specifically 8 bit data path processors....

I can believe programs on those small micros tend to use a few static
storage areas for parameters, buffers, etc. but not tend to have
concurrent tasks created on the fly, lookup structures of significant
size built at runtime, languages with garbage collection, etc.: typical
things done in programs on larger cpu's. Small cpu's constrain the
programs and programming styles that can run in them. It's not that the
algorithms with bottomless memory appetites have to curb their desires
on those cpu's--it's that they normally aren't used on those cpus at
all.

[Walter Banks]

Paul Rubin wrote:

> Walter Banks <wal...@bytecraft.com> writes:

> > The numbers came from a study we did of several hundred embedded

> > applications and reference designs. They are the used ram and
> > rom in the application. The applications we looked at were
> > specifically 8 bit data path processors....
>
> I can believe programs on those small micros tend to use a few static
> storage areas for parameters, buffers, etc. but not tend to have
> concurrent tasks created on the fly, lookup structures of significant
> size built at runtime, languages with garbage collection, etc.: typical
> things done in programs on larger cpu's. Small cpu's constrain the
> programs and programming styles that can run in them. It's not that the
> algorithms with bottomless memory appetites have to curb their desires
> on those cpu's--it's that they normally aren't used on those cpus at
> all.

I basically agree with you. The processor we looked at are mostly
used in consumer products and small scale process control
systems.

w..

[Richard Damon]

I think the reason comes to economics of scale for production. The desk
top cpu has much more area devoted to building the processor, so adding
the additional ram for the cache has economic viability. These
processors use more expensive chip technology to fit all this on the
chip, but the processors have value worth the expense.

For the lower end processors, the technology doesn't really allow for
that large of a memory array to keep within the value range of the
processor. The fact that this also aligns with the memory needed for
typical uses of these chips is a bonus that reduces the need to try and
develop the exception processor.

The way to get a microcontroller with a somewhat larger memory space is
to use an external memory chip (not a memory stick with multiple chips).
SRAM would be a smaller/cheap choice than DRAM.

[dp]

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).
But on larger systems, where buffering may or may not
be needed things can quickly change by some huge factor
from application to application. A tcp/ip stack running
at 100 MbpS (and actually using it for streaming lots
of data) alone can eat up a few hundred kilobytes or
even a few megabytes, for example, this just for inbound
packet buffering.

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/

[Paul Rubin]

Richard Damon <news.x.ri...@xoxy.net> writes:
> For the lower end processors, the technology doesn't really allow for
> that large of a memory array to keep within the value range of the
> processor.

It occurs to me also, most microcontrollers are mixed signal chips
(a/d's and so forth). That might dictate some fab process decisions
that don't play well with high density memory.

> For the lower end processors, the technology doesn't really allow for
> that large of a memory array to keep within the value range of the

I'm pretty impressed with that STM part that Stephen Pelc mentioned. 1M
flash, 192kb ram (I didn't see a 256kb version but 192kb is almost as
good), tons of on-chip peripherals, and there's an ultra cheap
development board for it. The next step up is external memory as you
mentioned.

[Paul Rubin]

upsid...@downunder.com writes:
>>Wow! This thing can reach into areas where I had been thinking
>>of using a Linux board with DRAM.
> 192 KiB might be on the low side for Linux, but some older RSX-11 or
> early Unixes style OSes would run fine in this amount of RAM.

Actually quite a bit less ram, and a lot of the ram they used actually
held program code that would run from flash in the case of this STM part.

> Of course, these OSes were disk based,

The chip has an SDIO controller. It's too bad that the Discovery
evaluation board doesn't have an SD card socket. That would allow
re-creating the PDP-11 Un*x experience ;-).

But, I think in reality I'd run a simple RTOS or a standalone
application on this chip. The next step up would be a Linux board as
those have also gotten quite inexpensive (various boards inspired by the
Raspberry Pi). They just have more power drain and more software to
deal with, and a bit less realtime capability.

[David Brown]

That's not particularly surprising - "general" code will use stack and
local variables at a statistically fairly similar rate, so ram-to-rom
ratio will be reasonably consistent. When moving to 32-bit, the rom
usage (for the same program functionality) typically increases a little,
but the ram usage increases by a factor of 2 to 4 (due to the wider
integers). But with this correction factor, the ratio will again be
reasonably consistent.

The exception to this is buffer space - for arrays of sample data,
communication buffers, etc. This is particularly common in bigger
micros, especially ones with high speed communication (USB or Ethernet).

Thus when manufacturers make a family of devices, they will typically
have a range of ram/flash sizes for different uses, but have a similar
ratio across the family. And a 32-bit family will have about 4-8 times
the ram for the same flash size as an 8-bit family would do.

Statistically, this all makes economic sense. But as Jon says, it's a
pain if that doesn't fit the task in hand.

[Paul]

In article <7x8v74m...@ruckus.brouhaha.com>, no.e...@nospam.invalid
says...

>
> upsid...@downunder.com writes:
> >>Wow! This thing can reach into areas where I had been thinking
> >>of using a Linux board with DRAM.
> > 192 KiB might be on the low side for Linux, but some older RSX-11 or

For desktop yes, embedded no.

> > early Unixes style OSes would run fine in this amount of RAM.
>
> Actually quite a bit less ram, and a lot of the ram they used actually
> held program code that would run from flash in the case of this STM part.
>
> > Of course, these OSes were disk based,
>
> The chip has an SDIO controller. It's too bad that the Discovery
> evaluation board doesn't have an SD card socket. That would allow
> re-creating the PDP-11 Un*x experience ;-).
>
> But, I think in reality I'd run a simple RTOS or a standalone
> application on this chip. The next step up would be a Linux board as
> those have also gotten quite inexpensive (various boards inspired by the
> Raspberry Pi). They just have more power drain and more software to
> deal with, and a bit less realtime capability.

Hmm the Raspberry Pi uses a difficult to obtain Broadcom chip wuth
stacked packages.

First version was 256MB with HALF of that by default assigned to
graphics, yes 128MB to run Linus.

Second version has 512MB RAM package using SD cardd IO for disk.

These days you can reduce the graphics ram size significantly.

--
Paul Carpenter | pa...@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/> GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

[Walter Banks]

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..

[rickman]

"Large microprocessors", isn't that like "jumbo shrimp"?

--

Rick

[Hans-Bernhard Bröker]

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.

[Rob Gaddi]

On Sat, 02 Feb 2013 22:17:29 -0800

Paul Rubin <no.e...@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.
>
> Is there some technical reason for this, or is it just a
> market-determined thing? I know that desktop cpu's often have megabytes
> of sram cache, so it's certainly technologically feasible to do
> something similar with a smaller cpu.
>

> Thanks.

NXP LPC3250. 256k on-board SRAM, and 32k each of I/D cache. It's an
ARM9, about $7 each in reasonable quantities. Vendor support
is...present...sort of, and the peripherals have some interesting
personality quirks.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

[dp]

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.

[Paul Rubin]

Walter Banks <wal...@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.

[Robert Wessel]

"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.

[Walter Banks]

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..

.

[Walter Banks]

The standard deviation was around 1% and both were
essentially normally distributed.

w..

[Jukka Marin]

On 2013-02-03, Paul Rubin <no.e...@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

[Spehro Pefhany]

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).

[Spehro Pefhany]

On Mon, 04 Feb 2013 09:41:05 -0500, the renowned rickman
<gnu...@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"
sp...@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

[Paul Rubin]

Jukka Marin <jma...@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.

[Jukka Marin]

On 2013-02-08, Paul Rubin <no.e...@nospam.invalid> wrote:
> Jukka Marin <jma...@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

[Przemek Klosowski]

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?