It has been quite some time since integration capabilities first allowed the processor, memory, and I/O to all go on one chip and the name changed from microprocessor to microcontroller.
The problem in the early days was the development process–it was quite feasible to get a large quantity of a device built with a fixed program permanently integrated (if you were using a micro in a high-volume application such as an engine controller in an automobile), but getting just one device with a new iteration of a program you were developing was a different matter. While I never used the 8048 family, and didn’t keep track of the Motorola developments, the 8051 came along just when I needed it. Here was a device that could be self-sufficient on a single chip (it could give you four 8-bit I/O ports if you didn’t expand to off-chip memory), only needed a crystal (or an R-C circuit, I think…its been a long time).
Intel marketed a (very expensive) self-contained development system that included an emulator. Right in the socket where the final controller would go on the “final” circuit board, you plugged in a pinned header with a flat cable leading into a magic development system about the size and shape of an oscilloscope. All the programming and assembling/compiling could be done in the box and the program could then run at full speed as though the final chip was installed, or you could run to break points–all the development techniques we now take for granted with modern tools. Unlike a simulator, the hardware it connected to could be right there. Unfortunately we fried the emulator a few times and that would stop development dead for a week or two!
With simulators (where you developed the software on some other computer which could pretend to run like the 8051 itself) it was a big job to model the hardware connected to the I/O and I was never convinced it was worth the effort. Any unexpected problems relating to the hardware were not anticipated in the simulation–if you put in the hardware the way you thought it would work, reality could be slightly different and problems could hide until the final circuit.
There were other development techniques that used RAM in place of the EPROM and had enough firmware to allow the program space to be loaded as RAM and then switch the control lines to have the process or treat it as program memory (you would never write to program space!). The problem with all of these approaches was that processor resources were tied up in the development process–you would lose a couple of ports or at least the serial I/O pins. Common designs used expansion memory and expansion I/O, missing the point of a single chip microcontroller.
When E2PROM (electrically erasable) program memory became feasible, things got easier. Designers integrated a built-in program that allowed quick and simple loading of development code to the (erasable) program space and you could make repeated iterations of a program as you developed it. The 8051-family devices that are now under the SiLabs umbrella took that even further so the develoment code did not eat up program memory. Since integration capability had now gone far beyond the limits of the first 8051-family members, the devices were given quite elaborate I/O (including analog) capabilities and, with the arrival of USB, came the ability to run and debug quite independent of ANY of the processor resources–you even got to keep all the serial I/O, even during the debugging.
In some ways the development steps from the first days are unchanged. You still should try to get small routines running before putting the pieces together (and I suspect there is still the tendency to ‘go for broke’ and ‘hoping for a miracle’ before backing up to the incremental approach). The hardware still behaves the same, be it LEDs or stepper motors. Logic is still needed and getting into the machine code at key points can still be necessary at times.
The sad thing to me is that today’s new developers have such luxury, and they don’t even appreciate how good they have it! Worse yet, they look down on the ‘crude’ way it had to be done ‘in the old days’ without appreciating how improvements in the integration processes were so vital to the situation they now enjoy.