Archive for the ‘Arduino’ Category

« Older Entries
Newer Entries »

Free: Boxed Manuals → Cases for Prototyping On the Go?

Wednesday, June 25th, 2008

I’ve been saving these relics of the Information Age forever, initially because I had the computers to go with them, then out of nostalgia, then because I forgot I had them, and now because it seems like the boxes should be useful. But really, I’d just like them to go away.

Anybody want some three-ring binders with matching boxes, maybe to put an Arduino and breadboard in to take with you on vacation and play with circuits when you’re stuck in Saint-Tropez for a couple of weeks with nothing to do? The rings oughtta be good for holding baggies of parts, or something.

Seriously, if anyone wants any of these, they’re yours for the cost of shipping. The MS-DOS Operating System is missing one of the two volumes from the double-wide case; the Wordstar and Operating Instructions are intact in single-wides.

Posted in Arduino, Hacks, Miscellaneous, Salvage | 1 Comment »

“Airduino” Scungy Anemometer Part 2: Digital Connections and Interrupts

Sunday, June 8th, 2008

In part 1, I described making a propeller out of foil to measure the airflow of my air conditioning system, building an optointerruptor from an LED and a CdS photocell, and amplifying the signal to a usable level.

Next, I needed to feed the signal into a digital input on the Arduino. Old-school digital inputs don’t like having analog signals fed into them; but I knew from working with a PIC that some of the Arduino/ATmega pins would probably have Schmitt-trigger inputs, which have hysteresis.

A digital input with hysteresis turns on when the analog input becomes higher than an upper threshold but doesn’t turn off until the signal falls below a lower threshold. The effect is that an analog signal wandering back and forth around the midpoint doesn’t cause lots of twitching back and forth of the digital interpretation. Regular thermostats work this way — they turn on your AC when the temperature gets one-half to one degree above the thermostat set point, and turn off the AC when the temperature falls one-half to one degree below.

Schmitt-trigger on ATmega input

So imagine my delight to find that every ATmega8/168 input pin has Schmitt-triggering. Any pin would do! But I had two particular ones in mind . . .

External Interrupts

All I wanted the program to do was count how fast the propeller blade went by, activate a relay when it got above a higher speed, and deactivate the relay when it got below a lower speed (hysteresis again, at a different layer of the system). For a program that simple, I could write a loop to watch the input pin in software . . . but why, when the ATmega can do it in hardware?

(more…)

Posted in Arduino, Hacks | 3 Comments »

“Airduino” Scungy Anemometer Part 1: Detection and Amplification

Sunday, June 8th, 2008

Necessity is said to be the mother of invention, and 90+°F daily temperatures with the air conditioner on the fritz made me feel pretty inventive.

Arduino anemometer, angled view

Our air conditioner was low on refrigerant and the blower fan motor may be running slower than spec and not moving enough air. Between the two problems, the expansion coil inside the furnace housing would ice up, over a few hours completely blocking the airflow and preventing any meaningful heat exchange. I’d then have to switch off cooling mode and run only the fan for a few hours to melt the ice.

On a weekend when I was home all day, I discovered that I could keep the house fairly cool by setting the blower fan to run all the time, manually monitoring the airflow out the vents, and cycling the AC off when airflow was restricted and back on when it opened up. Which sounded like a perfect job for a microcontroller.

Introducing the scungy anemometer, or Airduino v0.1, for short. Also introducing real-life code using the Arduino’s external interrupt pin(s).

(more…)

Posted in Arduino, Hacks, Slim | 5 Comments »

Arduino I2C Expansion I/O

Monday, May 26th, 2008

Arduino with I2C connection to TI PCA9535 and PCA9555 GPIO chips

Cort and I are good friends and both interested in electronics, but have had surprisingly little opportunity to work on electronics together. He’s an amateur radio operator and very much into RF design, and I’m more interested in physical computing.

So when he started describing his receiver voter project and suggesting that I might be able to help out on some of the digital interfacing, I jumped at the opportunity. A radio repeater receives transmissions at one frequency and rebroadcasts them at a nearby frequency, effectively boosting the signal (by repeating it) without increasing transmission power over the legal limit.

The voter picks the best signal from several different receivers (possibly several miles apart, linked back to the repeater base) and routes it to the repeater. And Cort’s voter will have lots of pushbuttons, LEDs, and digital controls — more than he could wire directly to the Arduino he’s planning to use to control it.

That’s where I come in. Cort is very interested in learning the Arduino, but he hasn’t done much with microcontrollers lately and is to some extent playing catch-up with a decade’s worth of advances in technology. So I’ll pitch in and give him some ideas and programming assistance on the digital I/O.

I2C I/O Expansion

I started by looking for digital I/O expansion chips, and I did not start by looking for I2C. I’ve never worked with I2C before and I thought I’d find something with SPI, but oh no, that was not to be the case. Nearly everything I could find — and everything I could find that was readily available and affordable — used I2C. This is actually a good thing — I2C uses only two interface pins to talk to up to 127 devices, and SPI needs two pins for the bus plus a separate chip select line for each device — but it wasn’t what I was hoping for when I started looking.

So I ordered some samples, warmed up by trying to interface to an I2C EEPROM I had lying around (with no luck whatsoever, although I now know several things I did wrong and will go back to it soon), built some breakout boards, and got I2C communications up and running on the Arduino this weekend.

And the number of mistakes I made along the way was staggering. Not just little misunderstandings, but mind-numbing stupid mistake after stupid mistake, things I’ve know better since I was six. With a weekend like this, it’s a wonder I haven’t run over myself with my own car somehow.

So do what I say, not what I did.

Arduino I2C

First off, I had to get the Arduino talking to I2C. There’s not much online about doing I2C on the Arduino, and the most useful for me was Julian Bleecker’s blog post prosaically entitled Arduino and the Two-Wire Interface (TWI/I2C) Including A Short Didactic Parenthetical On Making TWI Work On An Arduino Mini.

It turns out there’s a Wiring library called Wire (why not, oh, say, I2C???) that operates the ATmega’s hardware I2C port and which has been incorporated into the Arduino software since version 6, so everything I needed was right there; I just had to figure out how to hook it together.

Between the Wire documentation being sketchy and not explaining how each function corresponds to an I2C function, its code examples being outdated and occasionally incorrect, my lack of familiarity with I2C in general, my not yet having a working I2C circuit to reference, and of course my many, many mistakes, this made for a bit of a vexing experience.

Let’s do it.

(more…)

Posted in Arduino | 127 Comments »

My First Arduino Shield

Sunday, February 17th, 2008

An Arduino “shield” is a PC board made to plug into the top of the Arduino, covering it (hence the name) and extending the Arduino signals to provide some extra functionality. Shields I know about are prototyping shields (“protoshields”), with a tiny breadboard on top; motor control, with H-bridge drivers to run motors, servos, and steppers; and ethernet, with a Lantronix Xport ethernet interface onboard. (I know there are shields from places other than Adafruit, but I really like supporting Lady Ada’s open-source hardware lifestyle, so I tend to look there first.)

After getting my Arduino, I had thought about getting a protoshield, but dismissed it pretty quickly — it seemed to me that the tiny breadboard on it would be too small to be useful for anything complex enough to be worth using the Arduino for. But Friday the Arduinos arrived for class, I agreed to do a demo/intro on Monday, and I realized it’d be a lot easier to do on a protoshield than on a separate breadboard.

With no time to order one before Monday, I had to construct my own over the weekend. I started with Lady Ada’s EAGLE schematic and board files (Creative Commons 2.5 Attribution Share Alike) and hacked them up for a single-sided board that I could etch quickly and easily. I took out her solder prototyping area, moved headers to align better with my tiny breadboard, changed up the LEDs and pushbuttons, and generally did enough work that I’m not sure I saved any time starting with an existing design. :-)

Homebrew Arduino protoshield

Here’s the result — ugly but very functional. I generally use breadboard wires cut and bent to length, so it matters to me that the header sockets are aligned with the breadboard columns and spaced a multiple of .1″ away. It works out very nicely.

Silkscreen Toner Transfer

Worth noting is that I used Cort’s idea of iron-on toner transfer for the silkscreen layer on the top side of the board.

Arduino protoshield PCB with iron-on silkscreen

After the copper is etched, the etch resist cleaned, the board tinned if you’re tinning, and the holes drilled, you print the silkscreen layer and do an iron-on toner transfer just like you would for etch resist. The main difference is that for appearance’s sake, you really want to get all the paper fibers scrubbed off of the toner — I probably spent half an hour in the sink with the toothbrush getting it clean.

I think the method is great; it’s just this instance that’s less than perfect. For one, this PCB is very dark, and the black toner doesn’t show up well; it’s much more readable on lighter boards. For another, the font is really smaller than is advisable for a toner transfer — I’m surprised it actually worked as well as it did.

It’s a very nice change to have labeled connections on a homebrew PCB.

Using It

I practiced my spiel tonight for class tomorrow, starting with the Arduino “Blink” sketch flashing the onboard LED, then:

  • plugging in the shield and jumpering in the green shield LED to blink as well
  • jumpering in the red LED and updating the sketch to alternate green-red-green, etc.
  • plugging a common-cathode RGB LED into digital pins 9-11 and updating the sketch to alternate red-green-blue-red, etc.
  • writing a pulse() function that uses analogWrite() (PWM output on pins 9-11) to fade an RGB color from dark to bright to dark and updating the sketch to pulse red-green-blue-red, etc.
  • wiring three more pushbuttons to digital pins 0, 3, and 6 (LOVE the ATmega’s internal pull-up resistors!) and changing the sketch to pulse a color dark-bright-dark on demand

It’s all pretty easy stuff, so the idea is that I’ll be able to do it while maintaining a stream of patter. We’ll see how that works out. :-) Still, it’s a nice introduction to a few of the capabilities of the Arduino and to how easy it is to just try things when you have a breadboard and a nice microcontroller development system.

So Do I Like It?

Using the protoshield tonight has convinced me that it’s great for a tiny demo, and too small to be useful for real work. :-| I’m not complaining, though; it’ll be fun to have around.

One thing that would help is the addition of a ground bus at the bottom — I waste a lot of column space leapfrogging ground to everywhere I need it. There’s room on my board that I’ll add a ground row on V2.

Credits

Original shield design by Lady Ada

PCB stock from Slim

Tiny breadboards from terminalcity

Iron-on toner transfer “silkscreen” method from Cort

Posted in Arduino | 15 Comments »

LED Calculator Prototyped with LCD

Friday, February 8th, 2008

I still want to find a small LCD module for the LED calculator, so I can fit the whole thing into a box with a footprint about the size of a deck of cards. But for prototyping, I have a stack of 2×16 LCD modules about 3 1/2″ wide (viewable about 2 1/2″) from Slim, and Wednesday night I got one hooked up and working.

They’re Optrex DMC-16207 modules, and they seem to be using the Hitachi chipset that everyone uses, or at least an equivalent, although I didn’t know that at the time. Searching online, I had a hard time finding data on this exact module, but came across a mechanical drawing, a module user’s manual, and finally a full datasheet.

Interfacing the Arduino and LCD

I dived in and wrote my own LCD interfacing code. I found out in retrospect that there are several other Arduino LCD interfacing projects out there:

But all of them are using hard-coded delays to pause while the LCD processes commands, rather than checking the busy flag. To be sure, I’m doing the same thing right now in my first draft of the code; but I’m going to go back and clean it up to do it right.

Also, I haven’t checked all of them, but at least one is using digitalWrite() to manipulate each bit of the port register individually. Since I’m dedicating eight Arduino lines to the LCD’s I/O port, I can write the port register as a byte rather than twiddling individual bits, saving time and effort.

My goal will be to write a nice library module/class that encompasses these different approaches (8-wire vs 4-wire, busy flag vs hard-coded delays, read/write interaction vs hardwired write-only) and presents a clean interface to the programmer to select the options. Of course, for now, I just wanted to get it up and running.

I found this ATmega to Arduino pin mapping, which confirmed that Arduino digital lines 0-7 are PORTD lines 0-7. And the Arduino port register reference shows that DDRX and PORTX are defined as Arduino variables; so writing to a port is as easy as PORTD = $ff . It’s very nice that they left those low-level features exposed, even though in most cases it’s better to use the higher-level interface for portability.

Calculator Prototype

So here’s the work in progress.

LED calculator prototype with LCD on breadboard

The Arduino is getting power from USB and supplying 5V power to the LCD. The LCD contrast is hard-wired to ground. Although it actually looks pretty good right now, I’ll want to put in a potentiometer to adjust contrast. And I’m still using my bench power supply to run the LED circuit at 9V.

I don’t have a method built to select the voltage of the target circuit — the software is assuming 5V for now. The easy thing to do would be pushbuttons to bump the desired voltage up and down. It’d be kind of fun to do it with a spinny-wheel, although I’m not sure how much that would increase the cost, and I’m concerned about overengineering this thing if I really want to offer it as a kit. Maybe another potentiometer is a good compromise.

However the target voltage is selected, I need to determine the selectable range (which could of course be overridden by an owner with an AVR programmer). I’m thinking 3 – 15V in .1V increments. Is that enough?

Posted in Arduino, Circuits, Ideas | 18 Comments »

Arduino USB Auto-Reset Hack

Monday, December 31st, 2007

Older Arduino boards like mine have two annoyances associated with uploading software to them. First, you have to press the reset button (physically) to trigger the bootloader to expect new software from the host computer. Second, the Arduino waits allegedly 6-8 seconds (actually about 10 on mine) on every boot before starting your program, in case you might want to be uploading new software to it.

Small annoyances, to be sure, but they add up quickly when you’re trying to tweak a timing constant in a program and uploading software repeatedly. Thus in designing the latest Arduino, the Diecimila, the team addressed these two issues.

On the Diecimila board, they added a capacitor between the USB-serial chip’s DTR line (active-low) and the microcontroller’s reset line, so that the host computer can trigger DTR and pull down the reset for a moment, relieving you of pressing the button. In the new version (10) of the IDE, they added code to support that new functionality. And in the bootloader burned into the ATmega168 microcontroller, they shortened the boot wait time to a second or less.

All of that comes prepackaged for Diecimila owners; but owners of older Arduinos are resourceful and found how to adapt their own boards as well. The NG can be hacked by soldering a capacitor across two adjacent pads that appear to have been put there for that purpose. The Arduino serial can be hacked by stringing a capacitor between the serial connector and the reset line.

Arduino USB hacked for auto-reset, top side

But I have an Arduino USB, the first version to support USB and not yet a “next generation,” and I haven’t been able to find instructions on modifying it. It doesn’t have the pads already broken out like the NG; in fact, it doesn’t even have the same package USB-serial chip. So I muddled through, found the right pins, and did it myself. Works (mostly) great!

Finding the Right Pins

The page for the NG hack simply shows you physically where to put the capacitor on the NG board and doesn’t describe what it’s connecting electrically, which didn’t help me, as I needed to figure out where to put it on the physically different USB board. Fortunately, the page for the Arduino serial hack gives the critical information:

The retrofitting process consists on soldering a 0.1uF disc capacitor between the DTR pin [of the serial port or USB-serial chip] and the Reset signal [of the microcontroller].

Good enough!

I got the datasheet for the FTDI FT232BL USB-serial chip, and for a moment got my hopes up higher than I should have. The DTR line is in the row toward the top of the Arduino board, and it looked as though it might already be broken out into the unpopulated, .1″-spacing X3 header. Nope, nope, it’s about the only line on that side that’s not already broken out. I was going to have to solder directly to the chip.

Given that it’s a 7mm-square LQFP with .8mm (.03″) lead spacing, I should perhaps have set it out with a thimbleful of Special Sheep Liniment to entice the Nac Mac Feegle to solder for me. But I have no dearth of hubris, and soldered it myself. Twice, in fact, the second time after cutting the other end of the wire too short to reach the capacitor.

top-side zoom

One side of the capacitor connects to the DTR line of the USB-serial chip, the fourth pin from the left on the upper edge. The other side connects to the reset line, which appears to be available only on the microprocessor, the ISP header, and the reset button. I chose the reset button on the underside of the board.

I could have used a capacitor with long leads, sleeved them, and connected them directly to the pins at both ends as in the serial board hack; but I thought it looked better to use wire-wrap wire.

bottom side

I laced the (insulated) wire-wrap wire through open vias in the board to keep things tidy and the capacitor snugged down. A few dots of glue would have done the same had I wanted to keep all the wires top-side, but this felt a little more artful to me. Plus it seemed easier to solder to the underside of the reset switch rather than the top, so I was feeding a wire to the back side of the board anyway.

IDE and Auto-Reset

I upgraded the integrated development environment to version 10, which adds the DTR-triggering, and tried it out. The host computer does indeed now reset the Arduino, and I can upload software to it without pressing the button! Hooray!

But there’s still about a 10-second delay after a boot, reset, or upload before the software starts running. Boooo!

Bootloader and USBtinyISP

One of the hacking guides suggested that the Arduino bootloader would need to be upgraded in order to reduce the reset delay, which makes sense. The IDE includes the ability to burn a new bootloader, for which the bootloader web page gives instructions. Burning the bootloader, unfortunately, can’t be done through the Arduino’s serial interface; it requires a separate AVR programmer.

Thus it was time to assemble my USBtinyISP kit from LadyAda.

USBtinyISP PCB

I bought it a while back in order to be prepared for programming ATmegas outside of the Arduino board. It’s an Atmel ATtiny chip interfacing directly between a USB connector and two cables for in-system programming. The board is nicely made, the instructions are clear enough for absolute beginners, and it was a joy to solder.

USBtinyISP

Fully assembled, it lives in a shell that makes me think of old serial line drivers; but the shell is somewhat customized to fit the USBtinyISP board (and vice-versa).

I read recently and have since forgotten the name of the little “columns” built into plastic enclosures (like toys) to hold PCBs in place; but no matter, since my point is that this case doesn’t have them. The USB end of the board had a lot of room to move and was a bit wibbly-wobbly, but I took the foam that the chip shipped in and packed it between the USB connector and the top of the case, which secured the whole thing nicely.

The term is mounting bosses, seen at Near Future Laboratory.

That done, I unplugged the Arduino’s USB connector, plugged the USBtinyISP into the Arduino’s ISP header and into my iBook’s USB, and burned a new bootloader. I went to the Arduino IDE’s Tools / Board menu and selected Arduino NG or older w/ ATmeta8, then Tools / Burn Bootloader / w/ USBtinyISP. The USBtinyISP’s programming light went on and IDE told me it was burning and would take a minute. Twiddle twiddle.

Finished. Disconnected the USBtinyISP and reconnected the Arduino. It didn’t seem to have my program on it any more, which I guess makes sense that doing low-level AVR programming would wipe the whole memory. I uploaded my code again; and when the upload finished, it took about 10 seconds to start the code. Hrm. Pressed reset, and it took about 10 seconds. HRM.

Arduino Bootloaders and ATmega8

My Arduino is so old that it has the ATmega8 instead of the ATmega168. I don’t know whether that’s true of all Arduino USB boards, but it’s certainly true of mine.

It would appear that the ATmega8 bootloader image has not been updated for the auto-reset. Poo.

The bootloader source code is available online, but the ATmega8 code looks unusable. By that I mean that large sections of code are commented out, including the part that makes timeout after n seconds. (Yes, I’m saying it appears that it would wait forever for a software upload before starting your program.)

It looks to me like it’s been half-***ed patched with updates that have been made to the ATmega168 bootloader, but that parts that would have taken any effort to fix have been commented out rather than updated. Yes, I’m bitter.

See the comment from David Mellis, a developer of the Arduino, below. The timeout value is still present; I just didn’t look carefully enough. The ATmega8 bootloader code probably is what’s in the IDE, and it should be possible to recompile it with a shorter timeout. I’ll provide a further update once I get that worked out.

Interestingly, the ATmega168 bootloader code includes conditional compilation for many different ATmega chips, including the ATmega8. It seems likely that I could build it for the ATmega8 and get it to work. However, the bootloader web page says that the ATmega8 bootloader is only 1k rather than the newer bootloader’s 2k, an important savings given the ATmega8′s mere 8k of FLASH.

Fix the abandoned ATmega8 bootloader code myself? Sacrifice an extra 1k of program space by using the newer bootloader? Sigh.

Another option would be to buy Lady Ada’s preprogrammed ATmeta168 microcontroller. Of course I’d check first, but I think the ATmega8 and ATmega168 are pin-compatible. If that’s the case, I could pop in a 168 (preprogrammed from her, or straight from the factory and program it myself with the USBtinyISP) and be done with this. But it really grates on me to replace hardware when a software fix is perfectly viable.

And of course I could just try lying to my IDE about what chip I have and burning the ATmega168 bootloader into my ATmega8. But looking at the source code, there are enough differences between the ATmega168 and ATmega8 sections that I’m leery of doing this. I wouldn’t mind if it simply didn’t work, but I don’t know enough to be sure it wouldn’t damage the chip somehow. I’d rather live with the delay (for now) than destroy the only chip I have (for now).

To Sum Up

The capacitor-reset hack was easily adapted to the Arduino USB, if you don’t mind a little fine-pitch soldering. Yay! That plus an upgrade to v10 of the Arduino IDE allow the host computer to reset the Arduino when uploading new software, relieving you of pressing the reset button each time. Yay! But I don’t yet have a solution to reduce the reset delay on a board using the ATmega8 microcontroller. Boo!

Posted in Arduino, Hacks | 2 Comments »

LED Puck: Tilt Prototype

Thursday, December 27th, 2007

My wife isn’t interested in electronics. She doesn’t do electronics, she doesn’t understand electronics, and she really doesn’t want to hear me ramble on at length about electronics. (I say this all in a very good-natured way, of course. Identical interests were not a prerequisite for our marriage.)

So when my wife asks my why I keep soldering chips onto boards in the wrong direction, I know I have a problem.

Oh, and the ADXL202 is a hardy little sucker.

Prototype Puck I/O Board

Over the weekend, I laid out and built a prototype of the I/O for the puck — just the LEDs, their driver, an accelerometer chip, and a pushbutton. I expect to use the Freeduino circuit for the microcontroller and will still need to add it to the board (as well as battery-charging circuit and all that other good stuff); but I wanted to get started programming the actual LEDs and tilt system.

LED puck I/O prototype PCB, cleaned and cut

I laid out the board in EAGLE; and believe me, it’s a bit of a challenge routing nice curves as traces. The V+ circle around the edge wasn’t too bad; but I wanted to route the LED drive traces as concentric arcs and just couldn’t find a way to do it.

I had a few SMT A6276 LED driver chips around, so I was able to make most of the board SMT already. The A6276 will want to be on the underside of the board (shown here) so its pins are in the same order as the LEDs it drives. I’m not sure where the other chips should be, but it was easy to make a single-sided board for this prototype.

I worried that I was packing the traces too closely together; but they came out well enough (iron-on toner transfer), I think I could have made them smaller. And having to run to headers to go off-board to the Arduino complicated the routing; if the microcontroller were on the other side of the board, each of those signals could have gone through on a via wherever it was convenient rather than having to converge to the two headers at the top and center.

Tinnit

I tried plating the board with Tinnit, because I had such good results last time — that board was incredibly easy to solder. Alas, five-month-old eighteen-year-old Tinnit apparently doesn’t work very well. After forty minutes at 110°F with no plating appearing on my traces at all, I gave up, washed the board clean, and dumped the rest of the Tinnit.

I still think it’s great stuff and I intend to use it again. I just need to be sure I’ll be making enough boards for it to be worthwhile.

I did learn something else, though. After cleaning the board, it sat out for a few hours, and I noticed that it was already oxidizing — the copper was considerably less shiny than when it was fresh. Before soldering, I polished it with wet 600-grit sandpaper, and it took solder beautifully — completely unlike untinned boards I’m used to soldering.

Lesson: If a copper board has been exposed to air for even a few hours, polish it with wet, fine sandpaper before soldering.

Assembly

I soldered on all the SMT components first. I was pleased that I was actually able to find all the resistors and capacitors I needed in my salvage bin. I’ve desoldered a number of SMT boards (heat with heat gun, then bang on the bench vise and the components come flying off; or pluck them off with tweezers for a more orderly approach), and I think these came from a dead Cabletron hub.

LED puck I/O prototype, SMT components soldered

The resistors were all labeled, so they were easy to search for the right values (if you call picking through a bag of grains of rice easy). The capacitors were a bit more challenging — they were completely unlabelled, so I had to dump them out on the workbench and use the meter (tweezer-style) to find the values I needed.

LED puck I/O prototype, copper side

I placed all the LEDs with their cathodes facing clockwise (as viewed from the top) for simplicity — so I wouldn’t have to think about which way each one goes. Although parts of the puck are obviously asymmetric, I prefer to think of the puck as a whole having at least rotational symmetry, and I wanted the LED orientation to reflect that as well.

LED puck I/O prototype, LED side

The jumper wires are a bit scabby, particularly the one running halfway across the board at an odd angle; but again, they’re at least partly due to routing challenges with not yet having the microcontroller on board, as I mentioned earlier.

I should stop to add that laying out an SMT board is really refreshing, in that you can fill both sides of the board with components and traces, and not worry about through-holes impacting the routing on the other side of the board. As long as you don’t need to hop to the other side and back to cross one trace over another, each side can be completely independent of the other.

That’s not illustrated well by my single-sided SMT board; but I mention it because I’m really looking forward to laying out the microcontroller (probably on the top side) and cleaning up some of these traces and jumpers.

Two Mistakes on the Accelerometer

First: absent-mindedly running the resistor that sets the PWM output period to the self-test pin by mistake. Second: soldering the accelerometer to the board 180° from its proper orientation.

When I first powered up the board, I was most interested in testing the LED driver, since I had already tested the accelerometer on the breadboard. The lights didn’t come up (I had forgotten to manipulate the output enable line in my program), but I also smelled hot electronics. I fixed the program, the LEDs worked, the accelerometer didn’t, and I realized my mistake.

On the EAGLE PCB layout, I had a marking for the accelerometer orientation, of course. But the marking was on the silkscreen layer, and I didn’t make a silkscreen layer when I etched the board at home. Then because the components are on the bottom side, I got myself confused about which end of the accelerometer was which.

Lesson: Copy IC orientation markings to the copper layer for homebrew boards.

Rework

Last night I waved my soldering wand and cast a spell of devious reparo on the accelerometer chip; but apparently it backfired, because it ended up looking like this.

Closeup of LCC and stacked SMT capacitors

I actually used solder wick to remove the errant PWM period resistor — it did a nice job of sucking up solder, heating both ends at the same time, and then scooting the resistor off its pads so it wouldn’t stick back down when the solder cooled.

I used solder wick to suck up all the solder I could from around the accelerometer; but I didn’t have a way to heat the whole thing at once, so I couldn’t scoot it away. I need a hot-air pencil and looked at several DIY designs, but didn’t want to take the time out to build one. There was little enough solder left, I was able to twist the chip off the board with a pair of pliers.

I lost a couple of pads in the process; but when I soldered it back down, one was NC and the other I was able to bridge with solder. Then I needed to move one of the resistor traces from the left pin to the middle . . . and the easiest way to do it was to solder one end of the resistor directly to the chip.

Yes, I’ll fix it right in EAGLE for the next board.

BTW, notice the stacked SMT capacitors on the right. I couldn’t find anything in the .1uF – .2uF range in my bag, so I paralleled a couple of 75nF. Nasty!!! :-)

Proto-Puck

The upshot of all this, if I can finally get to the point, is that I have a working proto-puck.

Arduino and puck

I have ribbon cables connecting it to the Arduino for power, LED output, and tilt input. The LED driver works perfectly, and (miraculously) the accelerometer works now that I’ve reoriented it. And that means I’ve been able to start writing code.

This isn’t much yet — it only detects whether the tilt is inner or outer, and which quadrant it’s in — but I think it gives a flavor of things to come.

Posted in Arduino, LED Puck | 6 Comments »

LED Puck: Tilt Menu Demo

Sunday, December 16th, 2007

I have a working prototype of the tilt menu system for the LED puck, albeit square instead of round, and missing the select button.

It started a couple of weekends ago at Cort’s house, where we made some breakout boards for two Analog Devices ADXL202 MEMS accelerometers I have. Sparkfun used to have a great-looking breakout board for them, but it had the filter capacitors on board and I really wanted them off-board for easier prototyping and testing different signal bandwidths.

ADXL202 breakout board, etched

We did iron-on toner transfer etch resist, using Cort’s heat press. We also did toner transfer for the silkscreen-layer labels.

ADXL202 breakout boards

The boards came out very nicely, although the straightness of my hacksaw job leaves something to be desired. Besides indicating the positive directions of the X and Y axes, the silkscreen layer also had labels for the individual header pins; but they didn’t stick at all well going up and down the edges of the copper traces, so I scraped ‘em off. Ditto the pin-1 indicator for the LCC chip.

ADXL202 breakout board, top view

Here’s the board I’ve assembled, with header pins hand-labelled.

ADXL202 breakout board, LCC soldering

I used the Sparkfun SMT soldering method — slop solder on and wick off as much as you can. It leaves enough between the chip and the traces to make good contact, while eliminating solder bridges.

This was a bit interesting to position while soldering. Because it’s an accelerometer / tilt-sensing chip, I wanted its orientation as closely aligned as possible with the orientation of the carrier board. Absolute position doesn’t matter; but if it were rotated relative to the board, its readings wouldn’t align with the tilt of the project it was part of.

I knew I wanted to hold it securely in place while soldering, rather than tacking down a corner and hoping it was rotated about right while soldering the remaining pins. I thought about using a hemostat, but Cort’s was way too strong and would have crushed the chip. I ended up using a needlenose vise-grip, backing it off far enough to just barely grip the chip. I still worried about crushing it; but I was careful enough, as the accelerometer still works.

Tilt Menu Software and Prototype

The whole idea of tilt-menu-based control comes from reader Kevin Reid‘s suggestion:

Accelerometer-based control!

1. Press single control button.
2. Tilt puck such that the LED indicating the relevant function is lit.
3. Release button.

I don’t know whether that’s the exact mechanism (press/release) I’d like to use, but I love the overall idea. To clarify one point, the top of the puck will be rounded/domed, so tilting the puck will light the LED that’s “on top,” like an air bubble floating inside a liquid-filled dome.

With the accelerometer breakout board completed, I was able to prototype the system.

Tilt menu prototype

The Arduino at the bottom is the brains. The accelerometer is at the left end of the breadboard with fairly large signal-filtering capacitors — I sized them for about 50 discrete readings per second, which I think should be more than enough (and is still far fewer than the device is capable of). Note that I’m using the accelerometer’s analog outputs and the Arduino’s A/D inputs; I didn’t feel like measuring pulse length from the ADXL’s digital outputs.

The LED matrix at the right end of the breadboard is kind of ugly, at least to implement on a breadboard (as well as hard to see in this picture). I intend to use an Allegro MicroSystems A6276 16-bit serial-in, parallel-out, constant-current LED driver for the real thing . . . but I can’t find where I put mine, so I just hacked together a row/column drive straight out of the Arduino.

The Arduino code is nothing special, but here it is:

tilt_menu_demo.pde

It reads the analog inputs to get the X/Y tilt, translates from the scale of the A/D converters into the size of the LED matrix, and drives the row/column outputs. I added hysteresis that (although simple) does a fantastic job of keeping the LEDs from flicking back and forth when you’re on the fence between two adjacent ones. And I used tristating on the LED matrix drive because it made more sense to me to float unused lines than to flip them to the opposite value.

Tilt menu demo, flat

Here’s what it looks like sitting on a flat surface. One of the four center LEDs is lit — it turns out to be always the same one, as I haven’t calibrated the accelerometer readings for perfect level yet and it lists a bit to one corner. Note that one of the envisioned modes for the puck is a bubble level; and in that mode, I think I’d flash the four center LEDs to indicate when the puck is perfectly level.

Tilt menu demo, upper right

Tilted a little bit, a different LED is “uppermost” and lights.

Tilt menu demo, far upper right

Tilted dramatically, the corner LED is “uppermost” and lights. Note that the amount of tilt required is set by the TILT_MIN and TILT_MAX values, so it’s easily adjustable for dome shape and/or user preference.

Not Really a Square Matrix

I indicated early on that I pictured LEDs around the perimeter of the puck angled slightly out for good dispersion, so the square matrix I made this weekend was just for a quick demo. I’m actually thinking of twelve LEDs around the perimeter (analog clock mode!) and four in a square surrounding the center, totalling the 16-LED capacity of the A6276 driver chip. I’m working up some very simple drawings of what it might look like, which I hope to post soon.

Posted in Arduino, LED Puck | 2 Comments »

Arduino First Impressions

Sunday, August 12th, 2007

I’m back to working on my CNC machine and wanted to hook some joysticks up to a microcontroller to run the motors back and forth during development, before I have the whole thing running under computer control. I realized that the PIC18F232 (LogoChip) has only two PWM outputs and I have three motors to control, so the LogoChip isn’t going to be ideal for this.

The Atmel has scads of PWM outputs, so I finally busted out the Arduino I bought a year ago from SparkFun Electronics. The Arduino is, to snip from their own description, an open-source prototyping platform based on a couple of Atmel microcontrollers.

Arduino with joystick, LED, and stepper controller attached

The Arduino folks really shined up their Macintosh dev system install procedures since the last time I looked — I downloaded a zip file, double-clicked a USB driver installer and rebooted, double-clicked the IDE icon, and I was in.

I played with the Arduino Friday night. It’s really, REALLY nice to be programming in C again. I had come to the conclusion earlier from looking at the language that it was C with some microcontroller-specific libraries provided, and that’s exactly what it is. The documentation even mentions that it’s using avr-gcc underneath.

Here are my first impressions:

  • The early Arduino board I have requires you to press the reset button each time you want to download code. This is a huge pain. The newest boards have reset magic built into the USB circuit.
  • It waits about seven seconds after power-up or reset to see if you’re going to download new code to it before it starts running your program. That’s a long delay waiting for something to happen, especially if you’re not even connected to it. I expect that could be shortened by tweaking the bootloader, but I suspect you’d need a real Atmega programmer for that.
  • Taking power from the USB port is really cool, particularly during the development phase when you’re constantly tethered anyway.
  • I don’t like the GUI-based text editor in the integrated environment — but then I never do. I understand there’s a way to do all this stuff from the command-line (so advanced developers could edit with vi or emacs), but I haven’t looked up how to do that yet. (Remember, first impressions.)
  • PWM frequency is fixed by the firmware. There’s example code to change it, but the frequency is probably controlled directly by a hardware timer, and I don’t know if there are enough timers to run three PWMs at different frequencies. So the Arduino may not be any better for this application than the LogoChip was. :-)

So overall, it’s super easy and fun for geeks with programming experience. Proooobably not a good introduction to microcontrollers for visual arts students, though.

Posted in Arduino | No Comments »

« Older Entries
Newer Entries »