Motorized Camera Dolly Rolls With the Changes

Over the last semester, Cornell student [Ope Oladipo] had the chance to combine two of his passions: engineering and photography. He and teammates [Sacheth Hegde] and [Jason Zhang] used their time in [Bruce Land]’s class to build a motorized camera dolly for shooting time-lapse sequences.

The camera, in this case the one from an iPhone 6, is mounted to an off-the-shelf robot chassis that tools around on a pair of DC motors. The camera mount uses a stepper motor to get just the right shot. A PIC32 on board the ‘bot takes Bluetooth commands from an iOS app that the team built. The dolly works two ways: it can be controlled manually in free mode, or it can follow a predetermined path at a set speed for a specified time in programmed mode.

Our favorite part of the build? The camera’s view is fed to a smart watch where [Ope] and his team can take still pictures using the watch-side interface. Check it out after the break, and stick around for a short time-lapse demo. We’ve featured a couple of dolly builds over the years. Here’s a more traditional dolly that rides a pair of malleable tubes.

Time-lapse example

Thanks for the tip, [Bruce Land]!

Filed under: digital cameras hacks, Microcontrollers

Programming the Open-V Open Source CPU on the Web

openriscv_webYou can now program the Open-V on the web, and see the results in real time. The code is compiled in the web IDE and then flashed to a microcontroller which is connected to a live YouTube live stream. It’s pretty neat to flash firmware on a microcontroller thousands of miles away and see the development board blink in response.

We’ve covered the Open-V before, and the crowd funding campaign they have going. The Open-V is an open hardware implementation of the RISC-V standard. And is designed to offer Cortex M0-class capabilities.

This feels like a create way to play around with some real hardware and get a taste of what a future where we can expect Arduino-like boards, open source down to the transistor level.

For a closer look at why open silicon matters, check out [Brian Benchoff’s] hands-on review of the HiFive, an Arduino form-factor board built around an open hardware RISC-V microcontroller.

Filed under: ARM, Microcontrollers

Encoders Spin Us Right Round

Rotary encoders are great devices. Monitoring just a few pins you can easily and quickly read in rotation and direction of a user input (as well as many other applications). But as with anything, there are caveats. I recently had the chance to dive into some of the benefits and drawbacks of rotary encoders and how to work with them.

I often work with students on different levels of electronic projects. One student project needed a rotary encoder. These come in mechanical and optical variants. In a way, they are very simple devices. In another way, they have some complex nuances. The target board was an ST Nucleo. This particular board has a small ARM processor and can use mbed environment for development and programming. The board itself can take Arduino daughter boards and have additional pins for ST morpho boards (whatever those are).

The mbed system is the ARM’s answer to Arduino. A web-based IDE lets you write C++ code with tons of support libraries. The board looks like a USB drive, so you download the program to this ersatz drive, and the board is programmed. I posted an intro to mbed awhile back with a similar board, so if you want a refresher on that, you might like to read that first.

Reading the Encoder

The encoder we had was on a little PCB that you get when you buy one of those Chinese Arduino 37 sensor kits. (By the way, if you are looking for documentation on those kinds of boards, look here.; in particular, this was a KY-040 module.) The board has power and ground pins, along with three pins. One of the pins is a switch closure to ground when you depress the shaft of the encoder. The other two encode the direction and speed of the shaft rotation. There are three pull-up resistors, one for each output.

I expected to explain how the device worked, and then assist in writing some code with a good example of having to debounce, use pin change interrupts, and obviously throw in some other arcane lore. Turns out that was wholly unnecessary. Well… sort of.

Abstract Reasoning

I forget that the Arduino, mbed, and other similar platforms have a wealth of (often user-contributed) libraries. I did a quick search from the import dialog (see below) and found several likely-looking libraries. The highlighted item (from [Karl Zweimüller]) was updated this year, so I figured it was a safe bet. Pressing the ridiculously large import button near the top right of the screen took care of it.


With the library in the project, the question becomes: how to use it? Luckily, there’s documentation built in. When you navigate your project, some nodes are source code and some are documentation (they look like little blue documents in the navigator). Clicking on the mRotaryEncoder node shows a useful help document (shown below). What else do you need to know?


The Code

Armed with this, there are just a few lines of code to write. This one sets up the encoder:

mRotaryEncoder enc(D7,D8, D4,PullNone);

The D7, D8, and D4 constants define pin numbers (D7 and D8 are the encoder pins and D4 is the switch which I am actually not using). The PullNone prevents the CPU from enabling internal pullup resistors because the board already has them.

Next, we can assign functions that the library will call on certain events. In particular:

void cw()
 if (dutycycle>1.0) dutycycle=1.0;

void ccw()
 if (dutycycle<0.0) dutycycle=0.0;

You may have deduced my clever naming scheme. The cw function handles clockwise motion, and the ccw function handles the reverse. How does the library know what to call? It takes some setup in the program’s main function:


But Wait a Minute!

Sure, that’s simple. It is a great abstraction that handles a lot of complex issues. But what do you learn doing that? Not much. For all you can tell, the encoder might have a microprocessor on it and is sending data via some serial protocol (which, actually, isn’t a bad idea with as cheap as processors are now).

I decided it wasn’t sufficient to just roll out a canned library. I drug out the scope, and we put the encoder on channel 1 and channel 4 (it is a shame that channel 2 and channel 4 have nearly the same color on the probe rings). Here’s the result of twisting the shaft clockwise and counterclockwise:

Clockwise Rotation Counter Clockwise Rotation

The key is to look at the falling edge of the top trace. Note that in the clockwise case (left image), the bottom trace is high at that time. In the counterclockwise case (right image), it is low. You can actually detect on both edges if you like, but for most purposes, this is sufficient and it really is that simple. Watch for the edge, note the other signal’s state, and that tells you the direction. Clearly, the faster the edges come, the faster the shaft is spinning.

This is known as quadrature encoding because the two signals are 90 degrees out of phase.

Bouncy Bouncy

In an ideal world, this would be pretty easy. However, the world is far from ideal. You can see some noise on the signals if you look closely. Let’s zoom in:


You don’t want to take all of those as falling edges! You need some debouncing. Ideally, you’d wait for the signal to go low, wait a bit, make sure it was still low and then react. Then you would not look again for some other time out delay.

This can be tricky because you typically don’t want to poll for the edge. You want to use something like a pin change interrupt that calls your code when a pin changes state.

Since the mbed libraries include the source, it was easy to look at what was really going on. The library doesn’t use an interrupt. It uses a class known as PinDetect (by [Andy Kirkham]) that polls on a timer (by default, every 20mS).

The code doesn’t have any comments, so I added a few to the partial code below:

 void isr(void) {
 int currentState = _in->read();  // get current pin state
 if ( currentState != _prevState ) {  // if the state has changed
   if ( _samplesTillAssert == 0 ) {   // see if that was long enough
     _prevState = currentState;       // remember state for next time
    _samplesTillHeld = _samplesTillHeldReload;  // reset hold time
    if ( currentState == _assertValue ) // call correct callback;
 else {
     _samplesTillAssert--;  // state held, so keep counting down
 else {
 _samplesTillAssert = _samplesTillAssertReload;  // reset

Remember, this code runs every 20mS. It looks to see if the input changed from last time and makes the appropriate decision.

The actual encoder object is simple given that you have debounced data. Here’s the function PinDetect calls when the main input goes low:

void mRotaryEncoder::fall(void) {
 // debouncing does PinDetect for us
 //pinA still low?
 if (*m_pinA == 0) {
   if (*m_pinB == 1) {  // state of 2nd pin tells us CW or CCW
     m_position++;;  // notify user code
   } else {
     m_position--;;  // notify user code
   }; // call the isr for rotation; notify user code

Naturally, you might not provide all the callbacks, and that’s not a problem. The library has a similar piece of code for the rising edge, as well. You can find the entire library online if you want to browse it without creating a project.

Just to put this all in perspective, I joined the KY-040 encoder module with a KY-016 RGB LED. I selected pins on the Nucleo board, so the LED module will just plug in, but you’ll still need wires for the encoder. You can find the code on the mbed site, and the comments in the code describe the wiring.

The idea is simple. You can use the encoder to set the level of red the LED emits. Push on the shaft of the encoder, and you can control the green level. Another push sets the blue level. Subsequent pushes repeat the cycle. A simple program, but strangely entertaining to dial in strange colors (like pink or aqua). There’s a quick and dirty demo in the video, below.


I often say you don’t have to know how an engine works to drive a car. But the best drives do know. By the same token, it was easy enough to use this library to read the encoder, and if all you want is results, that’s the way to go. After all, all engineering boils down to abstractions. Maybe you understand assembly language. Maybe you can design a CPU at the logic gate level. Maybe even at the device level. But you probably aren’t growing your own silicon crystals, lapping a wafer, and building the device from there. Even then, you are relying on abstractions about how electrons flow and probably a few others.

However, it probably wouldn’t hurt if you had at least a feeling for how each one of those abstractions work. I don’t think letting students avoid understanding how a rotary encoder works is a good thing. Even if you choose to use a library to hide the details, it is good to understand what is really happening under the hood.

By the way, if you are running short on pins, you might be interested in this alternate method which is truly a hack. Meanwhile, I should probably take my own medicine and build my own encoders.

Filed under: ARM, Hackaday Columns, Microcontrollers, Original Art, rants, Skills

CES2017: Complete Register Documentation For The C.H.I.P.

Last October, Next Thing Co., makers of the popular C.H.I.P. platform unleashed the C.H.I.P. Pro, a very capable Linux system on a tiny board. The goal of the C.H.I.P. Pro is to be the brains of a project or product, similar to the Gumstix boards from an ancient era long before the Raspberry Pi.

Introduced alongside the C.H.I.P. Pro was a fantastic little device. The GR8 module is a complete Linux system on a chip, with an ARM Cortex-A8 processor and 256 MB of RAM, all on a relatively small BGA chip. This is a drop-in part that gives any piece of hardware a Linux brain.

There was a datasheet at the time the C.H.I.P. Pro and GR8 module were released, but a datasheet can only go so far. What you really need to use a Linux system on a module is a massive tome filled with descriptions of registers and all the hardware nooks and crannies needed to get the part working. At CES this week, Next Thing Co. brought what everyone has been asking for: an NDA-free complete register documentation for the core they’re using on the GR8 module. This is 400 pages of spiral-bound goodness that will tell you how to do everything with this chip.

The GR8 datasheet and register documentation A selection from the table of contents

Using the C.H.I.P. for products

When the C.H.I.P. was first released, it was easy to write it off as a board glomming on to the popularity of the Raspberry Pi. However, Next Thing Co. didn’t start with the C.H.I.P. – they started with Otto, an animated gif camera built around the Raspberry Pi compute module. The Otto was successful, but the compute module is a little expensive, so Next Thing Co. turned their attention to building a modern, inexpensive version of the old Gumstix boards.

The C.H.I.P. Pro and GR8 is the culmination of this work, and already a few companies have used it in production. At the Next Thing Co. suite, they showed off a new version of the Outernet base station powered by the C.H.I.P. Pro, and the TRNTBL, a wireless, Bluetooth, Airplay, and Spotify-connected turntable.

A new version of the Outernet base station will use the C.H.I.P. Pro Trntbl is a wireless turntable, powered by the C.H.I.P. Pro This is all you need to build Otto with the C.H.I.P. Pro The Otto camera, redesigned to use the C.H.I.P. Pro

To illustrate how easy using the C.H.I.P. Pro in a product is, the guys at Next Thing Co. removed the Pi-powered guts of an Otto and replaced it with a C.H.I.P. Pro. There wasn’t much inside – just a battery, camera module, and a few bits and bobs. That’s great for anyone who wants to build a product that needs a relatively fast chip running Linux, and the stuff from Next Thing Co. makes it easy.

Filed under: Microcontrollers

ESP-ing a Phillips Sound System.

IoT-ifying old stuff is cool. Or even new, offline stuff. It seems to be a trend. And it’s sexy. Yes, it is. Why are people doing this, you may ask: we say why not? Why shouldn’t a toaster be on the IoT? Or a drill press? Or a radio? Yes, a radio.

[Dr. Wummi] just added another device to the IoT, the Internet of Thongs as he calls it. It’s a Phillips MCM205 Micro Sound System radio. He wanted to automate his radio but his original idea of building a setup with an infrared LED to remotely control it failed. He blamed it to “some funky IR voodoo”.  So he decided to go for an ESP8266 based solution with a NodeMCU. ESP8266 IR remotes have been known to work before but maybe those were just not voodoo grade.

After opening the radio up, he quickly found that the actual AM/FM Radio was a separate module. The manufacturer was kind enough to leave the pins nicely labelled on the mainboard. Pins labelled SCL/SDA hinted that AM/FM module spoke I²C. He tapped in the protocol via Bus Pirate and it was clear that the radio had an EEPROM somewhere on the main PCB. A search revealed a 24C02 IC in the board, which is a 2K I²C EEPROM. So far so good but there were other functionalities left to control, like volume or CD playing. For that, he planned to tap into the front push button knob. The push button had different resistors and were wired in series so they generated different voltages at the main board radio ADC Pins. He tried to PWM with the NodeMCU to simulate this but it just didn’t work.

In a somewhat ironic turn of events, he realised that he could just tap into the IR receiver wire and simulate an IR code being sent, directly to the wire. No light interference, and no “funky IR voodoo” this time.

Some Lua lines later and the radio was upgraded with a GET API that allowed to:

  • Push all the buttons
  • Set an arbitrary FM frequency
  • Check if the radio is on or off

Let’s see it in action:

[Thanks gregor4005]

Filed under: Microcontrollers, wireless hacks

Hands On With The First Open Source Microcontroller

2016 was a great year for Open Hardware. The Open Source Hardware Association released their certification program, and late in the year, a few silicon wizards met in Mountain View to show off the latest happenings in the RISC-V instruction set architecture.

The RISC-V ISA is completely unlike any other computer architecture. Nearly every other chip you’ll find out there, from the 8051s in embedded controllers, 6502s found in millions of toys, to AVR, PIC, and whatever Intel is working on are closed-source designs. You cannot study these chips, you cannot manufacture these chips, and if you want to use one of these chips, your list of suppliers is dependent on who has a licensing agreement with who.

We’ve seen a lot of RISC-V stuff in recent months, from OnChip’s Open-V, and now the HiFive 1 from SiFive. The folks at SiFive offered to give me a look at the HiFive 1, so here it is, the first hands-on with the first Open Hardware microcontroller.


Before I dig into this, I must discuss the openness of the HiFive 1, and RISC-V in general. Free Software and Open Hardware is a religion, and it’s significantly more difficult to produce Open Hardware than Free Software. No matter how good or how Open the design is, the production of the first Open Source microcontroller will generate far too many comments from people who use the words ‘moral imperative’ while citing utilitarian examples of why Open and Libre is good. You should ignore these comments, but not just because these people have only read the back cover of the Cliff’s Notes for Philosophy For Dummies.

The Openness of the HiFive 1 and RISC-V

The biggest selling point for RISC-V chips is that there are no licensing fees, and this microcontroller is Open Source. This is huge — your AVRs, PICs, ARMs, and every other microcontroller on the planet is closed hardware. You can’t study the silicon. If we’re ever going to get a completely Open Source computer, it has to start somewhere, and here it is.

With that said, this is an Arduino-compatible board with an FTDI chip providing the USB to serial conversion. If we had a facepalm emoji, we’d use it here. An FTDI chip is not Open Source, and they have designed drivers to break chips that aren’t theirs. The design files for the HiFive 1 were made with Altium, a proprietary and non-Free software.

This was the best picture for this section of content.
This was the best picture for this section of content.

Will Stallman ever say the HiFive 1 is Free as in speech? Absolutely not. Instead, the HiFive 1 is an incrementally more Free microcontroller compared to a PIC, ARM, or AVR. There will be people who will argue – over the Internet, using late-model Intel processors with Management Engines — this is insufficient to be called Free and Open Source. To them, I will simply link to the Nirvana fallacy and ask them to point me to a microcontroller that is more Free and Open Source. Let’s not cut down the idea of an Open Source microcontroller because it’s not perfect on the first release.

Hardware Teardown

So, what’s in the HiFive 1? The spec sheet is simple enough, the datasheet is complete enough,  although there are some caveats:

  • Microcontroller: SiFive Freedom E310 (FE310)
    • CPU: SiFive E31 CPU
    • Architecture: 32-bit RV32IMAC
    • Speed: 320+ MHz (the stock frequency seems to be about 256 MHz, this can be changed)
    • Performance: 1.61 DMIPs/MHz
    • Memory: 16 KB Instruction Cache, 16 KB Data Scratchpad
    • Other Features: Hardware Multiply/Divide, Debug Module, Flexible Clock Generation with on-chip oscillators and PLLs
  • Operating Voltage: 3.3 V and 1.8 V
  • Input Voltage: 5 V USB or 7-12 VDC Jack
  • IO Voltages: Both 3.3 V or 5 V supported
  • Digital I/O Pins: 19
  • PWM Pins: 9
  • SPI Controllers/HW CS Pins: 1/3
  • External Interrupt Pins: 19
  • External Wakeup Pins: 1
  • Flash Memory: 128 Mbit Off-Chip (ISSI SPI Flash)
  • Host Interface (microUSB): Program, Debug, and Serial Communication

Basically, the HiFive 1 is the SiFive FE310 microcontroller packaged in an Arduino Uno form factor. The pin spacing is just as stupid as it’s always been, and there is support for a few Adafruit shields sitting around in the SDK.

There are no analog pins, but there are two more PWM pins compared to the standard Arduino chip. The Arduino Uno and Leonardo have 32 kilobytes of Flash, while the HiFive 1 has sixteen Megabytes of Flash on an external SOIC chip.

The HiFive 1 supports 3.3 and 5V I/O, thanks to three voltage level translators. The support for 5V logic is huge in my opinion — nearly every dev board manufacturer has already written off 5V I/O as a victim of technological progress. The HiFive doesn’t, even though the FE310 microcontroller is itself only 3.3V tolerant. It should be noted the addition of the voltage level translators add at least a dollar or two to the BOM, and double that to the final cost of the board. It’s a nice touch, but there’s room for cost cutting here.

Other than that, the only other chip of note on the board is the FTDI FT2232HL, a well-supported but most certainly not Free and Open Source USB to UART chip. This is a two-port chip that provides programming, serial, and debug connections simultaneously.

Getting Started With The HiFive 1

blinking-gifThe folks at SiFive realize documentation and SDKs are necessary to turn a chip into a development board. To that end, they have a bare-metal SDK and support for the Arduino IDE. The board itself comes with a bootloader, and when you plug the HiFive 1 into a USB you get the equivalent of the Blink sketch from the Arduino. Yes, you too can have Open Source blinkies. What a magical time to be alive.

Right now there are two methods of programming the HiFive 1. The Freedom E SDK, and the Arduino IDE. The Arduino IDE appears to be dependent on the Freedom E SDK, so either way, you’ll have to get the SDK running.

Right now, the SDK only works under Linux (and OS X, and possibly Cygwin), but support for Windows is coming. For Linux users, the getting started guide is more than sufficient, although it will take quite a while (at least 30 minutes) to build all the tools.

Once the Freedom E SDK is installed, support for the Arduino IDE pretty much falls into place. You’ll have to futz around with the Boards Manager, but with a few clicks, you get something fantastic. You can blink an LED with Open Source Hardware.


 Actually Programming the Thing

Blinking an LED is proof enough this can be programmed, but what about the vast SDK we had to install before getting the Arduino IDE working? Here, too, it’s pretty easy to get the SDK up and running:

1hellohackaday 2make-software 3hellohackaday

For this example, I simply changed the ‘hello world’ program shipped with the SDK to a ‘hello Hackaday’ program, compiled it, and ran it. Yes, someone as dumb as me can compile and upload a program to the HiFive 1.

This Stuff is Still New, Okay?

Before receiving the HiFive 1, I originally planned to benchmark this dev board against other small, common dev boards. The SDK comes with a Dhrystone program, making this the obvious choice. The results were not good, but this isn’t a reflection of the power of the FE310 microcontroller. Allow me to present the shocking infographic you should not pay attention to:

Ignore this infographic

This test used this Dhrystone Arduino sketch with the Arduino Micro, HiFive 1, and the Teensy 3.6. As you would expect the Arduino Micro performed poorly (but still ten times faster than a mainframe from 1988), and the Teensy 3.6 was extremely fast. According to this benchmark, the HiFive 1 did terribly at barely twice the computing power of the Arduino while running 16 times faster. If this benchmark was accurate, it would immediately spell the end of the RISC-V ISA.

The above benchmark is not accurate, and the poor Dhrystone performance was due to incorrect assumptions about the timer’s frequency. I plopped this problem up on the SiFive forums, and a patch was available in a few hours. What does the real benchmark say?

That’s a fast microcontroller. RISC architecture is gonna change everything.

love this test. Beginning this review, I originally planned to run a few benchmarks on an Arduino, a Teensy, and the HiFive 1, throw together a graph and spend a hundred or so words on the results.  I got so much more.

Right off the bat, we can see the HiFive 1 is fastReally, really fast. Right now, if you want to build a huge RGB LED display, you have one good option: the Teensy 3.6. If you need a microcontroller to pump a lot of data out, the Teensy has the power, the memory, and the libraries to do it easily. In this small but very demanding use case, the HiFive 1 might be better. The HiFive 1 has more Flash (although it’s an SPI Flash), it has DMA, and it has roughly twice the processing power as the Teensy 3.6. This could be very, very cool, and I can’t wait to see the real life examples of how much the HiFive 1 can push out of its pins.

There’s your hundred word review on the performance of the HiFive 1 based on synthetic benchmarks. However, getting this benchmark working revealed far more about the state of the HiFive’s software, and how much support SiFive is throwing at it.

Admittedly, I do have a very early version of this board, and the CrowdSupply campaign for the HiFive 1 was only funded last week. No one would expect one of the three demo apps shipped with a newly released board with a mature architecture to be completely broken (unless it’s an Allwinner chip, but whatever). Very few people would expect the devs to get a patch out in less than 24 hours in response to a random person on a support forum.

All of this circles back to a single observation on the HiFive 1: It’s new. The HiFive 1 and all RISC-V microcontrollers don’t have a vast market share, user base, or decades of work behind them. However, the SiFive team seems to be taking their work seriously. They’re fixing the problems they have, and they’re constantly pushing out new documentation. This is great, and a very good indication of how much support the RISC-V chips from SiFive will have.

Chips As A Service

I should note that the folks at SiFive aren’t in the business of building RISC-V Arduino boards. They’re in the business of making chips for people. This is custom silicon we’re talking about here.

The easiest parallel to draw is between SiFive and OSH Park. These companies don’t have their own manufacturing capability; the value is in connecting end users (engineers, startups) to manufacturers. OSH Park connects you to a board house that really knows purple, and SiFive connects you to a chip fab. In the case of the FE310, that’s TSMC.

For anyone who wants silicon you can study, this is great. No, it’s not as simple as sending a board off to a fab house, but it’s a start. The fact that SiFive chose to start with Open Hardware is great, and we can’t wait to see the other hardware made with their sweat and hydrofluoric acid.

It’s a Beginning

At the base level, the HiFive 1 is a powerful microcontroller with a lot of Flash, with support for hundreds of Arduino libraries. That’s great, and alone this might be worth the $60 price of admission.

However, the big story here is the Openness of the HiFive 1. Is it completely open? No. the HiFive 1 itself uses an FTDI chip, and I’ve heard rumor and hearsay the FE310 chip has proprietary bits that are ultimately inconsequential to the function of the chip. A strict interpretation of Open Hardware will not allow this board to be called Open Hardware. Those who advance this interpretation are dumb, and to counter this argument I will quote the man himself:

…We need to distinguish levels in the design of a digital product (and maybe some other kinds of products). The circuit that connects the chips is one level; each chip’s design is another level. In an FPGA, the interconnection of primitive cells is one level, while the primitive cells themselves are another level. In the ideal future we will want the design to be free at all levels. Under present circumstances, just making one level free is a significant advance.

– Richard M. Stallman, Free Hardware And Free Hardware Designs

A design that fails to be completely Open does not deserve to be grouped with designs that are explicitly closed.

Nevertheless, this is the best we have so far, and it is only the beginning. We’re going to have more microcontrollers that are more Open, but until then, the HiFive 1 is actually a pretty cool board.

Filed under: Microcontrollers, reviews

A Singing Arc Lighter

We’ve all been guilty of buying things we want, but don’t need. And that’s how [PodeCoet] found himself in possession of a couple of double-arc electric lighters, thanks to those far-eastern websites purveying cheap goods. ‘Tis the season of giving after all, justified [PodeCoet]. Being a hacker, the obvious thing to do was to make them belt out tinny tunes. If you’re still holding on to your gas lighters, don’t — because these electric ones are ‘oh so hackable’. Dual-arcs are the same, but twice the fun.

[PodeCoet] starts off with a tear down of the lighter, to figure out the schematic and understand how it works. There’s a charger IC for the LiPo, an unidentifiable micro-controller, a pair of FET’s driving a pair of power transistors, which in turn drive the HF output transformer at around 15.6kHz. He guesses that the “original micro-controller is probably an OTP part like a 12C508” but in the absence of a chipID he couldn’t be sure.

Instead of trying to break his head over it, he just swapped in a pin-compatible PIC12F1840. All that’s left to do is to write some quick-n-dirty code and sprinkle it with funny comments in order to modulate the output signal at audio frequencies. His first choice of tune was “We are Number One” by Lazy Town, the Icelandic educational musical comedy children’s television series (phew). But redditors are awesome, and someone asked him to add the “Imperial March” and [PodeCoet] obliged.

Since he was going to gift these lighters, the sneaky hacker added a prank in the code. Every time the button is pressed for more than two seconds, it works as normally expected and a counter is incremented. On the 20th count, and for one time only, the tune is played. No amount of pressing the button will play the tune again, confounding the user to wonder if he was hallucinating. This also helps ensure the lighter does not self-destruct prematurely, since the output transformer is likely designed for low duty cycles. His blog post contains all of the information needed to do this hack along with handy tips to avoid the problems he faced. A “Happy Birthday” tune would be great when lighting some birthday candles, we think.

[PodeCoet] has a fancy for high voltage stuff – check out “Home built Stun Baton turns you into a cop from Demolition Man“. This man surely loves his pranks, as evidenced by “Hacking your Co-Workers Label Makers“. And the farce is strong in this one — “Student trolls anti-Arduino Prof with parasite MCU“.

Thanks to [ryg] for tipping us about the reddit thread.

Filed under: hardware, Microcontrollers

Retrocomputing for $4 with a Z80

Sure, you’d like to get in on all the retrocomputing action you read about on Hackaday. But that takes a lot of money to buy vintage hardware, right? Sure, you can build your own, but who has time for a big major project? [Just4Fun] has a project that disproves those two myths and gives you no more excuses. His retrocomputer? A 4MHz Z80 that can run BASIC with 64K of RAM, all built on a breadboard with 4 ICs. The cost? About $4.

Of course, that’s with some power shopping on eBay and assuming you have the usual stuff like breadboards, wire, small components, and a power supply. While it will gall the anti-Arduino crowd, [Just4Fun] uses an Arduino (well, an ATmega32A with the Arduino bootloader) to stand in for a host of Z80 peripheral devices. You can see a video of the device below, and there are more on the project page.

The ATMega serves as a clock and reset generator. It also is the computer’s EPROM. There is a separate RAM chip, but half of it isn’t used (we smell a bank switching mod here). You do need the CMOS Z80 chip to play nice with the other modern chips like the ATMega.

This is a great retro project. We can’t help but notice the IC pin labels on the chips which is a nice touch, along with the labels on switches and LEDs.

[Just4Fun] has done this kind of thing more than once. If you are wondering how many chips the ATmega saves, you might have a look at this build.

Filed under: Microcontrollers

8008 Exposed

[Ken Shirriff] is no stranger to Hackaday. His latest blog post is just the kind of thing we expect from him: a tear down of the venerable 8008 CPU. We suspect [Ken’s] earlier post on early CPUs pointed out the lack of a good 8008 die photo. Of course, he wasn’t satisfied to just snap the picture. He also does an analysis of the different constructs on the die.

Ever wonder why the 8008 ALU is laid out in a triangle shape? In all fairness, you probably haven’t, but you might after you look at the photomicrograph of the die. [Ken] explains why.

He also explains a bit about how PMOS works and the history of the design, including why it was in the odd 18-pin package. At the end, he talks about how he decapsulated the part and got the pictures, in case you ever want to try that yourself.

As a personal aside, I used to do this at Motorola and I think [Ken] was wise to stick to the ceramic packages since you can mechanically decapsulate them. With an epoxy part, you can use a Dremel or similar tool to mill out some epoxy (just don’t go too deep), put the chip on a  hot plate (a copper bar helps carry the heat up to the package), and then fill the milled cavity with fuming nitric acid. But you shouldn’t be doing that without a lot of protective equipment including vent hoods, safety showers, and experience storing, handling, and disposing of nasty acids. I have a feeling [Ken] could pull it off, but it isn’t something you just want to try on a whim.

[Ken] has done this kind of thing before. If you are wondering what kind of computer you could build with such a tiny device, we just saw one the other day. Of course you already saw [Ken’s] talk about his process at this year’s SuperCon, right?

Filed under: Microcontrollers

Sorting Resistors with 3D Printing and a PIC

If you aren’t old enough to remember programming FORTRAN on punched cards, you might be surprised that while a standard card had 80 characters, FORTRAN programs only used 72 characters per card. The reason for this was simple: keypunches could automatically put a sequence number in the last 8 characters. Why do you care? If you drop your box of cards walking across the quad, you can use a machine to sort on those last 8 characters and put the deck back in the right order.

These days, that’s not a real problem. However, we have spilled one of those little parts boxes — you know the ones with the little trays. We aren’t likely to separate out the resistors again. Instead, we’ll just treasure hunt for the value we want when we need one.

[Brian Gross], [Nathan Lambert], and [Alex Parkhurst] are a bit more industrious. For their final project in [Bruce Land’s] class at Cornell, they built a 3D-printed resistor sorting machine. A PIC processor feeds a resistor from a hopper, measures it, and places it in the correct bin, based on its value. Who doesn’t want that? You can see a video demonstration, below.

At first, it appears the device uses a rotary encoder as an input device. However, it isn’t an encoder. It is a 10-turn potentiometer. This is simple to read but causes some unique processing. For navigating the LCD, for example, the PIC looks at the rate of change of the pot value. However, if it sees the pot go to the end of travel, it moves the navigation fully in that direction.

We thought it would be cool to marry this with an OpenCV resistor reader to also identify out of spec or mismarked resistors. There’s actually a few phone apps that can do that with varying degrees of success.

Thanks to [Bruce] for the tip, and for launching so many young engineers.

Filed under: 3d Printer hacks, Microcontrollers, tool hacks