If you’re at all like us, or like [Vadim], you’ve got a stash of development boards in a shoebox on a shelf in your closet. If you’re better organized that we are, it might even be labeled “dev boards”. (Ah well, that’s a project for another day.) Anyway, reach into your box and pull one out, and put it to use. Do something trivial if you need to, but a dev board that’s driving a silly blinker is better than a dev board sitting in the dark.
[Vadim]’s good example to us all is going to serve as the brains for an automated plant watering system. That’s a low-demand application where the microcontroller can spend most of the time sleeping. [Vadim]’s first step, then was to get a real-time clock working with the hibernation mode. There’s working code inline in his blog.
If you use Arduino, you’ll feel at home in the Energia ecosystem. But it’s like ordering a Quarter Pounder with Cheese in Paris: Energia is a Royale with Cheese (YouTube) — it’s the little differences. And maybe that’s the point of the exercise; it’s always a good thing to try out something new, even if it’s only minimally different.
So grab that unused dev board off the shelf, struggle through the unfamiliar development environment and/or toolchain, but remember to keep an eye out for the sweet little differences. The more tools that you’re familiar with, the more solutions will spring to mind when you’re hacking on your next project.
Are you already comfortable working with Serial Peripheral Interface (SPI) parts and looking for a challenge? We suspect many of you have cut your teeth on 8-bit through 32-bit microcontrollers but how much time have you spent playing with hardware interfaces on embedded Linux? Here a new quest, should you choose to accept it. [Matt Porter] spoke in detail about the Linux SPI Subsystem during his presentation at FOSDEM 2017. Why not grab an embedded Linux board and try your hand at connecting some extra hardware to one of the SPI buses?
The hardware side of this is exactly what you’d expect from any embedded SPI you’ve worked on: MOSI, MISO, a clock, and a slave select. [Matt] gives a succinct overview of SPI and reading datasheets. Our own [Elliot Williams] has done an excellent job of digging through the basics and most common gotchas if you need to get up to speed on all the SPI basics.
The fun details in the talk start at about 18:30 into the video when [Matt] jumps into the Linux side of SPI. You need a controller driver and a protocol driver. The controller driver is responsible for dealing with the pins (actual hardware) and the protocol driver handles the job of making sense of the SPI packets (messages containing any number of transfers) going in or out. In other words, the controller drive just want bits and pushes them in or out on hardware, the protocol driver makes those bits meaningful to the Linux system.
Adding SPI devices (think devices like LCDs and sensors) to your own embedded systems means telling the OS the particulars about that hardware, like max speed and SPI mode. There are three ways to handle this but the Device Tree is the preferred method for modern systems. This paves the way for the controller driver which implements an API set that the Linux SPI subsystem will use to work with your new hardware.
Protocol drivers follow the standard Linux driver model and are pretty straight forward. With these two drivers in place the new device is hooked into the OS and opens up common SPI API calls: spi_async(), spi_sync(), spi_write(), and spi_read(), and a few others.
One of the sticking points for us with our own Internet of Things is, ironically, the Internet part. We build hardware happily, but when it comes time to code up web frontends to drive it all, the thrill is gone and the project is only half-done.
Note that everything happens inside the ESP8266 here, from hosting the web page to interpreting and then blinking back out the IR LED codes to control the remote. This is a sophisticated “hello world”, the bare minimum to get you started. The interface could look slicker and the IR remote could increase its range with more current to the LED, but that would involve adding a transistor and some resistors, doubling the parts count.
For something like $10 in parts, though, this is a fun introduction to the ESP and BASIC. Other examples are simpler, but we think that this project has an awesome/effort ratio that’s hard to beat.
You might think that our community would always strive to be at the cutting edge of computing and use only the latest and fastest hardware, except for the steady stream of retrocomputing projects that appear. These minimalist platforms hark back to the first and second generation of accessible microcomputers, often with text displays if they have a display at all, and a simple keyboard interface to a language interpreter.
Often these machines strive to use the hardware of the day, and are covered with 74 logic chips and 8-bit processors in 40-pin dual-in-line packages, but there are projects that implement retrocomputers on more modern hardware. An example is [Sebastian]’s machine based upon a couple of PIC microcontrollers, one of which is an application processor with a PS/2 keyboard interface, and the other of which handles a VGA display interface. The application it runs calculates whether a 4-digit number is a prime and displays its results.
His write-up gives a fascinating overview of the challenges he found in creating a reliable VGA output from such limited hardware, and how he solved them. Though this one-sentence description makes a ton of work sound easy, horizontal sync pulses are generated as hardware PWM, and pixel data is streamed from the SPI bus. The VGA resolution is 640×480, upon which he could initially place a 10×10 block of text. Later optimizations extend it to 14×14.
Sometimes it’s not the power of the hardware but the challenge of making it perform the impossible that provides the attraction in a project, and on this front [Sebastian]’s retrocomputer certainly delivers. We’ve featured many other retrocomputers before here, some of which follow [Sebastian]’s example using modern silicon throughout, while others mix-and-match old and new.
If you’re looking for the technology here, you won’t find much. There’s no lens, no shutter, and no electronics of any kind in [Mick Farrell] and [Cliff Haynes]’ Straw Camera. This is literally a box full of drinking straws standing on end, with a sheet of photo paper behind it. Each straw sends a spot of light that represents the average hue and luminance of its limited view of the subject directly to the film. The process of making an exposure consists of composing the scene, turning out the lights, loading the camera, and setting off a flash.
The resulting images are defocused but recognizable, like seeing familiar sights through a heavy fog. The straws make a strong texture over the ghostly image of the subject – indeed, the straws are the only thing in focus. The fact that the straws don’t form a perfect honeycomb due to settling and imperfections in the bundles is jarring at first, but as you see the images you get used to the extra texture.
When we first saw this, we wondered about the possibility of putting a simple photosensor at the bottom of each straw to capture similar images digitally. The TCS3200 would be about the right size, but given that there are about 32,000 straws in the bundle, the BOM might get a little out of hand. Still, a scaled down digital straw camera might yield some interesting images.
Yup, another clock project. But here, [Jan] builds something that would be more at home in a modern art museum than in the dark recesses of a hacker cave. It’s not hard to read the time at all, it’s accurate, and it’s beautiful. It’s a linear RGB LED wall clock.
The technical details are straightforward: WS2812 LEDs, an Arduino, three buttons, and a RTC. You could figure that out by yourself. But go look through the log about building the nice diffusing plexi and a very clean wall-mounting solution. It’s the details that separate this build from what’s hanging on our office wall. Nice job, [Jan].
Browse around eBay for an original Altair 8800 and you quickly find that the price range is in the thousands of dollars. If you are a collector and have some money in your pocket maybe that’s okay. But if you want the Altair 8800 experience on a budget, you can build yourself a clone with an Arduino. [David] kindly shared the build details on his Arduino Project Hub post. Using an Arduino Due (or a Mega for 25% of original speed), the clone can accurately reproduce the behavior of the Altair’s front panel elements. We covered a similar project in the past, using the Arduino Uno.
While not overly complicated to build one, you will need a fair amount of patience so you can solder all the 36 LEDs, switches, transistors, and resistors but in the end, you’ll end up with a brand new computer to play with. In 1975, an assembled Altair 8800 Computer was selling for $621 and $439 for an unassembled version. Sourced right, your clone would be under 50 bucks. Not bad.
The simulator comes with a bunch of software for you to try out and even games like Kill-the-Bit and Pong. BASIC and Assembler example programs are included in the emulator software and can easily be loaded.
In addition, the simulator includes some extra functions and built-in software for the Altair which are accessible via the AUX1/AUX2 switches on the front panel (those were included but not used on the original Altair). From starting different games to mount disks in an emulated disk drive, there are just too many functions to describe here. You can take a look at the simulator documentation for more information.
In case you don’t know already, here’s how to play Kill-the-Bit: