Slashdot Mirror
BSD Real-Time Operating System NuttX Makes Its 100th Release: NuttX 6.33
paugq writes "NuttX is a real-time operating system (RTOS) with an emphasis on standards compliance and small footprint. Scalable from 8-bit to 32-bit microcontroller environments, the primary governing standards in NuttX are POSIX and ANSI standards. Additional standard APIs from Unix and other common RTOS's (such as VxWorks) are adopted for functionality not available under these standards, or for functionality that is not appropriate for deeply-embedded environments. NuttX was first released in 2007 by Gregory Nutt under the permissive BSD license, and today the 100th release was made: NuttX 6.33. Supported platforms include ARM, Atmel AVR, x86, Z80 and others."
Seems like a pretty ambitious project to run on a Z80. Good thing this isn't April 1st.
Git off my lawn you young whippersnapper.
I was running OS-9 on a Tandy Colour Computer (6809E, 2MHz) back in the late '80s. A full preemptive multi-tasking multi-user unix like system in a tiny little box. I even had a GUI running on it (well for about 1/2 an hour as it was too frisking slow!). Its amazing what you can do if you avoid bloat.
I am Slashdot. Are you Slashdot as well?
UZI: UNIX Z-80 IMPLEMENTATION
UZI is an implementation of the Unix kernel written for a Z-80 based computer. It implements almost all of the functionality of the 7th Edition Unix kernel. UZI was written to run on one specific collection of custom-built hardware, but since it can easily have device drivers added to it, and it does not use any memory management hardware, it should be possible to port it to numerous computers that current use the CP/M operating system. The source code is written mostly in C, and was compiled with The Code Works' Q/C compiler. UZI's code was written from scratch, and contains no AT&T code, so it is not subject to any of AT&T's copyright or licensing restrictions. Numerous 7th Edition programs have been ported to UZI with little or no difficulty, including the complete Bourne shell, ed, sed, dc, cpp, etc.
UZI180 - Unix Z80 Implementation for the Z-180 (UZI180)
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
What is Real Time and Why Do I Need It?
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
Had a friend ask me this once. I honestly couldn't come up with an answer. You look at the nuts and bolts of O/S's both realtime and non realtime, and it's basically all the same stuff, with more emphasis given to lower transaction times. Is it just a buzzword? Not trying to troll, but if someone has a definitive answer I'd love to hear it.
Realtime simply means that certain operations are guaranteed to complete in a given timeframe. This is harder than it appears.
There have been several threads on NuttX on the RPi and the "problem" is: what to do with so many resources? NuttX does not need 512 MB or RAM. It does not even need 512 *KB* of RAM! But yes, it's completely possible and there was a thread recently about using NuttX as a desktop operating system. Maybe not that crazy.
A hard real time system has to be deterministic. Operations have to happen exactly at the right times, and take exactly the same amount of time every time. Nothing can go on inside the OS that could delay or slow down the vital operations of the embedded device.
That being said you can have a real time os and do things that will make your system not deterministic. Unless specially designed (ethercat ect...), filesystems and network communication are typically non deterministic.
I suppose another thing I associate with real time is concept of a watch-dog. If you have a task that monitors some A2D and it absolutely has to run every 10ms in order for the system to function properly, you want your watch-dog to trip if your task doesn't run within some window.
This looks interesting but I can't find any information on whether it can run an SSH server or HTTPS on their site or through google. Does anyone know if it would be possible to port something Dropbear SSH to NuttX (assuming the CPU can handle it)?
They claim they have a POSIX-like system, which Dropbear needs so it should be possible, but has anyone done it yet?
Unicode in Slashdot
The headline creates the impression that this is a real-time adaptation of BSD (the "Berkeley Software Distribution", that is, BSD Unix). In fact, this OS is an original development; it is merely licensed under the terms that BSD is licensed under.
Would the headline have said "A GNU real-time OS" if it was licensed under the GPL, the license of the GNU operating system?
General gist:
A realtime OS is designed to handle a system that needs to operate in real time, generally one operating some sort of machinery. As such, the scheduler can offer certain guarantees - interrupts will be processed within a certain time limit, processes will get a certain amount of CPU time, and so on. A regular OS scheduler does not offer these guarantees, because they can come with performance limitations in peak scenarios.
Or to put it another way, a realtime OS aims for lowest maximum latency, a regular OS aims for lowest average latency, or potentially even highest average bandwidth.
Imagine an airplane (it's like a car analogy with wings). You have some sensor and a control surface, and every millisecond that sensor reads an input and that needs to affect the control surface in a very simple way. A regular OS scheduler does not guarantee that some other process won't have hold over the CPU for 2ms, while a realtime scheduler can be told to give you that guarantee, and even told how to prioritize tasks if the CPU is overutilized. In a plane, or other machinery, that guarantee can be very important because if things don't happen when they need to happen, things break.
Maybe, maybe not. There have been systems built in the past using all low-latency static memory and it made less of a difference than expected. Hard to say, maybe things would be different now. You would certainly want to test it, not just assume.
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
Some years ago in motor racing's Formula 1 competitions, when computer-controllers were in their infancy, Ferrari ran into driver problems -- they kept burning up tires and/or crashing. As it was well-known at the time that Ferrari motors were more powerful than their competition, there was a lot of "expert" press and fanboy head-scratching.
In the off-season, FIAT (Ferrari's parent company) bought Wind RIver RTS, which ran as 32-bit instead of 16, giving Ferraris more even (deeper bit depth) throttle response. Result? The next two seasons, no one could catch them, crashing was a thing of the past and so was excessive tire wear from wheelspin as the drivers had finer control of traction through their right foot.
Eventually, other teams went to 32-bit RT and Ferrari's dominance has waned..
You never know when a RTOS will make the difference.
Real real-time OSs have various elements that are REQUIRED for real-time:
- Masked interrupts (you can PREVENT hardware interrupts from actuating code, instead scheduling future software handlers)
- Determnisitic interrupts (so that you can tell WHEN the clock will force action, not "generally" when clock "will or will later" react)
- Codepath timings (so you know how long it takes to execute X, and X won't change during the life of the system).
BSD-based systems are knocking on the door of being usable. It will be a while before these "We're true to our 1970s
Unix codebase and we don't play well with others copyleft" systems can catch up to the 20th century, the 21st century,
and real-time software-design and OS requirements.
I love watching ants build anthills. They are so proud of their work. They make great molten-lead art.
Just like BSD being used for anything other than pretending it's almost as good as linux, neither of
which are good for real time OSs.
M
The summary doesn't give a good idea of the scope of the project. The lead developer is targeting chips with low pincount. He considers more powerful smartphone class ARM's like found on the Raspberry Pi and Beaglebone Black to be too powerful for his project to make sense, and recommends running linux: http://comments.gmane.org/gman... That said, he offered to help if someone else wanted to do a port for some reason.