Thanks to the virus crisis, lots of people are designing makeshift ventilator designs in the hopes of saving people’s lives. Many of these are based around some sort of Arduino-powered CPU. [Armstrong Subero] things that’s a great idea, but cautions that making an electronic pair of dice is a different proposition than creating a machine to breathe for someone. But he isn’t just complaining. He talks about considerations when building a real-time and safety-critical system.

[Armstrong] has a lot of good points, although we aren’t sure you need the complexity of a real-time operating system just to squeeze a bag. If anything, that seems like it might make it more susceptible to unexpected operation. However, we agree with his comments that you should have closed-loop control to make sure the device is working, alarming when the device isn’t working, and watchdog timers to guard against lockup.

One excellent point from the post:

For example a high availability system real time system may be specified as having an up time of around 99% in a 24 hour period. Which 1% of the day is it acceptable to have the ventilator not operational? Since we have 1440 minutes in a day, which 14.4 minutes of the day should the patient not be allowed to breathe?

However, he does have some solid suggestions such as using an IDE with debugging and adhering to a coding standard such as MISRA. Of course, he also points out you might choose a different CPU that has safety-critical certifications and corresponding libraries. One suggestion is to have multiple CPUs, and this is a common enough solution in many safety-critical systems. For example, imagine 3 CPUs driving a switching circuit that requires a low logic level to turn on.

You could make the outputs go to inputs if the CPU wants to not drive the switch, or pull the output to ground if it does. Then a pull-up resistor holds the state high if no CPU pulls it to ground. All CPUs could sense the state of the line and if they don’t think it looks right they sound their own alarm. Some systems vote so that two of three CPUs must agree (at least) or, in some cases, three out of five.

We’ve been talking about ventilators quite a bit lately. The kind of mechanical design [Armstrong] is probably thinking of is like the MIT design we talked about last week.

What was your first Arduino program? Probably an LED blinker — that seems to be the “hello world” of microcontrolllers. You probably moved on to things a little more complicated pretty quickly. At some point, things get harder because the Arduino lacks an operating system.

There are operating systems that will run on the Arduino. They aren’t full-featured like Windows or Linux, but they allow you to run multiple tasks that are both isolated from each other (to some degree) and have a way to cooperate (that is, synchronize, share data and resources, and so on). One such operating system is ChibiOS. It will run on AVR- and ARM-based devices. You can find documentation about the entire project on the home page along with other ports.

The problem with adopting a new operating system is always getting started. [ItKindaWorks] has started a video series on using ChibiOS and has posted three installments so far (see below; one is about getting started, the other two cover messaging, mutexes, and priorities).

If you want to follow along with the videos, the code is available on GitHub. We aren’t sure if he’s planning more videos, but these will be more than enough to get you started.

According to the ChibiOS project, they are better than many common similar operating systems because of their static design (you can put the processor to sleep without causing problems). They also support true threads instead of simple tasks, meaning that you can dynamically create and destroy threads and synchronize threads easily.

If you are building sophisticated software that needs multiple things occurring at once, having an operating system can make life a lot easier. We’ve seen examples of using ChibiOS ranging from motor control to MIDI players. There are quite a few choices other than ChibiOS, too, if you look around.

The Linux Foundation is a non-profit organization that sponsors the work of Linus Torvalds. Supporting companies include HP, IBM, Intel, and a host of other large corporations. The foundation hosts several Linux-related projects. This month they announced Zephyr, an RTOS aimed at the Internet of Things.

The project stresses modularity, security, and the smallest possible footprint. Initial support includes:

• Arduino 101
• Arduino Due
• Intel Galileo Gen 2
• NXP FRDM-K64F Freedom

The project (hosted on its own Website) has downloads for the kernel and documentation. Unlike a “normal” Linux kernel, Zephyr builds the kernel with your code to create a monolithic image that runs in a single shared address space. The build system allows you to select what features you want and exclude those you don’t. You can also customize resource utilization of what you do include, and you define resources at compile time.

By default, there is minimal run-time error checking to keep the executable lean. However, there is an optional error-checking infrastructure you can include for debugging.

The API contains the things you expect from an RTOS like fibers (lightweight non-preemptive threads), tasks (preemptively scheduled), semaphores, mutexes, and plenty of messaging primitives. Also, there are common I/O calls for PWM, UARTs, general I/O, and more. The API is consistent across all platforms.

You can find out more about Zephyr in the video below. We’ve seen RTOS systems before, of course. There’s even some for robots. However, having a Linux-heritage RTOS that can target small boards like an Arduino Due and a Freedom board could be a real game changer for sophisticated projects that need an RTOS.

Everyone loves Top Gear, or as it’s more commonly known, The Short, The Slow, And The Ugly. Yeah, terrible shame [Clarkson] ruined it for the rest of us. Good News! A show featuring drones will be filling the Top Gear timeslot. And on that bombshell…

More Arduino Drama! A few weeks ago, Arduino SRL (the new one) forked the Arduino IDE from Arduino LLC’s repo. The changes? The version number went up from 1.6.3 to 1.7. It’s been forked again, this time by [Mastro Gippo]. The changes? The version number went up to 2.0. We’re going to hold off until 2.1; major releases always have some bugs that take a few weeks to patch. Luckily the speed of the development cycle here means that patch should be out soon.

Need an ESP8266 connected to an Arduino. Arachnio has your back. Basically, it’s an Arduino Micro with an ESP8266 WiFi module. It also includes a Real Time Clock, a crypto module, and a solar battery charger. It’s available on Kickstarter, and we could think of a few sensor base station builds this would be useful for.

[Ben Heck] gave The Hacakday Prize a shoutout in this week’s episode. He says one of his life goals is to go to space. We’re giving that away to the project that makes the biggest difference for the world. We’re not sure how a [Bill Paxton] pinball machine fits into that category, but we also have a Best Product category for an opportunity to spend some time in a hackerspace… kind of like [Ben]’s 9 to 5 gig…

[Jim Tremblay] wrote a real time operating system for a bunch of different microcontrollers. There are a lot of examples for everything from an Arduino Mega to STM32 Discovery boards. Thanks [Alain] for the tip.

45s – the grammophone records that play at 45 RPM – are seven inches in diameter. Here’s one that’s 1.5 inches in diameter. Does it work? No one knows, because the creator can’t find a turntable to play it on.

Are we betting on the number of people who don’t get the joke in the first paragraph of this post? Decide in the comments.