ChickTech Strikes Again!

ChichTech events keep evolving, and this was the best one yet! One hundred highschool-age girls for two days at Portland State University in downtown Portland. It really had the flavor of a professional conference with badges, keynote speakers, swag bags, workshops, and breakout sessions. The event kicked off Saturday with a keynote from Michell Rowley, the founder of Code Scouts, who told the ladies not be afraid of making mistakes, and to enlist the help of their friends to learn new things.

Instead of having rotating groups, this time the ladies got to chose one workshop for the whole event. There were morning and afternoon session of two hours each meaning we got a total of eight hour to help fifteen girls learn, design, and build an embedded microcontroller fashion project. Other groups were working on robotics, building computers, and designing websites.

We used the LilyPad USB for the controller and had buttons and light sensors for the inputs and LEDs and a speaker for outputs. The components were soldered to small breakout boards made for us by OSH Park to make it easy to sew and get good electrical connection. The girls picked up soldering very quickly, even with the use of lead-free solder which has a higher melting point.

It was amazing how fast time flies when you are involved in an engaging project. By lunch, we had learned how to upload a program and make the on-board LED blink. After lunch they had a short project of creating a USB bracelet which came in handy to save code examples on. They returned to our workshop and by the end of the first day, they had basic designs laid out and tested with alligator clip.

As a canvas to work with, the girls got a tote bag. They could either incorporate the electronics in the design, or hide them on the underside of the flap. One girl brought a hand made felt hat to modify, and another brought a plushie heart. The girls were amazingly creative with their designs. 

On the second day, we actually started sewing. Working with conductive thread is a bit tricky, but they were quick studies. Soft-circuits is a relatively new endeavor, and there are no "hard and fast" rules. It seems like my technique is constantly evolving, and it is always fun when I learn something from the girls with more experience sewing.

For the final hour of the event there was a Tech Show where the girls got to show off their hard work to friends and family. It was exciting to see them explain to others what they had learned from the workshop.  Hopefully we gave them the skills and interest to keep working on the project at home, or start another project using the LilyPad!

I predict great things for these ladies, in any endeavor they choose to pursue!

Scratch your Arduino?

Why, yes you can. There are several projects I've played with that let you use the graphical Scratch-style programming to talk to your Arduino, which is excellent news for younger kids who are not ready for much typing or the "curly-bracket/semicolon" lifestyle just yet.

There are two different approaches to graphically programming an Arduino. The first is to run a sketch on the Arduino which talks to the Scratch program, passing commands and data over the serial port. The sketch is called Firmata, and requires the Arduino be attached to a computer running a server program to link Firmata with Scratch. Both Scratch for Arduino (S4A) and the newer Scratch to Arduino (S2A) use this approach. S2A seems a bit harder to set up initially, but works with the newer Scratch 2 Offline Editor.

The other approach is to translate the block structure into Arduino C-code for upload using the IDE. This might be a better option for older kids who are ready to make the transition from blocks because they can see the direct C-code equivalent. Both Blockly Arduino and ArduBlock projects take this approach, with ArduBlock actually integrating into the Arduino IDE making the transition from blocks to C-code at the press of a button. Blockly Arduino has the advantage of being web-based, so no installation is required, and the base project, Blockly, has some fun, non-Arduino, online programming tutorials.

I showed ArduBlock to one of the younger Teen Makers at the library program and he quickly programmed an LED to turn on or off at the push of a button. That may sound trivial on paper, but in practice, it is not. He had used Scratch before, and integrated some sophisticate techniques such as using flags to track state and a while loop to debounce the button.

Here is the equivalent C-code:

All of these tools make programming the Arduino a bit easier for younger programmers. They each have their strengths, but if you had to pick one, I'd go with ArduBlock because it is open source and integrates with the Arduino IDE. This makes it both easy to set up, and easy to use.

Coding Around the Clock

I got a chance to participate in an amazing event called CodeDay. Two dozen youth from around the Corvallis area descended on Hewlett Packard for programming party that would last a full twenty four hours.

Festivities started at noon. Ideas were pitched and teams formed. The goal was to complete an application or game within twenty four hours. The event was sponsored by StudentRND who sent a facilitator down from Seattle, but most of the planning was done by a local high school student who had participated in a previous event and wanted to help bring it to Corvallis.

In the evening, as projects progressed, there were seminars on programming frameworks like Construct and Meteor. Several of the groups completed their projects using Construct having no prior experience with it.

As the night wore on, the students took a break to get a "ghost" tour of the HP facility. They got to see the FAB facility and giant industrial web presses, both of which were eerily silent for the long weekend.  Security checked in on us periodically, but we pretty much had the place to ourselves.

It was amazing to see the kids keep up their energy and focus for such a long period. I haven't had to pull an all-nighter since my Navy days and by 6 a.m. I was flagging and took a short nap. The other chaperons snuck some shut-eye here and there, as did more than one of the students.

By nine in the morning, the coding was over. It was time to present. The judges spent some time talking with the teams, and then they each gave a presentation and demonstrated the game play.

The game ideas and implementations were amazing. A couple of them were quite playable and involved compelling story lines. One, programmed by a single student, dealt with protecting a planet using bio-remediation and had amazing graphics.

I sure wish I had had an opportunity like this when I was younger. The tools and systems available to upcoming programmers are amazing. I was proud that HP was able to sponsor the event and thought every minute was worth it.

Soft Circuits Reloaded

I had the opportunity to help with another amazing ChickTech event. This was a six hour soft-circuit workshop for high school girls and was held at Portland Community College's Sylvania Campus. The goal was to have them do something fun and creative while sneaking in some computer programming and electrical theory. I created several example projects based on Leah Buechley's new book Sew Electric and using her LilyPad USB Arduino board. There was a stuffed monster who played music and flashed an LED when his hands were touched. The second project was a playable felt piano.
Photos courtesy of

Six hours may seem like a long time to work on a project, but time flies when you are having fun and lunch was provided. The first order of business was connecting the LilyPad to a computer and learning how to upload code to it. There is an on-board LED you can flash in patterns without adding any circuity.

My Example Template

The next job is deciding on the project. My examples were just to show the possibilities. The girls were free to come up with their own designs. Having an internet connected computer and Google helped with inspiration. Project ideas ranged from a floral arrangement with blinking LEDs (my favorite) to an Opera singer whose dress would play different tones when touched.

To really round out the experience, we included some soldering. I used OSHPark's service to created some inexpensive, small "break-out" boards that allowed them to solder the LEDs, photo cells, or speakers to PCB boards containing large eyelets to enable sewing them into the circuit using conductive thread. They proved their worth in making quick, reliable connections, something that has been a problem using other techniques.

In the introduction, I told the girls that they were going to get frustrated at some point during the day and that they were going to have to have faith that:

  1. The problem would be because of a logical, discoverable reason, and that ...
  2. If they had patience and were persistent, they could discover and solve the problem. 
I had many opportunities to demonstrate those principles as we worked through troubleshooting their various circuits. I think a project like this is one part creativity, one part engineering, one part programming, and one part troubleshooting. The girls brought plenty of creativity. Hopefully they picked up a little of rest as the day wore on.

These events never go quite as planned or expected, but in all, I thought it went well. I was amazed at their creativity and how quickly they picked up the new skills. There were lots of smiles and I even got a high-five for soldering four LEDs together for an "epic" heart. Everyone had fun and went home with a working programmable circuit. They also went home with knowledge and confidence to reprogram the hardware to do something else for their next project. The next project always comes out better than the first, just like this workshop was far better that my last. Based on what these ladies came up with this time around, their next one should be spectacular!

Anatomy of a Small Open Source Hardware Project

Most of us have heard of Open Source Software, as in GNU Linux, but fewer of us have heard of Open Source Hardware (OSHW). If you haven’t, you have now, and I venture most Makers know the concept if not the term.

Open source hardware is hardware whose design is made publicly available so that anyone can study, modify, distribute, make, and sell the design or hardware based on that design.”

As Makers, most of what we do is open source. We study other’s projects, we build on what we learn, and then we document our project in order for someone else to do the same. Well, not all of us, but quite a few. It is sort of a “Circle of Life” kind of thing, and the freedom of this exchange is why I think the Maker movement is growing in leaps and bounds.

I wanted to document a project in a little different way than “step-by-step, this is how you build it”. I wanted to outline line how we used the Open Source Hardware idea to learn, create, and share a project of our own. Of course, if you want to build it, we’ll documented that as well, but here we will take you through the process we went through.

The Idea
Our best ideas always seemed to be sparked by something we learn from someone else. At work, we have a group of people interested in embedded electronics who get together every other Friday to talk about what they've seen or done in the Maker world. The group spans from master Makers, who have produced and sold products, to novice Makers, who are looking to learn how to blink an LED. It is a great group to bounce ideas off, and for a while we had been looking for a project we could do together to learn circuit layout. One person had brought in an automatic mailbox light, showing how he programmed a BlinkM using the Arduino IDE. Another person had been wanting to transfer an Arduino project from the official board to a breadboard and was looking to burn a bootloader to a new chip. Both these projects can be done using the ArduinoISP sketch that comes with the IDE, but wiring it up every time you needed it seemed like a bit of an error-prone chore. Enter the AVR Programming Shield idea.

The best starting point for any project, after the initial idea, is to see what others have done. Turns out several hobby electronics companies have made shields for programming Atmega328 (Arduino’s main chip). These all use the ArduinoISP sketch and featured ZIF sockets for getting chips in and out easily. A separate software project extended the Arduino IDE to allow programming of Attiny chips like used in the BlinkM, and another project had made a small board for programming these smaller chips, but no one had put the two together in a simple manner.

We spent time studying each of the three main shield kits. They are all open source, and all provide schematics. Several also provided their PCB layout files as well. While they all use the same software (ArduinoISP sketch), and thus have roughly the same pin configurations, each had their own special tweaks. It was up to us to determine if we liked the feature and wanted to incorporate their ideas. Regardless if we used it, it was important to try and understand what they did and why. People are going to be looking at our plans later and asking the same question, “what were they thinking!” Hopefully, they’ll figure it out and say “that is kinda cool”.

So here was the goal for our group project: Create an Arduino shield that allowed for bootloading Atmega chips as well as programming the smaller Attiny chips using the ArduinoISP sketch. Piece of cake, right?

The next phase of our research was to look at the pin layouts of each of the target chips and come up with a method to talk to each one. It turns out the pin assignments are vastly different for the different packages. The VCC pin on the attiny85, for example, matches the GND pin of the attiny84. We came up with three ideas for handling this problem. First, each chip could have it’s own socket. This would be simple, but require a lot of board space, and ZIF sockets are expensive. Secondly, you could use a single socket, aligning pin 1 the same every time, and then route signals using dip switches. This would require six switches (one for each ISP line), for each chip (18 total), and would still leave open the chance to mis-align the signals by having the wrong switches thrown. We found examples of projects using both these ideas, but weren't convinced that was the way to go. The third idea, and the one we went with, was to again have a single ZIF socket, but route the signals using a single jumper to one of three headers, one for each chip. There is still the possibility of using wrong header for the chip, but using a jumper also opened the possibility of using the ISP header to program a chip on it’s own board off the shield (say another Arduino with a new chip in it).

This all sounds good until you commit it to paper. Our next step was to draw out the circuit to see if this scheme was even viable. Since actually laying out a PCB was part of what we wanted to learn, we started by drawing the schematics in Eagle Cad.

Once we had a schematic that looked like it would work without releasing any magic smoke, it was time to try it out. It is always best to take baby steps, so a good first step was to start with the smallest chip, the Attiny85, put it on a breadboard, wire it up, and try and talk to it. This process would be repeated for each of the target chips until we had everything wired up and working.

It sounds much easier than it was. We were plagued by such novice errors as jumper wires in the wrong spot and jumper headers put in 180 degrees out of position. Adding to the frustration was some sporadic behavior traced to breadboard rows being loose. We did have several things going for us. First, I had just bought a pack of new jumper wires, and was able to color code the ISP lines for the three sets of signal, making an impossible mess a little more manageable. Second, we only spent the lunch hour working on it, so would never get too frustrated at any given time and were always coming back to the problem with fresh eyes. And last, there were three of us, so careful watching and double checking caught a lot of errors before they became headaches.

Perhaps a final comforting thought was that all the headache we were working through would be spared, both for us when we used the shields, and for anyone else building the project. We were improving our skills in design and troubleshooting while lowering the bar for others who might try and follow our work.

One of the design features we added was the ability to have a programmed target chip blink an LED to confirm it was programmed. You know how Arduinoist love to blink LEDs. The problem is that the Attinys don’t have a digital pin 13 because they have fewer input/output pins. The challenge was to find a digital pin common to each chip that wasn't already being used for the ISP signals. Digital pin 3 became the candidate, allowing the default example Blink sketch to work by just changing the pin number.

In addition to targeting the three chip families, we also wanted to make sure different Arduinos worked as the programmer. I contributed my trusty veteran Duemilanove for testing duties to join a fresh Uno. Additionally, we added the extra four jumpers that would be needed for an Arduino mega to use the shield (it’s ISP pins are on a different header), and tried that as well. A great part of being in a group of enthusiasts was the access to a wide variety of hardware.

A design issue that required addressing for using different Arduinos was the auto reset. When the Arduino IDE goes to upload code, it pull the reset line low to get the attention of the chip to be programmed which may be banging away on the last sketch you uploaded. (This also occurs in Windows when you open serial console, causing the sketch to restart). This feature become a liability when the Arduino in question is the programmer already running a sketch we need to pass on data to the target chip, and so for certain boards, needs to be disabled. We tested several methods, and ended up using a 10uF capacitor tied to power to keep the reset line high. This still allowed the reset button on both the Arduino and the shield to still function if needed, and worked for all board, even those that didn't really need it.

Once we were convinced that schematic worked as intended, it was time for the board layout. I don’t know how most people feel about it, but I think routing a layout it is an addictive multi-dimensional logic puzzle. You have two layers, top and bottom, to work with, and need to get the signals to the correct pins with as few crossovers, or vias, as possible. Your constraints are the size of the shield, which affects the cost, and the width and spacing of the traces. To your advantage are an auto-router function and the ability to move parts where ever they will fit.

Some things to remember:
  • There are several great tutorials on the web to help. Start with SparkFun’s (
  • You are actually smarter than the autorouter, or will be after a little practice.
  • Your experience with the schematic and breadboard setup should give you a feel for the most efficient way to route traces.
  • There is a lot of trial and error involved.
  • Smile, because even though you are frustrated, you are learning something new!

My experience with routing has let me to the following method:
  • Place the parts logically based on what you know from the schematic and breadboard layout.
  • Try the auto-router to see what it does and where it fails.
  • Look at the unrouted traces to see where part placement or rotation may be beneficial.
  • Rinse (undo) and repeat.
  • Once the placement looks good, start with the most important signals like power and route them manually.
  • Route any obviously symmetrical or repeating signals to your satisfaction. The auto-router will just spaghetti them without mercy.
  • Load you board-house’s design rules first thing and check often. The further you get down the layout road, the more painful it gets to move things around.
  • If you get stuck, save and let the auto-router have a crack at it.
  • If you are really stuck, you either need more layout room (a bigger board) or better part placement. Rip it all up and start over.

Physical Layout
Once you have the board routed, it is time for a reality check. In hindsight, perhaps we should have done that prior to routing! We printed the board out at 1:1, taped it to a piece of cardboard, and use a thumbtack to “drill” holes. Once we placed the components, we could see what our project looked like in “user space”. In our case, the physical layout showed we needed to move a capacitor and bring the reset switch closer to the edge so my fat fingers could hit it reliably it. We decided we were O.K. with a little overhang on the ZIF socket since it was over the main board. Time to ship off the design files to a board manufacturer and wait. This was the time to order the parts we did not already have on hand during prototyping.
We used a company called OSH Park to manufacture the boards. They require a minimum order of three boards, which worked out perfect since there were three of us working on this. There was no setup fee, and shipping was included, so each board cost less than $7, which is an amazing bargain if you have ever tried to make your own. I have also used Sparkfun’s board-making service BatchPCB with great results.

After all the effort that went into getting the breadboard version working, making the shield was a snap and took only a few minutes. All those loose wires vanish into two invisible layers on the board, and soldering make sure that the components don’t fall out every time you move it! Then it was just a matter of testing it on all the Arduino versions and using all the target chips. The only real design issue that surfaced was that the jumper headers were too close to the ZIF to make removing and inserting them easy. A small pull-tab of Tyvek solved that problem.

Share it with the word!
[You are here] It worked. We met our goals. It was fun learning, and we each had very nice programming boards to help with future Attiny projects. What now? In the spirit of open source, and being proud of our work, it was only natural to share what we had done with others.

My first attempt at an open source project five years ago, while generating a lot of interest, was very hard to replicate (see I made the circuit boards by hand, and the chips required a dedicated programmer and a difficult to set up tool-chain. I know of only one other person who tried to replicate my work. Nowadays, the inexpensive and easy to use board manufactures like OSH Park take care of the circuit boards, and using the Arduino IDE and TinyCore libraries take care of the tool-chain. And as for the AVR programmer, well, we just made it!

The only way we could make this project any easier for someone to replicate is to make it into a kit. Parts come from several different places, which adds shipping costs. Buying parts in ones and two cost significantly more than in bulk. Buying three of a circuit boards doesn't help much when you are making just one for yourself. What if we put it all together in a kit? At the quantity of 50 kits, overall price of the components drops nearly 40%! Imagine at the scale of 1000s. No wonder they are able to do Raspberry Pis in lots of 100,000 at $35 each!

Unfortunately, the cost of putting 50 kits together is a bit of a barrier to us in the same way that having to pay for three boards might be a barrier to you. We have to sell a majority of the kits to keep from losing money, so it is a bit of a risk. Or is it? Just as design tools have gotten easier, and board-manufacturing cheaper, putting a small project like ours in to production has gotten a step up through new services like! We are able to put our design out there for pre-orders to see if there is enough demand to justify us spending the money and making the kits. That, perhaps, will be an article for another day.

We copied a lot of people’s ideas and used a lot of people’s hard work. It is easy to forget that. Think of all the time and effort that goes into large open source projects like Arduino, let alone the smaller electronic projects that we studied. All these people were willing to share in the hopes that someone would take it farther. Now it is our turn. In addition to just making the kits available, we are posting our designs as well. Someone is going to learn something from them, even if it is just “how not to do it”, and perhaps make something even cooler. And hopefully, they’ll share it as well so we can see!

Arduino Beyond the Blink: How Fast is Fast?

Arduino's "blink" sketch has introduced a lot of people to the world of programmable microcontrollers, but where do you go from there? A simple 555 circuit can blink an LED, so why did we pay $35 to have an 8-bit computer do it? Let us investigate a bit about how fast our eyes, ears, and brain are compared to silicon transistors and LEDs.

In addition to the LED, let's add some input so we can vary the LED speed. Attach a potentiometer to ground, pin A1, and VCC like shown in the diagram.

Load and run the following sketch:

LED attached to D13
Potentiometer attached to A1

int sensorPin = A1;   // potentiometer connected analog pin 1          
int ledPin = 13;      // LED is connected to digital pin 13
long lastPrint;       // variable to track how often to print

void setup()
{// this function runs once when the sketch starts up
  Serial.begin(9600); // so we can talk back to the computer
  pinMode(ledPin, OUTPUT);
  lastPrint = millis(); // time in ms since reset

void loop()
{ // this function runs repeatedly after setup() finishes
  int sensorValue = analogRead(sensorPin); // get 10-bit reading  
  digitalWrite(ledPin, HIGH);              // Turn the LED on
  delay(sensorValue);                      // Pause for sensorValue in ms
  digitalWrite(ledPin, LOW);               // Turn the LED off
  delay(sensorValue);                      // Pause for sensorValue in ms
  if((millis() - lastPrint) > 1000){// only print once a second
    lastPrint = millis();

You should be able to open the Serial Monitor () and see how long the delay is and change it with the potentiometer.  Here are some questions:
  • What is the range of sensorValue
  • How many bits would it take to represent these values?
  • What is the shortest sensor value that you can still see the blinking?
Your eye can detect changes somewhere in the 10 - 20 ms range. That seems to be limited by how fast the rods and cone can react. I don't have a data sheet for the human eye, but there is a trick to catch much faster changes if you employ a range of receptors instead of one group. How you you do that? Just move the LED. You should be able to see blinks 10 times as fast.  Here is an RGB LED spinning on a piece of thread while cycling at 1 ms.

So how fast can the Arduino cycle the LED? It is clocked at 16 MHz, which means it executes 16 million instructions per second, but how many instructions does it take take to turn the LED on and off? Let's write a routine to figure it out:
void timerLoop(){
  long cycles = 100000;
  long startTime = millis();
  Serial.print("Timing 100,000 LED cycles: ");
  for(long x=0; x<cycles; x++){
    digitalWrite(ledPin, HIGH);
    digitalWrite(ledPin, LOW);
  long elapsedTime = millis() - startTime;
  Serial.println(" ms");
  Serial.print(cycles / elapsedTime);
  Serial.println(" LED cycles per millisecond!");
  Serial.print("or ");
  Serial.print(cycles / elapsedTime * 1000);
  Serial.println(" per second.");
I'm measuring 112 on/off cycles per milliseconds. That has us talking about 9 microseconds per on/off cycle. Notice we've gone from milliseconds to microseconds. That is a jump of 1000 times or three orders of magnitude. (We are going faster, so shouldn't it be orders of "minitude"?) So at 16 million instructions per second, in 9 microseconds 144 instructions would execute. That seems like a lot to just turn an LED on and off, but that is part of the overhead the Arduino libraries and the beautiful simplicity the digitalWrite() function provides. If you needed it faster, you could write it in assembly language, but it is already several orders of "minitude" faster than your eye so why bother! That, and it would be nearly impossible to read or debug the code.

Tune in next time and we'll add a button and test the eye/hand reaction time.

MineCraft Paper Craft

A couple of the Cubscouts in my Den are big MineCraft fans. We've gotten snowed in recently, so here is a project to work on while they are warming up after building the snow fort.

Just print them out on 8.5 x 11" cardstock use scissors and white glue to put them together.

Everyone knows these guys always come in pairs, so here is his companion:

And then upload it here to get the printout: