Developed in the very late 60s and through the 70s, the PDP-11 series of minicomputers was quite possibly the single most important computer ever created. The first widely distributed versions of Unix and C were developed on the PDP-11, and it’s hardware influence can be found in everything from the Motorola 68000 to the MSP430.
When [Dave Cheney] saw the recent 8086 simulator written in 4kB of C code, he realized simulating entire computer systems doesn’t actually require a whole lot of resources outside a big chunk of memory. Armed with an Arduino Mega clone, he set out on one of the coolest projects we’ve seen in a while: simulating a PDP-11 on an AVR.
[Dave] used an ATMega2560-powered Arduino Mega clone with an Ethernet module for the hardware of this build. Attached to it is a shield filled up with a pair of RAM chips that expand relatively limited amount of RAM on the ‘Mega.
So far, [Dave] has his simulated system booting Unix V6 off an SD card. For PDP-11 storage, he’s also simulating an RK05 disk drive, a massive 14 inch platter containing 2.5 Megabytes of data. Compared to the original PDP-11/40, [Dave] estimates his machine is about 10 times slower. Still, an original 11/40 system fills multiple server racks, and the most common installations consume several kilowatts of power. The Arduino Mega can fit in a pocket and can be powered over USB.
Future developments for this system include improving the accuracy of the simulator, running more advanced operating systems and the DEC diagnostic programs, and possibly speeding up the simulation. We’d suggest adding some switches and blinkenlights on an additional shield, but that’s just us.
All the code can be found on [Dave]’s git, with a description of his SPI RAM shield coming shortly.
The lowly Arduino, an 8-bit AVR microcontroller with a pitiful amount of RAM, terribly small Flash storage space, and effectively no peripherals to speak of, has better speech recognition capabilities than your Android or iDevice. Eighty percent accuracy, compared to Siri’s sixty.Here’s the video to prove it.
This uSpeech library created by [Arjo Chakravarty]
uses a Goertzel algorithm to turn input from a microphone connected to one of the Arduino’s analog pins into phonemes. From there, it’s relatively easy to turn these captured phonemes into function calls for lighting a LED, turning a servo, or even replicating the Siri, the modern-day version of the Microsoft paperclip.
There is one caveat for the uSpeech library: it will only respond to predefined phrases and not normal speech. Still, that’s an extremely impressive accomplishment for a simple microcontroller.
This isn’t the first time we’ve seen [Arjo]’s uSpeech library, but it is the first time we’ve seen it in action. When this was posted months and months ago, [Arjo] was behind the Great Firewall of China and couldn’t post a proper demo. Since this the uSpeech library is a spectacular achievement we asked for a few videos showing off a few applications. No one made the effort, so [Arjo] decided to make use of his new VPN and show off his work to the world.
Continue reading “An Arduino With Better Speech Recognition Than Siri”
Ideally, technology is supposed to enhance our lives. [Shane and Eileen], two seniors at Cornell have found a great way to enhance the lives of visually impaired individuals with their acoustic wayfinding device. In brainstorming for their final project, [Shane and Eileen] were inspired by this Hackaday post about robots as viable replacements for guide dogs. They sought to provide wearable, hands-free guidance and detection of (primarily) indoor obstacles—namely chairs, benches, and other inanimate objects below eye level.
The wayfinder comprises two systems working in tandem: a head-mounted navigation unit and a tactile sensor worn on the user’s finger. Both systems use Maxbotix LV-MaxSonar-EZ0 ultrasonic rangefinder modules to detect obstacles and vibrating mini-disc motors to provide haptic feedback at speeds proportionate to the user’s distance from an obstacle.
The head unit uses two rangefinders and two vibrating motors. Together, the rangefinders have a field of view of about 120 degrees and are capable of detecting obstacles up to 6.45 meters away. The tactile sensor comprises one rangefinder and motor and is used in a manner similar to a Hoover cane. The user sweeps their hand to detect objects that would likely be out of the range of the head unit. Both parts are ergonomic and size-adjustable.
At power up, [Shane and Eileen]’s software performs a calibration of the tactile sensor to determine the distance threshold in conjunction with the user’s height. They’ve used an ATMega 1284 to drive the system, and handled real-time task scheduling between the two subsystems with the TinyRealTime kernel. A full demonstration video is embedded after the break.
Continue reading “Acoustic Wayfinder for the Visually Impaired”
Hosting a New Year’s Eve party, but don’t want to be stuck behind the bar all night? You could set out a bowl or two of
spiked punch, but where’s the hack? Free yourself from drink slinging duties with the Automated Drink Mixer created by Cornell University students [Justin] and [Austin]. Their design uses a 14″ diameter lazy Susan powered by a 12V bi-directional motor attached to a 2″ rubber wheel. The motor is capable of 70RPM, so the glass ultimately rides around at 10RPM. Orders are entered on a push-button menu. As this is a school project that should adhere to IEEE standards, all libations are non-alcoholic.
The software uses an overarching state machine, so the system polls for input from the menu at idle. When it receives an order, the lazy Susan rotates the glass to the right spout or series of spouts and then returns it to the starting point. [Justin] and [Austin] controlled the position of the glass with an IR emitter and phototransistor. This pair detects the black strips of tape around the edge which are spaced 60° apart. A comparator digitizes the signal and triggers an interrupt in the software, which counts the number of 60° slices. A full demonstration is waiting for you after the jump. Before you jump: drink responsibly, kids. If you aren’t up to that particular challenge, make yourself an alcohol-aware LED ice cube. If you need more LEDs in your life, whip up the Inebriator.
Continue reading “Automated Drink Mixer Is the Life of the Party”
Candle flicker LEDs are a one part replacement for a real candle. They contain both a yellow LED and a control chip that modulates the light to create a candle effect. [Cpldcpu] took a deep look into reverse engineering one of these LEDs.
To analyze the circuit, which is potted into the LED itself, a shunt sense resistor was connected to the LED. By connecting this resistor to a logic analyzer, the control signal could be observed.
This control signal looked like pulse width modulation, with some randomness to the duty cycle. [Cpldcpu] determined that a linear feedback shift register was most likely used to generate a pseudeorandom bitstream, and some shaping was applied to make the LED look more like a real candle.
It turns out a blinking LED can be quite complex, and this takes a deep look into it by analyzing the signal. [Cpldcpu] took the lessons learned and wrote an implementation of the algorithm for AVR.
[Ralph] has been working on an extraordinarily tiny bootloader for the ATtiny85, and although coding in assembly does have some merits in this regard, writing in C and using AVR Libc is so much more convenient. Through his trials of slimming down pieces of code to the bare minimum, he’s found a few ways to easily trim a few bytes off code compiled with AVR-GCC.
To test his ideas out, [Ralph] first coded up a short program that reads the ATtiny85’s internal temperature sensor. Dissassembling the code, he found the a jump to a function called __ctors_end: before the jump to main. According to the ATtiny85 datasheet, this call sets the IO registers to their initial values. These initial values are 0, so that’s 16 bytes that can be saved. This function also sets the stack pointer to its initial value, so another 16 bytes can be optimized out.
If you’re not using interrupts on an ATtiny, you can get rid of 30 bytes of code by getting rid of the interrupt vector table. In the end, [Ralph] was able to take a 274 byte program and trim it down to 190 bytes. Compared to the 8k of Flash on the ‘tiny85, it’s a small amount saved, but if you’re banging your head against the limitations of this micro’s storage, this might be a good place to start.
Now if you want to hear some stories about optimizing code you’ve got to check out the Once Upon Atari documentary. They spent months hand optimizing code to make it fit on the cartridges.
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.