Shawn Schaffert’s ratcheting scheduler
Real Time Operating Systems?
Even though this project is about a smart home dashboard that doesn’t necessarily have any time-critical tasks, it very easily could. What if a cloud covered the solar panels, and I wanted to dim the lights in response. I don’t want my software to wait for all the temperature sensors to finish updated before changing the lighting. To avoid this potential problem, I want a “Real Time Operating System” for my project.
Systems using embedded controllers are often characterized by the need to exhibit real-time computing behavior. It’s important to understand what this means and how it affects the choice of software to use in a project. No one would argue that computers have been getting faster and faster over the years. Hard drive, memory, video card, and motherboard speeds and clock rates have been steadily increasing with each new generation of hardware. This has meant that the user can run complex applications without having to wait unreasonable amounts of time, and that simple applications perform their functions in vanishingly small time increments. For most desktop applications, small delays in program execution are unnoticeable and insignificant. But what if part of your application monitors the emergency-stop button for your home-built CNC milling machine? You need the emergency-stop button to shut the machine down within a guaranteed amount of time. Not having this determinism could create a very dangerous situation if, say, a background task like playing music or saving a file have momentarily taken over the computer bandwidth. You press and release the emergency-stop and watch in horror as your mill bit keeps going right through your part.
It doesn’t take a powerful or fast CPU to give a timely response to a single bit change in a peripheral I/O register. Anyone who has programmed a port interrupt in a simple 8-bit microcontroller can figure out how long it will take for the 8-bit processor to capture the I/O interrupt and call the code to respond to the event. With PC operating systems like OSX, Windows, and Linux, there is some ability to implement “real-time” threads, but this capability is often implemented by overriding the operating system’s normal behavior by using an operating system add-on to achieve this capability. These operating systems were designed to be effective general purpose tools for running a wide variety of applications and interacting with numerous third-party hardware devices, but they were not designed to have real-time, deterministic behavior.
A true real-time operating system (RTOS) is designed with features such that a program can be split into tasks which run on a fixed schedule, and asynchronous events, such as the CNC mill emergency-stop button press, will have a guaranteed maximum latency before they execute. You can write a program to toggle one I/O pin at 5 kHz and another at 1 kHz with minimal jitter, or program the emergency stop button response to shut off your CNC mill motors within a guaranteed 1 millisecond.
Check out a list of real time operating systems and find out about Windows Embedded CE 6.0 R2 here.
This SPARK Your Imagination Make: Windows Embedded project series is sponsored by Microsoft Corporation.
14 thoughts on “SPARK Project #1, Post #5”
Comments are closed.
A true emergency stop pretty much kills the tool dead by cutting all the power. None of the machine controls I’ve ever worked on trusted the computer to handle the e-stop, it was a hard switch of the power. Yeah, it might destroy whatever was in the machine, but it would keep the machine from destroying itself or somebody else.
I totally understand where you are coming from, as cutting the power to a misbehaving power tool seems like the best policy all the time, but see my reply to Nick below for my thoughts.
For a dramatic example of this, check out the SawStop:
http://www.sawstop.com/howitworks/how_monitor.php
Not every emergency stop relies on human intervention, and the hot dog in the SawStop video is probably happy that there was active intervention instead of just cutting the power…
Emergency stop buttons should never be “soft” stops, i.e. rely on software. They should always be hard-wired to cut the power directly to the device.
I was primarily using the emergency stop example to emphasize the consequences of failing to execute a time critical task in time. That said, the emergency stop systems on machine tools I’ve used (and had to hit the emergency stop) do rely on software. They actively create braking torque in the motors to rapidly halt motion. Cutting power to the motors simply allows them to spin down, which can be very dangerous situation.
I wouldn’t trust Windows Embedded CE to make my tea, let alone shut off my CNC mill motors.
It’s great to see some mention of RTOS on Make: I was just thinking the other week how it would be nice to do some RTOS project to open people’s minds to some of the engineering problems surrounding Realtime scheduling. However the emergency-stop example is not a great example since it has a human in the loop and you are already introducing huge delays and variability by that fact.
A hard realtime system might, e.g. detect a spinning disc and fire a strobe, giving the illusion that the image on the disk is stationary. The microprocessor could “rotate” the image according to a reading from a connected potentiometer.
Then, additional tasks could be added like communicating on a serial port, which mustn’t affect the stability of the image.
But then I doubt winCE has the engineering to be able to handle this scenario.
I’m with Robert on this one. I use MS Windows on the desktop, MS Windows on my phone, and I’ve developed WinCE applications for handheld computers, but I draw the line at my own uC projects. Ugh, enough already with the Windows everywhere thing! I don’t need Windows Embedded CE to make my LEDs blink!