Microcontrollers may or may not have storage for firmware. Requiring an off-chip flash is nothing new. Microcontrollers have SRAM, but so do processors. That's where the firmware runs before it gets the DRAM running. Microcontrollers may include a bunch of peripherals, but so do processors. Especially so if you refer to SoCs as processors, like the article here does. And SoCs stir it up further: they have tons of peripherals, and we also have SoCs with on-package DRAM. Discrete SRAM chips exist too, I figured there must be microcontrollers that can use them (but I haven't actually looked).
Yes, the terminology has evolved.
> Microcontrollers have SRAM, but so do processors. That's where the firmware runs before it gets the DRAM running.
Which microprocessor architecture does this?
I regularly use the 1788 + a meg or two of DRAM to hold an LCD framebuffer. The LPC has a really nice interconnect between EMC and the internal LCD controller block and will drive the display all on its own (with a hardware cursor) once it is initialized.
> LPC is a family of 32-bit microcontroller integrated circuits by NXP Semiconductors.
Not a microprocessor. You are the second guy to pull this on me. Do people even read what i write? Did i write unclearly?
"chipset" is very different than a traditional microprocessor chipset though on that. E.g. you don't have an exposed system bus outside the CPU, but rather specialized interfaces. (And ARM systems have evolved the same way over their history)
Traditional microprocessors are getting really rare, even though pretty much all the modern architectures started as them, and thus some use the term more widely. Some vendors use the differentiation between microcontrollers and application processors now, which also isn't a 100% clear line and explicit crossover models existing, but more useful today and avoids the fights over "what's a microprocessor today". (where "application processor" ~ "can reasonably run a full OS like Linux"). But that's also often limited to discussion in embedded use cases again, e.g. I don't know if they'd call a standard desktop CPU that or insist on some arbitrary level of "embeddedness"... Not that standard desktop CPUs don't end up embedded, but that's another discussion entirely.
For the article, i don't want to leave it standing as it is. Redefining "Microprocessors" as "having an MMU" is making communication about these topics very unpleasant, especially when its about Retrocomputing. Same pains as i ranted about in https://news.ycombinator.com/item?id=30278936 .
It has a x86 Microprocessor architecture, but it is not IBM PC compatible because it does not has an BIOS, instead using a more embedded-style RedBoot setup.
Maybe you should do a quick web search before talking shit.
2) SRAM is almost always on the die, not external. Here's a die shot of a random STM32 (cortex M): [1]. The SRAM is quite obvious.
x86 being the classic example. Here [1] is an example of a microprocessor board, you can see the MX support chips on both sides of the CPU. As you can see, the RAM (and the most of the address space-mapped things) is not on-chip. The bus is wired across the PCB.
[1] https://upload.wikimedia.org/wikipedia/commons/d/de/386DX40_...
All the RAM you see on the motherboard is DRAM. It's a totally separate thing and happens to be what the FSP initializes after it loads stuff into SRAM.
"Emulation" evolved to mean virtual machine, now people are denying that wine or xterm are emulators.
"Operating System" evolved to require virtual memory and paging, now people are denying that MS-DOS was an operating system.
"Microprocessor" evolved to mean computing chips with MMU, im waiting for people to deny that the 8086 was an microprocessor because it does not have an MMU.
The infinite shitcycle of people improvising language instead of researching.
https://web.archive.org/web/20150928042254/http://wiki.wineh...
I mentioned the shift of meaning to "virtual machine" in the post you replied to, please read it more carefully.
Emulation and Simulation are different in some regard: emulation is only imitating some aspect of a thing, while simulation imitates a thing by using (usually physical) models.
xterm is a VTxxx emulator, and VT simulator does look like this: https://www.pcjs.org/machines/dec/vt100/
I totally agree with your main point though that emulation is a broader topic than is generally thought.
Also, back in the day emulators emulated the CPU for sure, while an API implementation wasn't never called "emulation". Ever.
The BIOS starts running on the x86's internal SRAM.
https://stackoverflow.com/questions/63159663/how-does-bios-i...
I've done this with PowerPC cores that no one would call microcontrollers.
https://www.coreboot.org/images/2/23/Apollolake_SoC.pdf
https://blogs.coreboot.org/blog/2019/07/17/gsoc-how-to-run-c...
https://9esec.io/blog/open-source-cache-as-ram-with-intel-bo...
The TLDR is that you need to get DRAM running before you can use it (e.g. by poking at DRAM controller's registers until it knows how to talk to your stick of RAM reliably and at a comfortable speed). Until then, you're stuck with SRAM. On ARM SoCs and Intel Apollo Lake, you use addressable SRAM. On most other x86 systems you use cache as RAM. Cache is just SRAM though, and the only difference between ARM and typical x86's case is that the latter doesn't let you directly address it.
You can find examples of DDR DRAM configuration in u-boot sources, and presumably in coreboot too.
As far as I know, all of them. It's possible that there are historical systems where DRAM configuration is fixed, but I wouldn't know about it. Any modern system requires rather complicated configuration to get the DRAM going.
Excluding the caches, this is how x86 functioned for quite a while, i don't know until when.
Microprocessors don't require internal RAM to bootstrap, because they expose their bus and its simple to map a ROM to the starting address, which can be executed from directly.
All of them. They have to. Sometimes the trick is using cache as RAM. Some Intel CPUs do early memory init this way, for example.
You need some memory somewhere to run the complex DRAM init procedure.
Which bus is "the bus"? SoCs and microcontrollers alike expose a bunch of different buses.
I'm assuming Naumann arch, with instructions and data on a single bus.
If anything, the things people today refer to as microcontrollers have more to do with your legacy microprocessor than they have with a high end CPU or SoC.
What's the right term to use?
Microprocessors going back to the Intel 486 have more on-chip RAM than many microcontrollers sold today have. CPUs have built-in firmware ROM for loading boot code. Also, CPUs haven't had a system bus with address/data pins for like 30 years β somewhat ironically, the only chips that have that are microcontrollers. Northbridges haven't existed for 15 years, and southbridges are basically just PCIe-to-USB/SATA/Ethernet/I2C adapters. And many mobile CPUs that Intel and AMD make have on-chip I2C, SPI, UART, GPIO peripherals.
In my article, I'm trying to differentiate between processors that can run a modern multiuser operating system like Linux and microcontrollers that runs bare-metal code, since that's a question I get asked a ton. After carefully considering all the options, the MMU seemed like the most obvious place to draw the line. Every CPU in the last 40 years (since the Intel 286) has had an MMU, while no microcontroller ever made has had one. I'm not sure why that seems so unreasonable to you.
Surely odd, but tolerable. But what is worse that people will read your article, think the MMU is what makes a microprocessor. And upon hearing that the 8086 has no MMU, they will deny that it is a microprocessor. Which would be a logical conclusion from your article.
I listed some other words here that suffer from similar issues https://news.ycombinator.com/item?id=30278936
So really the more practical terminology difference should be SoC vs. microcontroller.
Our of curiosity - does anyone still sell a (by strict definition) a true "micro-processor"?
Digi-Key still shows the 750CL in stock, but it's obviously an obsolete product at this point.
We know definitions change over time because slang words come and go and someone's vocabulary can be used to identify people online or identify their knowledge.
Obviously this wasn't always the case, e.g. a good 15+ years ago I put ucLinux on an old ISP router I had lying around for fun, and it was an ARM946 without an MMU. But that class of device no longer exists today for all practical purposes, and so it's easy to use the existence of an MMU to decide what to call them.
The 8086 may have been a microprocessor, and so was the 80186, but you know where you find 80186 cores today? Microcontrollers. Specifically, some video processing chip manufacturers (e.g. stuff that goes into monitors and DP-HDMI adapters) seem to like using V186 cores still.
The problem with these definitions is a control device and computer are two different things, so I wonder if he is applying an engineer's perspective/definition to the 8086 even though many know the 8086 were used in the early computers. This is a bit like arguing whether a microprocessor is a microprocessor because of the inclusion or exclusion of one or more instruction sets, ie a basic intel cpu with a minimum instruction set or a xeon intel cpu with a much more extensive number of instruction sets.
Or are you picking up on an AI masquerading as a blogger and have highlighted something an AI wouldnt pick up on from online technical resources?
Microprocessors are just the CPU, usually with the system bus wired out. Microcontrollers are combined systems, which include a processor and usually some kind of firmware storage and RAM. You can usually differentiate them by whether their pins are address/data lines or gpio-like.
> microprocessors have a memory management unit
The 8086 didn't. Having an MMU seems unrelated to the MCU/MPU distinction...
At least, this was my knowledge until now. Is this like "crypto" where the meaning changed while i was not paying attention?