When debugging something as involved as kernel scheduler timings, you would typically use one of the software-based debugging mechanisms available. However, in cases when software is close to bare metal, you don’t always need to do that. Instead, you can output a signal to a GPIO, and then use a logic analyzer or a scope to measure signal change timing – which is what [Albert David] did when evaluating Linux kernel’s PREEMPT_RT realtime operation patches.
When you reach for a realtime kernel, latency is what you care about – realtime means that for everything you do, you need to get a response within a certain (hopefully very short) interval. [Albert] wrote a program that reads a changing GPIO input and immediately writes the new state back, and scoped both of the signals to figure out the latency of of the real-time patched kernel as it processes the writes. Overlaying all the incoming and outgoing signals on the same scope screen, you can quickly determine just how suitable a scheduler is when it comes to getting an acceptable response times, and [Albert] also provides a ready-to-go BeagleBone image you can use for your own experiments, or say, in an educational environment.
What could you use this for? A lot of hobbyists use realtime kernels on Linux when building CNC machine controllers and robots, where things like motor control put tight constraints on how quickly a decision in your software is translated into real-world consequences, and if this sounds up your valley, check out this Linux real-time task tutorial from [Andreas]. If things get way too intense for a multi-tasking system like Linux, you might want to use a RTOS to begin with, and we have a guide on that for you, too.
While the official title of the 5th Solvay conference was “on Electrons and Photons”, it was abundantly clear amongst the guests that the presentations would center on the new theory of quantum mechanics. [Planck], [Einstein], [Bohr], [de Broglie], [Schrodinger], [Heisenberg] and many other giants of the time would be in attendance. Just a month earlier, [Niels Bohr] had revealed his idea of complementarity to fellow physicists at the Instituto Carducci, which lay just off the shores of Lake Como in Italy.
The theory suggested that subatomic particles and waves are actually two sides of a single ‘quantum’ coin. Whichever properties it would take on, be it wave or particle, would be dependent upon what the curious scientist was looking for. And asking what that “wave/particle” object is while not looking for it is meaningless. Not surprisingly, the theory was greeted with mixed reception by those who were there, but most were distracted by the bigwig who was not there – [Albert Einstein]. He couldn’t make it due to illness, but all were eager to hear his thoughts on [Bohr’s] somewhat radical theory. After all, it was he who introduced the particle nature of light in his 1905 paper on the photoelectric effect, revealing light could be thought of as particles called photons. [Bohr’s] theory reconciled [Einstein’s] photoelectric effect theory with the classical understanding of the wave nature of light. One would think he would be thrilled with it. [Einstein], however, would have no part of [Bohr’s] theory, and would spend the rest of his life trying to disprove it.
Complementarity – Wave , Particle or both?
[Niels Bohr] contemplates one of [Einstein’s] many challenges to quantum theory.For more than a century it was thought that light was a wave. In 1801, [Thomas Young] had discovered interference patterns when shining a light through two very close slits. Interference is a well known property of waves. This combined with [Maxwell’s] equations, which predicted the existence of electromagnetic radiation put little doubt into anyone’s mind that light was nothing more, or less, than a wave. There was a very odd issue, however, that puzzled physicists during the 18th century. When shining light upon a metallic surface, electrons would be ejected from that surface. Increasing the intensity of the light did not translate to an increase in speed of the expelled electrons, like classical mechanics says it should. Increasing the frequency of the light did increase the speed. The explanation of this phenomenon could not be had until 1900, when [Max Planck] realized that physical action could not be continuous, but must be a multiple of some small quantity. This quantity would lead to the “quantum of action”, which is now called [Planck’s] constant and birthed quantum physics. It would have been impossible for him to know that this simple idea, in less than two decades, would lead to a change in understanding of the nature of reality. It only took Einstein, however, a few years to use [Planck’s] quantum of action to explain that mind-boggling issue of electrons releasing from metal via light and not following classical law with the incredibly complex equation:
E = hv
Where E is the energy of the light quanta, h is Planck’s constant and v is the frequency of the light. The most important item to consider here is this light quanta, later to be called a photon. It is treated as a particle. Now, if you’re not scratching your head in confusion right about now, you haven’t been paying attention. How can light be a wave and a particle? Join me after the jump and we’ll travel further down this physics rabbit hole.
[Andreas] has created this tutorial on real-time (RT) tasks in Linux. At first blush that sounds like a rather dry topic, but [Andreas] makes things interesting by giving us some real-world demos using a Raspberry Pi and a stepper motor. Driving a stepper motor requires relatively accurate timing. Attempting to use a desktop operating system for a task like this is generally ill-advised. Accurate timing is best left to a separate microcontroller. This is why we often see the Raspi paired with an Arduino here on Hackaday. The rationale behind this is not often explained.
[Andreas] connects a common low-cost 28BYJ-48 geared stepper motor with a ULN2003 driver board to a Raspberry Pi’s GPIO pins. These motors originally saw use moving the louvers of air conditioners. In general, they get the job done, but aren’t exactly high quality. [Andreas] uses a simple program to pulse the pins in the correct order to spin the motor. Using an oscilloscope, a split screen display, and a camera on the stepper motor, [Andreas] walks us through several common timing hazards, and how to avoid them.
The most telling hazard is shown last. While running his stepper program, [Andreas] runs a second program which allocates lots of memory. Eventually, Linux swaps out the stepper program’s memory, causing the stepper motor to stop spinning for a couple of seconds. All is not lost though, as the swapping can be prevented with an mlockall() call.
The take away from this is that Linux is not a hard real-time operating system. With a few tricks and extensions, it can do some soft real-time tasks. The best solution is to either use an operating system designed for real-time operation, or offload real-time operations to a separate controller.
