%#@&$! Raspberry Pi! I’ve been a Raspberry Pi hater since they first appeared on the electronics hacking scene a few years ago. I had no strong reason for disliking the Pi, but something about it just bugged me. It was too cute and trendy. It felt like a new kid forcing its way into the clubhouse of ATMegas and PICs and Propellers, trampling everything with well-meaning but misplaced enthusiasm. The media portrayal of the Pi bugged me too. It was constantly compared with the Arduino, but the Pi isn’t even really the same class of device. It’s a full-on desktop computer, with a Linux operating system, USB mouse and keyboard, ethernet, and HDMI video. I thought it would make as much sense to write articles comparing Arduino to the MacBook Air.
Part of my dislike for the Raspberry Pi was also a grumpy old man conviction that it was just too easy. “Back in my day,” I’d say, “we didn’t have your fancy operating systems and scripting languages and network adapters. If we wanted to code on an embedded microcontroller, we had to use bootloaders and cross-compilers and bit shifters and registers named UCSR1A. Now get off my lawn!”
You can probably guess where this is going: I finally gave in to the march of progress, and built some experiments with a Raspberry Pi. And despite my initial reticence, I have to say that Raspberry Pi tastes pretty good!
A First Taste of Raspberry Pi
My first Pi project was an electronic symphony orchestra, derived from an article in Make Magazine. I connected a few external pushbuttons on a breadboard, and wrote a Pi program to play various instrument sounds when the buttons are pushed. I also created an on-screen GUI showing what instruments are currently playing, and you can click on an instrument’s picture to make it play through the UI. Pretty neat! Maybe it could evolve into some kind of Pi-based jam box.
So how is Raspberry Pi development similar to working with a PIC or ATMega (or the ATMega-based Arduino), and how is it different? What kinds of projects are best suited to each platform?
Both the Pi and the Arduino are self-contained computing boards, about the size of a deck of playing cards, with a price around $30. Both have a bunch of general-purpose I/O pins that can be connected to external buttons, LEDs, sensors, LCD screens, motors, etc. Manipulating those I/O pins from software is easy on either platform:
GPIO.setup(10, GPIO.OUT) # configure pin 10 as an output
GPIO.output(10, True) # LED on
GPIO.output(10, False) # LED off
Arduino LED blinking, in C
pinMode(10, OUTPUT); // configure pin 10 as an output
digitalWrite(10, HIGH); // LED on
digitalWrite(10, LOW); // LED off
Looks similar enough, although the preferred programming language for Raspberry Pi development is Python, rather than C. It’s certainly possible to write Pi programs in C, but you’ll be swimming against the current, as virtually every common Pi library and example project is Python based.
While these code snippets appear similar, look beyond the LED blink example and you’ll discover that developing for the Raspberry Pi is a completely different experience from the Arduino. With the Arduino, you write your program using an editor that runs on a Mac or PC. Then you push a button, and your code is sent over a cable to the connected Arduino, where it runs. Contrast this with the Raspberry Pi, where you can write your program using a graphical editor running on the Pi itself, in a full-blown Linux operating system. You can hook the Pi to an HDMI monitor, or view its virtual display using remote desktop software.
The significance of having a tiny but full-featured computer may not be clear from an LED example, but how about playing a sound when a button is pushed?
GPIO.setup(10, IN) # configure pin 10 as an input
trumpet = pygame.mixer.Sound("trumpet.wav") # load the sound file
if GPIO.input(10) == True: # is the button pressed?
trumpet.play() # you're Louis Armstrong!
Arduino Sound Trigger
// buy a wave shield?
How about logging an 8-bit digital sensor value to a web server every 60 seconds?
for i in range(8):
GPIO.setup(10+i, IN) # configure pins 10-17 as an inputs
sensor = 0
for i in range(8): # build a byte from the 8 input bits
sensor = sensor * 2
if GPIO.input(10+i) == True:
sensor += 1
url = "http://api.mylogserver.com/logdata.php&value=" + str(sensor) # log it using HTTP GET
response = urllib.urlopen(url).read()
Arduino Sensor to Web Logger
How about any kind of physical computing project that can benefit from easy access to sound, video, USB, a file system, or internet? Send a tweet when your toast is ready. Stream data from an SD memory card to a GPS chip. Use a mouse to control a robot. All these things could probably be done with a traditional microcontroller like an Arduino too, but would need extra hardware and complicated software. The Raspberry Pi makes this kind of work easy – almost too easy. And I didn’t even mention the huge advantage in RAM space and CPU speed that it has over traditional microcontrollers. It’s not hard to see why the Raspberry Pi has become so popular. Yes the Pi is overkill for many simple projects, but if it’s no bigger nor more expensive than the alternative, why not?
Arduino – It’s Not Dead Yet
For all the advantages of the Pi, there are still some situations where a good old Arduino or bare ATmega or PIC makes more sense. If your project has time-critical behaviors or requires specialized low-level hardware functions then you’re probably better off with an Arduino. An Arduino program is the only thing running on that hardware, so you can rely on fast, deterministic timing of I/O events. If you need to set pin 10 high exactly 20 microseconds after pin 9 goes low, you can do it on the Arduino, but the vagaries of the Pi OS’s task scheduling prevents this kind of precision. Likewise if you want something like super-fast pin change interrupts, a hardware watchdog, or advanced use of serial protocols like I2C, the Pi isn’t the best choice.
If you need a device that’s “instant on”, then you’ll be disappointed with the Raspberry Pi. An Arduino based project can be up and running within milliseconds after the power is turned on, but my Pi takes about 40 seconds to boot. Then it dumps me to a login prompt, and finally I have to run my program manually from the command line. You can edit a config file to skip the login and auto-start a specific program after boot-up, but it’s a little cumbersome and you’ll still be waiting 40 seconds.
Need analog inputs? Too bad, because the Pi doesn’t have any. You can use external solutions like this 8-way A-to-D converter with SPI interface, but reading an analog sensor is definitely more hassle on a Raspberry Pi than an Arduino.
What about battery-based projects? In sleep mode, the power consumption of an ATmega microcontroller can be tiny – in the microamps range. My Backwoods Logger ran off a single 3 volt coin cell battery for two years! In comparison, the Raspberry Pi is a huge power hog.
If these issues are important for your project, then stick with a traditional microcontroller. But if not, give the Raspberry Pi a try. I think you’ll be as surprised how easy it is to build something exciting!
Now it’s your turn. What kind of microcontroller do you use for your projects? What are the Raspberry Pi’s biggest strengths and weaknesses? What does the future hold for embedded computing boards like these?Read 4 comments and join the conversation
Sometimes a Floppy Emu board fails one of my functional tests, and I can’t find the cause of the problem. I have several boards that appear to work fine for 400K and 800K disk emulation (tested on a Mac Plus and Mac 512K), but that don’t work reliably for 1.4MB disk emulation on newer Macs. Instead of throwing these in the trash, I’ve decided to sell the “scratch and dent” boards for $15.
If you’ve got a Mac 512K, Plus, or older Mac SE that only supports 400K and 800K disks, one of these boards might work well for you. Because the boards failed some of the functional tests, there’s definitely a problem with them, so keep that in mind when deciding between these and the regular Floppy Emu boards. Scratch and dent boards are warranted for 400K and 800K operation for 30 days. The 1.4MB emulation on these boards isn’t guaranteed to work, but maybe you’ll get lucky.
These Floppy Emu boards have a built-in connector, and are physically identical to those that normally sell for $89.
Update: The scratch and dent boards have all been sold. Thanks for the interest!
Nobody ever said selling Floppy Emus to the public would be easy, but for an operation that’s barely one step above an eBay garage sale, the amount of legal hoops I’ve had to jump through is ridiculous. How did it get this bad? I’ve had self-employment income in previous years, from consulting projects and ads on my web sites, and I simply listed it on schedule C of my state and federal tax returns. Now Floppy Emu sales have ensnared me in some kind of endless bureaucracy of forms and licensing and taxing. Ugh.
It all started when I found a local company to assemble Floppy Emu boards, because I was tired of hand-assembling them myself. The owner advised me that unless I had a California seller’s permit, he would have to charge me 9% sales tax on the assembled boards. Since this was a fairly large order and 9% was a non-trivial amount of money, I did some research and obtained a seller’s permit for Big Mess o’ Wires. Hooray, unnecessary tax avoided! Unfortunately this meant I was now obligated to collect sales tax from California residents when they buy a Floppy Emu, and file a special sales tax return with the state. Ugh. Maybe that wouldn’t have been too bad, if it had been the end of it.
Unfortunately, getting a California seller’s permit seemed to be the trigger for every other state and local agency to hit me up for something. I received a letter from some company called Muni Services informing me that I lacked a business license for the city where I live. I was invited to apply for a license, but there was no mention of the cost, and the application form was entirely geared towards traditional businesses with an office and a retail storefront. I managed to reach somebody at Muni Services who was entirely unhelpful, telling me I should just leave any non-applicable sections of the form blank. In my case, that was pretty much the whole form, except my name and contact info. I sighed, completed the form, and mailed it in.
Some weeks later I received a cryptic bill for $496, which included the business license fee as well as an unexplained penalty. Oddly, the bill wasn’t even from the city, but from this mysterious Muni Services. I was suspicious of some type of scam, but from everything I could tell the city had legitimately contracted Muni Services to handle their business license compliance. So I sighed again and sent them a check for $496, hoping that would be the end of it.
After another interval of a few weeks, I received a phone call from somebody at the city, saying that I needed to go through the “zoning compliance process”. This requires me being at city hall on a weekday between 2:00 and 3:30 PM. Apparently there was some problem with my business license application, because the address provided is not zoned for businesses. No surprise there, it’s my home address! So I have to find a time to visit city hall in the middle of the afternoon on a weekday, and submit some kind of home-based business affidavit. After which it will hopefully be the end of my troubles, but I’m not optimistic.
This whole process makes sense and would be reasonable if I were opening a grocery store or a tire center. But for a part-time hobby that only earns a few hundred dollars a month, these hassles tip the scales to where it’s questionable whether it’s worth it at all.Read 7 comments and join the conversation
It’s been quiet here in electronics hobby land, but I do have some good news to report: as of now, all Floppy Emu boards are professionally assembled by Microsystems Development Technologies in California, USA. No more hand assembly! It’s a glorious thing to receive a big box stuffed with assembled boards, and as good as a kid opening a package on Christmas Day. Microsystems wasn’t the cheapest option I found, but they weren’t too far off. I was convinced to go with them thanks to their quick and helpful answers to my many questions, and by their nearby location in San Jose. That’s a short drive from where I live, so when the boards were finished I was able to drive down there and meet the owner in person, and discuss potential changes for future board revisions. That alone was worth the cost difference versus slightly cheaper Asian alternatives.
Microsystems took my design files and bill of materials, and handled everything from there. They made the PCBs, purchased the parts, assembled everything, programmed the chips, and ran the board self-test. That’s a huge time savings for me, and it also removed a major source of potential faults because they handled all the tricky surface-mount work.
Unfortunately, the “finished” boards from Microsystems still aren’t quite ready to sell. It takes another 15-20 minutes of labor per board for me to attach a DB-19 connector (or build a DB-19 extension cable, depending on the type of board), assemble an LCD module, adjust the LCD contrast, and run the board through real-world file copy tests on a couple of vintage Macs. I thought Microsystems wouldn’t be able to handle those steps very easily, so I asked them to skip it. After more discussion, though, it looks like they can do everything except the file copy tests without much trouble. It’ll cost me a few extra dollars, but if it saves me time and headache, it’s probably worth it.
One bummer is that I’m still seeing a few boards that consistently fail my file copy tests, and can’t be sold. This happened sometimes with the old hand-assembled boards, and I never did find the cause, but I suspected it was related to my lousy hand-soldering job. But since it’s still happening with the professionally assembled boards, it’s probably some kind of design flaw. Ugh. For the time being I’m just setting these boards aside in the reject bin, but eventually when I’m sufficiently motivated I’ll see if I can figure out what’s wrong.
TL;DNR – While it doesn’t solve every problem, having professionals source the parts and assemble the boards is very nearly the best thing since sliced bread. I’m happy to give my soldering iron a well-deserved rest.Read 6 comments and join the conversation
I’m something of an anti-backlight guy, and I intentionally designed Floppy Emu with the LCD screen’s backlight disabled. Without the backlight, the text is crisp and the contrast is excellent. With the backlight, the text looks more washed out, and imperfections in the LCD glass become visible. Nevertheless, some people really want a backlight, so this post will show you how to hack your Floppy Emu to turn the backlight on.
The LCD already has four backlight LEDs built-in to the edges of the display, and all you need to do to enable them is solder a resistor or a piece of wire to the right pins. The procedure is slightly different, depending on which version of the LCD you have.
For Floppy Emus with serial numbers 51 and higher, connect the holes labeled LIGHT and GND at the top-right of the LCD with a low-value resistor, or a plain piece of wire. If you use a resistor, I recommend something in the range of 10 to 50 Ohms (lower values will give a brighter light). Because the LIGHT and GND pins are so close together, you’ll probably need to orient the resistor vertically, as shown in the photo. For the brightest backlight, use a plain piece of wire instead of a resistor. This won’t damage the LCD, because it already has a small backlight resistor built-in.
For Floppy Emus with serial numbers 1-50, the LCD design is slightly different. Connect a resistor between the pins labeled LED and VCC at the top of the board. You’ll probably find that there’s already a cut-off pin at those two spots, so you can solder your resistor to those pins. I recommend a resistor in the range of 47 to 100 Ohms. Don’t use plain wire here – these LCDs do not have any built-in resistors, and using them without any resistance may damage the LCD.
Some of the LCDs have a white backlight, and some have blue. It’s a surprise!Be the first to comment!
There’s a big difference between building one of something, and building a hundred. When building one, the challenge is simply to get the thing working at all. When building a hundred, the focus changes to issues like how fast you can do the build, and how reliably. Little problems that only crop up rarely start to become headaches. And if you’re like me, you start to get obsessed with achieving 100% reliability without sacrificing build speed or cost.
With Floppy Emu now past the 100 units mark, I can start to get some meaningful data from the assembly process. Thus far slightly more than 90% of the units I’ve built passed all my tests, and were able to be sold. Even for a hand-built piece of hardware, that’s not great. Getting closer to 100% yield will require troubleshooting what went wrong, and making sure it doesn’t happen again, but that’s easier said than done.
Releasing the Magic Smoke
The most common failure I’ve seen is something I call “burnout”, and has affected about 4% of the units. After anywhere from one minute to a few hours of working normally, the Floppy Emu stops functioning, and both the 3.3V regulator and the CPLD become hot to the touch. The AVR, SD card, and LCD still seem to operate normally, but floppy emulation or anything else involving the CPLD no longer work. After some experimentation, I discovered that if the CPLD is removed and replaced using a hot air gun, the Floppy Emu can be returned to normal functioning and the problem does not reappear.
Hot chips imply a short circuit somewhere. Measuring the current draw is tricky, because Floppy Emu is normally connected directly to the Macintosh which powers it, and there’s no place to insert an ammeter inline and measure the current. I finally broke down and built a simple bench test rig, where the Floppy Emu is powered from an external power supply and no Macintosh is involved. This only provides a way to measure the current draw of the whole board, and not individual chips, but it’s better than nothing.
What I found is that a normal board idling on the main menu screen draws about 124 mA. Removing the CPLD with the hot air gun lowers this to 41 mA, implying that the CPLD and the incremental 3.3V regulator current are about 83 mA combined. That’s a bit more than the CPLD datasheet says is typical, but the actual supply current depends on how the CPLD is configured, so it’s within the realm of possibility. The CPLD current likely increases when the device is active and floppy emulation is happening, but I don’t have any way to measure that with the existing bench test rig.
Next, I measured a Floppy Emu in “half burnout” condition. This one actually functioned OK, but after several minutes it would grow pretty hot and stop working. Unlike the other burnout Emus I’ve had, this one would start working again if it were left to cool off for a minute. With my test rig, I measured this board’s idle current draw at 400 mA, more than three times higher than the normal board. Removing the CPLD dropped the current down to 41 mA again, so it seemed clear the trouble was related to the CPLD and not somewhere else.
So what’s going on with this burnout? It looks like something’s causing the CPLD to draw high amounts of current from the 3.3V regulator, resulting in high power dissipation and overheating in both chips. The regulator has an internal safety switch that will protect it from damage, but the CPLD apparently gets toasted. That makes sense, but what causes the high current draw in the first place? Like a good mystery detective, I came up with a few theories, which I think cover all the possibilities:
- The chip was defective. That’s possible, but blaming faulty chips should always be a last resort. In all the electronics projects I’ve ever built, only once have I ever encountered a problem that was conclusively linked to a faulty part.
- The PCB was faulty, and two closely-spaced CPLD traces were shorted together somewhere. The fact that replacing the CPLD fixed the problem seems to rule out this theory.
- A software error in the AVR program or the CPLD config caused two chips to simultaneously drive the same signal to different values. This seems unlikely, as almost all of the signals are unidirectional, and the only bidirectional signals are controlled by a simple mechanism that would be hard to go wrong. A software error should also affect all the hardware, not just a few units, unless it’s some rare timing-based error that only appears in very specific circumstances.
- The chip was damaged during assembly, due to static electricity or high heat. Possible, but I’ve never encountered a damaged AVR, and it’s the exact same package and pin count as the CPLD, and I handle it exactly the same way during assembly. Maybe the CPLD is more sensitive to mishandling somehow? Seems doubtful.
- I accidentally shorted two CPLD pins together with a poor soldering job. I carefully checked all the pins with a 10x magnifier, and couldn’t find any shorts. Still, this seems like the most plausible explanation.
- The “5V tolerant” chip isn’t very tolerant, and continuous 5V inputs eventually lead to damage. The datasheet seems clear this shouldn’t be true. Recommended operating conditions for a high input voltage are between 2.0 and 5.5 volts.
- “Bad” voltages from the Macintosh damage the CPLD, because it’s the only chip that’s directly connected to the Mac. I can’t rule this out, but it seems unlikely. It’s definitely possible for a vintage Mac’s 5V supply to be out of adjustment, but the CPLD is a 3.3V chip and doesn’t use the 5V directly. The Macintosh signal voltages could be out of whack, but I think that would also cause problems for the Mac itself.
- The Floppy Emu circuit design pushes the CPLD beyond its maximum ratings, causing damage. Maybe there’s some significant voltage overshoot or undershoot somewhere that can cause damage, or a big transient that happens at power-on. Possible, but without a specific culprit to investigate it’s hard to say.
Of these, the most likely explanations are the poor soldering job and the chip damage caused by a design that exceeds maximum ratings. Replacing the CPLD with a new one would fix both problems, since it replaces both the soldering job and the chip itself at the same time. To separate these theories, I took the “half burnout” board, removed the CPLD with the hot air gun, then resoldered the same CPLD. It still failed the same way, and drew exactly the same amount of current, demonstrating that the problem lay with the chip itself and not the soldering.
So I’ve got a few damaged CPLDs. Maybe they came defective from the factory (theory 1), maybe I damaged them during assembly (theory 4), or maybe a rare software bug causes damage (theory 3). Maybe an evil Mac is frying them with 12V logic signals (theory 7). But I’m betting on theory 8, and it’s somehow my own fault for a design that zaps the CPLD with occasional voltage overshoots, power-up transients, or other circuit gremlins that lead to failures in a small fraction of the CPLD chips.
Unfortunately there’s not a lot I can do to test this theory with the current hardware. I can only measure the current drawn by the whole board, not a single chip, and I can’t do any measurements while the board is connected to a Mac. Even if I could, an instantaneous surge in current would be met by the CPLD’s decoupling caps more than the power supply, so it might not even show up in any measurements I did. As for checking individual signals for overshoots or weird transients, it’s just not practical. The CPLD is a surface mount chip with tiny 0.5 mm pin spacing, so there’s no way to connect an oscilloscope or other probe. For now, then, there’s probably nothing to do but keep testing, and try to look for patterns in the timing and nature of future failures that might point to a more specific cause.
Read 40 comments and join the conversation