What makes a Teensy a microcontroller as opposed to a single board computer?

This is a gap in my knowledge that a fair bit of surfing could not satisfactorily answer.

Most descriptions of microcontrollers give fluffy descriptions of them usually being small or not having an OS or peripherals or non-cpu memory.
A Teensy 4.1 has specsthat are comparable or better to some rPi devices, yet an rPi *feels* very different. Is it the limited operating system on the Teensy? Clearly there is some level of OS because my Teensy can load files and write to a memory card and communicate via ethernet. Could I theoretically load a light version of Linux onto it and use it similarly? Or is there some fundamental physical architecture difference that makes the 2 systems different?
 
This is a gap in my knowledge that a fair bit of surfing could not satisfactorily answer.

Most descriptions of microcontrollers give fluffy descriptions of them usually being small or not having an OS or peripherals or non-cpu memory.
A Teensy 4.1 has specsthat are comparable or better to some rPi devices, yet an rPi *feels* very different. Is it the limited operating system on the Teensy? Clearly there is some level of OS because my Teensy can load files and write to a memory card and communicate via ethernet. Could I theoretically load a light version of Linux onto it and use it similarly? Or is there some fundamental physical architecture difference that makes the 2 systems different?

https://internetofthingsagenda.techtarget.com/definition/microcontroller

Excerpt:
Microcontrollers vs. microprocessors

The distinction between microcontrollers and microprocessors has gotten less clear as chip density and complexity has become relatively cheap to manufacture and microcontrollers have thus integrated more "general computer" types of functionality. On the whole, though, microcontrollers can be said to function usefully on their own, with a direct connection to sensors and actuators, where microprocessors are designed to maximize compute power on the chip, with internal bus connections (rather than direct I/O) to supporting hardware such as RAM and serial ports. Simply put, coffee makers use microcontrollers; desktop computers use microprocessors.

Perhaps one of the first linux <30Years old? would run after some modifications. Worst is, that Arm Cortext has no MMU (Memory management unit) which Linux needs (as far as I know)
Then, 1MB of RAM is not very much..
 
Teensy 4.1 is a microcontroller.


could not satisfactorily answer.

Indeed this question isn't so clear with modern parts. Even NXP's marketing info calls these new chips "crossover".

screenshot.png

But other than the high CPU performance, it really has almost everything in common with microcontrollers and little else in common with microprocessors.


Is it the limited operating system on the Teensy? Clearly there is some level of OS because my Teensy can load files and write to a memory card and communicate via ethernet.

No, not an operating system, just a collection of software libraries.


Could I theoretically load a light version of Linux onto it and use it similarly?

The short answer is no, Linux can't run on Teensy 4.1.

The long answer is also essentially no. But if you take the word "light" to mean so lacking in drivers and features to be basically worthless and the phrase "use it similarly" to mean booting up to a shell without the ability to actually run any useful software and the word "theoretically" to mean spending an incredible amount of difficult work, then perhaps the answer becomes maybe. Linux porting has been discussed at length on this forum, so maybe with searching you can find those old messages.
 
I generally wanted to understand if it is the lack of some specific piece of a Von Neuman architecture. It seems it is in the lack of an MMU and a bus. I certainly have enough old Linux boxes lying in the back of closets, and enough LED art development to keep me from wanting to take on Linux on a Teensy.
 
In short I'd divide the processor landscape like this:

Microcontrollers have many interfaces to drive sensors and things like motor drivers. They do not need
support chips to function. Typical clock speeds 10MHz to 200MHz, typical memories 1k to 256k.
Number of pins 10...100, support ultra-low-power modes. Power consumption measured in mW. No OS needed,
real-time performance is important feature.

A modern microprocessor typically only talks to support chips using very wide and very high speed busses (think GB/s).
Clock speeds 100's of MHz to many GHz, typical RAM 100's of MB to 10's of GB. Number of pins ~1000. Power
consumption 5--100W (Forced air cooling mandatory) Runs an OS, real-time performance may be poor.
May or may not have integral GPU. Heart of laptop or general purpose computer/server.

A system-on-a-chip is a microprocessor and GPU and support chips combined, and sometimes RAM too. Pin count
intermediate. Often used within equipment that's not general purpose (lab test gear, phones, routers, etc etc).

There's a huge variety, the boundaries are blurred (such as by the i.MX RT1062 used in the T4.x boards), and
this landscape changes fast - just look at the new M1 from Apple for instance, with build-in neural net support.
 
I generally wanted to understand if it is the lack of some specific piece of a Von Neuman architecture.

Maybe I'm reading too much into this question, but it kinda sounds like an assumption that a SBC microprocessor is a superset, that it would have everything a microcontroller has, that a microcontroller is defined pretty much only by what it lacks. But the truth is both types of chips have very different designs in many ways.

Microcontrollers like Cortex M7 are designed for low latency interrupts. Some ARM instructions, like the load and store multiple registers, can take many cycles. On M7, the CPU is able to abort those instructions and then redo them after the interrupt, so they don't add extra latency. Quite a number of other design choices go into the CPU's pipeline design to achieve that low worst case latency.

Interrupt controllers also tend to have very different design. Cortex-M microcontrollers have a nested vector interrupt controller which gives a pretty much fixed functionality for a small pre-determined set of interrupts. More traditional processors have interrupt systems which are designed to be expandable with a not-determined-in-advance set of peripherals, but they usually involve the CPU doing more work in software to manage that complexity. Features to delay interrupt processing slightly, so multiple events can be handled with the overhead of only 1 operating system context switch are also common. You get more far more flexibility and throughput, but at the cost of latency. The NVIC in Cortex-M is designed to do almost all the work in hardware (with little flexibility and no expandability), so interrupt response has the lowest possible latency.

Microcontrollers typically have memory systems designed for deterministic timing. With these newer 600 MHz M7 parts, the lines are blurred slightly, because some memory is cached and external QSPI memory is quite slow for cache misses. But still, half of the internal RAM is "tightly coupled" and partitioned as either used for instructions or data. Usually most variables and code are implemented with this fast, non-cached memory which has fixed access time. On traditional microprocessors, the memory is typically DRAM which has substantial row access time but very high burst speed to read columns within a row. Operating systems like Linux implement virtual memory and write some memory out to swap media, so random memory access time is rarely but could be as long as the media access time to restore memory from swap. But L1 & L2 cache make normal microprocessors run very fast, on average. The main difference is the large variation and possibly very long latency in those unlikely cases. Normally microcontrollers are designed to have fixed or highly deterministic memory timing.

This theme is usually found throughout the design. Traditional microprocessors are designed to maximize throughput. Microcontrollers are designed to minimize latency. Often times just making something faster wins on both fronts, but in many cases there are design trade-offs where low latency comes at the cost of high throughput, and vise versa.
 
Back
Top