obligatory obscure reference

self-deprecating yet still self-promotional witty comment


Blocking the mount of a UF2 Bootloader in OSX (and maybe Linux)

Filed under: Arduino,Hacking — jet @ 00:04

I’m really liking Adafruits “Metro Express” version of the Arduino Zero.

Except for one thing.

The UF2 boot loader.  Every time I compile and load a sketch I get a whine notification from OSX about how I’ve unmounted a volume without the proper Steve Jobs NeXT dance.

The fix is actually pretty simple — tell fstab to stop mounting the filesystem in the first place.  Apple has one solution but it needs a few tweaks for the UF2 boot system.

I'll use Adafruit's METRO as an example.  

First, use diskutil to find the UUID of the METRO:

$ diskutil info /Volumes/METROBOOT/
 Device Identifier: disk3
 Device Node: /dev/disk3
 Whole: Yes
 Part of Whole: disk3
 Device / Media Name: Metro M0 Media

Volume Name: METROBOOT

Mounted: Yes
 Mount Point: /Volumes/METROBOOT

File System Personality: MS-DOS FAT16
 Type (Bundle): msdos
 Name (User Visible): MS-DOS (FAT16)

Content (IOContent): None
 OS Can Be Installed: No
 Media Type: Generic
 Protocol: USB
 SMART Status: Not Supported
 Volume UUID: CA043DAF-C1C3-33CC-A5C4-A4B0D2BFDE85

Total Size: 4.1 MB (4096000 Bytes) (exactly 8000 512-Byte-Units)
 Volume Free Space: 3.5 MB (3530240 Bytes) (exactly 6895 512-Byte-Units)
 Device Block Size: 512 Bytes
 Allocation Block Size: 512 Bytes

Read-Only Media: No
 Read-Only Volume: No

Device Location: External
 Removable Media: Yes
 Media Removal: Software-Activated

Virtual: No
 OS 9 Drivers: No
 Low Level Format: Not supported

Now, use vifs to change the fstab file:

$ sudo vifs

and add this line to the end of the file using the “Volume UUID” field to replace [Volume UUID]

UUID=[Volume UUID] none msdos ro,noauto

save and quit, then run

$ sudo automount -vc

to update your mac with the new fstab file.

This should stop the device from automounting under OSX and make the METRO work like a “normal” Arduino.



Engineering Lesson 101

Filed under: Arduino,Hacking,MakerBot,Rants — jet @ 09:46

I think it’s been 10, maybe 15 years since I’ve actually worked on open source software as an author. I’ve helped fix bugs in things like Arduino and ReplicatorG, but I haven’t done anything major on my own.

Until Friday, when my frustration with a certain class of software got the perspective and skill of my being a professional engineer. Instead of complaining, instead of getting frustrated with how someone else managers their project, instead of not being able to pull rank and make them do it my way, I can just go write my own and hand it out.

It’s a nice feeling. I don’t think I’d have gotten here without writing it-cannot-fail code for security and privacy projects as a day job. That sort of rigor is like daily exercise for the brain, like daily exercise or workouts only for the brain.


new list for open source fabrication

Filed under: Arduino,Hacking,MakerBot,Metalworking — jet @ 08:15

I’ve been using open source software at work since the late 80s and have spent the past couple of years experimenting with Arduino, Reprap, Makerbot, and I’m getting involved with early lasersaur development.

It’s my strong opinion that over the next year open source hardware will really start making an impact in the local and small-scale fabrication space. While there are plenty of shops using EMC2 in large-scale fabrication, the learning curve is steep and EMC2 is focused on subtractive machining operations. There are no fundamental patents on things like mills or lathes to deal with, but a lot of the control circuits and interfaces used are proprietary or at least closed source.

With lasersaur using grbl, Makerbot using (and supporting) ReplicatorG, and the increase of quality tools like Inkscape and OpenSCAD I think we’re finally seeing small-scale manufacturing with a toolchain almost entirely made of open source hardware and software. (I’m not going to wade into the argument about whether or not it’s “real” open source if you’re still buying steppers or power supplies or other COTS items. :-)

In order to help move this process along, I’ve created a new mailing list, opensourcefab, and am working on a wiki/web forum as well.

My goal for this list (and for the forum that will soon go online) is to create a space for those of us who want to use these tools for serious fabrication. Maybe you make/sell model railroad components or build big skeery robots or work at an in-house shop making spares but we’re all interested in the same thing — using open source tools in a production environment.



cupcake + gen4 + mk6 progress

Filed under: Arduino,MakerBot — jet @ 22:08

Turns out my boards were dead, MakerBot RMA’d them and the new ones seem to be working just fine for manual controls and temp settings. Will do some test runs, get some end-stops made, and post a how to in the next week or so.


The magic of the 74LS259

Filed under: Arduino — jet @ 20:10

In the previous note I made a pitch for learning Boolean logic so you can solve problems with chips instead of code and suggested browsing parts catalogs to find things you’d never look for.

Now, a demo of a chip I discovered by accident that solves a kerbillion problems I’ve had in the past, the 74LS259. There’s two types of chip you need to know about to understand what makes the 74LS259 great for Arduino projects.

The multiplexer

Multiplexers are pretty common, and if you’ve spent a fair amount of time doing Arduino projects, you’ve probably seen them in demos, if not used them yourself. They are handy for things like routing signals to/from your Arduino when you don’t have enough pins for everything you want to connect to your Arduino. (There’s a short tutorial on the Arduino site that you should go read if you’re unfamiliar with how to use a multiplexer. Read the code, look at the diagram, it’ll make sense.) On the one hand it’s very convenient being able to use 4 pins to drive 8 outputs, however they are real time and don’t have any concept of state or memory. If I have 8 LEDs on a multiplexer, and I want to turn the first one on and off, the others will all go off. Then when I go to turn a different one one on and off, the first one goes off. (There’s a ton of tricks to deal with this, most of them involve some form of persistence of vision.)

The latch

The second component to know about is the “latch”. (Say it in the Monty Python narrator voice for extra fun.) If you didn’t study EE/CS at the college level, odds are you’ve never heard of a latch. I spent 1.5 semesters doing digital logic and I’d pretty much forgotten about latches other than to remember what a pain they were to use in a circuit. The latch is one of those core functions of computers that we tend to forget about because there’s not really a software version that we use while writing code the way we use OR, AND, NOT, and so on.   

Simply put, a latch is a way to store 1 bit of data, and that bit’s value is either “on” or “off”. You have an input wire, an output wire, and some sort of “control” wire that lets you change the value stored in the latch. You enable the latch and capture the value on the input wire, then disable the latch and the output wire will continue to have the same value as the input wire did, even if the input wire changes value. Latches can be combined with many other chips to create memory to store bytes of data, move it around on buses, and do all sorts of things that modern computers are based on.

The 74LS259

I’d kinda forgotten about latches until I was killing time flipping through a databook and stumbled upon the 74LS259:

“The SN74LS259 is a high-speed 8-Bit Addressable Latch designed for general purpose storage applications in digital systems. It is a multifunctional device capable of storing single line data in eight addressable latches, and also a 1-of-8 decoder and demultiplexer with active HIGH outputs.[…]”

See the connection? It’s a multiplexer with a latch on every output. To put it another way, it’s a multiplexer with memory. If you want to run 8 outputs and be able to turn them on and off independently, this is the chip you’ve been looking for. Granted, it takes 5 pins to run the LS259: 3 to generate the address, 1 to generate the on/off signal, and one to enable/disable the latch, but you gain the ability to turn things on and off and have them stay the way you left them. Another thing in the LS259’s favor is that it works just like a multiplexer, so there’s nothing new to learn and it will work with your old code with only a slight modification. You use three pins to select the address of the output pin, set your signal pin high or low, then enable and disable the latch with a fifth pin. After you toggle the latch, you can move on and set the value in the next pin.

It’s just this easy: LS259.pde


Arduino, Boolean logic, and the magic of “vintage” logic chips

Filed under: Arduino — jet @ 20:09

Two things this time around. The first is advocacy for learning Boolean logic, the second is an example of how to use a somewhat obscure chip to solve a common problem found in Arduino projects.

First off, the advocacy.

If you don’t know it already, spend some time over the next few evenings learning the basics of Boolean logic. I’m not talking about binary numbers, I’m talking about the actual logic used by chips to manipulate the bits that make up a binary number. (Don’t sweat the Boolean algebra, just stick with the easy logic stuff for now.) There are a lot of basic tutorials on the net, I like this one even though it uses Comic Sans. Once you get your head around the basics, you’ll be able to solve some of your problems with chips instead of Arduino code.

Here’s an example I’ve seen plenty of times in the lab: Someone is doing a simple Arduino project, and they want to read multiple switches. Maybe they have four switches and they don’t care which one is closed, only that one (or more) is closed. Or maybe they have tw switches and they only want to know when both of the switches are closed at the same time. If you’re unfamiliar with Boolean logic, you’re probably going to put each switch on its own pin then try to read them in some clever fashion in your Arduino script.

Alternatively, you could use a chip that implements Boolean logic, wire your switches to that, then wire the chip to your Arduino.

In the first case, where you have four switches and you don’t care which one is pressed, you could use a chip that implements “OR”, like the 74LS32. It has 4 OR gates, each with two inputs. Hook two switches each up to two of the OR gates, then hook the outputs of those two OR gates to a third, and the output of that to a single pin on your Arduino. You’ve just implemented, “if switch1 or switch2 or switch3 or switch4 then true” in hardware instead of trying to write a clever Arduino script. You’ve also used only one pin on the Arduino instead of four, which can be a really big deal on complex projects.

In the second case, where you want to know when both switches are closed, you’d hook them to a “AND” gate and run the output of that to your Arduino. In this case, you’ve implemented “if switch1 AND switch2 then true” and saved yourself a pin on the Arduino in the process.

Ok, so how do you find out which chip does what you want? There are endless catalogs of spec sheets on the net (hint: search for “TTL databook”) and if you go to a major component vendor or octopart you might get lucky just typing in what you want, like “4 gate OR” then look at the data sheets for the results. Also, chip vendors often produce huge printed catalogs of their chips or post PDFs on their websites. I find these useful for thumbing through while waiting on my coffee, as I often discover a chip that I would never have thought to look for but that solves some sort of problem I’ve had in the past.

[edit: yes, you can do the examples without chips, but I wanted a simple example to show how Boolean logic can be implemented in hardware instead of software.]

And now, an example of how browsing chip catalogs can be useful.



as much fun as my first computer…

Filed under: Arduino,Hacking — jet @ 22:24

..which was a Commodore C64 with monitor, printer, and *floppy drive*, even. No more sharing the Radio Shack Model 1 Level 2 at school, I could write D&D and Morrow Project character generators to my heart’s content. It was amazingly expensive relative to our other household expenses at the time, I think my dad was making $45K a year or so while he was in the Army and the out-the-door cost of the C64 Kit was around $1200.

For less than that + a few evenings of assembly, I now have my own desktop 3D printer. It’s basically the Altair 8800 of 3D printers, the Makerbot “cupcake”, which is based on the open source Reprap project. It only has as a working envelope of 4″x4″x6″ so I won’t be printing anything huge, and the resolution isn’t good enough for commercial resale. However, it’s going to be trivial to print out small objects for test purposes while doing design/fabrication projects or creating structural elements for other 3D projects.

Say “Hello” to Cupcake #235:

Cupcake #235

(I stained and sealed it before assembly, it shows up as unfinished birch plywood.)

[tags]makerbot, reprap[/tags]


Not dead, just busy

Filed under: Arduino,Hacking — jet @ 19:52

Have a ton of things going on right now, but none are finished so there’s not much to post.

Mostly I’m working on an entry for the Instructables Arduino Contest, but just now my MakerBot Cupcake showed up on the doorstep. Do I risk missing the deadline for the contest in order to use the Cupcake to make something for my entry? Decisions, decisions.

[tags]arduino, fdm, makerbot[/tags]


Hall Effect Sensors and Arduino Interrupts

Filed under: Arduino,Hacking — jet @ 16:51

The Hall Effect sensor (usually shortened to “Hall sensor”) is an amazingly useful bit of circuitry: a simple, easy-to-use component that responds to a magnetic field by changing the voltage level it emits. What it does is so simple it’s not even obvious why it’s useful until you start seeing where and how hall sensors are used. One of the more useful things you can do with a Hall sensor is to detect motion and to count motions without touching the thing you’re detecting. Imagine you want to detect if a door is open or closed, and you want to count how many times the door is opened or closed. The simplest solution might be to put a physical switch somewhere near a hinge or latch, but this is hard to do without interfering with the door’s regular operation. Instead of modifying the door, you could instead use a Hall sensor with a magnet. The magnet goes on the edge of the door and a Hall sensor goes on the door frame so that it lines up with the magnet when the door is closed.

Because Hall sensors output a voltage, the first solution for hooking it up to an Arduino might be to connect it to an analog pin, repeatedly read the value, and wait for it to change. This is called “busy waiting” or a “polling loop” in CS lingo and it is generally frowned upon for reasons best illustrated by a code example:

// if the door is opened, call a function that turns on alarms.  otherwise, turn them off.
  int i = analogRead(0);
  if (i > 0) {
    Serial.println("door is closed");
    DisableAlarms(); // a function that turns off all the flashing lights.
  else {
     Serial.println("door is opened");
     DoAlarm(); // a function that turns on a bunch of flashing lights

Looks ok, right? And it mostly is, except for one thing. What happens if the door is quickly opened and closed while the DisableAlarms() function is running? What if you want to do other things in your script, like read a temperature sensor and print out the value? What if you want to keep track of how long the door was open the last time it was opened?

A common solution for this is to use an "interrupt". Interrupts aren’t always obvious at first, but once you understand how they interact with an Arduino script you’ll find all sorts of places to use them. (They’re instrumental to modern computing and the Wikipedia entry is a CS-heavy description as a result.)

An interrupt is exactly what it sounds like — it interrupts your Arduino script when an outside event happens, your script can do some simple task, then the script goes back to what it was doing earlier. The doorbell on your front door is an excellent example of an interrupt. You could go to the door every minute and check to see if someone is there or you can wait for the doorbell to ring. When it rings ("an interrupt occurs"), you temporarily stop whatever you’re doing and check to see who is at the door ("execute the interrupt routine"). When you’re done answering the door ("servicing the interrupt") you go back to whatever it is you were doing earlier.

So let’s say you want to know how long it’s been since the last time a door was opened. You could poll the Hall sensor, but your script has a lot of other things that need to be done, like display values from sensors or take input from other sensors. Instead of polling, let’s use an interrupt:

unsigned long doorNow = 0;
   unsigned long doorLast = 0;
   unsigned long doorDiff = 0;
   int doorCount = 0;
void setup()
   // We need to tell the Arduino what to do when the interrupt happens and
   // the details of our interrupt.  We want to use interrupt #0, we want
   // to know when it's going from a low value to a high value, and we want
   // it to run the SetDoor() function.  See the arduino.cc reference for
   // the various options and pins available on your particular Arduino.
   attachInterrupt(0, SetDoor, RISING); 
void loop () 

 // this is the function that is called to service the interrupt
 // It checks the time, then computes the difference between now
 // and the last time the interrupt was serviced.
 void SetDoor()
 doorLast = doorNow; 
 doorNow = millis();
 doorDiff = doorNow - doorLast;

Note that the only thing that happens in loop() is printing the value of "doorDiff" and “doorCount”. We never actually go read the sensor to see if the door is opened or closed, we let the interrupt handler update the values of doorLast, doorNow, and doorDiff on every occurance of the interrupt.

Another common application of this is to compute the speed of a rotating object. Instead of putting the magnet on the edge of the door, put the magnet on the edge of a disc, say a gear or pully. Every time the magnet goes by we know the disc has made a revolution. We can use the time between revolutions to compute the current speed of the disc and we also know how many times the disc has revolved.

Interrupts are useful in other places and don’t always require Hall sensors. How many scripts have you seen (or written :-) that use digitalRead() to determine if a button has been pushed? You could easily use an interrupt to simulate an on/off switch using a simple pushbutton switch and an interrupt handler that did something like:

void ButtonPress()
if (buttonState == 1) {
    buttonState = 0;
else {
    buttonState = 1;

Then in your code, instead of doing a digitalRead() and hoping it’s while the button is pressed, you could just test the value of buttonState:

if (buttonState == 1) { // someone pushed the button!

What are the downsides of interrupts on the Arduino? The biggest problem is that most Arduino only have two interrupt pins available. Another problem is that it’s risky to do anything complex in your interrupt handler and it’s a bad idea to call other functions from within your handler. When an interrupt handler is called, the Arduino temporarily stops doing everything else, so it’s best to stick with simple math and setting/testing global variables in your interrupt handler as in the above examples. If you do something involving input/output in your interrupt handler — say call Serial.println() — you might run into problems that are very difficult to debug.

Now, go make something and tell people what you did and how it works.

[tags]arduino, hall sensor, interrupt[/tags]


Can We Teach Debugging?

Filed under: Arduino,Hacking — jet @ 12:01

[thx to Tom Igoe for making me write all this down]

Question: Can we teach people how to debug? We often talk about “the art of debugging”, but is it really an art? Is it a science? A mixture of both?

I’ve never given thought to explicitly teaching a unit on debugging, it’s always something that gets covered along the way while teaching coding and physical computing. Which isn’t surprising, I don’t remember anyone teaching any sort of debugging in any of my CS classes or ever thinking of it as an academic subject. It was mostly treated as a practical thing that we’d pick up after we got work. You get your first few coding jobs, you have bugs to fix, and someone senior (usually) comes by and teaches you what they know about finding bugs in software.

However, I think that where I really learned how to debug wasn’t while writing software, it was while working on cars and motorcycles. When you’re faced with a motor that won’t start or a strange noise or an intermittent failure in some part of the electrics, you have a problem space much bigger than you can see all at once. You have to break the problem down, rule out areas that can’t obviously be at fault, and try and focus on the areas where the problem might lie. There’s an iterative process of selecting smaller and smaller domains until you get to the point you can start asking questions that are simple enough to be easily answered. “Why won’t the car start?” can’t be answered until you’ve answered all the little questions, like “is the battery fully charged?” or “is the fuel pump sending fuel to the carbs?” or “are the spark plugs firing?”. More often than not, answering those questions simply leads to even more big questions that have to be broken down again, “ok, why isn’t power getting from the battery to the spark plugs?”

Another issue is that in the physical world, you don’t have x-ray vision (debuggers) or the ability to replicate the problem over and over without causing physical damage (“let’s add some printf’s and run it again”). You have to learn to break the problem down into tests that won’t damage the engine or make the problem worse. You also can’t magically make most of the car go away with #ifdef’s in order to isolate the problem, you have to physically connect and disconnect various things both for safety reasons and so that you can perform proper tests. (Always remove the ground strap from the negative pole of the battery. No, really. Trust me on this.)

When unit testing started gaining in popularity in the software dev world it made perfect sense to me. This is the way I fix a vehicle — break the problem down into increasingly smaller chunks, isolating unrelated systems from one another, to the point that I can “Has the flayrod gone askew on treadle, yes or no?” instead of being stuck at “there’s a problem at the mill”. Granted, we use these tests to prevent bugs in code under development, but adding them to an existing code base often reveals all sorts of, “oh, so that’s why it makes that odd noise on Tuesdays after lunch” bugs that were never worth tracking down. The problem with unit testing, however, is that you’re usually adding it from the bottom up while you’re actively focused on the task of software development. You’re almost ruling out the need for debugging later by doing extensive testing now, or you’re adding it to an existing code base to “increase stability,” as they say. (In other words, there are all sorts of mildly annoying bugs we can’t find easily, so let’s just add unit tests and hope that fixes things.)

My gut feeling is that there’s a pattern involved in debugging both hardware and software problems, and that the pattern is similar to other patterns we use in hacking and design. I believe “my car won’t start” and “my LED won’t light” can be solved using similar methodologies to generate domain-specific questions. Each domain requires its own set of knowledge and specialized tools, but I think the process for fixing each problem is similar.

So how do we teach debugging? I think we start by teaching the good ol’ scientific method, translated to computational space:

  1. Have you solved this problem before? If so, repeat your previous investigation to see if it’s happened again.
  2. Define questions that you can answer with simple tests.
  3. Perform tests and collect data
  4. Analyze results.
  5. Repeat 1-4 until problem is solved.

Ok, granted, that seems pretty obvious, but it took us humans a really long time to sort that out and write it down. I suspect most of us couldn’t recite the scientific method off the top of our heads, especially if we didn’t study science in high school or college.

Using these steps also requires a certain amount of domain specific knowledge and ability to choose and use the appropriate tools. If I don’t know ground from positive and that current can only flow through an LED one way, I’m not going to get very far figuring out why my LED won’t turn on because I’ll never be able to ask the correct questions.

In theory, what we’re teaching when we teach computing is the necessary domain specific knowledge and tools, so the student should be able to debug simple problems in their own work. What I’m suggesting is that we also hammer on the above methodology any time a student shows up saying, “my LED won’t turn on”. Make the student break the problem down, generate the questions, then show the student how to answer those questions if they’re unable to do so on their own. If the student can’t ask the right questions, then there’s a bigger problem: the student doesn’t have the domain specific knowledge to turn the LED on in the first place. If the student can ask, “is there power to the LED” then you can show them how to use a multimeter to answer that question. But if they’re still unclear on polarity, then they’ve got a bigger problem.

I think we can teach debugging, even though we weren’t taught debugging when we were learning. Not only can we, I think we do students a disservice if we don’t teach debugging as a core competency.

Footnotes: “Kit-building isn’t learning” and “It’s not my fault that Windows sucks”.

There are at least two exceptions to the above.

1) Building a kit isn’t the same as studying and learning a subject. Knowing only how to solder and read English, one can put together kits ranging from a simple Adafruit Arduino kit to a complex synthesizer from PAiA. But unless the builder does research into why the kit is put together the way it is, they haven’t learned much, if anything, about what they’ve built. As a result if there is a problem, whether it is in the instructions, the components, or their assembly, they’re going to find it very difficult to ask the right questions that will let them debug the problem. (I’ve assembled kits from both outfits and they both provide excellent kit-building instructions.)

2) Windows sucks. Ok, all computers suck, but Microsoft has spent decades innovating new and wonderful ways for Windows to suck, so I’m picking on them. There comes a point in debugging a hardware or software problem where the problem is out of operational scope. Maybe “my LED won’t turn on” because there’s a subtle bug in the USB driver between the IDE and the breadboard. The student will probably never have the domain specific knowledge needed to start asking questions about the USB driver, and odds are the instructor won’t either. Sadly, even the person who developed the driver or tool or OS can’t formulate the right questions either, this is why the final step in many troubleshooting guides is, “reinstall the drivers and then the operating system”.

[tags]debugging, pedagogy[/tags]

Next Page »

Powered by WordPress