pls can u tell why we use external sdram on the microcontroller

[me.rishabh12]

i seen lot of design use external sdram with microcontroller
although the microcontroller has a ample amount of ram for that particular application
pls help me in understandig

[donotdespisethesnake]

Because you can never have too much RAM.

[NiHaoMike]

Because you can never have too much RAM.

The exact phrase from one of the PC service videos was "You can never be too rich or have too much RAM." The counterpoint is that an inconsiderate developer can get used to having a vast surplus and end up with something a lot of end users can't afford to use.

[maginnovision]

It's also possible you're under estimating RAM requirements. It also leaves room for future expansions and updates.

[0xdeadbeef]

I guess the rule is as simple as that: if it's a true embedded realtime application, nobody will use external RAM deliberately. Heck, most microcontrollers don't even have an external bus interface anymore.
But if it's pseudo-embedded stuff running Linux, WinCE, Android or whatever, then you will need  lots of RAM of course.

[Brutte]

i seen lot of design use external sdram with microcontroller

I'd say this is rather rare for a microcontroller to have an SDRAM interface. Most likely SRAM. The dynamic memories are more for processors (like application processors, gpu-s etc).
The reason is that SRAM is expensive in terms of bang per buck when compared to SDRAM. And built-in memory is more expensive than a general purpose memory chip, in terms of bang per buck of course.

[NorthGuy]

You must be kidding. How's that possible to guess why a certain engineering decision has been made without even knowing anything about the device being engineered except that it uses SRAM?

It is hard to reverse engineer human behaviour even in the best possible circumstances. Someone used more RAM than he should. So what? Happens all the time with and without reason.

[mrflibble]

Because you can never have too much RAM.

Word.

Apropos, does anyone know of a PCB vendor that offers a mauve solder mask option?

[rhb]

The Zynq line allows up to 1 GB of SDRAM.  Which is very valuable in a DSO or LA for history buffers. A bottom end DSO has 256 MB of SDRAM.

The MCU world is vast ranging from toys to industrial processes.  And "embedded systems" encompasses everything up to and including supercomputers as the CPU.

[dgtl]

Add dynamic memory allocation and an operating system into play and you'll increase your memory requirements rapidly.
There are microcontrollers with SRAM/SDRAM controllers and SRAM-only controllers. SRAMs are much smaller than SDRAMs at the same price point, but are simpler to control and the controllers are smaller. So if the application does not require large add-on memory, the SRAM-based solution may be cheaper than using an more expensive uc with SDRAM controller.

[Yansi]

I guess the rule is as simple as that: if it's a true embedded realtime application, nobody will use external RAM deliberately. Heck, most microcontrollers don't even have an external bus interface anymore.
But if it's pseudo-embedded stuff running Linux, WinCE, Android or whatever, then you will need  lots of RAM of course.

Not true at all.  Please stop looking at the 8bit PIC crap in DIL packages, you'll see that almost any modern decent MCU is equipped with external bus controller. Heck even some 8bit MCUs today have external mem IO.

[0xdeadbeef]

Not true at all.  Please stop looking at the 8bit PIC crap in DIL packages, you'll see that almost any modern decent MCU is equipped with external bus controller. Heck even some 8bit MCUs today have external mem IO.

Nope. We're only using modern multicore 32bit controllers at work. Most of them don't even have an external bus interface so if you need RAM as ROM emulation ("calibration") during development, you need to buy expensive "engineering devices" with embedded emulation RAM (I.e. Infineon Aurix, Renesas RH850 -> FCCx). Only the very high end NXP eSys MPC5XXX controller still have package variants with external bus interface. But again, there it's only used to simulate ROM during development.

[Yansi]

Then stop talking about some very specific, obscure presumably APPLICATION PROCESSORS targeted at a specific single purpose, as the thread is about MCUs. See the difference?

I don't want to be mean, but it is just not true at all, considering general MCUs.  Some MPC5xxx or Renesas is not in any way a general purpose MCU. That is just some automotive specific whatever strange part, and I strongly doubt that the OP was asking for these.

[NorthGuy]

Please stop looking at the 8bit PIC crap in DIL packages, you'll see that almost any modern decent MCU is equipped with external bus controller.

Many old (and obsolete now) PIC18s, although not in DIL packages, had external memory bus, but nobody was using it, so modern PIC18s don't have it any more.

There are lots of bad programmers out there who write very bloated software, and consequently  think they need much more RAM. But as soon as they get more RAM, they add more bloat and thus need even more RAM. It will never be enough.

[0xdeadbeef]

Then stop talking about some very specific, obscure presumably APPLICATION PROCESSORS targeted at a specific single purpose, as the thread is about MCUs. See the difference?

The thread is about microcontrollers and by all means, NXP, Infineon and Reneasas produce microcontrollers. Heaps of them.
Don't become emotional if your 8bit drivel is objected just because your view of the usage of microcontrollers is limited.

I don't want to be mean, but it is just not true at all, considering general MCUs.  Some MPC5xxx or Renesas is not in any way a general purpose MCU. That is just some automotive specific whatever strange part, and I strongly doubt that the OP was asking for these.

There are several words for either not understanding of admitting when you're wrong, but "mean" is not one of them.

[maginnovision]

Many atmel controllers have external memory interfaces, even the 8 bit.

[ejeffrey]

Then stop talking about some very specific, obscure presumably APPLICATION PROCESSORS targeted at a specific single purpose, as the thread is about MCUs. See the difference?

I don't want to be mean, but it is just not true at all, considering general MCUs.  Some MPC5xxx or Renesas is not in any way a general purpose MCU. That is just some automotive specific whatever strange part, and I strongly doubt that the OP was asking for these.

Lots of microcontrollers have external memory interfaces.  Maybe not on every model or package variant, but it is quite common, and not just on "automotive" stuff.  Automotive is also a *huge* industry for microcontrollers and many microcontrollers are designed to support automotive applications even if they are also used elsewhere, so "automotive specific strange part" makes no sense.

Anyway, there are tons of reasons to have external DRAM in a microcontroller, even if you think the application wouldn't require it. 

* One reason might be to store log data.  Think of a monitoring device that normally sends data immediately to some remote host but needs to be able to function for a few days without access.
*  You might want to support safe(er) firmware upgrades.  Most microcontrollers have far more flash than SRAM.  If you have an external memory you can load new firmware into the DRAM, checksum it, and then start programming the flash.  That reduces your risk of corruption if the upload connection is broken or has data errors. In this case, the DRAM would possibly not even get used under normal operation.
* More and more microcontrollers are being asked to host web interfaces.  Whether that is a good idea or not, that can take a lot of RAM to render pages.  So it makes sense to keep your real time stuff in SRAM and put the web stuff in DRAM.
* A CNC motor control system might need DRAM to store a large program while using SRAM to hold only the currently executing tool path.
* In a low volume application it might make sense to simply add the DRAM for future growth, since it is easier than retrofitting systems.

Also, I want to steadfastly and strenuously object to NorthGuy's characterization of "bad programmers."  A bad programmer is one that wastes time trying to write the smallest and least featureful program to fit into a tiny microcontroller when realtime requirements don't require it and the volume cost savings don't justify it. Also, frequently microcontroller developers do really crappy stuff like impose arbitrary limits or fail to test input values properly in order to fit in memory since SRAM is still precious.  If your application can support DRAM and that lets you write more functional less brittle code, that is a big win.  Frankly, many micocontroller applications, especially IoT nonsense, should not even use microcontrollers, but small application processors.  There are now affordable ARM application processors with a reasonable compliment of IO peripherals, and if you are going to run TCP/IP you should really do it with a real OS.  Those wiznet chips or tiny IP stacks are cool, but ultimately quite limited.  Obviously if you need super accurate real-time or a huge number of IO pins, you may still need a microcontroller, but many applications don't require that.

[NorthGuy]

Also, I want to steadfastly and strenuously object to NorthGuy's characterization of "bad programmers."  A bad programmer is one that wastes time trying to write the smallest and least featureful program to fit into a tiny microcontroller when realtime requirements don't require it and the volume cost savings don't justify it.

Oh, dear. That wasn't a characterization. There are many varieties of bad programmers. Very many.

IMHO, a good programmer is the one who's capable of designing simple and reliable solutions. This has nothing to do with fitting anything into anywhere. If you find a good approach to your task - you will get it all:

- less code, which means your code is more understandable and maintainable, and also requires less development time.
- simpler code which means more robust and reliable behaviour, less testing time, less bugs
- less resources, which means lower costs

Note that good design doesn't use less resources because you try to fit your solution into anything specific. Good design uses less resources because it doesn't need more.

If you start with a bad design, then it doesn't really matter whether you overbloat it beyond comprehension, or whether you try to squeeze it into something really tiny. The bad design will remain a bad design. Facing such situation, it takes a lot of courage to admit that "my design is bad, we need to start over", especially if you're in the middle of the project and someone has already paid you good money for it. Why not to say that "the design is good, but we have problems because there's not enough resources". But once you say this, you simply must go the distance to convince everyone (and primarily yourself) that what you're saying is the very truth. And people work on this really hard ...

[coppice]

I guess the rule is as simple as that: if it's a true embedded realtime application, nobody will use external RAM deliberately. Heck, most microcontrollers don't even have an external bus interface anymore.
But if it's pseudo-embedded stuff running Linux, WinCE, Android or whatever, then you will need  lots of RAM of course.

Not true at all.  Please stop looking at the 8bit PIC crap in DIL packages, you'll see that almost any modern decent MCU is equipped with external bus controller. Heck even some 8bit MCUs today have external mem IO.

Most 32 bit MCUs don't have an external bus controller. MCUs with expandable memory are something of a niche market, unless they are using a QSPI interface. There are often one or two family members which have an external bus, but its not a characteristic of most devices in most families. QSPI to boot the internal RAM from external flash has been getting pretty common in the last couple of years, and I would expect that trend to continue. The vast majority of MCUs which don't contain a high pin count peripheral, like an LCD controller, are fairly low pin count devices. A full external bus would really eat into the available I/O.

Any MCU targeting ULP applications is unlikely to have any kind of external memory bus, beyond a QSPI that's used only during boot. The power consumption of driving such a bus makes a mockery of any ULP goals if it is used continuously.

[donotdespisethesnake]

Also, I want to steadfastly and strenuously object to NorthGuy's characterization of "bad programmers."

People who make that sort of snark are invariably people who have no clue about software development. It's annoying, but I wouldn't waste time arguing.  It's like trying to argue with Flat Earthers.

[mikerj]

Also, I want to steadfastly and strenuously object to NorthGuy's characterization of "bad programmers."  A bad programmer is one that wastes time trying to write the smallest and least featureful program to fit into a tiny microcontroller when realtime requirements don't require it and the volume cost savings don't justify it.

If you object to a generalisation by countering it with your own generalisation, what does that make you?