[Update: This article has been continued with Part 3]

Back again with the next phase in the Arduino-based sequencer for the SX-150 project. Boy, I need a catchier name for that. I'll work on that.

If you recall, at the end of Part 1 I had used a digital potentiometer to replace the stylus-and-strip control for the Gakken SX-150 Analog Synthesizer.

In this next stage of the project, I'm going to replace the digipot with one that has a wider range, then extend my circuit and my source code to let the arduino directly play individual notes without having to worry about resistance values.

Read more »

This seemed worth coming back to since it was buried at the bottom of my "Using the 555 timer as an external clock for the Arduino" article, but I have built a calculator for oscillator timing with the 555.

I know, I know, there are a lot of those out there. Well, that's half true. There are a lot of calculators that will take the resistor & capacitor values and tell you what the resultant timing would be... but usually you start from the other direction... you have a timing spec in mind and you need to know what components to use. That's how I tackled it.

You tell it that you want the timer to fire every 60 seconds, or at a frequency of 440Hz, and it will make recommendations about some common components that will have that effect, along with duty cycle, etc.

Because my blog software doesn't like adding javascript very much, I put the calculator on it's own separate page: http://totusterra.com/555timercalc.html

Hopefully this will be useful to anyone playing with the 555, with or without the Arduino involved.

The Need for an External Clock

[Update 12/30/09: I have since found out that the Arduino has hardware timers built in. They seem to be hidden away in the API and I didn't see them when I started, but I will write a little sample with them sometime soon. In the mean time, I think there are still reasons why this is a valid approach in some cases -- plus it's got a simple introduction to interrupt handling, and the 555 timer is still a super useful IC, so hopefully you'll find something useful here.]

Often when I’m programming the Arduino, I can be a bit sloppy about time handling. I’ll throw in a delay(1000) without really thinking about it. And, for the most part, that works just fine. The delay() is just to “slow things down a bit”, and I could just easily have written delay(1111) and not really noticed anything different.

There are times, though, when precision counts.

Say you’re timing something against a video recorded at 30 frames a second – even small inaccuracies can add up and pretty soon your timing is off by several frames. Or perhaps you’re recording data from an experiment and you want to record the results every 1/100 seconds – inaccuracies can skew your results. Or if you're controlling the motion of a device, inaccuracies in timing can cause your expected location to be off.

The key here is an ‘external clock’. Rather than have the Arduino keep track of when to perform the next task, you have an outside signal that says “Now!” and fires an interrupt which the Arduino responds to. If your source fires every 100 milliseconds, then 10 times a second, the Arduino will receive an interrupt which will stop any processing currently happening and immediately execute the interrupt handler. For every tick of the clock, the interrupt handler will execute.

In my case, I was looking to build a synthesizer of sorts and wanted to ensure that I would have a 8000 Hz sample rate, so I had to make sure that the Arduino would do my bidding exactly every 125 microseconds. It turns out I was maybe over-optimistic about the what I could ask of the little guy, 125 milliseconds didn’t leave much time for me to do anything between samples. But I think that if you were in the 1/500th second range, this technique would work very well.

Read more »

For many years, Dr. Watson ‘minidump’ files have been one of the mainstays of the Windows debugging arsenal. Usually generated automatically, they contain stack trace information, a list of loaded modules, and a chunk of memory at the time of the crash, and other related info to help track down errors.

Since I moved primarily to C#, I’ve had less call to dig in at that level. There are some circumstances, however, where getting a peek under the CLR at the underlying Win32 app comes in handy. One of those times came up a couple years back, and since I couldn’t find much love on the search engines, here’s a quick review of my findings. This was originally posted to an old blog at the time, but it's kind of fun and figured I'd move it over to my more permanent home. Enjoy!

Read more »

For a while now I'd been interested in things like networked objects and gps/location-awareness, and I think that soon enough we're going to see a lot of 'intelligent objects' out and about in the world.

I love the idea of being able to actually build something like that, but there's a lot I don't know about the hardware side of things. What little electronics I studied was long in the past; I'd done a little coding for microcontrollers, but only a little. But there was something about the Arduino that made it seem more accessible.

So my wonderful wife, who is wonderful if I didn't mention that, bought me the "Arduino Advanced Starter Kit" and the accompanying book "Getting Started with the Arduino" for my birthday. Yay!

Read more »