|        I think there's a limit to how much we can economically expand a
|microcontroller.  Again, the ideal design has zero parts, and it'd be
|great to have micro designs with one part: the microcontroller.  Piling a
|bunch of stuff around it, we may as well go to a microprocessor instead
|of a microcontroller.  At some point, this becomes a lower cost approach.
| Want more ROM?  Hang it on the bus!  Want more RAM?  Hang it on the bus!
| Want more I/O?  Hang it on the bus!

One advantage a microcontroller has, though, over a microprocessor
is that the code-space address and data buses are "sheltered".  On
a microprocessor-based system, any sort of fault on the address or
data bus will totally hose system operation, but a suitably-design-
ed microcontroller-based system may be able to detect the fault and
either attempt to recover (if the fault is transient) or diagnose
and report the condition (if it's persistent).

On one microcontroller system I designed which used external RAM for
data storage (but ran code internally) I had a CPU burned with test
code which would output a unique sequence of pulses on all of the
port pins.  Thus, troubleshooting boards was a simple matter of scop-
ing all points on the board until I found one whose pattern was not
as it should be.  I then knew that that pin was either open or short-
ed to something.  Looking at the corresponding signal on the CPU
would tell me which.

By contrast, if that had been a microprocessor-based system, all I
would have been able to see was that it wasn't working and was run-
ning seemingly-random code.  Finding the specific fault and fixing
it would have thus been much more difficult.