It was just one of these nights. We were sitting at the O’Neil’s San Mateo Pub, taking a break after a long day at the Maker Faire. Hackaday was hosting an informal drink-up and a steady stream of colorful characters has just started flowing in. That’s when we met [Robert Coggeshall].
It started off as a normal discussion – he runs Small Batch Assembly and does a lot of interesting things in the maker space. Then he brought up a fascinating detail – “Oh, did you know I also co-invented sudo back in the 80’s?”
If you ever did as much as touch a Unix system, you’ll know this is a big deal. What came as an even bigger surprise was that something like sudo had to be “invented” in the first place. When thinking about the base Unix toolkit, there is always this feeling that it all emerged from some primordial soup of ideas deep inside of Bell Labs, brought to life by the infinite wisdom of [Ken Thompson] and the rest of the gang. Turns out that wasn’t always the case. We couldn’t miss asking [Bob] for an interview, and he told us how it all came about…
[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.
From time to time we realize that sayings which make sense to us probably will have no meaning for future generations. Two of the examples that spring to mind are “hang up the phone” or in a vehicle you might “roll down the window”. And so is the case for today’s Retrotechtacular. Linux users surely know about TTY, but if you look up the term you actually get references to “Teletypewriter”. What’s that all about?
[Linus Akesson] wrote a fantastic essay on the subject called The TTY Demystified. We often feature old video as the subject of this column, but we think you’ll agree that [Linus’] article is worth its weight in film (if that can be possible). The TTY system in Linux is a throwback to when computers first because interactive in real-time. They were connected to the typewriter-mutant of the day known as a teletype machine and basically shot off your keystrokes over a wire to the computer the terminal was controlling.
This copper pipeline to the processor is still basically how the terminal emulators function today. They just don’t require any more hardware than a monitor and keyboard. We consider ourselves fairly advanced Linux users, but the noob and expert alike will find nuggets and tidbits which are sure to switch on the lightbulb in your mind.
For both the Raspberry Pi and BeagleBone Black, there’s a lot of GPIO access that happens the way normal Unix systems do – by moving files around. Yes, for most applications you really don’t need incredibly fast GPIO, but for the one time in a thousand you do, poking around /sysfs just won’t do.
[Chirag] was playing around with a BeagleBone and a quadrature encoder and found the usual methods of poking and prodding pins just wasn’t working. By connecting his scope to a pin that was toggled on and off with /sysfs he found – to his horror – the maximum speed of the BBB’s GPIO was around three and a half kilohertz. Something had to be done.
After finding an old Stack Overflow question, [Chirag] hit upon the solution of using /dev/mem to toggle his pins. A quick check with the scope revealed he was now toggling pins at 2.8 Megahertz, or just about a thousand times faster than before.
After seeing [Dimitry] build the most minimal Linux computer ever, [Kyle] decided he needed one for himself. In true hacker fashion, he decided to take this build for the worst Linux PC one step further: he would add I2C to his version, making it somewhat useful, considering the number of I2C peripherals out there.
This build is based on [Dmitry]’s ARM Linux computer emulated on an 8-bit AVR. It’s a full-blown Linux computer with 16 MB of RAM courtesy of a 30-pin SIMM, a lot of storage provided by an SD card, all running on an emulated ARM processor inside a lowly ATMega1284p. [Kyle] built this clone over the course of a few months, but from the outset decided he wanted to implement an I2C protocol on this terribly under specced computer.
After booting his computer, [Kyle] eventually got an I2C module loaded by the kernel. With an I2C module and a few spare GPIO pins, he set out to create something to attach to this terribly slow computer – an ancient LED dot matrix display. With a real-time clock, this display became a clock with the help of a homebrew program written in C. Considering the speed of the emulated processor, the program takes nearly three seconds to read the RTC and display the current time to the display. We’re thinking it was a wise choice to only implement hours and minutes in this clock.
If having a useful computer running at about 10 kilohertz isn’t enough, [Kyle] also compiled the classic text-based adventure Zork. It actually runs, proving you don’t need Megahertz of power to do something useful and fun.
Christmas is coming, and if you have nieces, nephews, or ankle biters of your own roaming your house, you’re probably wondering how you’ll be subsidizing Santa this year. it looks like Toys R Us will be selling the Leapfrog LeapsterGS for $30 on Black Friday this year. It’s a Linux device running on a 550 MHz ARM 9, with 128 MB of RAM and 2 GB of Flash. Overpowered for a children’s toy, but perfect for when the kids forget about it in a month, because now you can replace the firmware with a proper Linux install and run classic emulators.
Putting Linux on these cheap handhelds made for children isn’t anything new; we’ve seen it done with the Leapfrog DIDJ and the Leapfrog Explorer. Those consoles, however, had rather anemic CPUs and not a whole lot of RAM. Moore’s Law finally kicked in for stocking stuffers, it seems, and the Leapster GS is powerful enough to play all those Nintendo, Game Boy and even MAME games.
All that’s needed to flash the new firmware is soldering a few wires onto the LeapsterGS’ board for a serial connection. The new LeapsterGS firmware even has an MP3 and movie player, so even if the recipient of one of these machines grows tired of it in a week, there’s still a lot of life left in it.
Video of the LeapsterGS playing the greatest arcade game below.
Over the last few months, a few very capable hackers have had a hand in cracking open a Transcend WiFi-enable SD card that just happens to be running a small Linux system inside. The possibilities for a wireless Linux device you can lose in your pocket are immense, but so far no one has gotten any IO enabled on this neat piece of hardware. [CNLohr] just did us all a favor with his motherboard for these Transcend WiFi SD cards, allowing the small Linux systems to communicate with I2C devices.
This build is based upon [Dmitry]’s custom kernel for the Transcend WiFiSD card. [CNLohr] did some poking around with this system and found he could use an AVR to speak to the card in its custom 4-bit protocol.
The ‘motherboard’ consists of some sort of ATMega, an AVR programming header, a power supply, and a breakout for the I2C bus. [Lohr] wired up a LED array to the I2C bus and used it to display some configuration settings for the WiFi card before connecting to the card over WiFi and issuing commands directly to the Linux system on the card. The end result was, obviously, a bunch of blinking LEDs.
While this is by far the most complex and overwrought way to blink a LED we’ve ever seen, this is a great proof of concept that makes the Transcend cards extremely interesting for a variety of hardware projects. If you want your own Transcend motherboard, [CNLohr] put all the files up for anyone who wants to etch their own board.