effluvia of a scattered mind

Ubuntu 11.10/Gnome 3.0: Surviving the transition!

2012-01-31T10:01:00.000-08:00

I've had significant issues with the new Ubuntu GUI and Gnome 3.0; ranging from irritations (difficulty to create launchers) to bugs (mouse stops responding). If you are googling around I'm sure you've seen the near universal cry of dismay. If there is one message to send Canonical (if any of you ever read this posting) it would be that while its a great idea to "dumb down" the interface so a single GUI will work between your desktop and touch machines, you can't disable the advantages available through a mouse interface!

Anyway, here is what I did to make it workable. These are mostly culled from various web sources; they are not my original work.

1. Install Linux Mint http://www.linuxmint.com/ instead. This is a "downstream" distribution from Ubuntu (i.e. its a customized Ubuntu) so you won't be moving that far from what is familiar. But you will get a Gnome 3 customized for people who preferred Gnome 2.

2. Enable all apps to show up in the "Startup Applications":

sudo sed -i 's/NoDisplay=true/NoDisplay=false/g' /etc/xdg/autostart/*.desktop

3. Put most "window" buttons on the left, but "close" on the right side:

gconftool-2 -s -t string /desktop/gnome/shell/windows/button_layout "menu,maximize,minimize:close"

4. Add the ability to right click on the desktop to create a new launcher (launchers are icons that run programs):

echo "gnome-desktop-item-edit ~/Desktop/ --create-new" > ~/.gnome2/nautilus-scripts/Create\ New\ Launcher
chmod a+x ~/.gnome2/nautilus-scripts/Create\ New\ Launcher

5. Right click on the desktop->Scripts->Create New Launcher to create launchers for your key programs.

5a. Here's a launcher I use to automatically connect into multiple virtual machines:

/usr/bin/gnome-terminal --window --command "ssh -X -A root@192.168.1.200" --tab --command "ssh -X -A root@192.168.1.201" --tab --command "ssh -X -A root@192.168.1.202" --tab --command "ssh -X -A root@192.168.1.203" --tab --command "ssh -X -A root@192.168.1.204"

5b. You can use the same thing to log in a multiple users.

/usr/bin/gnome-terminal --window --command "ssh -X -A me@localhost" --tab --command "ssh -X -A minime@localhost" --tab --command "ssh -X -A maxime@localhost"

6. Multiple gmail/firefox sessions. Even if you spawn firefox from different users to use multiple gmail accounts, it outsmarts you by checking the desktop to see whether firefox is already running. If it is it just uses that program. To defeat that, run firefox like this "firefox --no-remote". I made a simple script called 'ff':

sudo -i
cd /usr/bin
echo "firefox --no-remote" > ff
chmod a+x ff

7. Head on over to menu->other->advanced settings->desktop and turn everything "on". You might want to peruse the other settings as well...

8. Install the gnome config editor and really start tweaking:
apt-get -y install gconf-editor

8a. Multi-monitor workspace "bug" -- the workspace does not change on one monitor
go to: gconf-editor -> /desktop/gnome/shell/windows/workspaces_only_on_primary and uncheck it.

Important keys:

ALT-F2: then "r" restarts the desktop without losing your windows

That's it! Your desktop should now be usable! :-)

Please post any other tricks you discover. Especially:

1. How do I add launchers to the top/bottom bar?

2. How do I specify the total number of workspaces (not have them be dynamically created)?

Transdescending Arduino: Going cheap and small

2012-01-27T19:23:00.000-08:00

The Arduino is great; a microController you can actually do something with for 30 bucks! Ok, but your train layout needs 5 of them ($150), your home sensor network needs 10 + $40 xbee cards (clocking in at $700!). Or the mere fact that your want to KEEP your projects around means that you get nailed for 30 bucks over and over again.

But wait a second... the AVR328p is a 3 dollar chip! And the AVR ATMega48 (pin compatible but with a LOT less space) is 2 bucks (for 10)! And if your requirements are extremely minimal, there's the ATTINY13 which comes in as little as 60 cents -- but in an inconvenient package (you'll be better off spending another 4 dimes and getting one for 1 buck).

Choosing Parts

The first step is getting your part. This can be tricky because paradoxically there are both too many parts and too few. By "too many" I mean is that since there are literally hundreds of AVR parts to choose from, it can be hard to pick what you need. So your first stop should be the Atmel "parametric" selector here (most vendors have parametric selectors on their web sites but they can be hard to find). I've already selected the basic stuff in that link (like 8 bit AVR) but there are still hundreds of possibilities.

Another excellent way to narrow it down is to pick choices that other people have already used. These can be found by looking in the Arduino or Adafruit forums, www.avrfreaks.net, or more eye candy sites like www.hackaday.com.

Or pick from these popular choices: ATMEGA328 (Uno), ATMEGA168 (like Uno but 16k ram), ATMEGA48 (Uno, 4k RAM). ATTINY24, ATTINY13 (no serial), ATTINY2313 (a "tiny" with serial).

Navigating Parts Suppliers

Once you've found some candidates, you'll want to head over to www.findchips.com to see if there are any for sale in a package you can handle. This is where you may find there are "too few" parts -- that awesome device perfect for your job is not stocked and only available in 1000 units! :-(

So you'll need to do a bit of back-and-forth between the parametric table and the marketplaces to find what you need.

Another choice is to head directly to www.digikey.com which has a large selection and a great interface. Basically, type your part name prefix in (like ATTINY, or ATTINY13). You should see a product selector. Click "in stock" and then refresh. Then head over to the "price" column (far right), click on the triangles, and enter ascending sort with 10 units (never buy just one or 2, if you do Murphy's law guarantees you'll burn them out!) Personally, I find that digikey has the best prices on average, but other suppliers sometimes sell particular parts for significantly cheaper.

Once you've picked out your part, pop up the datasheet just to make sure the parametric table was correct and to verify that it is "in-system programmable" -- or ICSP (in-circuit-serial-programming). I think all AVRs have this feature but you never know... Its also good if they have an internal oscillator so you don't have to hook up a crystal. Besides it will be nerd-enhancing for you to actually read (skim) the datasheet; you'll learn valuable data mining skills :-).

Other Stuff

If you bought a thru-hole version, you'll want a breadboard to solder it on to (or use a solderless breadboard). If you bought a SMT chip (congrats!), you'll need to either buy or make a break-out board and to learn how to bake surface mount parts.

Next, you need a device programmer. You can actually use your Arduino as described here http://arduino.cc/en/Tutorial/ArduinoISP, or buy a standalone one like the one I use: http://www.ladyada.net/make/usbtinyisp/. You'll also want the standard electronics stuff; a bunch of jumper wires, a soldering iron, a multimeter.

Ok, it will take a few days for the stuff to arrive... when it does we will hook up the chip, write a simple program and upload it.

Using The Chips

Ok, everything arrived? Next let's hook it up!

The first step is to mount the chip into a solderless (or soldered) breadboard. If you bought a SMT chip, you'll have to first bake it onto a breakout board.

Next, take a look at the datasheet of your chip. Right at the top of AVR datasheets you'll see a section called "Pin Configuration" that shows the physical layout of the chips. Here is what the ATMEGA 328/168/88/48 PDIP package looks like:

And the ATTINY13:

And finally the ATTINY24:

On all chips, we have power and ground (yellow), reset (orange) and a SPI programming interface (red). When the chip is in reset, the SPI interface can be used to upload programs.

Now take a look at the Arduino ICSP header:

This is what the 6 pins look like coming into the Arduino's ICSP port. Your programmer should have the equivalent pins (but see caveat below). These are the same pins located on each of the chips. So, hook 'em up (connect the same named pin together)!

Some caveats: If you are using the ArduinoISP project to program your chip, don't hook the "reset" lines together. The "reset" in the Arduino's ICSP header will reset the Arduino. You want to hook a general purpose IO to the chip's reset so that the ArduinoISP can put it into reset. For more details: http://arduino.cc/en/Tutorial/ArduinoISP

The ICSP header is symmetrical, (and the "top" view vs the "bottom" view will mirror the pins) so if you can't tell where pin 1 is, use a multimeter to look for the 5 volt difference across the power and ground pins (2 & 6). That way you can be sure you've found the correct orientation!

Ok, so here I've hooked my USBtinyISP up to a MEGA48. I've also added a resistor and LED in series connecting to one of the pins so I can try the "hello world" of embedded programming -- blinking a LED.

This might be hard to make out, because I can't focus on both the programming header and the chip... its just the foreground center chip, and connections, the other stuff is just that -- other stuff :-).

Ok, next step is to use avrdude to verify that we can talk to the chip!

DIY PCB SMT Breakout board fabrication: Results

2012-01-20T18:38:00.000-08:00

In the last posting I described how I made a few PCBs to act as SMT breakouts. I've discovered that this seems to be a pretty ideal job for DIY PCB work! To mount thru-hole stuff, you need the hole -- and that means hand drilling... but a small breakout board can be done on a single side, and its possible to use .1" Right Angle headers soldered onto an oval thru-hole pad so you don't even need to drill the hole for the breakout header.

In my last posting I finished with the circuit board ironed onto the blank PCB. It turns out that the final steps are quite easy. First you get some etchant. I used ferric chloride from Radio Shack, but I wish I had used muriatic acid and hydrogen peroxide as it seems slightly better for the environment. I poured the etchant in a leftover food container (now forever dedicated to PCB etching) and left the boards in for about 30 minutes. I used a twisted wire hanger to keep my fingers out of the etchant:

Then rinse the board in lots of water, and leave the tap running to dilute any drips of etchant solution that go down your drain. When you're done, put the top on the container (make sure it seals!) and store for next time.

To remove the laser printer toner, I tried a few paint removers, liquid sanders, etc. Nothing really worked. It turns out that Acetone (nail polish remover) is required. Its available in the paint section of hardware stores, and is absolutely amazing at the job. 2 swipes with a rag daubed in Acetone cleans the toner like wiping milk off a table!

Next I soldered the parts on to the PCBs using a toaster oven. I was concerned that the lack of a solder mask might make the solder bridge across PCB pads because its impossible to keep the solder paste onto pads. In fact, I don't even bother, I just paint a thin line down across all the pads in a row (see my earlier post on DIY SMT soldering techniques here). But in fact, the solder balled up nicely as you can see here:

These are tiny SOIC-8 and SOT-23/5 parts. I left the chip off the rightmost SOT-23/5 to see how well the solder wicked onto the pads. Before putting it in the oven, the space between all the pads was completely covered with solder paste -- the wicking works great!

I cut some of these boards with a hobbiest bandsaw, like you can get for $200 at Home Depot. But its even easier to cut them by scoring the front an back with a ruler and then breaking them against the edge of table (preferably metal). Place something hard (like a metal or hardwood block) on top, grab the protruding board with pliers and then crack it by rotating the pliers downwards quickly.

One surprise was how fine a pitch may be possible. I had originally "designed" this board for professional fabrication and I accidentally left some tiny lettering on the board. Amazingly, it transferred to the PCB perfectly well! Here is a close up:

As you can see, by the ballpoint pen I put in for scale, the height of these letters is less then one millimeter! I will need to go back to the file to check, but I'll bet that the line width is just a few mils (thousandths of an inch) wide. Many professional PCB houses won't do less then 8mils! Of course, they require repeatability across hundreds of large boards -- my goal is to get a single small breakout board out of a panel with a half dozen attempts.

So basically, if the transfer works without smudging or distortion you can get amazingly fine detail. And from my limited experience it does tend to do so reliably across portions of the board that can be 2 square inches in size. This makes me believe that it may be possible to home fabricate chip-scale BGA breakout boards -- at least for small BGA packages. I have not discovered anyone who has tried it yet; so I think that will be my next experiment (as soon as I find a "fun" BGA chip)!

EDIT: Here's a photo of the SOIC8 installed on a PCB. I think that its better to put all the pins in a single row, rather then the DIP configuration because that gives you the other side of the breakout board to use to make your circuit!

Also note that no drilling is needed! Get right angle breakaway headers and then solder them to the (undrilled) thru hole pad.

EDIT 2: Here is a photo of a SOT-363 chip with a 2 mil circle indicating pin 1. To get an idea of the size, the circle is indicated by the lead of a standard 1/4 watt resistor. As you can see the 2 mil line width was etched perfectly!

DIY PCB fabrication; Breakout Board Toner Transfer Experiments

2012-01-13T18:47:00.000-08:00

Using modern components in PCB circuit board design essentially requires the use of small surface mount packages. Testing these components can be costly and time consuming if you need to have a break-out-board professionally fabricated for every component. It is possible to hand-solder extremely thin magnet wire to individual leads of a SMT package but that is a very painstaking process.

It would be much easier if individual PCBs could be hand-fabricated for the task. I dug around on the web and DIY PCB fabrication for very small parts seems quite tricky; most people use home PCBs to make larger circuits out of thru-hole parts.

However, even if multi-chip SMT designs are not feasible, it would be very valuable to be able to rapidly fabricate single chip breakout boards for SMT parts (for noobies: a breakout board is a PCB that simply brings all the pins in a SMT chip to a male header that can be plugged into a solderless breadboard). Especially small parts; if you are putting a TQFP-144 on you board there are places where you can buy breakouts. And there are fewer footprints so you could build up a "library" of breakouts. But there are tons of different packages for components ranging from 2 to 32 pins!

Making these small-pin count PCBs might be feasible (where large SMT designs are not) for several reasons. First, the PCB will be quite small, allowing you to panel multiples "tries" onto a single DIY board. You only need one success! Second, the routing will be pretty short and simple. If the pins are placed on either side of the chip the routes will be short and on a single side (so you can try the same circuit on both sides!). Finally, I think that right angle .1" headers could be used in place of straight pins, so the final board would not need to be drilled. This will save a lot of time (and painstaking work).

Here are my first attempts (ever) to use the toner transfer method to put a mask on copper PCBs. I panelized 6 SOIC-8 and 6 SOT-23/5 breakout boards onto a space about 2x3 inches:

And the back side attempts:

The basic methodology (for people who are reading this as an instructable) is to:
1. Remove all layers of your PCB except routes, pads and vias. Export it as an image (monochrome, 600 dpi). Load it up in a graphics editor (gimp), reverse the color, and horizontally mirror it.

2. Next, use a laser printer to print it onto some kind of paper. You want a paper with unique, generally undesirable properties; essentially the toner should just barely stick and it should dissolve readily in water. Four types are commonly suggested:
A) glossy paper ripped from a cheap magazine/catalog
B) glossy photo paper
C) sticker backing paper (pull the stickers off and print on the shiny side)
D) speciality PCB toner transfer paper.

3. "clean" a blank PCB with steel wool, and then iron the toner on by placing the iron at its highest setting on the paper (which is on the PCB) for about a minute. You can't move the paper relative to the PCB so some masking tape on the corners might help. Also don't push down hard, and don't move the iron around much.

4. Soak the PCB in water for about 5 minutes and then rub the paper off. You can rub quite hard; if it toner comes off then it did not transfer.

The PCB on the upper left of image 1 was made with glossy photo paper. This paper essentially did not work for me; it would glue itself to the iron and then separate from the PCB or pick it up as well. The toner was still melted at this point so most of it stayed with the paper.

The upper right image 1 board shows what happens when you push down too hard. Pressure on the melted toner caused it to spread out. So don't do that!! :-) The bottom left of image 1 was ironed on for several minutes. It got so hot it changed the copper color -- additionally the paper was extremely hard to remove. Oops! The last photo on image 1 was again done with glossy photo paper. The paper still lifted off with the iron but amazingly it left a perfect transfer in the middle! Unfortunately I doubt its repeatable.

I left board on photo 2 clean to show how the PCB should look after it has been rubbed by the steel wool. The other 3 boards on the bottom image show transfers with the sticker-backing paper with ironing times of 30seconds, 1 minute, and 1:30. I'm sure you can see which is which since they show more toner sticking. In fact, the last image has perfect transfers of 9 out of the 12 circuits! The only miss transfers are on the top of the PCB. Clearly I did not get that portion hot enough (in fact, I think that it may have been under the steam holes of the iron). Removal of the paper was pretty quick under hot water; about 5 minutes (so clearly the boards were not under the iron for too long). But the paper did not "pill" up like other web postings suggest; it mostly peeled off. After ironing, the paper it was a little browned in spots but not significantly.

Like any other craft there is clearly a bit of skill and practice required. And some experimentation is required to become familiar with your particular tools. However, so far this looks like a pretty feasible method for breakout board fabrication. In the next installment I will attempt to etch the boards and solder the parts on!

Ubuntu 11.10 64bit CadSoft Eagle 6.0.0 installation pain

2012-01-10T06:48:00.000-08:00

I think Eagle 6 was rushed to market :-). It resists installation on the most popular Linux distros, and when you do finally get it working it pops up with an "I'm sorry, there's a nasty bug" dialog. But Kudos to Cadsoft for admitting it!!!

Here are my notes on the installation. I think I might be missing a step or two so if you follow these and run into issues, please post a comment!!!

These instructions should also mostly work in 32 bit Linux distros, but you won't need to install as much (remove the packages with "i386", or "32" in their names).

Step 1: Prep Ubuntu for 32 bit compilation

sudo apt-get install build-essential lib32z1-dev g++-multilib gcc-multilib ia32-libs libssl1.0.0 libssl1.0.0:i386 libjpeg8 libjpeg8:i386

Next, get and install libpng14 from source:

http://sourceforge.net/projects/libpng/files/libpng14/1.4.8/libpng-1.4.8.tar.xz/download

tar xvf libpng-1.4.8*
cd libpng-*
./configure CFLAGS=-m32 --prefix=/
make check
sudo make install

32 bit distros should remove "CFLAGS=-m32" and just use this line instead:
./configure --prefix=/

[Troubleshooting] If you get the error: "configure: error: C compiler cannot create executables" check the config.log file. If the problem is: "/usr/bin/ld: cannot find crt1.o: No such file or directory" then you did not install g++-multilib gcc-multilib.

If you get: "configure: error: zlib not installed" you did not install lib32z1-dev

Now install Eagle:

chmod a+x eagle-lin*
sudo ./eagle-lin*

Good Luck and keep building OSHW!!!

Open Hardware Journal

2011-11-02T17:18:00.000-07:00

Bruce Perens (who did Busybox and Debian as well as defining "Open Source") has created an Open Hardware Journal (http://openhardware.org/journal/). Check out the first issue, I've got two articles in it! Ok ok, probably he needed more submissions which is why my stuff made the cut :-). But hey I'll take it!

The first article "An Open Hardware Platform for USB Firmware Updates and
General USB Development" is about the USB interface on the Lightuino. I chose that topic because this interface is a cheap and tiny way to put USB in many of your projects. The interface will talk SPI to your uP or some SPI chip, or I2C (although I did not use that in the Lightuino). And it will do serial (USB CDC ACM if you need the formal acronym) or emulate an input device (USB HID). Read the article for more info, and check out my code on github here: https://github.com/gandrewstone/toastedCypressUsb

My second article "A Return To Open Devices" is about my ideas around the philosophy and driving forces behind the open hardware movement. I'm sure the people who come to open hardware do it for many different reasons; this is simply my perspective.

DIY Surface Mount Workshop

2011-09-09T15:46:00.000-07:00

A few days ago I held a workshop on do-it-yourself (aka cheap) surface mount electronics techniques at a Boston artspace/hackerspace called sprout & co (http://thesprouts.org/). This was organized through the Boston Arduino meetup group. Participants got to mount a tiny QFN-24 chip (a PCA9555 io-expander) onto a QFN breakout board and then we tested them by connecting them up to an Arduino. There was one bad chip; but once that was replaced everybody's boards worked!

Here are my notes from the workshop. If you did not attend, these notes are a good tutorial on how to get started cheaply! Also, if you'd like some of the QFN breakout boards, please contact me and I will sell you a few.

Surface Mount Tools (homemade/modified):

Toaster Oven:

Got mine from the dump. Keep it simple; you don'tneed to mod it with fancy temperature feedback like some web posts suggest.

Hot air “pencil”:

$30 used heatgun (ebay) with aluminum foil to narrow and speed the air jet. Secure the aluminum foil by wrapping steel wire around the nozzle. Shape the hole in the end by forming it around a pen with your fingers. This tool is indispensable for removing and replacing chips (rework), and works great!

Cheap plastic Mechanical Pencil:

Pencil lead solder paste onto pins;eraser dabs off too much.

PCB Vice:

You can use any clamp like this. You can probably get one for less then $10 if you look around. Just drill a hole in your desk slightly smaller then the clamp bar and stick it in upside down.
Here it is holding the boards we made, with my breadboard-to-IDE-or-RJ-45 connector in the background.

But once you do this fairly often you'll want to upgrade to a Panavise.

Soldering Iron:

You CAN use a standard cheapo wide tip soldering iron for SMT rework -- even though you can't touch just a single pin, it is sufficient to heat a single pin.

However, knockoffs of the "Hakko 936" soldering iron are pretty cheap at $50; check Amazon or ebay. And they are all you'll ever need...

Tweezers:

You use these to hand "pick-and-place" chips. Buy them from a drugstore. But don't buy the cheapest pair you can find. Buy a set that looks totally overkill for plucking nose hairs :-) -- like they were milled out of a block of metal.

Magnifying glass/bright light:

You may need these to peek at the board as it is cooking, and for rework. I'm sure you can do it on the cheap. I have a "helping hands" for the glass:

Available on ebay for 6 bucks. And the clips are actually great for other soldering jobs, like joining 2 wires. For the bright light, any portable (plug in) work light will work fine (try home depot). Once you do a lot of work you may want a "swing arm magnifying glass lamp":

Supplies:

Solder wire:

Get thin rosin core solder

Solder Paste:

Solder paste are tiny balls of solder in a flux mix that is viscous like toothpaste. It can be very expensive and require refrigeration. Don't buy that. Buy this Lodestar paste from DealExtreme. It does not require refrigeration, however, as a hobbyist you should refrigerate it so it will last you forever.

Flux:

Flux is a substance that cleans your PCB and lets the solder flow better. It is also available at DealExtreme. They often mis-name it "paste" but you'll know it is flux only because it won't be grey. Get "no-clean" or "neutral PH" (its almost all like that now).

Solder Remover Braid:

This braid is necessary to remove excess solder when doing fine SMT work. Solder suckers don't work!

Step 1:

Use an oven to solder a QFN-24 part onto abreakout board.

Mix a TINY bit of solder paste and flux to about a 60/40 mix. You don't need much. Put any extra back into the container since it contains lead so its good to generate as little hazardous waste as possible...

Too much paste and the solder willnot wick onto the pads (it will stay on the non-metal parts of the PCB or create bridges between pads -- "pads" are the metal parts of the PCB that you are trying to solder the chip's wires "pins" to)

Too much flux and the pins won't besoldered.

Apply with your mechanical pencil (click out the lead). Fortiny QFN leads, just draw your pencil straight across all the leads. That is, cover the entire surface including between theleads. This is important so let me emphasize: Don't try to keep the paste out of the 6mil space between the leads! That is impossible & when heated the flux will cause the paste to flow to the pads anyway.

But if there is a center square pad, use the pencil todraw around that pad to clean any paste that would bridge the center pad to a lead (it isvery hard to fix that issue).

You need to apply a thin layer. You should be able to see the shape of the pads under the paste, but they should be obscured. But if the paste goes on clear, with just a few "dirty" spots you have too much flux in your mix.

This photo shows 6 boards with solder paste on them -- this wasn't part of the workshop, I just grabbed this photo from my archives. Perhaps the paste is on a little thick... but as you can see, no attempt was made to keep the paste away from the spaces between the pads.

Next, put the chip on with tweezers. Positioning is not critical; you can be off by a half-pin in any direction. When hot, the chip will actually float on the flux layer and surface tension will actually cause the chip to be sucked onto the pads! But if you are off by more then a half-pin, the chip might be sucked onto the wrong set of pads.

Now bake your board. You need to bake the board in a particular fashion, but its not rocket science.

Here is an example provided by Kester paste. It works fine for any paste:

Basically, you want to raise the board to 150C in a minute or two. Then wait for another minute or two so the entire board gets to that heat. This bakes out any water and lets everything expand (if you chip pops like a firecracker its ruined. You have too much water in those chips and need to bake the rest at low heat for hours to evaporate it out; its only ever happened once to me).

Next, you bring the heat up to a max of 220-240C rapidly to melt all the solder paste. Excessive exposure to this heat can harm the chips or melt plastic parts so you want to keep this brief. At this point, use your magnifying glass and a bright light to watch the paste on the board. It will go from grey to bright shiny silver when melted (bubbling is just the flux moving around). Wait 10 more seconds after you see no more grey to make sure solder you can't see also melts. Then turn the oven off.

Now you have a choice. You can either wait with the oven door closed so the oven cools down slowly (as shown on the heat profile). Cooling slowly will mean there are fewer mechanical stresses on the board.

Or if you see any problems, you can open the oven door, pull out the tray andreposition “tombstone” (sticking up) resistors and caps. Also if a chip is out of alignment (off by one pin for example), you can “tap”the chip to make it position itself! When doing multiple bigger boards, you'll often find a few issues.

I'd imagine that while this cools the board faster, it is probably still less stressful then heating a portion of the board with your "air pencil". That is the only other way to reposition chips.

Debugging

Now that your board is baked and cooled, you need to visually inspect it. Look for bridges (2 pins connected) and unsoldered pins. A bridge will look more shiny then the other pins since it is a bigger solder blob. Unsoldered pins will look darker.

Unsoldered:

Apply a tiny bit of paste to solder pins. Heat the pin (and perhaps nearby pins) with an iron to melt the solder. Often you'll have added too much paste, so now check for bridges.

Bridges:

Use flux to cause the bridge to flow onto nearby pads/pins. This only works if the bridge is not caused by too much solder.

Use copper solder remover wire (braid) toremove solder. I guess this is often misused. This is how you do it:

Touch braid to you can of flux to get a tiny bit on it)

Put the braid onto the bridge part so it complete covers it (and probably a bunch more pins).

Heat the braid by using the iron to pressit into the bridge where you want to remove the solder.

The braid won't work if its not hot!!! So heat it and cause its heat to melt the solder.

If the braid is at all silver, clip it and throw that part away; it has already sucked up solder.

Speed solder headers

Next we need to solder long headers onto the board. There is a fast technique to do a row of pins that I will show. Eventually you should be able to do about a pin per second or two.

First, clip/break the pin header so it contains the right number of pins.
Next put the headers in the solderless breadboard; and put the PCB on top. This gets themaligned correctly. Use the PCB to seat them into the breadboard. This will keep the board steady as you solder it.

Now its often good to solder the ends to make sure the PCB stays firmly seated against the pin header, but as you get better you can skip this step.

Now use the speed solder technique to do the rest. Here's a video:

Here I am doing pins on both sides of the iron, so heating 6 pins simultaneously. But you should stick with one side for now.

Use an overhand grip on the iron so it can be placed flush along the pins.

Heat 3 pins simultaneously.

Preheat pin -- using iron tip
Middle pin -- focus on soldering it
3rd pin -- continue to heat to make a good solder joint

I noticed most people using not nearly enough solder. Feed the solder so fast that there is a large constant blob of solder on the iron. This solder blob is essential to transfer heat to the pins. As you push your iron across the pins it will actually clean up this excess solder (if not, your iron is too cold, or you aren't using rosin core solder). Actually you may end up with a few bridges, but those are easy (and quick) to fix once the job is done. Just hold a "dry" iron against the bridge and it should grab the excess. And look for any holes you missed; as a beginner you'll have one or two!

Testing: Hook up the breakout board

Read the spec to hook up the board. Really. This is a great exercise and very important to get correct. Because if you are trying a new PCB, new software, and a new chip you want to make sure you get something right! :-) But ok, Ryan Feeney was kind enough to help you out with this image:

In this image, GND are the blue rows on both sides and 5v are the red ones (connect them to GND and 5v on your Arduino).

One other trick; if you don't have a handy 3.3v power supply, you can use a red LED to reduce 5v to 3.3v. This will work up to about 20mA; beyond that your LED will burn out so use multiples!

Testing: The sample sketch
The sketch I used is located at: http://i2cdevices.svn.sourceforge.net/viewvc/i2cdevices/latest/ioexpander/pca9555/pca9555.pde?revision=1
Someday I might actually put other i2c devices in there too! :-)
It should blink the LED.

Hot air rework exercise

Some of you got to do or see this, because we had a dead chip.

In this exercise we'll use the hot air "pencil" to remove a chip and then replace it with a new one.

First, use aluminum foil and metal boxes to cover and protect other chips(and plastic headers). Well, there is nothing really to protect in the breakout board except for the plastic vise jaws -- but for a "real" board you'll need this.

Heat the chip with slow motions of the heat gun. When the solder on the edges goes shiny, pluck/knock it off with tweezers.

If there is a lot of solder on the pads then clean it with flux and solder remover. Put a little more paste on the pads.
Touch the new chip in the flux can to just get a TINY bit of flux on its pads

Place the new chip right near, but not on, the pads. This will cause the chip to heat up with the pads. The chip's leads have to be hot enough to melt the solder or the solder won't stick to it! Its the SMT equivalent of a "cold" solder joint.

Reheat with the hot air "pencil". When the solder melts (it goes shiny) it should wick to the pads so there is no bridges. If there are bridges you have too much solder or not enough flux. When it wicks correctly, tap the chip with tweezers to move it into place. You should see it "snap" or "pop" into place as the surface tension of each pad/lead pulls the chip. Heat for maybe 10 more seconds to make sure all the chip's leads were hot enough and then you are done!

Thanks! Please go forth and build open source hardware!!

RSD GameMaker

2011-06-16T17:49:00.000-07:00

Recreational Software Designs GameMaker product was a program that ran on the IBM PC machines around 1991-1995, sold in the USA, UK and Korea. I recently became aware of some efforts by the community at diygamer, specifically Eric-Jon to gather information about the program. He has written 20 or so posts about games that users created, see http://www.diygamer.com/author/eric/, and also created a wiki that attempts to capture the history about the community at
http://www.aderack.com/game-maker/index.php?title=Main_Page.

I was the creator and major author of the software, and was helped by my father who handled most business issues, my brother who also did some coding, and my mother who did GUI testing and made some games. We also had a friend of my father who graciously spent a few weekends sitting with me giving guidance (Thanks Pete!)

It was basically a toolkit that let you create your own platform-style (of course we did not call it that back then!) games.

As the creator of a very small piece of history (but one that seems to have a major effect on those who used it well, spawning passions and careers around programming, graphics, and games -- Google "RSD GameMaker"), I shall indulge in a very small soapbox so you can hear my thoughts and ramblings on the subject :-).

I think perhaps that in retrospect GameMaker's history may be interesting for a few reasons.

The first Game Creation Engine?

First of all, it obviously was the "diygamer" tool of that time, so it anticipated the thriving community we have today with countless game engines, web sites and indie game companies. I hear that it was preceded by a game maker on the Commodore machine, but I had/still have no knowledge of that software. As far as I knew, we were the first game engine in existence and we allowed games to be built with absolutely no programming (and ran up against the limitations that imposed as well)! But in the interest of complete disclosure, I believe that at that time professional game companies were also buying game engines for major $ to aid in game development. Very little information is available about these professional engines since at that time -- a time of game-feature "brinkmanship" -- the information was closely held.

Anticipating Creative Commons and the Remix Culture

Second, we shipped the software with a bunch of sample games and encouraged users to borrow and reuse our content. We also worked with a BBS owner (bulletin board system -- it was a precursor to the internet) to have an "official" community sharing repository. Also, I deliberately (in fact I remember an argument about it) made no effort to protect a game's content -- anyone could load up anyone else's game in the editors. My feeling was that if you were sophisticated enough to build a game that really needed protection, you could wrap it in your own encrypted .zip file or something. This philosophy emerged from knowledge of shareware licenses, but AFAIK is probably the first adaptation of the philosophy for content, not code. Today, the "creative commons" has standard licenses covering all manner of content.

And a lot of people did reuse our stuff (and other game authors)! In that way it anticipated today's emerging remix culture. If I remember correctly (and I may not), I was the one who decided to share all of the content shipped on our CD and disks while my father should receive credit for encouraging the community, through user letters (yes back then we got HANDWRITTEN letters, I still have a huge stack of them), the community BBS, and the GameMaker Exchange (which was sort of a "mail us your game & we'll mail it to other people" thing). But of course as a family company these decisions were often made around the dinner table. We also decided to buy (and beg) some games from our best users and ship them with the 3.0 version of our product in a "remixable" license.

Teen Hackers!

Third it was really a major piece of software built by teenagers, mostly for teenagers. This probably makes it pretty unique, if not completely unique. It consisted of 16000 lines of "c" code, 2000 lines of hard core x86 assembler, and 1000 lines of C++ (versions 1 & 2 predated the emergence of C++). So about 20000 lines of code total. 'Sloccount' (a Linux software line counting program) puts this at 4.5 man-years of effort with a $600000 price tag (assuming developer salary $50k 2010 dollars). But we did it during high school and college.

Sure we had adult supervision (and funding and support -- I can't overemphasise how supportive my parents were!!!), but at the same time we wrote all the code and essentially came up with the content entirely ourselves (with our user's input of course). If GameMaker somehow fast-forwarded itself to 2010, it likely would have been entirely teenager-driven. However, in the internetless world of the '90's there were countless costs -- lots of expensive advertising, CDs to print (sorry no CD burners), boxes and user manuals made, mailers, and on and on. I remain amazed that my parents put that kind of cash at risk for this effort.

Breathing Life into the DIY Culture

GameMaker was part of the DIY and programming culture of the 90's. I would love to see what my users are doing now. You have to be a certain kind of person to look through a magazine full of ads for instant-gratification twitch games and pick the software that makes you WORK hard. I would guess that we managed to pre-select the most creative individuals; a feat that our educational system has a very hard time doing.

Also I think that it is probably possible to trace a certain (changing) subset of the population throughout US history. Call them tinkerers, creative minds -- just people who like to do their own thing. And I am proud to have been an enabler of this culture in the 90's.

I see it in automobiles and phone systems in the 50s and 60s to the transistor (hi-fi) radio kits (hobbiest electronics), to the early garage build-your-own computers of the mid-70s and early 80s, the software of the mid-80s to mid-90s, all the web software, blogging etc from the mid-90s to sometime in the 2000s, and finally the emerging custom open-source hardware culture of the 2010s (www.arduino.cc, www.adafruit.com, and my own www.toastedcircuits.com). I fully expect that 2020 will see ubiquituous desktop manufacturing with communities not focused on building desktop manufacturing machines (as exists today) but focused on what can be made. By 2050 we'll probably be designing our own plants and animals, probably with an incompatible biology for obvious reasons.

Software Archaeology

Finally, it is an interesting piece of computer archaeology as its "heyday" fortuitously happened at the end of the prehistoric times (as people years from now will see these dark ages before the emergence of the global hive mind and recording device we call the internet).

What can be recovered by reaching back across the curtain? This is quite an interesting question and many scholarly articles have considered it (I have read several articles in Scientific American on this subject over the past decade for instance). These articles tend to warn against electronic media for pretty obvious reasons. Quick summary: Your grandkids find a 3.5" floppy (or CDROM) in the attic. Will they even recognise it as electronic media? How will they read it without a disk drive? Even if they manage to get the bits, will modern computers be able to run the programs, read the documents, play the movies?

Well, for GameMaker, it turns out that quite a lot is possible! You can even play the created games in a Java simulator called "DOSbox" in the wiki posted in the first paragraph of this article. For me, it was quite a trip to play games (and see the GameMaker software on Youtube) that I created 15 years ago. You results may vary. Remember, these were games built 15 years ago mostly by teenagers! Please don't go in there expecting amazing stuff -- go in there amazed that these kids could put together this stuff at all! But if you hunt for gems of creativity I promise you'll find some.

Software Obscurity

And what did I do after GameMaker? Have I been washing windows for 20 years? No I've been writing vast quantities of code in various startup companies which have been sold for a sum total of approximately a half billion dollars. But all that code is gone. A company gets sold, the product is either canned or is successful for a few years. Then it is done. Can I get my code for the next project? No.

I have even attempted to purchase some from prior employers. No dice, price does not matter, the company is not in the business of selling its software, so its just not possible to find a manager willing to even consider the proposition. Because what if hidden in that chunk of software is something really important?

So if there ever was an argument for open source software and open source content then this is it! As engineers in corporate America (and elsewhere) we build machines for obscurity. We write novels to be read by no-one. We architect palaces of structured information that shall soon disappear.

Let's try to do that as little as possible.

G. Andrew Stone
2011

---

The next episodes of this little blog may delve in more detail about RSD and GameMaker's history, etc. Perhaps only interesting to those who actually used it.

Lattice XP2 Brevia Diamond Starter Project

2010-10-10T06:32:00.000-07:00

Its a royal PITA to specify the pinout of a 144 pin part! So there is no point to doing this more than once -- across the entire internet.

Its unfortunate that Lattice does not provide one, but their Demo project does not specify the IOs since they are not used.

In my code repository is a Diamond project that specifies all XP2 IOs as used by the Brevia board. And it sets the XP2 part up with 3 clocks, 400mhz, 50mhz, and 25mhz. Of course you can change these clock values by editing the "pll" module.

You checkout the entire project (recommended), or browse and pull down the key files to add into your own project:

top.v: the "main" verilog file

starter1.lpf: the file that places the verilog symbols onto particular pins

pll.v: autogenerated pll module that sets up the 3 clocks.

Lattice Diamond on Ubuntu 10.04 64 bit

2010-10-05T18:08:00.000-07:00

For some reason, Lattice provides its new Diamond GUI for the second most popular Linux distribution instead of Ubuntu, the most popular distribution.

Here is how to fix their mistake :-). Additionally, they only provide 32 bit binaries but I have a 64 bit system. So this how-to solves that problem as well.

Installing the IDE

Step 1: Download Diamond's .rpm located here, and apply for a license.

Step 2: Install "alien", the .rpm to .deb package converter.
sudo apt-get install alien

Step 3: install "getlibs"
This handy script will install the 32-bit version of libraries even if you are running 64-bit Ubuntu. Since Diamond is 32 bit you will have to install some 32 bit stuff.

click here for info (http://ubuntuforums.org/showthread.php?t=474790)

Step 4: Install 32 bit libraries (if on 64 bit Ubuntu)
apt-get install ia-32libs
sudo getlibs -p libmotif3

I am doing this from memory...if you run diamond (later step) and get a missing .so, please run "getlibs -l " to install that library and post a comment so I can update this HOW-TO!

Step 5: Run alien on the diamond RPM.
When the diamond RPM is downloaded, run alien on it:
alien -d diamond_1_0-base-135-i386-linux.rpm

Wait for a very long time. This will ultimately have an error and drop you back to the Linux prompt. It will not hang (be patient). However you will find that it created a subdirectory called "diamond_1_0-base-1.0" off your current directory. Everything we need is in there. I'll copy it to /usr/local so it is accessible:

sudo cp -r diamond_1_0-base-1.0/usr/local /usr/local

Step 6: Copy the license
You should have gotten a license file in your email stream from step 1.
Save that file into the diamond subdirectory: /usr/local/diamond/1.0/license/license.txt

Step 7: Run it!
/usr/local/diamond/1.0/bin/lin/diamond

if you get any missing libraries, please attempt to "getlibs" (see step 4) and post a comment here so others can benefit from your pain :-).

Installing the Lattice USB Programmer

Before you actually program your board, you'll have to install drivers for the programmer dongle.

The Lattice USB programmer uses libusb so that is convenient as no kernel module needs to be built. I think there is another programmer that uses the FTDI 2232 chip that does require drivers to be installed. This how-to won't cover that one, or the parallel port programmer (which I was unable to get working).

Step 1: install libusb
sudo apt-get install libusb-1.0-0

Step 2: Add the USB device to "udev"

sudo emacs /etc/udev/rules.d/10-local.rules

Append this line:
#lattice
BUS=="usb",ACTION=="add",SYSFS{idVendor}=="1134",SYSFS{idProduct}=="8001",MODE=="0660",OWNER=="root",SYMLINK+="lattice-%n"

Step 3: Plug in the USB device programmer

You should see a device in /dev named "lattice":

~$ ls /dev/lat*
/dev/lattice-6

Step 4: Fix permissions.
Shown here is an impermanent fix. Every time you turn off your computer or remove the programmer you'll have to re-run this, since the device is removed and recreated during these events. I'm sure that some of you Ubuntu/Linux wizards can tell me how to make it permanent...

sudo chmod a+rw /dev/lat*

That's it! The ispVM programming tool should auto-detect the cable now.

Have fun and post some OSS designs!

Lattice FPGA -- They are beginning to get OSS

2010-10-04T18:07:00.000-07:00

After a quite a bit of comparative evaluation I chose the Lattice XP2 FPGA and the Brevia demo board for a bit of hardware hacking. (In short, I wanted a non-volatile FPGA or large CPLD, and found that the XP2 and MachXO seemed better than the Altera and Xilinx offerings).

And I'm happy to say that unlike my prior complaints about Cypress, I do think that Lattice "gets it" around open source hardware.

Al is not perfect, but they seem to be moving rapidly in the right direction.

First off, they recently obsoleted their old GUI and released their "Diamond" GUI for both Windows and Linux. Its a little crunchy still on Linux. However, this is a major, probably very expensive, initiative and Lattice should be commended for letting Linux be part of it! While they officially only support Red Hat, check out this output coming from the "compiler":

Warning: You are running on an unsupported platform
'synplify_pro' only supports Red Hat Enterprise Linux 4.0 and above
current platform: Ubuntu 10.04.1 LTS

That's right! I managed to get it up on Ubuntu 64 bit (I'll provide a little HOW TO in my next post).

Secondly, they priced the board extremely well at $29.

Third, they provide a lot of free libraries (called "designs" or "IP" in the hardware world) so long as you only use them on Lattice parts. Personally, I can live with that. After all Lattice is in the business of selling chips. And you know if I decide to switch chips, I can implement the underlying library myself and still have benefited from using Lattice's library to get me prototyping my application code faster...

Fourth, the GUI/compiler is free (well, its a 1 year free license so I guess someday they could take that away) and command line accessible.

Fifth, the USB programmer uses libusb, so you don't even need to install a special driver. This makes it a lot easier to run on different linux distros.

This is a great first step!!! Its perfect for OSS hackers and students.

... but there is stuff Lattice needs to work on.

First, my biggest gripe is that the Brevia board ships with a parallel port programmer. But who has parallel ports anymore? And by the way, purchasing a USB->parallel converter WILL NOT work. Those converters do not translate all parallel signals. Lattice FAEs claim some converters work, but will not endorse a particular one so we are left guessing.

In fact I was unable to get the parallel port programmer to work.

Second, the USB programmer purchased separately costs $150!!! This is an evil bait-and-switch. Honestly I haven't priced components out, but in this market I'd bet that USB components are cheaper than parallel because its all about volume. So what is going on here!!?

However its standard JTAG so other programmers should also work...

Third, the ispVM device programming tool was poorly ported to Linux. In particular, you actually specify the old 8088 parallel port number 0x378 (or whatever) to identify the parallel port, not the device name (and again I never got it to work with the parallel programmer).

Fourth, they only offer RPMs. Lattice, even if you don't want to support every distro, its traditional to just jam your program in a big gzipped tarball archive so we can pull it down and install it by hand by coping it to /usr/local or something along those lines.

And finally, Diamond is still a little rough around the edges. For example, sometimes the editor stops working and I have to close and reopen my project. Even worse, I managed to get my project into an inconsistent state where some generated files thought that certain clock resources existed but I had removed them. The easiest way out of that was to create a new project :-(, and copy my source code over.

However Diamond is very new. I expect very good things.

All in all its a great start! Thanks Lattice!

Disclosure: I am in no way affiliated with Lattice, other than having bought their $29 Brevia board...

Arduino/AVR vs Cypress/PSOC

2010-08-07T04:17:00.000-07:00

I've recently been working on a simple PSOC (www.cypress.com/psoc) project using the CY8C64315 USB chip and can't help but compare it to the popular Arduino platform since it is pretty similar to the AVR 328P. These are my observations:

Feature Comparison

Cypress/PSOC 9, Arduino/AVR 5

Initially I chose PSOC because it has some great features packed into a tiny 16 pin QFN part at a cheap price. In particular it provides a full-speed USB device with very few external components -- not even a crystal! It runs at 24Mhz instead of the AVR's 20mhz and contains SPI, I2C, a bunch of IOs and so forth.

One issue is that it does not contain a serial UART (but other, bigger PSOC parts do), but I'm hoping to do a soft-serial implementation.

Perhaps its kind of silly but I didn't want my USB controller to be larger, more expensive, and have more pins than an embedded CPU itself (but when you get right down to it, it is in fact on par or more powerful than the 328p)! So the tiny part size combined with good features was the clincher for me.

Documentation

Cypress/PSOC 3, Arduino/AVR 10

The Cypress Application Note search tool is totally impossible to use. And their community site www.psocdeveloper.com is better but not "alive" like the Arduino or even avrfreaks. Its too tightly coupled with Cypress I think.

And none of this stuff comes up in google searches.

Note to Cypress -- you are NOT a SEARCH company! Just post all your App Notes in HTML form on a public site and let Google do the job. It will do it much better and you'll save some money.

One wild/good thing; I posted an issue bringing the chip up and actually got an essentially unsolicited telephone call from a real human being engineer the next day to help me (but had already figured it out). So that can make up for a lot of doc issues, but of course its pretty expensive for Cypress...

Hardware Design

Cypress 2, AVR 10

2. Application Schematic? It seems that Cypress didn't bother to put one in the datasheet. In fact I had to glean portions of the full "typical application schematic" from a bunch of "Application Notes" -- USB from here, ISSP from there. And of course those schematics were not necessarily for the chip variant I chose so there was lots of uncertainty in this process.

In contrast the Arduino project and all its variants are open hardware, so there are lots of circuit examples to choose from.

PSOC Designer vs Arduino IDE

Cypress 5, Arduno 5

PSOC is supposed to be some reconfigurable hardware "magic" that requires a fancy windows-only IDE. Not in my chip. Everything is just registers AFAIK. But still you can use a GUI to configure things and then it generates the code to write these registers for you. Now, this might seem cool, but actually it just gets in the way. It gives Cypress and excuse to not supply an API like the Arduino's "pinMode" and not to supply good docs. So what if you want to CHANGE the behavior of a pin while your program runs -- you've got to delve into the registers...

The rest of the IDE is everything you'd expect from a programmer's IDE. Good job Cypress! You are just as good as the free Eclipse :-).

However I do have one or 2 beefs. It:
1. Only runs on windows *sigh*
2. Pops up an irritiating "Programming" dialog box. This should be done in a small side-docked pane so the programmer can continue to WORK while the chip gets programmed...

Build Toolchain
Cypress/PSOC 5, Arduino/AVR 5

G++, GCC???

For some reason, instead of adding a gcc backend for the PSOC CPU, Cypress decided to go with some commercial C compiler. So no C++.

The result is a bit more like "Kiel" C then gcc and in particular has irritatingly difficult tranlation between a string stored in "flash" vs one in "ram". In fact, you have to define 2 functions one to handle "__flash" strings and one to handle normal "char *". *sigh*

But of course Arduino has this strange thing called "processing" with is actually C++ with some "try to help me but actually get in the way" thrown in so really average marks on both.

How to "Blink" (Basic programs/sketches)

Cypress/PSOC 7, Arduino/AVR 10

Its pretty INSANELY hard to figure out how to do simple things like configure a digital input (you use the GUI to graphically set the pin as CPU open-drain, then in code write the bit HIGH). Also standard C functions like "printf" are there but don't work... better that they not be there if they don't work.

Yet at the same time, it can be very EASY to do an entire USB HID device. So it just depends on how many Cypress libraries you can use.

Software Layers

Cypress/PSOC 9, Arduino/AVR 9

Ok, I've got to give cred to Cypress for being the 1st hardware company (AFAIK) to realise that we don't want to program at the register level. Yes, the GUI has "user modules" and you just pull them into your project to get massive functionality like a USB endpoint.

One nasty issue the use of lots of assembly??!!? All the Cypress libraries AFAIK are written in assembly. This makes reading the code hard :-). And also you can't ignore it; installing things like interrupt handlers requires you to get down in there and call out to your C. And this is NOT easy; to make the C compiler correctly save state, you have to basically trick the CPU into calling your C routine as if it was an interrupt even though you are already IN an interrupt. There's an entire App Note about how to do it :-(.

The advantage is probably smaller code sizes. But the cost is essentially that if you need to modify the library or add a feature, you have to either rewrite the whole thing yourself in C, or learn PSOC assembly which of course ties you and your work inseparably to this processor.

Summary:

Its a neat little device with lots of potential. Great hardware, great software/support philosophy but not so good implementation. But its a pretty steep learning curve...

Now, Arduino/AVR generally relies on the community to provide great programming libraries, examples, tutorials and general help. And we do.

Cypress seems to be doing all/most of the work on its own. It seems to be caught attempting to implement a modern philosophy with a traditional unidirectional information-flow structure.

So while I give cred to Cypress for the tremendous effort I'm amazed at its total disregard for the open source movement -- in compilers, in IDE, in software libraries.

And I'm surprised at its inability to truly capitalize on internet resources and community.

Proposal for an "Open Device" License

2010-06-09T12:25:00.000-07:00

There is an interesting read about an "open hardware" license here:
http://www.tapr.org/ohl.html

But I am interested in something that goes much further in several ways.

First off, my license would enforce the right and ability to modify a product and (especially) its firmware/software after it has been produced. This is what I mean by "open device" as opposed to simply "open hardware". In a world where the PC is increasingly pushed into a niche market, it is very important to protect the right to run software on other hardware, cell phones for example. I believe that the openness of the IBM PC is what created the personal computer revolution -- and why Apple lost out... as much as I love what Apple is doing on the physical side with the ipod, iphone, ipad, we need to ensure that Apple's restrictive policies do not prevail in devices or we will lose innovation in the personal device marketplace to the detriment of everyone who uses the devices.

This "modifiable device" restriction is also nice because it lets the original producer (and others) can use a high volume producer's hardware, so long as its functionality is accessible.. I believe that this would satisfy many open hardware developers since some are not motivated to make money; they are simply building a device that does not currently exist, and would be happy instead to buy it at Wallmart for significantly less cost. On the other hand, the greatest IP "theft" would be for a company to take a piece of open hardware and inaccessibly embed it within some consumer product, thereby reaping all the rewards of the open hardware communities' efforts and giving nothing back in return.

Secondly, I disagree with the TAPR's reliance on the GPL license to protect software, since (as I said above) it does not protect the ability to run that software on some device. It is very common for a company to comply with GPL by releasing the source of a Linux port onto a new CPU but in fact have no way for the end user to actually upload that release onto the CPU within the company's product! And generally other available hardware will not exist for the new CPU... Ironically, this effect is what drives some open hardware development, because the community then must produce (at great personal expense) custom hardware to utilize the Linux port...

There is one instance that I know of where in fact the software was released and the hardware fortuitously provided an update mechanism. This was the WRT-54G router. This device was a tremendous market success, and open source community's modifications to this router were so popular that some features were actually pushed back into the commerical release, AND even though the company eventually built a cheaper version on vxworks (a different operating system), they continued to sell the original under the product name WRT-54GL (more...). What if this phenomemon was the norm instead of the exception!?

Therefore, I believe that the hardware and software in embedded devices is intrinsically related -- one is almost worthless without the other. And finally, my experience as a software architect within the telecom industry and my experience as an open hardware developer is that in fact the software/firmware is 90% or more of the time effort. Since it is the major cost, it provides great leverage to pry off the lid of "closed" devices.

When you add these and a few other ideas together, you end up not with "open hardware", but something that looks a lot more like an "open device".

Success, Wall Street Style

2010-06-02T06:57:00.000-07:00

I just finished reading "Den of Thieves" by James Stewart which is about the junk bond scandal that hit wall street in the '80s. What is fascinating about it is the similarities between it and the recent financial meltdown. Just swap "toxic asset" mortgages for corporate loans (AKA junk bonds) and hit the fast forward button.

Since this is a blog, I'm going to skip all explanations (read the book) and just hop to my observations:

First off, the financial system essentially and intrinsically encourages abuse. Capitalism trends towards perfect markets -- therefore there is an ever decreasing profit spread for financial guys to take advantage of. But wall street types are self-selected to not be happy with ever decreasing profits. They will find or create an edge.

Second, the junk-bond related crimes were totally unnecessary; they just added a buck or two per share to an already over-inflated, highly profitable transaction and sometimes "encouraged" a deal to go through if it was stalling. Judging by the lack of major arrests in the toxic asset meltdown, Wall street learned that crime in fact doesn't pay nearly as well as the long, legal con.

Third, never trust finance guys even as part of a reputable institution! [In fact, let me go on a limb and say, its your life, don't trust anyone! For major life issues like financial and medical, respect the expert opinions but learn their biases (for example, surgeons LIKE to do surgery, duhh!) and then spend the time to figure it out yourself!]

Around 2007-2008 a couple of my friends were buying a house and I was alarmed at the tendency for people to trust the bank's evaluation of how large a loan you could bear. Essentially they ceded responsibility for picking a reasonable load to the banking "experts", and did not bother to do even the most basic math. "If the bank is willing to offer me that much I must be good for it" is how the thinking goes. I think that this happened on a nationwide level. But I would tell my friends "yes but the bank's goal is for you to be in debt for the rest of your life, your goal should be to not be in debt. Because when you are in debt, you are paying 10% or more to your creditor. You are going into debt to buy more stuff, but ironically you'll end up with less".

Little did we know that many banks did not even care whether the loan could be repaid...

Recipe for Wall Street Mega-Success
(slashdot style)

1. Identify an information advantage. Look in unregulated areas of finance. For extra credit, artificially create an information advantage in your favor. For example, bundle financial instruments so the underlying entities are hidden. Write contracts that only finanical lawyers can understand (insurance is a great area of opportunity for this method). Transform an out-of-favor, high-risk financial instrument into one that is "in-favor". Take advantage of people's trust in "experts" -- i.e. yourself.

2. Market, market, sell, sell, sell. Get college professors to write papers about how low risk your market historically was (before you entered it).

3. Jam increasingly ludicrious and high risk underlying entities into your framework since that maximizes your profit by reducing the base cost.

4. Use recursion to keep the aura of good times going -- if an issue is about to fail, grab it up, twist it around, and jam it back into the system (AKA refinancing).

3. ??? (this is where the optional crimes are committed)

4. Profit!!!

5. You have 3-7 years; the fall will be from the summit, sudden and hard. be ready to bail.

Arduino PWM on all pins.

2010-02-06T12:39:00.000-08:00

What is PWM?
PWM (pulse width modulation) is the art of faking a particular voltage by rapidly moving between 2 other voltages. For example if you have a digital logic line that is 0 volts when LOW or 5 volts when HIGH, you can "trick" a multimeter into reading 1 volt by setting the line to low for 4/5s of the time and high for 1/5 of the time. The ratio of high to low is called the "duty cycle" and is specified in a percentage.

Why Use PWM?

You can trick a lot of other things too if you toggle the line tens to hundreds of times a second. For example if you connect a LED it will appear dimmer due to the same "persistence of vision" effect that makes movies appear smooth.

Another example is driving motors. Motors contain electromagnets which cause electrical inductance (in analogy "momentum"). If you put a diode across the motor's leads (backwards) then when the motor is turned off, the collapse of the magnetic field continues to drive current through the wire, and through the diode back to the other side of the motor. This current maintains the magnetic field! If there was no resistance this would go on forever (BTW this is how superconductors float above magnets). But since there is resistance, the circulating current slowly dies out.

But if you are doing PWM on the motor, a new influx of energy will re-energize the motor's coils resulting in a smoothly turning motor. But the speed of the motor will vary based on the duty cycle of the PWM. So you can use PWM to change the speed of a DC motor.

The Arduino has some hardware-based PWM. But only on certain pins. For things like motors, you do not need to PWM very fast so it can be done in software. So I have made a software PWM class for Arduino sketches that works on all pins.
The Four Line states in an AVR microcontroller

Another cool feature is that it will do PWM between any 2 line states. You may normally think of a digital line as having only 2 states (high or low) but the Arduino actually offers 4 states, high, low, high impedence, and pull up.

A lot of beginners think of the "low" state as "off" but really it means driven to 0 volts. So if you put a light between a "low" pin and 5v, the light will turn on!

On the other hand "high impedence" actually means "disconnected" or "floating" -- at least as close as you can get to that using solid state electronics. So in a high impedence state, the light described above would NOT turn on. But one issue with a line in the "high impedence" state is that its voltage is undefined and can be sensed as high or low and change between the 2 due to vagaries of electric fields on the board, etc.

"Pull up" refers to a connection to 5v through a large resistor. So it is "high impedence" in the sense that it cannot drive anything, and if driven by some external device it will follow that device. But if the line is otherwise floating, the connection to 5v thru the resistor will make the line show as high.

DOWNLOAD

The Code


#define PWM_NUM_PINS 16
#define PWM_MAX_DUTY 255
#define PWM_DEFAULT_FREQ (16000000.0/128.0) //2MHz for /8 prescale from 16MHz

//?? Software based PWM (Pulse width modulation) library for the ATMEGA168/328 (Arduino).
// 
// This class implements PWM in software.  PWM is a method whose purpose is to emulate an analog voltage by rapidly toggling a digital
// pin between the high and low states.  By changing the duty cycle -- the percent of time the pin is "on" verses "off" the apparent voltage changes.
// This technique is only useful if the pin is controlling a device that averages voltages; for example:
// * Inductors (electromagnets, motors)
// * Capacitors
// * Human perception (via LEDs for example)
// This library does not work as efficiently as the hardware based PWM availabe in the ATMEGA, so that should be used if possible.
// However this library offers PWM on all pins, and also allows you to specify what the "on" and "off" pin states are.  For example, you could choose the "off" state to be high impedence.
// 
class SoftPWM
{
  public:
  typedef enum
  {
    DRIVEN_LOW = 2 | 0,
    DRIVEN_HIGH = 2 | 1,
    DRIVEN = 2,
 
    FLOATING = 0,
    PULL_UP = 1,
    HIGH_IMPEDENCE = 0,

    UNUSED = 4   
  } PinBehavior;
  //?? Constructor
  SoftPWM();

  //?? Call this periodically to trigger a state change
  void loop(void);
  
  //?? Automatically call the loop() function periodically.  Once you call this function YOU SHOULD NOT CALL LOOP()!
  void startAutoLoop(int timer=2,int frequency=PWM_DEFAULT_FREQ);  
  //?? Stop automatic looping.
  void stopAutoLoop(void);
  
  //?? Duty Cycle.  The fraction of time that the pin is HIGH is duty/255
  uint8_t duty[PWM_NUM_PINS];
  
  //?? Set what it means for a pin to be off or on.
  // Typically you would want to PWM an output pin and toggle output voltage.  This is what PWM normally means, and is the default.
  //       However, for other applications you may want to toggle the impedence and value simultaneously.
  //       For example, if the pin is sinking the base of a PNP transistor then you would switch from a high impedence (i.e. open circuit) state to a low output state (i.e. closed circuit, sinking current).
  //       
  void enablePin(int pin, PinBehavior offMode=DRIVEN_LOW, PinBehavior onMode=DRIVEN_HIGH)
  {
    pinOnBehavior[pin] = onMode; 
    pinOffBehavior[pin] = offMode;
  }
  void disablePin(int pin) { pinOnBehavior[pin] = UNUSED; pinOffBehavior[pin] = UNUSED; }
 
  //?? Set all duty cycles to 0
  void zero(void)
  {
    for (int i=0;i != PWM_NUM_PINS;i++)
      duty[i] = 0;
  }

  uint8_t pinOffBehavior[PWM_NUM_PINS];
  uint8_t pinOnBehavior[PWM_NUM_PINS];
  int bresenham[PWM_NUM_PINS];
};

SoftPWM::SoftPWM()
{
  for (int c=0;c != PWM_NUM_PINS;c++)
  {
    bresenham[c] = 0;
    pinOffBehavior[c] = UNUSED;
    pinOnBehavior[c] = UNUSED;
  }
  
  
}

void SoftPWM::loop(void)
  {
  boolean lvl;
  unsigned char regLvlOut=0;
  unsigned char regLvlIn;
  
  unsigned char regDirOut=0;
  unsigned char regDirIn;
  
  for (int i=0;i != PWM_NUM_PINS;i++)
    {
      if (i==0) { regLvlIn = PORTD; regDirIn = DDRD; }
      if (i==8) { regLvlIn = PORTB; regDirIn = DDRB; }
      
      if (i==8)
      {
        DDRD = regDirOut;
        PORTD = regLvlOut;
      }

      regLvlOut >>=1;
      regDirOut >>=1;

      if ((pinOnBehavior[i] & UNUSED) == UNUSED)  // If its unused then keep the values the same
        {
          regDirOut |= (regDirIn&1);
          regLvlOut |= (regLvlIn&1);
        }
      else
        {
        bresenham[i] += duty[i];
        if (bresenham[i]>=PWM_MAX_DUTY) 
          {
          bresenham[i] -= PWM_MAX_DUTY;
          lvl = true;
          }
        else lvl = false;
        
        if (lvl)
          {
            regLvlOut |= (pinOnBehavior[i]&1) ? 0x80:0;
            regDirOut |= (pinOnBehavior[i]>>1) ? 0x80:0;
          }
        else
          {
            regLvlOut |= (pinOffBehavior[i]&1) ? 0x80:0;
            regDirOut |= (pinOffBehavior[i]>>1) ? 0x80:0;            
          }
      
        }

      regLvlIn >>=1;
      regDirIn >>=1;
    }
    
    if (1)
      {
        DDRB = regDirOut;
        PORTB = regLvlOut;
      }    
  }

typedef unsigned char byte;

int ledPin = 13;

void testSoftPWM()
{
  SoftPWM pwm;
  pwm.enablePin(ledPin, SoftPWM::DRIVEN_LOW, SoftPWM::DRIVEN_HIGH);
  for (int i=0;i<25600;i++)
    {
      pwm.duty[ledPin] = i/100;
      pwm.loop();
      delay(1);
    }
}

void setup() {}
void loop() { testSoftPWM(); }

Browser Hacking

2010-01-25T21:05:00.000-08:00

Firefox has a cool extension called pyxpcomext that sticks a Python interpreter inside your browser!

But as is it is pretty hard to use unless you are already a browser geek. For example, it is hard to figure out how to access stuff like a page in the browser because all of the Firefox extension documentation is for either C or JavaScript. So you have to sort of read those APIs and translate them thru XPCOM into Python. This is tricky.

So I extended the pyxpcomext example "PyShell" into something a lot more user friendly (it wraps the most common XPCOM stuff into normal Python function calls) and useful. You can access and read details about it here: http://code.google.com/p/juicedpyshell/

Now, what's the point of this, you ask?

Well, what this means is that you can write a Python program that can interact with your browser as you are browsing and even modify the page (sort of like greasemonkey, but in Python) or even "click" the browser to another page for you!

But that's still technology, how about applications?

0. Automation of repetitive browser tasks.

1. Automated test of your live web site if you are a web developer.

2. Sophisticated ad elimination.

3. I'm thinking of a history database that remembers not only the link, i.e. "www.cnn.com" but also the contents of a page. Don't you hate it when you browse to an article only to find it gone!

4. Python XML/HTML development. If you are writing a Python back end server then your python is generating HTML. Its pretty cool to just be able to write hprt(" <> My Header < /h1 >") in the Juiced Python Shell, and actually SEE the rendered HTML appear. Its just like the Python standard "print" command but understands html! This really speeds up the dev/test cycle.

But why not...?

...just write an app that grabs pages as an http client? Well, because your app can't execute Javascript so it won't work on all of the new Web 2.0 sites.

...use greasemonkey? Because everyone hates Javascript :-)!! Seriously, because you can spawn multiple threads in your Python program (however, only the main thread can "touch" the browser). Because you have access to the incredibly rich set of Python libraries. Because Python has a real console and debugger. Greasemonkey is a toy to markup web pages. A very cool toy of course! But still your program will always be limited in complexity by inherent Javascript limitations.

A well deserved plug

2009-10-09T13:28:00.000-07:00

I did not populate my Lightuino LED board with excessive LEDs. In retrospect, that is kind of ironic. But the board is made for you to put the light where YOU want it to go :-).

In particular I left off the TX and RX LEDs so you can't tell if it's downloading the sketch. But it does have power and the pin 13 LED. So... I decided to hack the bootloader to blink the pin 13 LED as the sketch comes down. Well guess what! Its already been done! And it worked flawlessly, without me even having to do a compile.

Thank you LadyAda and Brian! These are people who are building the community, not just selling knockoffs. So I say, if she stocks it here or he stocks it there then buy it from them!

[Disclamer: My only affiliation is as a satisfied customer of adafruit -- I use her USBtinyISP and the Boarduino]

Lightuino Design Thoughts

2009-10-06T19:16:00.000-07:00

From references

In designing the Lightuino I wanted to improve on my existing CCShield in several ways and provide an alternative to the Rainbowduino (which is also an Arduino compatible LED display board).

New Features!

NOT (necessarily) a shield!

The biggest change is the addition of the ATMEGA CPU, clock, etc logic, making the Lightuino a standalone board!

Of course, you can still use it as a shield, either WITH the ATMEGA populated or WITHOUT (if the ATMEGA is not populated, it MUST be used as a shield of course). And you can stack them. If it is stacked, it ought to let you do some really interesting distributed computing stuff.

By integrating the ATMEGA on-board, the total cost is a lot less, since you don't need the Arduino board. And its a lot smaller too!

Separate LED power Regulator

An LM317T was added to the board, with a 10k adjustable POT, so you can deliver consistent power to the LEDs (or to whatever) even if your wall-wart is unregulated. As long as your wall-wart provides the voltage, you can go up to 30+ volts, allowing each CCShield sink to control a string of LEDs. However the M5451 chips can only handle a 13 volt differential, so you must make sure that the voltage has dropped down to this before it enters the chip.

IDE cable headers

If you are stacking Lightuinos, the IDE cable header does not quite fit in a stack, so right angle headers are available.

The IDE cable pinout was also changed to put all of the power lines on one end, and to NOT provide a ground line unless a jumper is inserted on the board. Additionally, the pinout is the same on both sides (instead of upside down). This makes it a lot easier to wire up the LEDs AND also makes it very difficult to accidently burn out a LED by wiring it up to ground (for example) instead of to a current sink.

Finally, one of the lines is unassigned, and accessible via a pin on the board. So you can push whatever signal out that you want!

Pin Selection

Just like the CCShield, you can select whatever Arduino (digital) pins you want to control the LED portion of the board. But the CCShield's pin selection was difficult as it used extremely small SMT pads. The Lightuino simply has a section of the board with some thru-holes and you use jumper wires to make the selection.

Brightness Adjustment

It turns out that the M5451 chips can drive the LEDs at a barely discernible difference in brightness, so trim pots were added to the brightness adjustment to allow you to make the chips output the exact same light intensity (or actually, you could make one chip output bright, and one dim). Of course, this can be simply populated with resistors to save $ if exact brightness levels are not needed. It is unlikely that these will be needed for casual use.

Extras

The ATMEGA 328 QFN package has 2 additional analog inputs, so I brought those out by simply extending the Arduino standard pinout.

Also, I had extra space so I threw in the footprint of a voltage divider per analog input pin since that is a very common circuit. Just add your own resistors, and you are all set!

Comparison with Rainbowduino

Matrix?

Let me start by saying that I don't have a Rainbowduino, so this is all conjecture from reading the specs. It seems to me that it was mostly focused on driving an RGB 8x8 LED matrix display. In fact you can even plug a matrix directly into it. I was more interested in driving individually placed LEDs for art projects. While LED matrices are cool and have their uses in signage, frankly, if I wanted a big screen I'd just buy a flat screen TV! But whatever floats your boat. :-)

Of course, you can always use a LED matrix electrical connection, but not have the LEDs in a grid, but it is trickier to do that wiring... additionally you can use the Lightuino to "sink" the columns of an matrix (70 columns instead of just 24!)... but you would need to power the rows with some other circuitry. So again, its trickier :-).

Shield Compatiblitity

Additionally, the Rainbowduino does not seem to be Arduino shield compatible. This seemed to me to be a major drawback as it does not take advantage of the vast community of shields out there that can add so many cool features to a project!

CPU Power

The ATMEGA 168 is pretty limited in RAM, as I found when working with the normal Arduino, so I moved up to the 328 with double the RAM.

LED Capability

I opted for 2 chips that can drive 70 constant currents outputs at 20mA, the Rainbowduino allows you to drive fewer outputs (24) at higher capacity (120mA).

PWM Dimming

I wanted to experiment with POV art (i.e. a light strip that forms an image floating in space when your eyes flick by it, or spinning a strip to form in image in a circle) and to do that you need precise control of when the LEDs are ON vs OFF. In other words, a separate PWM chip won't work. However, this means that the Lightuino has to drive PWM in software, just like what the Arduino's PWM pins do. At very low PWM levels (say 10 on out of 256 counts) you can perceive the LED blinking (and of course more Arduino processor time is used). Therefore, you end up with another tradeoff, precise control over the blinking of each LED verses faster blink rates (note, I'm just assuming the Rainbowduino has an external PWM, but I haven't verified that).

Lightuino V2.0 -- An Arduino compatible optimized for driving LEDs

2009-10-03T17:33:00.001-07:00

The CCShield board was pretty successful and I had a lot of fun with it, so I decided to do another run. I wanted to attempt some surface mount work but at the same time not produce a lemon if it did not work, so I created the hybrid board you see above. The board has a complete Arduino-compatible subsection on it implemented using surface mount parts and the CCShield (plus some extra goodies) implemented using thru-hole parts. The idea is that the board can be used as a shield if the surface mount parts are not populated, or used standalone if the parts are.

Another cool feature is that you can stack them -- so I can experiment with running a bunch of processors simultaneously.

I'll be adding a couple of posts about this board. This first is about building up the surface mount parts. The image above is the board with the surface mount parts baked on and the minimum thru hole parts added to bring power and the ICSP programmer on.

I used the smallest part I could find for the CPU, QFN-32 and 0603 parts for the resistors and caps. The tricky part of the QFN32 package is that the leads are underneath the part, making it hard to repair solder bridges.

To make my surface mount station, I "rescued" an old toaster oven from the dump and "splurged" on some solder paste, rosin, and wick from dealsextreme dealextreme. Then I bought some .5mm mechanical pencils from Staples, some tweezers from Walgreens. Total cost about $20.

This supplemented my current thru-hole solder station that consists of a plastic clamp (Home Depot) to hold a circuit board, a radio-shack 40 watt soldering iron, and an old a magnifying glass/light on arm combo from the basement (really its the bright light that's important).

I then used the mechanical pencil to "paint" the solder paste on the leads. For the QFN part, I just laid the paste across the leads and then used an Exacto-knife to "cut" the spaces between them. It seems like the biggest pitfall is simply using TOO MUCH PASTE. You want just the thinnest layer, and do not even cover the entire pad!

Then I just placed the components in their positions using the tweezers, and did fine adjustment of the QFN32 part with the edge of the tweezers.

Baking was easy. I followed the temperature profile here. But not really... I used the thermostat on the oven, not a real temperature gauge. Basically, just set your oven for 170 C put the boards in and wait 3 minutes. Then raise the temperature to 220 C and shine a bright light in so you can see the boards clearly. After a minute or two the solder will go from grey to silvery. Wait another 30 sec to a minute to be sure that ALL the solder has gone silvery. Then turn off the oven (but leave the boards in there) and crack open the door. You want to cool the boards evenly. After a few minutes, open the door fully, and when they are cool to the touch, pop them out!

I did 4 boards and had 2 solder bridges on the QFN parts. Every other part worked without any issues.

If you have a bridge (you can see it), paint the entire side of the part with a gob of rosin. Then place your solder wick over all of the leads and heat it all up with a clean iron on top of the wick. The rosin will help the solder flow and it will either flow onto the pins, or onto your wick. Easy!

So if you are a DIYer who has been leery of using SMT parts, I'd say "go for it"!

[edit oct 15, 2009: I just did 12 successful boards without any solder bridges. Mix 50/50 paste and flux so the result is viscous like maple syrup]

Solar Powered Arduino

2009-09-11T12:14:00.000-07:00

I am working on an outdoor LED coffee table. The idea is for it to charge up all day long and then to drive a bunch of LEDs (blinking in cool patterns via an Arduino) for as long as it has power at night.

There are 5 components to the electronics:

The Arduino

The LED driver

Solar Cells

Battery pack

Charging/light sensor circuit

In the photo, clockwise from the top left are the solarcells, the battery, the charging circuit and finally the Arduino (actually a boarduino), LEDs, and LED driver chip.

The Solar Cells

I chose some flexible solar cells I had lying around from
www.flexsolarcells.com. It turned out that they are a great choice for generic Arduino use because a single thin film cell generates 7.2 volts which is enough to power an Arduino! In contrast, one of the silicon cells only produces .5 volts (you need from 4.5 to 5.5 volts to power an Arduino).

In fact just one of the cells pictured here can power the arduino even in the shade. You could image one of these on top of a small device... however, they are not ideal for my project because I will have plenty of room under the glass of my table to put a lot of cells. And the silicon cells are cheaper per watt and more efficient per unit area.

The Batteries

I chose 4 1.2 volt Nmh (nickel-metal-hydride) batteries. I chose Nmh batteries because they can be trickle charged with a very simple circuit. They actually generate 1.3 (5.2 total) volts when fully charged. But that is less then the Arduino's limit of 5.5 volts, so I can connect directly to the Arduino's 5v line instead of the Vin. This bypasses the Arduino's voltage regulator and so is much more efficient but a little dangerous. It for some reason the voltage ever does exceed 5.5 volts, I could burn out the chip.

Charging Circuit

Basically, when the battery voltage is above that generated by the solar cells, current can flow from the top through the base (middle) of the upper right transistor and then backwards through the solar cells. This turns on the transistor, which then turns on the bigger transistor at the bottom and so power can flow through the Arduino. So the solar cells themselves are used both to charge and to sense when it gets dark. In practice, they turn the system on at dusk, so I put the Arduino to sleep for 45 minutes before actually turning on the LEDs.

The diode near the solar cells is so cells can only charge the battery, the battery can't attempt to "charge" the cells!

And finally a close up of the charging circuit itself:

The orange wires to the left go to the Arduino. The upper right ones go to the battery and the lower right to the cells. The wires on the bottom of the photo are basically electrical ground.

The LEDs

I use an M5451 constant-current LED driver chip to light the LEDs. If you are interested in this, there is a lot more information in prior blog posts, or at: http://code.google.com/p/arduino-m5451-current-driver/

Share your solar projects! :-)

Arduino + wireless + reconfigurable hardware: A proposal

2009-07-07T12:27:00.000-07:00

I am thinking about doing a quadruple whammy Arduino board: Atmel Mega 640 + CPLD + wireless + MicroSD card.

For those of you who are unfamiliar with the term "CPLD", it is a reconfigurable hardware chip. Essentially, today's CPUs all follow what is called the "von Neumann architecture" in which a CPU executes a set of instructions in a sequential fashion. A CPLD is very different. It is a "sea of logic gates", so it essentially executes every instruction simultaneously. So if you visualize a plot with the horizontal axis being what can be done per unit time, and the vertical being how much time to do a task, the CPU plot looks long and thin. It can't DO much per unit time, but you can string together many instructions to do complex tasks. The CPLD plot looks short and fat. It can DO a lot per unit time, but cannot do complex tasks since tasks must be completed in essentially 1 time unit. CPUs are much more well known both because they are programmed in a manner more intuitive to people and because ultimately you can get a lot more done with a CPU. However, their linear nature means that there are things that CPUs do not do well, like simultaneously and monitoring rapidly fluctuating inputs.

The reasoning behind integrating a wireless network and MicroSD is much simpler. First of all, the MicroSD card has a very simple interface (8 wires) so its easy to plop down and very useful for data recording, etc. Its so simple there is no reason to NOT integrate it. Purchased separately, a wireless network is expensive. You must buy a shield ($20-30) and a wireless module (another $20-$30). So this ends up being an additional $40-$60, not that expensive until you consider that the most interesting uses are to have not just one or 2 devices but to have a "cloud" of them. So for 10 devices, that would cost $500 -- outside of the casual hobbyiest budget. However the basic wireless chips cost about $4 for single quantities, and maybe $5 when the few additional parts are added. So an integrated wireless would cost an extra $50.

It seems to me that once you leave thru-hole chipsets, the casual user can't just plop the AVR down on his own handwired circuit board... but if people are OK with that (and it seems like they are given how many other surface mount Arduino clones exist), then it really opens the door for a base platform that hits key features that the Arduino is missing today. If the chips are integrated into the base platform, this platform becomes MUCH cheaper and smaller then buying all the shields separately. The final result is a tiny computer with the all the essential components of a "standard" PC (CPU, network, disk) AND the components required for a high performance/high IO embedded device (CPLD running at 100mhz with 50+ digital IOs). This combination can be used for sensor networks, cooperative mini-robotics, illumination, art/design projects etc and would probably cost around $50 or less.

Thoughts on GPL, the Open Company concept, and making $ therein

2009-03-24T12:10:00.000-07:00

One aspect of the philosophy of GPL is to contribute back to the community. However, as we all know in the GPL license the only way to contribute is by submitting code.

This creates several problems; the primary being a chasm between it and all other economic activity. This has resulted in lots of people coming up with very creative but ultimately ancillary ways to fund GPL activity, the primary being support. There is probably a mountain of literature written about this and so I won't go into them more deeply here other than to summarize:

These methods are not satisfactory because the effort/reward relationship is obscure at best and at worst rewards the wrong activities.

So let us modify the GPL with a economic clause. This would essentially state, "If you want to use this software without licensing your derivative software via GPL, then simply pay us money.

In this way a company or individual can contribute back to the project in the traditional ($) manner (as an aside, does it also allow code contributions to be valued monetarily and therefore taxed?). But of course what should the project do with that cash? While many projects could definitely use the money to pay for server space and bandwidth; we can imagine an extremely successful piece of OSS that is actually generating a surplus of money. It would obviously be inappropriate for the project founder to keep it since in theory the software has benefited from submissions from many individuals.

That observation cannot sit in anyone's mind without producing the obvious answer within a modern meritocracy:

Project surplus should be distributed to individuals according to level of contribution

If the project is successful, one might imagine that this could become key contributors primary source of income. Essentially they would be "employees" of the project's "company", but without some of the pain associated with corporate involvement (and perhaps also without some of the benefits).

Of course, this brushes all kinds of issues under the rug such as how to measure "level of contribution". Let me throw out an initial breakdown formula:

contribution = "Trust Network" opinion * (alpha * sum(cool feature values) + beta * lines of code + delta * sum(bug fix value) - epsilon*(sum bugs you created))

"Trust Network opinion" = how other people rate you; used to catch people who are padding out their contributions by writing wordy code, etc.

Alpha, beta, and delta = arbitrary weighting factors depending on what's most important.

"cool feature values" = How much people like the feature you added (or maybe real-time feedback reporting what features the users are using)

"lines of code" should be obvious

"bug fixes" = Fixing bugs is a boring nasty job but someone has to do it.

And of course your contribution should be penalized by the # of bugs found; after all, if someone has to essentially rewrite your stuff; I'm not sure if you deserve too much credit.

But this only focuses on the code. How about the community? We can imagine similar metrics created for support forums; # of posts, response time, quality of posts, etc, and combined into a monster "value" equation. And documentation...

Even the necessary evil of "hierarchy and planning" can perhaps be captured by a pyramid scheme whereby section owners "contribution value" includes a tiny % of all contribution values to that section.

All of this begs the question: "Is it possible to capture all business activities?" To create an "Open Company?"

All of the above are my own ideas except for the word "Open Company". I was inspired to blog about them today because I think we are about to take the initial steps in regard to feasibility; there is a company out there who is going to try to do just that.

You can read a bit about it at: http://e-texteditor.com/blog/2009/opencompany

Arduino L298 stepper motor driver

2009-03-11T06:46:00.000-07:00

Here is an example Arduino sketch to drive a stepper motor using the L298 chip. The actual driver is the "StepperL298N" class, and then there is some code to test it. When you instantiate the class, pass in the 4 Arduino pins that you have connected to the stepper motor. For example, "StepperL298N motor(4,5,6,7)" will drive a motor connected to Arduino pins 4,5,6,7. If you need to drive 2 motors, just create 2 instances of the class with different pins!

To move the motor 1 tick, call the step(bool direction) member function. Call it with 1 to go forward, and 0 to go backwards. The faster you call it, the faster the motor will go. Note that the Arduino can easily call step() much faster than the motor can possibly be driven, so you must insert a delay by calling the delay function. For my test motor (and old AMP 2.3 volt 60oz*in, which I got from taking apart a printer) you have to delay at least 5ms for the motor to work.


/*
 * stepperL298N
 * Copyright 2008 G. Andrew Stone
 * Licensed under the Common Public License V1.0
 * For the full text of this license see: http://www.opensource.org/licenses/cpl1.0.php
 *
 */

int ledPin = 13;

void setup()                    // run once, when the sketch starts
{
  pinMode(ledPin, OUTPUT);      // sets the digital pin as output
}

void mydelay(int clk)
{
  int i;
  for (i=0;i< clk;i++);
  //delay(clk);
}

class StepperL298N
{
  public:
  byte pins[4];
  byte curState;
  byte* lut;
  StepperL298N(byte pin1,byte pin2,byte pin3,byte pin4);
     
  void step(boolean dir);
  void halfStep(boolean yes) { if (yes) lut = halfStepLut; else lut = fullStepLut;}
  void start() { curState = 0xa;}
  void free() { curState = 0; }
  void brake() { curState = 0; }

  byte fullStepLut[16];
  byte halfStepLut[16];
};


StepperL298N::StepperL298N(byte pin1,byte pin2,byte pin3,byte pin4)
{
  pins[0] = pin1; pins[1] = pin2; pins[2]=pin3; pins[3] = pin4;
  lut = fullStepLut;
  for (int i=0;i<4;i++)
    {
    pinMode(pins[i], OUTPUT);      // sets the digital pin as output
    }

 memset(&fullStepLut,sizeof(byte)*16,0);
 memset(&halfStepLut,sizeof(byte)*16,0);

 // High nibble goes one way, low the other
 fullStepLut[0] = 0;
 // 1010 -> 1001 -> 0101 -> 0110
 fullStepLut[0xa] = 0x9 | 0x60;
 fullStepLut[0x9] = 0x5 | 0xa0;
 fullStepLut[0x5] = 0x6 | 0x90;
 fullStepLut[0x6] = 0xa | 0x50;

 halfStepLut[0] = 0;
 // 1010 -> 1000 -> 1001 -> 0001 -> 0101 -> 0100 -> 0110 -> 0010
 halfStepLut[0xa] = 0x8 | 0x20;
 halfStepLut[0x8] = 0x9 | 0xa0;
 halfStepLut[0x9] = 0x1 | 0x80;
 halfStepLut[0x1] = 0x5 | 0x90;
 halfStepLut[0x5] = 0x4 | 0x10;
 halfStepLut[0x4] = 0x6 | 0x50;
 halfStepLut[0x6] = 0x2 | 0x40;
 halfStepLut[0x2] = 0xa | 0x60;
}

void StepperL298N::step(boolean dir)
{
  curState = lut[curState];
  if (dir) curState &= 0xf;
  else curState >>= 4;
  for (int i=1,j=0;i< 16;i*= 2,j++)
    {
    byte lvl = LOW;
    if (i&curState) lvl=HIGH;
    digitalWrite(pins[j],lvl);
    }
}


int serDataVal = LOW;
void loop()                     // run over and over again
{
  unsigned long int j;
 
  StepperL298N motor(3,4,5,6);
  motor.halfStep(true);
  motor.start();

  for (j=0;j< 1000;j++)
    {
    motor.step(1);
    digitalWrite(ledPin, j&1);   // sets the LED on
    delay(5+j/10);  // Change the delay to change the rate the motor spins
    }
  motor.halfStep(false);
  motor.start();
  for (j=0;j< 1000;j++)
    {
    motor.step(0);
    digitalWrite(ledPin, j&1);   // sets the LED on
    delay(5+j/10);
    }
}

Michael Margolis ('mem' on the Arduino.cc forum) was kind enough to let me cross-post a schematic:

GUI Design and click-distance

2009-02-28T07:06:00.000-08:00

I am not a GUI designer by trade, but I have done some GUI design both of web applications and normal GUIs. And I'd like to both rant a little and describe some of my GUI design thoughts.

First I think that we can all agree that many GUIs are poorly designed and therefore frustrating to use. And a lot has been written about how to clearly lay out information on the page, etc. A good layout is alway good, but especially for new users to the system. But what about the other 99% of the time the user uses the system? Once the user understands your GUI, how long it takes to physically move the mouse across the screen to use each widget required to get the job done becomes the determining factor as to whether your GUI is useable or not.

A lot less (if anything -- I can't find anything but I certainly haven't done a lit review on this!) has been written this -- about the kinematics of web design.

Wikipedia defines kinematics as studying motion without considering the circumstances leading to that motion. That is very similar to what I want to talk about -- which is the motion of the user's hands as he moves the mouse, moves from the mouse to the keyboard and so on. It doesn't really matter what the purpose of this motion is, other than to observe that good GUI design should attempt to minimize or eliminate the motion for common tasks.

Let me suggest a new metric called "click-distance". The purpose of click-distance is to create a quantitive measurement of how "far" the user has to move from his current GUI-state to get to his desired GUI state. So the metric will contain a lot more components then just clicking and moving the mouse, but I think that the term "click-distance" implies a good first order approximation.

One think that I don't like about the term is that perhaps even more important as "click-distance" is "click-time". That is, how long did it take to traverse the click-distance? But I think that "click-time" itself is not as important as "click-frustration" or how PISSED the user gets because he has to do something like individually select 500 files in 500 upload file dialog boxes instead of shift-clicking them all at once. But the further we go down this path, the less measurable the metric becomes.

Clearly by recording the sequence of input the user makes, we can infer something about the distance the user's hands travelled given a particular physical setup (desktop, laptop, or PDA/phone). And don't forget about left-handed people!

Click-distance should capture the following concepts.

Literal distance metrics:

1. Total distance the mouse cursor moved. Obvious!
2. Number of mouse-repositions. A person can move halfway across the screen in almost the time it takes to move just a little way. From experimenting on myself, it seems to take around a second for each individual mouse motion.
3. Number of uninterrupted mouse direction changes. A person generally moves the mouse in a straight line from its current position to the desired destination. If the mouse moves back and forth or around and around, that implies difficulty positioning -- that is, the GUI element is too small. From your high school calculus we know that the direction is changing along a particular axis when the velocity is zero...

Button press metrics:

4. Number of clicks and keys pressed.
5. Number of alternations between mouse press and key press. This metric is a rough estimate of how many times the user had to move his hand from the mouse to the keyboard, and is therefore a major contribution to click distance
6. ctrl-alt-shift-click Combinations.

Hard to measure metrics:

6. How often a certain sequence is repeated. Repetition is a huge source of user frustration (and is the source of carpel-tunnel syndrome) but conveniently is often the easiest to remove through a bit of GUI redesign. I think that it is so important that click-distance should be the square of the repetition, but only proportional to the rest of the metrics. However, it is difficult to programatically identify repetitive movements...

To make a quantitive formula, each of the terms described above should be multiplied by a constant adjustment factor that reflects the distance the hand must move. These constants might differ based on the physical layout being considered:

click-distance = A*mouseDist + B*mouseRepos + C*mouseVelZero + D*presses + E*mouseKeyAlternations + F*keyClickCombinations + (G*repetitions)^2

The idea is of course to mininize this click-distance for common tasks. Of course, you wouldn't really have to DO this math, just start thinking about your GUI in terms of how long it takes to do an operation and you'll be well along the path to good, useable design.

Here are some practical ideas that have emerged from my consideration of click-distance in GUI designs:

1. No modal dialog boxes!
They force the user to move the hand to the mouse, reposition, and click. For all "alerts", "errors", etc, use a "message bar" (preferably NOT hidden on the bottom of the screen) and graphics (like red text and animation) to draw attention.

They also position themselves "creatively" -- aka NOT where your mouse is!

Using a modal dialog box makes it hard to see the information behind it.

Does not scale: doing 200 operations that contain a modal dialog requires 200 reposition-click-reposition operations.

The only time a modal dialog should be used is in TRUELY irrevocable operations. Like formatting your hard drive.

Of course, the corrolary to this is that your program should not HAVE any truely irrevocable operations.

2. Keep it all in one window.
Use tabs, etc. They much shorter in mouse distance to switch between than windows that have to be sized and positioned.

3. Design with REAL data, not your unit-test toys.
You really ought to try the GUI with real-world examples, that contain lots of data. Doing so is the best way to discover repetition.

4. Allow multi-select absolutely whenever possible.
Creatively apply what this might mean in cases where you are not sure... implementing one of 3 possibilities at least fixed 1/3 of the problem...

5. Keep values populated in fields, and don't force a history selection from the selection box.

This will dramatically reduce click-distance for unanticipated repetitive tasks. Look, this is about click-frustration. If a person is entering 1000 people's addresses over the whole USA, it is not so bad to type the city and state. But if the person is the tax accountant for a particular town and so the city and state is almost always the same it can be very tiresome.

Its best to have an easy way to delete the field in one go like most boxes have. Or even better try a tiny "pin value" icon button near the field. If the "pin value" button is depressed, the last value entered is remembered for the next time.

6. Selection boxes suck!
Clearly the problem is that the user was probably typing, so now he must move from the keyboard to the mouse. Click to open the selection, all kinds of tricky clicking (especially since the selection box sometimes closes itself if the mouse wanders too far) to scroll down, and finally click to select. It is major mouse distance.

Here's one example that would save millions of people 10 seconds per day and massively reduce office rage:

Its much harder to find "New York" in a list of states 52 states then to just type "NY"!

Especially when some of you only show us 3 states at a time!

7. For the prime function, click distance should be <= 1.

Word processors allow you to add lots of letters to a document with 1 keypress per letter. They are not so good at saving 10 different copies of the document. You have to pop up 10 modal dialog boxes. File managers let you copy 100 documents to 10 different places with a mouse distance of about 20 (1 selection operation + 10*(mouse position + key:ctrl-v)). And so on...

Ok. I think that's enough examples. There are lots more. As you think of examples, please add them as comments!

First Arduino shield boards arrived!

2009-02-27T20:25:00.001-08:00

I designed an Arduino shield to provide a lot of outputs using very few pins on the Arduino... it uses 2 M5451 35 segment LED display driver chips.

Here's the board with all the parts soldered on.

Here is a angled view. On the front you can see a lot of pads. The idea was to allow the user to choose which Arduino pins should control the board by only bridging some of the gaps. However it turns out to be very difficult to solder tiny wires across these gaps.

Any ideas on how to do this better?

Here it is shown lighting up all the LEDs I happened to have lying around.

Here is the bottom view showing the Arduino connected.

A youtube video about it:

constant current LED driver thoughts (LM334)

2009-02-24T08:19:00.000-08:00

I was experimenting on how to mount surface mount LEDs in wood and made this little arch to test out ideas.

All the LEDs are in series. But the question was how to drive them? I could connect them to a wall wart transformer and put in a resistor, but that would mean that the resistance of the resistor would have to be tuned to the wall wart transformer. Since I was just going to grab a transformer from my junk pile of dead electronics I didn't want to do that. Instead I settled on this constant current circuit shown in discover circuits:

http://www.discovercircuits.com/DJ-Circuits/constantcurretled1.htm

This circuit is really strange because the current from the LED goes through R1 along with the current from the LM334's current selection. Was it a typo? Should the LED current really just go straight to ground?

Also, I popped up the LM334 spec. The LM334 basically has 3 pins: Positive, ground, and a third "current selection" pin. You just connect a resistor across the current selection pin and the ground pin to choose what current you want. So it turned out that the LM334 is a constant current driver itself, so why have the extra transistor?

And In fact, the naked LM334 circuit what I ended up using. But the issue kept bothering me and so I finally decided to think about it.

I decided to try 3 simple circuits. Let's call the simple one "A":

So basically the current from the LEDs runs through the LM334, and so, regardless of the input voltage, is regulated by the size of the resistor connected between pins 2 and 3.

I guess the problem is that all the current is passing through the LM334...

And then a "simplified" discovercircuits, call it "B":

The LM334 is used as suggested by the spec. But the LM334 only controls the current that flows out of the base of the transistor, so current through the transistor and LED will be about 100 times (or whatever the amplification of your transistor is) what is going through the LM334.

This turns out to be very useful if you want to use the relatively low current LM334 chip to control a much larger current. Or if you only have larger value transistors lying around.

This one from discovercircuits "C":

As I previously said, "C" is really strange because the current from the LED goes through R1 along with the current from the LM334's current selection.

The LM334 holds is middle pin at 68mV above the bottom. So without doing any math, you can see that current going through the LED wil have to "share space" through the resistor. As the current through the LED rises, the current sensed by the LM334 goes down. This therefore is equivalent (to the LM334) like putting a bigger resistor across its pins. End result: the LM334 lets a lower current pass through itself (i.e. out of the transistor's base). You actually end up with a stable situation.

As with the second circuit (B), the advantage is that load is going through the transistor, not the LM334. An additional advantage is that the resistor values to make it all work are similar to that in the LM334 spec, and you don't have a 100x multiplication of the current (which may or may not be an advantage)

Another disadvantage of B is that it is very sensitive to the exact amplification (beta) of the transistor. But I guess transistor betas used to vary pretty widely within the same part due to small fabrication differences (I am not sure how accurate they are nowadays)... So while B is great for home use where you can test the exact beta of the transistor and choose a resistor to match, this circuit might be a bad idea to use in a production circuit board.

However, a big disadvantage of C is that the load (from the LED) is going through the resistor, so you do waste more power than in B and most importantly will have to use a high-watt (bulky, expensive, don't have it in your basement) resistor. Or of course a bunch of normal resistors in parallel...but that is also pretty ugly.

Arduino and M5451 -- Control 35 LEDs, motors, etc!

2009-02-22T12:08:00.000-08:00

I've been fooling around with an Ardunio, which is a small embedded microprocessor and discovered that its a great way for software engineers to learn some hardware engineering. It is fairly limited in its outputs though, so I bought a couple of M5451 chips (futureelectronics.com MM5451YN for small quantities). This is nice because it is a 40 pin DIP device that plugs right into a breadboard, and is intended to drive LED displays.

But it does not HAVE to be used for LED displays -- I'm thinking of it as 35 constant-current switches that can be conveniently controlled (on/off) by 2 Arduino digital pins (clock and serial data). And if you want to change the current (of all pins) you can use a third pin to connect a "brightness" pin on the 5451 to a PWM on the Arduino.

So this is a *LOT* cooler than the chips that drive 8x8 arrays of LEDs by strobing them (MAX7219, search for "Arduino 8x8 matrix") because those chips flash the LEDs. So they really can't be used for other applications (like driving motors, or turning on a big-current transistor switch), and the LEDs are in theory not as bright because they are not on the entire time. In theory, I should be able to drive 2 of these 8x8 matrixes with one M5451 with 3 outputs left over, or one 16x16 (256 LEDS!) display (if I can get my hands on one).

Also, the cool thing about the M5451 being a constant current driver is that you don't need a current-limiting resistor inline with each LED. And you can connect several LEDs in series without worrying about V=IR math.

But let me emphasize for the beginning hardware DIYer, its important to NOT think of the outputs as logic, just think of them as switches. Basically you connect the M5451 to ground, and connect your load (let's just use LEDs, for example) between the + and it. So the M5451 must be on the cathode, minus, ground side -- whatever you call it -- of your LED. This is IMPORTANT, since if you buy something like RGB LEDs you want to get common ANODE. Remember, relative to the LED, the anode side is where conventional current (+) goes IN.

Of course, I bought the common cathode RGB LEDs (*sigh*).

So here's a picture of a M5451 on a breadboard with a boarduino and with a bunch of LEDs:

Ignore the upper part of the breadboard. all the activity is on the bottom. Also ignore the square silver chip and transistors on the far right. That's just stuff hanging around from another project!

The boarduino is on the bottom left. The 2 pins used are the green and yellow wires on the top side (the blue and short green wires are just power and ground).

You can see all the LEDs bridging from the + rail to the pins on the M5451 (middle)

I wrote a bit of code to drive the M5451 (see below). You can turn on each M5451 switch independently, control the brightness via one of the Arduino's PWM ports (PWM means pulse-width-modulation -- the Arduino toggles the line between 5 and 0 volts rapidly and so that it seems like the line actually has a voltage which is the weighted average of the time the line is 5 vs. 0 -- i.e. a simulated analog voltage).

On top of that, I made a class that is similar to PWM; it toggles the M5451 lines rapidly so the LEDs seem to change brightness.

Here is a video. To make it come out, I have a halogen desk lamp shining directly on the board from about a foot away. About halfway through I turned off the light so you could see the LED brightness in normal room light! Check out the video here:

Here's the code:


/*
 * M5451 LED driver chip
 * Author: G. Andrew Stone
 * Public Domain
 */

int myClockPin = 2;             // Arduino pin that goes to M5451 clock
int mySerDataPin = 3;           // Arduino pin that goes to M5451 data

void setup()                    // run once, when the sketch starts
{
}


#define M5451_NUMOUTS 35
#define M5451_CLK 0
class M5451
{
  public:
  byte clockPin;
  byte brightPin;
  byte serDataPin;
  M5451(byte clockPin,byte serDataPin,byte brightPin);
     
  void set(unsigned long int a, byte b=0);
  void setBrightness(byte b);
 
  private:
  void mydelay(int clk);
};

void M5451::setBrightness(byte b)
{
  if (brightPin < 0xff)
    analogWrite(brightPin,b);
}

#define MaxBrightness 4096  //256
class FlickerBrightness:public M5451
{
  public:
  FlickerBrightness(byte clkPin, byte dataPin, byte brightnessPin);
 
  void shift(int amt=1)
    {
    offset+=amt;
    if (offset>=M5451_NUMOUTS) offset -=M5451_NUMOUTS;
    else if (offset< 0) offset +=M5451_NUMOUTS;
    }
  void loop(void);
 
  int brightness[M5451_NUMOUTS];
  int bresenham[M5451_NUMOUTS];
  int iteration;
  int offset;
};

FlickerBrightness::FlickerBrightness(byte clkPin, byte dataPin,byte brightnessPin):M5451(clkPin,dataPin,brightnessPin)
{
  for (int i=0;i < M5451_NUMOUTS;i++)
  {
    brightness[i] = 0;
    bresenham[i]  = 0;
  }
 
  iteration = 0;
  offset = 0;
}

void FlickerBrightness::loop(void)
{
  int i;
  byte pos;
  unsigned long int a=0;
  byte b=0;
  boolean lvl=false;
 
  for (i=0,pos=offset;i < M5451_NUMOUTS;i++,pos++)
    {
      if (pos>=M5451_NUMOUTS) pos=0;
      bresenham[i] += brightness[pos];
      if (bresenham[i]>=MaxBrightness)
        {
          bresenham[i] -= MaxBrightness;
          lvl = true;
        }
      else lvl = false;
     
      if (i<32) a = (a<<1)|lvl;
      else b = (b<<1)|lvl;
    }
  iteration++;
  if (iteration > MaxBrightness) iteration = 0; 
 
  set(a,b);
}


M5451::M5451(byte clkPin, byte dataPin, byte brightnessPin)
{
  int i;
 
  clockPin = clkPin;
  serDataPin = dataPin;
  brightPin = brightnessPin;
 
  pinMode(clkPin, OUTPUT);      // sets the digital pin as output
  pinMode(serDataPin, OUTPUT);      // sets the digital pin as output
  pinMode(brightPin,OUTPUT);

  // Clear out the device so we can clock in items
  digitalWrite(serDataPin,LOW); 
  for (i=0;i< M5451_NUMOUTS+2;i++)
    {
    mydelay(M5451_CLK);
    digitalWrite(clockPin,HIGH);
    mydelay(M5451_CLK);
    digitalWrite(clockPin,LOW);   
    }
}

void M5451::mydelay(int clk)
{
  int i;
  for (i=0;i< clk;i++);
  //delay(clk);
}

void M5451::set(unsigned long int a, byte b)
{
  int i;

  // Write the initial "start" signal
  digitalWrite(clockPin,LOW);
  digitalWrite(serDataPin,LOW);
  mydelay(M5451_CLK);
  digitalWrite(clockPin,HIGH);
  mydelay(M5451_CLK);
  digitalWrite(clockPin,LOW);
  mydelay(M5451_CLK/2);
  digitalWrite(serDataPin,HIGH);
  mydelay(M5451_CLK/2);
  digitalWrite(clockPin,HIGH);
  mydelay(M5451_CLK);
  digitalWrite(clockPin,LOW);
   
  // Write the bits
  for (i=0;i< M5451_NUMOUTS;i++)
  {
    int serDataVal;
    if (i<32) serdataval =" (a&1);">>=1;}
    else { serDataVal = (b&1); b>>=1;}
    mydelay(M5451_CLK/2);
    digitalWrite(serDataPin,serDataVal);
    mydelay(M5451_CLK/2);
    digitalWrite(clockPin,HIGH);
    mydelay(M5451_CLK);
    digitalWrite(clockPin,LOW);
  }
}

void loop()                     // run over and over again
{
  unsigned long int j;
  int i;
  FlickerBrightness leds(myClockPin,mySerDataPin,9);
 
  leds.setBrightness(255);

  for (i=3;i>=0;i--)
  {
    for (j=0;j<35;j++)
      {
      leds.set(1L<< j,(j>=32) ? 1L<<(j-32):0);
      delay(10*i);
      }
  }

  // Proportional fading
  if (1) for (j=0;j<200;j++)
    {
      for (i=0;i< M5451_NUMOUTS;i++)
        {
          int k = 1<<(j%13);
          if ((i&3)<2)
          {
             if (leds.brightness[i] < 35) leds.brightness[i] = 35;
             else leds.brightness[i] += leds.brightness[i]>>2;           
          }
          else
          {
             if (leds.brightness[i] < 35) leds.brightness[i] = MaxBrightness;
             else leds.brightness[i] -= leds.brightness[i]>>2;           
          }
        }
      for (i=0;i<100;i++) leds.loop();
    }

  leds.set(0xffffffff,0xff);  /* ALL ON */
  delay(250);
  leds.set(0,0);  /* ALL OFF */
  delay(250);

  // Linear per-LED brightness method
  if (1) for (j=0;j<4096;j++)
    {
      for (i=0;i< M5451_NUMOUTS;i++)
        {
          int k = j*10;
          if (i&1)
          {       
            leds.brightness[i] = abs((k&(MaxBrightness*2-1))-MaxBrightness);
          }
          else
            leds.brightness[i] = MaxBrightness - abs((k&(MaxBrightness*2-1))-MaxBrightness);
        }
      for (i=0;i<10;i++) leds.loop();
    }


  // ALL FADE using M5451 Brightness feature
  leds.set(0xffffffff,0xff);  /* ALL ON */
  for (j=1;j<5;j++)
   {
   for (i=0;i<256;i++)
      {
      leds.setBrightness(i&255);
      delay(j);
      }
   for (i=255;i>=0;i--)
      {
      leds.setBrightness(i&255);
      delay(j);
      }
}

  leds.setBrightness(255);

  leds.set(0xffffffff,0xff);  /* ALL ON */
  delay(250);
  leds.set(0,0);  /* ALL OFF */
  delay(250);


  // MARQUEE
 
  for (i=0;i< M5451_NUMOUTS;i++)  // Clear all LEDs to black
    {
      leds.brightness[i]=0;
    }
   
  // Turn on a couple to make a "comet" with dimming tail 
  leds.brightness[0] =  MaxBrightness-1;
  leds.brightness[1] =  MaxBrightness/2;
  leds.brightness[2] =  MaxBrightness/4;
  leds.brightness[3] =  MaxBrightness/8;
  leds.brightness[4] =  MaxBrightness/16;
  leds.brightness[5] =  MaxBrightness/64;
  leds.brightness[6] =  MaxBrightness/100;

  for (j=0;j<100;j++)
    {
      leds.shift(1);
      for (i=0;i<150;i++) leds.loop();
    }
   
  for (j=0;j<100;j++)
    {
      leds.shift(-1);
      for (i=0;i<100;i++) leds.loop();
    }
 

  if (1)
{ 
  leds.set(0xffffffff,0x7);
  delay(1000);
  //leds.set(0xf0f0f0f0,0x7);
  //delay(10000);
  //leds.set(0x11111111,0x1);
  //delay(10000);
}
 
}