Linux Fu: An Odd Use For Fork()

If you are a Star Trek fan, you’ll probably remember the phrase “You have to learn why things work on a starship.” The truth is, in most episodes, knowing how to override another ship’s console or make gunpowder didn’t come in very handy, but boy when it did, it really saved the day. Linux is a lot like that. There are a few things you probably don’t need to know very often, but when you do need to know, it makes a huge difference. In this particular post, I want to look at an odd use of the fork system call. For many purposes, you’ll never need to know this particular irregular use. But when you need it, you are really going to need it.

This is actually based on an old client of mine who used Unix to run a massive and very critical report every day.  The report had a lot of math since they were trying to optimize something and then generate a lot of reports. In those days, the output of the report was on old green-bar paper on a line printer. The problem was that the report took something like 14 hours to run including the printouts. If someone discovered something wrong, there was no time to run the report again because the next day’s report would have to start before the second run would finish.

The client had a bunch of Windows programmers and — at that time — there wasn’t anything really analogous to a real fork call in Windows. I looked at the code and realized that probably most of the code was spending time waiting to print the output. The computer had multiple CPUs and there were multiple printers, but that one program was hanging on the one printer. There was a lot of data, so writing it to a database and then running different reports against it wasn’t a great option. The answer was to use the power of fork. With a change in the code that took less than 30 minutes, the report ran in five hours. They were very pleased.

So how did I do it? The answer lies in how fork works. Just about every time you see a fork, you see some sort of exec call to start a new program. So if you think about fork at all, you probably think it is part of how you start a new program and, most of the time, that’s true. Continue reading “Linux Fu: An Odd Use For Fork()” →

A Rotary Encoder: How Hard Can It Be?

As you may have noticed, I’ve been working with an STM32 ARM CPU using Mbed. There was a time when Mbed was pretty simple, but a lot has changed since it has morphed into Mbed OS. Unfortunately, that means that a lot of libraries and examples you can find don’t work with the newer system.

I needed a rotary encoder — I pulled a cheap one out of one of those “49 boards for Arduino” kits you see around. Not the finest encoder in the land, I’m sure, but it should do the job. Unfortunately, Mbed OS doesn’t have a driver for an encoder and the first few third-party libraries I found either worked via polling or wouldn’t compile with the latest Mbed. Of course, reading an encoder isn’t a mysterious process. How hard can it be to write the code yourself? How hard, indeed. I thought I’d share my code and the process of how I got there.

There are many ways you can read a rotary encoder. Some are probably better than my method. Also, these cheap mechanical encoders are terrible. If you were trying to do precision work, you should probably be looking at a different technology like an optical encoder. I mention this because it is nearly impossible to read one of these flawlessly.

So my goal was simple: I wanted something interrupt driven. Most of what I found required you to periodically call some function or set up a timer interrupt. Then they built a state machine to track the encoder. That’s fine, but it means you eat up a lot of processor just to check in on the encoder even if it isn’t moving. The STM32 CPU can easily interrupt with a pin changes, so that’s what I wanted.

The Catch

The problem is, of course, that mechanical switches bounce. So you have to filter that bounce either in hardware or software. I really didn’t want to put in any extra hardware more than a capacitor, so the software would have to handle it.

I also didn’t want to use any more interrupts than absolutely necessary. The Mbed system makes it easy to handle interrupts, but there is a bit of latency. Actually, after it was all over, I measured the latency and it isn’t that bad — I’ll talk about that a little later. Regardless, I had decided to try to use only a pair of interrupts.

Continue reading “A Rotary Encoder: How Hard Can It Be?” →

Micromachining With A Laser

[Breaking Taps] has a nice pulsed fiber laser and decided to try it to micromachine with silicon. You can see the results in the video below. Silicon absorbs the IR of the laser well, although the physical properties of silicon leave something to be desired. He also is still refining the process for steel, copper, and brass which might be a bit more practical.

The laser has very short duration pulses, but the pulses have a great deal of energy. This was experimental so some of the tests didn’t work very well, but some — like the gears — look great.

Continue reading “Micromachining With A Laser” →

Arm Pumps Up The Volume With Mbed And A Potentiometer

Last time, I told you how to get started with the “Black Pill” STM32F411 board using the Mbed OS. The example program, admittedly, didn’t use many of the features of the OS, unless you count what the USB serial port driver uses behind the scenes. However, this time, we’ll make a practical toy that lets you adjust your PC’s volume level with a pot.

The Black Pill module on a breadboard.

The Black Pill is a good choice for this application since it has analog inputs and can act as a USB keyboard. In fact, the Mbed OS has drivers for all kinds of USB devices. We’ve seen the serial port, but you can also look like a mass storage device or a mouse, for example. Just for practice, we’ll create two threads of execution. One will read the pot and send a message over to the other thread. That thread will communicate with the PC as a USB keyboard. Any computer that understands media keys on a keyboard should work with the device.

Threads

Creating threads is very simple. For many cases, you just define a void function that takes no arguments and use it with a Thread object:

readknobThread.start(vol_thread);

Of course, the function shouldn’t return unless you want the thread to end. As I mentioned in the last post, you can sleep with the ThisThread::sleep_for call. There is also a yield call if you simply want to give up the time slice without sleeping for a specific amount of time.

Continue reading “Arm Pumps Up The Volume With Mbed And A Potentiometer” →

Honey, Did You Feed The Lamp? Company Wants To Create Living Light Bulbs

The BBC’s [Peter Yeung] had an interesting post about a small French town experimenting with using bioluminescent organisms to provide lighting. A firm called Glowee is spearheading the effort in Rambouillet and other towns throughout France, using a variety of biological techniques to harness nature’s light sources.

Glowing animals are reasonably common ranging from fireflies to railroad worms. In the case of the French street lighting, Glowee is using a marine bacterium known as aliivibrio fischeri. A salt-water tube contains nutrients and when air is flowing through the tube, the bacteria glow with a cool turquoise light. The bacteria enter an anaerobic state and stop glowing if you shut off the air.

Continue reading “Honey, Did You Feed The Lamp? Company Wants To Create Living Light Bulbs” →

Solaris Might Be Free If You Want It

There was a time when “real” engineering workstations ran Linux Unix. Apollo and Sun were big names and Sun’s version was Solaris. Solaris has been an iffy proposition since Oracle acquired Sun, but Oracle announced last month that you can download and use Solaris 11.4 CBE free for non-production use.

Do you care? If you ever wanted to run “real” Unix this is an option although, honestly, so is Free BSD and it probably has better community support. On the other hand, since you can virtualize a machine to spin up, it might be worth a little time to install it.

On the other hand, if you have an old SPARC machine — this could be big news. We aren’t sure how far back the hardware this will support will go, but this could be just what you need to breathe new life into that eBay pizza box from Sun you’ve had in the basement. Of course, if you have an FPGA SPARC system, this might be interesting too, but we have no idea how much other stuff you need to implement to be able to benefit from Solaris.

Will you install Solaris? If so, tell us why. We are sure we won’t have to prompt you to tell us why not. In 2017, we thought we’d seen the end of Solaris, but apparently not. Maybe this will help those folks still on Solaris 9.

KiCAD Plugin Gives Your PCBs That Handmade Look

The first PCBs we built involved a draftsman laying out large pieces of tape. The finished artwork would be photographically reduced to produce the board. This solved a few problems. It was easier to work on the large pieces and any errors were reduced by the scale amount. Boards from this era have a distinct appearance because the tracks are generally curved. But when computer-aided drafting took over, the early packages couldn’t deal with wavy lines making all sorts of angles. So traces started appearing at very common angles like 45 degrees or 90 degrees only. If you use KiCAD, though, there’s no reason to have rectilinear traces. Now there is a plugin to help make your boards appear like old-fashioned circuit boards.

The video by [mitxela] below talks about how we got here and debunks some common myths about PCB design. The plugin produces rounded corners and teardrop-shaped pads. There’s also a second post on the topic with more details. The effect isn’t just ornamental. There are some reasons graceful traces might be better than sharp angles.

Continue reading “KiCAD Plugin Gives Your PCBs That Handmade Look” →