OS Planning for Teensy 4.1 - Just a Discussion

J

japreja

Active member
I've been curious to know how much discussion, if any, has gone in to planning a full fledged OS for Teensy 4.1. Here are my thoughts:

The 4.1 has USB, Expandable Memory, Networking, and an SD Card. It also runs at 600Mhz. Older PC's like the 486, 586, 686, and Celeron M cpu's ran at between 33Mhz to 600Mhz and had full fledged Operating Systems using around 4Mb to 32Mb of memory. The systems had (still have) dedicated lines for expansion busses, like ISA; VESA Local, etc... all usable with hardware support drivers. Even the old Dinosours (Tandy 1000/2000) had dos based and windowing style capabilities with around 1Mb to 2MB and free memory to spare, which was plenty back then, maybe even now.

I know the Teensy 4.1 is fairly new, about 3-4 years old. Not many people, probably none, have teamed up to attempt to define a Teensy 4.1 specific time slicing/multi tasking system to run like a PC for the teensy. In the sense that the Teensy would need a well defined, and documented, Kernel Core to bring a system into fruition. A BIOS (Basic Input Output System) on old PCs had dedicated ports for Keyboard, Mouse (optional), Floppy, IDE, ISA/VESA bus controllers, and display controllers like CGA/VGA.

Another thought I've had regarding a full fledged OS is that the hardware wasn't dependant on a specific OS. DOS, LINIX, XENIX, Microware OS-9, etc... were all written to make use of the dedicated hardware already in place. Even the Commodore/TRS-80 had various OS's for their hardware, and all the systems were expandable.

I know how much time and effort this would take. It would literaly be years of work, man hours, for a single developer to do something like this. It would take several developers to form a working group to define and impliment such a system.

Most of the experianced developers with the Teensy 4.1 are busy with their own projects, work, and/or running their own businesses. So I don't think it would be top priority for them. Would they even want to support a group like this? Probably, but they might not partake in the development. Is this already in the works behind the scenes? Has this already been discussed and scrapped? Is there enough of a user base to even attempt this? A group would need a good understanding of all the inner working and hardware already on the Teensy 4.1.

I would assume the first step is to define a memory management system where specific data about the system is kept, and a means to alter that data based on hardware attached to some sort of bus, like input type ( MOUSE/KEYBOARD/Button Set ); Output type (Display/SERIAL/File); MEMORY Available; etc...

I think the Teensy 4.1 is fully capable of all this and probably more, but... not one person has the time to do all of this, it would take a well established team of volunteers to get things started before recieving major support. Focus would have to be kept on Teensy 4.1 with atleast 8MB RAM to get it started. License type/s would also need to be considered. Some type of contractual agreement would probably be needed, just to prevent a group member from running off with code and claiming the system causing support requests to the group for unknown software.

Could it be as simple as paying the top developers on the forum through crowd funding? How much would it cost? I am willing to pay something, not the whole shebang. After all, the teensy does have mechanisms to lock software, why not an OS as is normal today...

I don't expect any of the above to happen, although it would be awesome! Maybe I am just dreaming... I would like to know what everyone else thinks, including any/all the experianced Teensy devs who may, or may not, have any opinions/facts about this.
 
japreja said:
After all, the teensy does have mechanisms to lock software, why not an OS as is normal today...
Click to expand...

Normal operating systems today (and since the mid-1990s) are built on virtual memory which requires MMU hardware.

Teensy 4 does have High Assurance Boot and other security measures, but those are (more or less) analogous to TPM and secure boot on modern PCs, not the MMU and virtual memory.

Teensy 4 also has a MPU, but it's not anything like a MMU, despite the confusingly similar name. The Memory Protection Unit only enforces simple access controls, like certain regions of memory are read-only, other can be read or written but not allowed to execute code, etc. The MMU does that too, but also does so much more.

The full MMU hardware actually translates addresses from virtual space to physical memory. That is the essential hardware which allows each program to appear to be running only by itself with full access to the 32 bit address space. It is the hardware which allows all programs to be built to use the same memory address space, because each program runs within its own virtual space created by the MMU (and a lot of management by the operating system). It is the critical piece which prevents a bug in user-level applications from crashing the entire system.

Certainly a lot can be done without a MMU. Windows 3.1 and early MacOS achieved quite a lot without MMU hardware. With an incredible amount of work, you probably could build up an operating system and applications like what existed in the mid-1990s. But to get to an OS as is normal today, MMU hardware for virtual memory really is needed.
 
Its a tempting idea but once you really think about it you find there isn't any point. If you want a small, embedded device that runs a full operating system then Raspberry Pi and BeagleBone boards already exist. They aren't that much money. They have more processor power, more RAM, an MMU, etc. The Teensy 4.0/4.1/MM fits a different niche in my opinion. The only real reason to use a full fledged OS is to be able to run multiple programs. But, generally I think we're all using our Teensy boards for dedicated tasks. That could be driving a bunch of LEDs, playing MIDI music, running an emulator, or something else. But, it's one task and everything is built up to do that one task. I don't think it really is the appropriate board to use for running a full OS. For what the Teensy is good at, I'd say things like FreeRTOS, Chibi, and Zephyr are just the thing.

As a side note, I find myself guilty of this sometimes but, a 600MHz ARM Cortex M7 isn't the same thing as a 600MHz Pentium 3. The ARM processors have three branches (cleverly A, R, and M) and the M series is the lowest of them. There's a reason that smartphones and such use ARM A processors. You lose some functionality with the M processors but they're great for the tasks we usually use them for. So, one shouldn't take the 600Mhz and run too wild with ideas. It's a very fast embedded processor but it is not a competitor to a desktop computer processor, even a 10 or 20 year old one.
 
Might be worth mentioning, while ARM Cortex-A (usually) gives higher overall throughput and MMU for virtual memory, it's far from superior in terms of deterministic latency. Some operations the hardware does can't be interrupted for many cycles. The huge memory is DRAM with substantial access latency for cache misses, which is also occasionally tied up for refresh cycles.

ARM Cortex-M gives you get features like NVIC and CPU designed for very low latency interrupts. Many instructions which take several cycles (like pushing many registers to the stack) have hardware designed to abort the operation for immediate response to an interrupt, then it's restarted after the interrupt completes. On M7 (at least the IMXRT chips from NXP) you get relatively large tightly coupled memory for highly deterministic timing.

Like most engineering, the hardware design involves many trade-offs. Cortex-A and other PC class processors are designed for maximum performance but often that high average performance and large memory comes at a cost of worst case latency. Cortex-M and other microcontrollers are designed around low and deterministic latency responding to hardware events.

It really is a case of hardware designed for different uses, which is generally the reason why nobody writes conventional operating systems for microcontrollers.
 
fdaniels said:
What purpose has a OS on an embedded microcontroller?
Click to expand...
I keep landing on this thread when I search for "Teensy" and "RTOS", so here's an answer for anyone else who winds up here:

Microcontrollers are often used to control internal and external hardware that operates independently and asynchronously. Implementing the desired behavior as a single threaded program (Arduino style) makes for a poor match to the HW, and makes coding difficult. Coding it up as a series of interconnected interrupt handlers gives the desired efficiency and responsiveness, but has a high degree of complexity, and the result is fragile and inflexible. So the main thing I would be looking for in a OS is the ability to code the behavior as a set of threads, each thread dealing with the independent parts of the HW, and the threads then coordinating via some sort of signalling system, plus FIFO/shared memory etc. Ideally the thread context switches would be driven by interrupts (i.e. "tickless", except for any default or CPU bound threads.), so that there is no busy-waiting. It would be great if the OS also included common HW drivers that fitted into this paradime. Any other facilities that the OS brings to the table are bonuses.
 
You only need pre-emptive multi-thread support for that, not a whole OS - although you might consider that an RTOS is just pre-emptive threading and a few locking primitives, I guess its a matter of preference whether you call that an OS or a library. Most microcontrollers are single-processor so shared memory isn't a thing, other than there being different caching for processor and DMA I suppose.

And back to the original post, I don't think OS's target one processor, let alone one dev board, that would just be a standalone application that happen's to look like an OS that's not portable... It might be more reasonable to target an OS to a certain class of ARM processors, for instance, to enable device drivers that are closer to the hardware, but to be reasonably portable too.

One thing OS's provide that's seldom needed in a microcontroller context is program execution - microcontrollers have a single program, and that's a good thing (in terms of robustness and security)
 
MarkT said:
You only need pre-emptive multi-thread support for that, not a whole OS
Click to expand...
Graeme says he is searching for RTOS, as in FreeRTOS, etc. These may not be OS in the sense of managing memory or multiple cores and/or programs, but they have long been called RTOS and do provide the features he lists.

There is a FreeRTOS port for Teensy, but it requires changes to the Teensy core, and preemption is of limited value because Arduino libraries are generally not designed for it. I use a cooperative RTOS that includes inter-thread communication and timeouts. yield() does a cooperative task switch, which is its intended use in Arduino. I find it easier to think about handling communication interfaces and events in threads, and the cooperative RTOS allows me to use the same designs on Teensy that I use on other systems.
 
You must log in or register to reply here.
Back
Top