I received a couple of email and twitter queries about various aspects of the code, so I thought I would add a followup to yesterday’s post.

First of all, I received a query as to whether it was “open source”. Frankly, the code is so minimal and so obvious I didn’t even consider it worthy of protection from any license. Consider it in the public domain. I do appreciate it when people who use this code give a nod back to my website as the origin of the code, but it’s not mandatory.

Seriously. It’s not a big deal.

Next, realize that I wrote the code in just a few minutes (less than thirty). It’s written in just about the most obvious way I could conceive. I really was just looking at a way to test my understanding of the U8glib library, and this seemed like a good way to go. There are a number of ways the code could be improved.

First, this implementation doesn’t use the full resolution of the 128×64 display: it only uses 96×64. The reason is quite simple: the way the code is written, it needs to maintain 2 buffers (the “current” and “next” arrays) each of which hold 128×64 bits. If you multiply out 128x64x2 and divide by 8 to get the number of bits needed, you’ll come up with 2048: coincidently, exactly the same amount of RAM in an ATMega328. But you’ll need some extra memory to hold temporary variables, buffers used by the U8glib, the stack for subroutine calls, etc… Trimming the resolution back to 96×64 provides enough space to actually run. But we could actually use the full resolution by being slightly more clever: instead of having two full size arrays, we could do more of the updates “in place”, and only buffer a couple of extra lines to hold out temporary values before we overwrite them. I have the code in my head, but a few odd details about it aren’t worked out yet, I hope to have nearly as simple an implementation worked out today some time. Stay tuned.

Second, it’s slow. Doing 8 independent bit lookups in the array, the increments, and the compares? It’s a straightforward implementation, but not a fast one. In particular, the shift operations on every pixel lookup are probably really a bad idea on the Atmel AVR: these chips don’t include a barrel shifter, so to shift by 7 takes 7 cycles. We could probably factor out a lot of these calculations with some work. It’s possible to use techniques that can process all the bits inside a given word “in parallel” by implementing bitwise arithmetic, but since the AVR is only an 8 bit processor, the gains are less than they would be on a 32 bit processor, and handling all the edge cases is kind of a nuisance. I remember doing this back in my college days, but I’d have to work out all the details again. You can look at this article from StackOverflow to get some hints and pointers to other implementations. Some of the ideas are good, some not.

Third: the display is really, really tiny. It might be fun to use the builtin scaling of the U8G driver to magnify it by two. Then, of course, we’ll only need to do 64×32, which should run around 4x as fast, and should be easier to see. It will also use a lot less memory, which makes it more useful as a module in (say) another program like a DIY watch.

Lastly, I was told that initializing the random number generator in this way would work, but it seems to generate the same seed each time. I’ll have to figure out a better way to initialize the seed on RESET.

Stay tuned for an improved version.

Earlier this week, I tried to print out the first version of my Arduino bumper. Sadly, our Replicator 2 had a malfunction mid print, and it’s still offline (a problem with the temp sensor) but that doesn’t mean I’ve been entirely stationary. I mentioned on twitter that I was having trouble using the minkowski operator to generate interior offset surfaces, and @kitwallace responded this pointer to some code he used which helped me generate a “lip” inside the outer wall that would snugly fit the Arduino. I also realized that this wall would bump into the backside of some of the pins, particularly around the DC jack, but also on the ICSP and header pins. So, I revised this a bit, and came up with this program:

[sourcecode lang=”cpp”]
module arduino_outline() {
polygon([[0, 0],
[0, 2100],
[2540, 2100],
[2600, 2040],
[2600, 1590],
[2700, 1490],
[2700, 200],
[2600, 100],
[2600, 0]]) ;
}

px = 2505.512 ;
py = 1198.031 ;

module icsp() {
translate([px, py-200, 31.25]) minkowski() {
cube([100, 200, 62.5]) ;
cylinder(r=50) ;
}
}

eps = 0.001 ;

s = 25.4/1000. ;

cl = 8 ;
th = 62.5 ;

module os() {
linear_extrude(height=250)
minkowski() {
arduino_outline() ;
circle(r=th+cl) ;
}
}

module is() {
translate([0, 0, -eps]) linear_extrude(height=250 + 2 * eps)
minkowski() {
arduino_outline() ;
circle(r=cl) ;
}
}

module final() {
difference() {
os() ;
is() ;
}
}

module neg() {
union() {
intersection() {
minkowski() {
difference() {
translate([-200, -200, eps]) cube([3000, 3000, 62.5]) ;
os() ;
}
cylinder(r=200+th+cl*2) ;
}
os() ;
}
final() ;
}
}

module holes() {
union() {
translate([550, 100]) cylinder(r=125/2., h=500, center=true) ;
translate([600, 2000]) cylinder(r=125/2., h=500, center=true) ;
translate([2600, 300]) cylinder(r=125/2., h=500, center=true) ;
translate([2600, 1400]) cylinder(r=125/2., h=500, center=true) ;
}
}

off = 31.25 ;
d = 31.25 ;
w = 31.25 ;

module relief() {
translate([1100, 100, 62.5]) translate([-w, -w, -d])
cube([1400+2*w, 2*w, 2*d]) ;
translate([740, 2000, 62.5]) translate([-w, -w, -d])
cube([1740+2*w, 2*w, 2*d]) ;
}

module slots() {
union() {
translate([-100, 125, 63+off]) cube([550, 350, 500]) ;
translate([-250, 1275, 63+off]) cube([625, 500, 500]) ;
translate([-cl, 125, 0]) cube([450+cl, 350, 500]) ;
}
}

$fn = 24 ;
scale([s, s, s]) difference() { neg() ; holes() ; slots(); relief() ; icsp() ; }
[/sourcecode]

Here’s a quick picture:

It might be a few days before I can get this printed. If anyone uses this to generate STL and print it, I’d love to hear about what you think.

If not, stay tuned. I’ll get there eventually.

A few days ago, I heard that Jayson Tautic (@tautic), manufacturer and purveyor of a interesting electronic prototyping goodies, had put up an interesting offering: a small PIR (passive infra red) motion detector. I’m always up for a new sensor to play with, so I ordered a pair for fun, and they arrived on Friday.

It’s a cute little package, much smaller than I expected, about 8x10mm. It has three pins, but didn’t come with a datasheet. Some queries among my buddies on the #tymkrs channel on afternet turned up this datasheet which appears to be the part. That was good enough to sort out the pinouts: the pin labeled + is the supply voltage, the pin on the opposite side is ground, and the middle pin is the sense pin. When the sensor detects motion, that pin goes high, and remains so for two seconds after the motion halts. And that’s about it.

It was tremendously simple to wire it up to an Arduino for testing. I wired the sense pin to pin 8, and then used this simple sketch…

[sourcecode lang=”cpp”]
const int pin = 8 ;
const int ledPin = 13 ;

void
setup()
{
Serial.begin(9600) ;
pinMode(pin, INPUT) ;
pinMode(ledPin, OUTPUT) ;
}

void
loop()
{
Serial.println("NO MOTION DETECTED") ;
digitalWrite(ledPin, LOW) ;
while (digitalRead(pin) == LOW)
delay(100) ;
digitalWrite(ledPin, HIGH) ;
Serial.println("MOTION DETECTED") ;
while (digitalRead(pin) == HIGH)
delay(100) ;
}
[/sourcecode]

It will turn on the LED wired to pin 13 when motion is detected, and also prints a message to the serial port. Simple.

I haven’t done any testing with this, but it appears they might be sensitive enough to detect the motion of my cat, which seems like it could be interesting. Stay tuned.

Last year, I spent a little bit of time to create a set of blinking Christmas lights that I could mount in a hat. It was powered by an ATtiny13 and mounted in an Altoids tin. While setting up my Christmas tree last weekend, I found them, and they still work. In case you missed it, here are some of the videos I did at the time:

It was kind of fun, and still works, so I’ll probably be wearing it around. But I thought to myself: what could I do to make it better?

The obvious thing to me was to try to add more lights, more patterns, and music. Rather than use a naked ATtiny13, I thought that I would just go ahead and use an Arduino. I have an Arduino Mini that I got to use in a radio beacon experiment that I haven’t gotten to yet, so that seemed like a good idea. The question was then: what could I do?

I came up with these ideas:

• More lights. At $.99 a string, I could put a lot more light strands in place. That would make fancier “chase” effects possible, and generally just look cool.
• More effects.
• A better hat! The missus has a new sewing machine, and could probably use a new project. I have a big head, so finding a Santa cap that fits is always a bit of a chore, and if we made our own, we could add pockets for batteries and sew in the wiring to make it neater.
• Sound. It would be cool to add a small speaker and amplifier, and play music with synchronized light effects.

I don’t think any of this is especially hard. The only part I hadn’t really done before (other than the sewing bit) was sound. So, last night I started reviewing what libraries existed for sound on the Arduino. I actually have a WAV shield lying around, but I was looking for something a bit more minimal: I didn’t really care to use a full shield, both for size and for just a sense of minimality. I kind of wanted to store a few Christmas tunes in the on-chip flash, and then synthesize some high quality (well, decent quality) audio directly.

Which lead me to the Mozzi sound framework.

The Mozzi sound framework for Arduino

Mozzi seems to generate some pretty cool sounds (samples here) and is a pretty neat framework. I decided to give it a whirl last night. I was somewhat delayed by trying to get the Arduino software installed on my new Windows 8 laptop. Apparently the drivers that you need aren’t sufficiently digitally signed for Microsoft to trust them, and you have to go to some effort to disable those checks and get them to install. But once I got that sorted out, I didn’t have any problem downloading and playing with the Mozzi library. To hear the samples, I just hooked a high impedance earphone from a crystal radio to pin 9 and ground, and they worked as expected. The Mozzi webpage actually recommends a bit of output filtering: they have a 6Khz lowpass filter followed by a 16Khz notch filter to get rid of the PWM noise. The design is quite simple RC filter and uses very common values of components, so it should be pretty easy to build. I spent a few minutes entering the schematic into LTSpice, and it seems like it works as expected, and should help audio quality considerably.

Going forward, I need to find some decent Christmas tunes (perhaps in ABC notation like these, although I’d like more complex, polyphonic tunes) and figure out how to synthesize some nice sounds in the incredibly limited time available, as well as control the switching of the LEDs themselves. Stay tuned for more experiments.