Code your hardware using this open source RTOS
Programming a chip is hard, but RTOS solves many of the major issues on embedded systems.
By: Zhu Tianlong | Opensource.com.
In general computing, an operating system is software that provides a computer’s basic functions. It ensures that a computer detects and responds to peripherals (like keyboards, screens, mobile devices, printers, and so on), and it manages memory and drive space.
Even though modern operating systems make it seem that multiple programs are running at the same time, a CPU core can run only a single thread at a time. Each task is executed so quickly and in such rapid succession that the result appears to be massive multi-tasking. This is managed by a subroutine called a scheduler.
Operating systems, usually, are for computers. The OS is installed to your hard drive, and manages the computer’s tasks.
I discovered embedded software in 2008, when I was a student learning about programming on an MCS-51 chip. Because I was majoring in computer science, all the programs I was doing in other courses were executed on a PC. But programming on a chip was a completely different experience. For the first time, I saw my programs running on a bare-metal board, and I can still remember the excitement when my first cycling lamp program ran successfully.
The excitement was relatively short-lived, though. The more bare-metal programs I wrote, the more issues I encountered. I wasn’t alone in this frustration. Programming a chip directly is hard, and there are good reasons PCs use an operating system. Unfortunately, computer chips (an embedded system) don’t normally have an OS. They’re “hard coded” with code with no OS to help manage how the code gets executed.
Here are the problems you might encounter when hard coding a computer chip:
You don’t have daemons on a chip to manage execution. For bare-metal programs, there is inevitably a huge while (1) loop that contains almost all the transaction logic of the whole project. Each transaction invokes one or more delay functions. These are executed serially when the CPU is running a delay function. There’s nothing to preempt an unnecessary delay, so the transaction reset has to wait. As a result, much of the CPU time is wasted on empty loops, which is bad for concurrency.
