obligatory obscure reference

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.

[tags]arduino,logic[/tags]

First printed items: A handle for the z-axis, STL downloaded from thingiverse. I didn’t even do a calibration print, just rolled the dice to see what would happen. There’s plenty of room for improvement in terms of quality, I just need to put in some hours calibrating things.

MC Supersize is concerned that in the future, people will be able to print out their own collectible toys at home for pennies instead of paying tens of dollars at a store.

..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:

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

[tags]makerbot, reprap[/tags]

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]

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.
loop()
{
  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); 
   Serial.begin(9600);
   }

void loop () 
   {
   Serial.println(doorCount);
   Serial.println(doorDiff);
   }

 // 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()
 {
 doorCount++;
 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!
    DoButtonStuff();
}

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]

I have a nicely functioning OSX FT-897 setup and thought I’d document things to make it easier for others wanting to do this.

What didn’t work

Let me start out with what *not* to do. Do not buy anything that is not %100 guaranteed to work with Mac OSX by the manufacturer. When I say “%100 guaranteed” I mean an explicit statement that it the product is fully supported on the Mac by the manufacturer, not “it will work if you get drivers from a third party.”

I used a West Mountain Rigrunner Nomic with my old Powerbook using a USB<->Serial adapter and it kinda worked most of the time. When that third party solution stopped working due to driver conflicts when I switched to my G5 desktop, I upgraded to the West Mountain Rigblaster Data Jack plug & play because the very first line of the description says, “USB interface support for Mac (OS9,10), Linux, Windows (98SE – Vista 64)!”. What I missed was this on a different page of their site: “NOTE: WEST MOUNTAIN RADIO DOES NOT OFFICIALLY SUPPORT MAC INSTALLATIONS. PLEASE DO NOT CONTACT US WITH ANY QUESTIONS OR PROBLEMS USING THESE DRIVERS. THE DRIVERS ARE SUPPLIED BY SiLabs THE MAKER OF THE CHIP”. In other words, if you can’t get it to work with a third party driver, they’re not going to help you. I wasted a better part of a weekend trying to get it to work and got nowhere fast, and I like to think I know a thing or three about *nix, serial, and USB. (And I now have TWO Rigblasters I need to sell.)

What worked

After the West Mountain fiasco, I broke down and spent 2x as much on a microHAM USB Interface III. It’s a pretty cool little unit that does everything over USB — only one cable to hook up to your computer! It’s actually supported by uHAM and therefore supported by OSX software authors. For software, I finally got around to upgrading my aging copy of MacLoggerDX to the 5.x release which has full Cocoa support. It really was just a matter of setting the internal jumpers, installing all the uHAM drivers, plugging in the USB cable and the rig cables, launching MLDX, setting some configs, and I’m chasing clusters and beacons with the best of them. Serial seems to be working pretty reliably at 38400. (Note that this is under 10.5.8, I haven’t taken the Snow Leopard dive just yet.)

[tags]ft-897,MacLoggerDX,microHAM,osx,USB[/tags]