Happy 2010! Resolutions & Review

Now that I'm back from Christmas break, I am filled with a newfound resolve! Actually, for the new year I resolved to make my robot army self-aware by November. So I'd better get crackin, eh? Good news is I'm awash with new ideas built up in the hiatus. For example, I heard you can build guitar effects using components commonly found in compact florescent lamps - neat! (see Make: magazine vol 19). I also have a malfunctioning remote car start module with neat still-working radio tranceiver stuff with which I could do interesting things. The makerspace crew here in Urbana are still bringing the space towards fully operational (doors-open day), so there's lots going on there too. But today I decided to focus on a Chrismas present given to me by my daughter: Tom Igoe's book, Making Things Talk. For those not familiar, this book is a practical walk-through guide on creating physical interfaces that can communicate with our arduino or other platforms. It's just what I've been working at, so what a great gift. I decided to use it for some of our future experimentation.


I skipped around a bit in the beginning of the book. Yeah, got tools. Yeah, know what a network server is. Yeah program in PHP. Yeah know what a pulse is. Yeah yeah yeah. I skimmed right to the part where the author mentions some API called Processing which allows us to write some Java-looking programs which will ostensibly help later on? Looked interesting, so I went to processing.org, got the Linux version, installed it, and proceded to write some sample code that takes some mouse inputs and draws some artsy muticolored triangles. I modified the code in the book, and my daughter played with the thing for twenty minutes.  Noteworthy is the fact that processing programs were also called "sketches", which was was the Arduino API program also called its programs. I started Arduino and confirmed that the two were not the same thing (Arduino uses AVR-GCC, not Java), but I thought this was interesting and maybe not coincidental.


Next, the book gave pointers on using CLI, ssh, and nano (nano? really?). After that, more on Arduino, the Arduino API, and some other platforms, such as Wiring (similar to Arduino), using raw AVRs and PICs. It breifly went into basic circuits, and how to pull pins high and low with pull-up and pull-down resistors and switches. Interesting, but we're past that stuff. I skipped along until it delved into serial communications in chapter two. I finally found out what those MISO and MOSI pins from the AVR programming interface (what was that, 2 months ago?) are for - apparently what I didn't get before was the fact that there are two kinds of serial comms. The first one, the one we all know so well, is asynchronous. This is our 2-wire grounded serial. The second is synchronous and requires a master to initiate the connection. The master provides a clock signal (CLK) for and has a chip select line (CS - not sure what this is for though), and the data lines, Master-In, Serial-Out (MISO), and Master-Out, Serial-In (MOSI). That being said, asynchronous should be fine for now. Also learned a bit about the nature of USB, and how we can host multiple serial connections on a bus and sort out all the signals

I wrote some code in the Arduino API that communicated over the USB->serial interface and messed around with it in minicom while blinking an LED, of course. I suppose the first chapter and a half was a good review of everything I've figured out up to now. At least I've some affirmation from several sources that I'm focusing on the right things.

Review time is over. Let's start getting into some project work. In the next couple of weeks, I intend to make the pong-playing stuffed monkey (monski) project in chapter 2, where we abtract the mouse input into a data object and learn about communication flow control. Also, since I've already taken apart a CFL and recovered the neat electronics, I will be making some guitar effects pedals for my rocker girl using the plans in Make: Volume19. Excited? I am. Enough blinky LEDs, time to make! Happy new year!

Nascent Makerspace Emerging

This week I put aside my normal tinkering to help some friends organize a makerspace in Urbana. This is an organization dedicated to enabling the mashup of arts, humanities, hard and applied sciences and technology. Learning and collaboration are key goals here, so you know I'm all over that like white on rice. I figure every minute invested on making this idea into reality is well spent, since I realized the value of bringing together a community of artists, technologists, students, scientists, mathematicians, kids, tradesmen, tinkerers, dreamers. It is well spent because the collaborative nature of the effort should yeild more "eureka!" moments than if we all journeyed separately (as I've been doing in this blog). It also allows us to give back to and support each other in many more tangible ways than just sharing knowledge on a page. Additionally, I realized I may be able to reinforce my knowledge by actually putting together some ideas and presenting them to an audience, not to mention applying what I know to other interesting problems presented. All around, it's a very attractive idea, both from selfish and benevolent standpoints.

We have no name yet. We have a mission statement draft, some starting organizational designs, and several enthusiastic individuals who are willing to sacrifice time, talent, and treasure to make the idea a reality. We are on the verge of having a 500 sq ft. space nailed down. We have piggybacked our association such that we will start out of the chute with 501(c)3 nonprofit organization status. As I write, we are inventorying all of the tools we have already and all the stuff we need. So much yet to accomplish. I'll keep you all posted, so stay tuned.

Until then, keep your irons hot. A makerspace* may be coming to your town.

* NOTE: "Makerspace" is synonymous with "hackerspace" or "hackspace", but since the news media and government has taken the term "hacker" and projected it to the masses as lawlessness and destruction, to prevent confusion we will refer to our effort as a makerspace. We will however display the glider logo, as we truly do identify with the hacker culture as defined by ESR.

Links:
"Respect the Past, Examine the Present, Build the Future" (hackerspaces)
"Hack the Spaces"
"Building the MIlwaukee Makerspace" JSOnline, The Milwaukee Journal Sentinel
Noisebridge Vision Statement

If you are around the Urbana-Champaign area and are interested in making stuff with us, message me, either through the comments or via DM on twitter.

Additionally, if you wish to help by donating or lending equipment such as a CNC mill, oscilloscope, drill press, lathe, MIG welder, or other maker gear, contact me either through the comments or via DM on twitter. 

Grokking Arduino

Now that I've constructed from scratch a testbed with a stable 5 VDC power supply, used it to power the ATMega168, added a rs232 interface, external timing, blinky blinky LED's an so forth, I decided perhaps I could now partially comprehend just what's going on with the all-inclusive Arduino platform. So I ordered an Arduino Duemilanove from Sparkfun to get a closer look. I set out to find out what all the hubbub was all about. After all, it's just a prebuilt AVR sled, right?

I first took a look at the hardware. If you look closely, you will see a lot of familiar stuff. Let's see, I see an AVR. I see a FTDI rs232 interface, with nifty SMD RX and TX LEDs. I see a power interface, voltage regulators with a couple electrolytics and a diode. I see a 16 Mhz crystal. I see a reset switch. I see some pin headers. So far, this thing has everything we built on our breadboard. Well, OK it has a few extra nifty hardware fetatures. Number one in my book is the USB interface. Notice two voltage regulators? Makes sense, we can power from our wall wart or alternately from the same USB interface we use to program. That is pretty nice. No more hacking 18ga wire spaghetti to the MOSI and MISO pins. Of course a biggy is the ATMega328 - It's a drop in replacement for the ATMega168, but with twice the program space. I also see some nice analog and digital I/O pinouts. I see an IC marked "358 G35A" - is that an op amp? It's over near the analog inputs, so I suspect that's the case. Let me know if I missed anything.

I spent some time readying my laptop to use all the Arduino environment goodness, and in doing so stumbled upon the why this thing is so cool. Sure the hardware is nice, but the Open Source Arduino development environment is the real jewel here. I had been spending my cycles manually driving avrdude and avr-gcc with my ATMega168/breadboard setup, which is fine for some with technical leanings, but what the Arduino folks did with their "sketch" programming environment was to abstract most programming tasks into something akin to snapping Legos together. And they open sourced the entire thing (I was on the verge of making my usual kneejerk dig on the Java programming language that Sketch was designed in, but it's so cool, I am going to let it be)! Now I haven't dug incredibly deep on this, but I get the idea. Of course this means they may have just successfully opened up a technology wide open for use by those who could care less about the inner workings, and more about creating cool shit. I may want to dig into C code, but now it seems that's a choice, not a requirement. Way cool. Way cool.

I was going to go into detail, explaining to you Internet readers all the crap I had to do to to get the environment working on my Ubuntu 8.10 (Intrepid) system, but it's late and probably largely irrelevant. Just a few notes before I part: Remember that you need avr-gcc 4.3.3 or better because 4.3.1 and older jacks up calculations with long ints on the 328. I solved my problems just by uninstalling all my AVR tools, logging into AVRFreaks and replacing them with the AVR tools DEB package supplied by them to address the issue. Or you could run Jaunty, or a Mac, or hell even Windows. However you do it, you have to check this out. Playing with Arduino is going to be excellent fun. In fact, I am going to show it to some of my artist pals to see what they do with it. I know what I'm going to do with it. Something big.

Links:

AVRFreaks avr-gcc 4.3.3, avrdude, avr-libc, binutils, etc install scripts (requires account+log-in)

Arduino Development Environment (arduino.cc) (Sketch + tons of extra libs n stuff)

Arduino Docs, Tutorials, Examples (arduino.cc) 

Arduino Blinky LED Tutorial (sparkfun)

Arduino Blinky LED Tutorial (Ladyada.net) 

Crafter Goes Nuts With an Arduino LilyPad! (Craftzine)

avr-gcc Programming Guide

Happy Thanksgiving

I really thought I'd do something this week, but at present. I am drinking wine with my chix0r, and playing with a robotic cockroach on the dining room table with my daughter. Screw it, it's a holiday weekend.

All I have for you this week is some information from my readings. When rummaging around at my house, I uncovered my old copy of TTL Cookbook by Don Lancaster - a classic! For fun, I looked up our 74HC164 shift register from last week. I learned that the function of this device is a lot like seating 8 people for Thanksgiving dinner, then ordering them all to attack the buffet at once :) There will be more on this when we get this in and put it to use. There wa also much other goodness I will be referring to in the future (555, 556 timers, etc). I have also been digging around in Applied Robotics by Edwin Wise. We will be making motor controllers using N-channel MOSFETs in the near future using plans from there.

OK enough for now. Time to go eat some lox, drink some wine, and count my blessings.

Shift Registers are Important

I started out this week's lap looking at my options. I had a RS232 shifter board kit. Interesting, but that's mostly a bunch of boring soldering. I just received a cool new Arduino Duemilanove! Sweeter than sweet, but I don't have the required version of AVR-GCC installed (you need 4.3.3 for the ATmega328 due to a bug in older versions - I currently run AVR-GCC version 4.3.0). Compiling software is not how I planned on spending my Saturday, so nixed. The 16x2 LCD display I bought to monkey around with sounded pretty good.  Figured it should be fun figuring out how to display something childish and dirty to the little guy!

Knowing practically nothing about the display, I started with a close examination of the hardware. Nothing dramatic, besides the display screen, the only other outstanding feature on the display was 16 solder pads on the edge. To figure out which pad was for what, I consulted the data sheet - and almost fell asleep! OK, from an EE perspective, all that stuff is interesting, but I thought this was not quite the right doc to start with. Too low, like in the freakin weeds low-level. Being the impatient pragmatist, I want to see working examples and overviews first, and then later on maybe we can put a microscope on in to scope out the bit plumbing. I found better (better, I mean because I could at least identify what was useful) info on the manufacturer's sheet. Found out I have 8 data lines, power (Vcc, Vss), some adjustment inputs, register select and read/write controls, not to mention some ambiguously labeled control input called "enable" (insert Spock sound byte: 'fascinating!'). I think I may understand what most of these might do. Now was the time to dig deeper though, since I didn't have enough to go on yet.

When ferreting out more info on the unit, I discovered that the HD44780 character display seems to be a defacto standard. This means many different manufacturers make character displays, using the same basic interface. This is a good thing. Why? Well because this means I will likely never need to read the datasheet ever again, since many engineers have already done this and documented the living dogshit out of it prior to my arrival. Have I mentioned that at this point I felt all mushy and awkward toward Peter Ouwehand for having an entire site dedicated to HD44780 character displays? I'm gonna send him a fruit bastket just for saving us from that nasty datasheet. He has examples! Examples!

I jumped quickly to a linked AVR example. For whatever reason, the first thing to leap out at me was the 10K trimmer required for the contrast adjustment. Luckily, after digging through my stuff I found that my arduino kit included a 10K trim pot. Why the 74HC164 interface IC on there didn't register in my consciousness first is an utter mystery. It did eventually though. And when I finally figured out what "serial in, parallel out shift register" means I knew my day was destined for shortness. Yep, the 74HC164 takes serial input and then outputs to a parallel device. This whole time I guess I had assumed the LCD display somehow used serial I/O. I imagine the datasheet may have had this info somewhere between all the clock timing specs and register state bitmaps, but really just seeing 8 data I/O pins should have tipped me off! Hey well I do learn eventually.

Without a shift register, I was pretty much done. Ordering one right now so we can do this up later. I spent the rest of my project time soldering up the RS232 shifter board. Looking great! Except I couldn't find my dikes to snip the legs. So tune in next week! Does Chuck find his dikes? Will he also notice that the example uses a dissimilar AT90S2313 micro? Will he reread the evil datasheet and slip into a coma? Why is there a pizza in the first picture of this blog? The suspense! Have a great week, and happy hacking everyone.

Mucking About with Code and UART I/O

While attending my daughter's dance recital Saturday, my mind stuck on the word "recital". The kids weren't reciting anything, they were dancing. Neither do kids at a piano recital actually recite anything, and so on*. "Recital" I suspect is one of those words originating out of a specific common event, which eventually broadened in definition to mean any event where a pupil demonstrates his progress and/or achievement in a very formal and public way. Once I sorted it out in my head, I realized I am performing sort of an electronics recital here, am I not? Only difference is, when I'm done I intend to launch killer flying killer robots instead of playing "Mary had a Little Lamb". Heck, I might even make flying killer robots that play "Mary had a Little Lamb"! Onward with the recital then...

I did Sparkfun's Beginning Embedded Electronics tutorial #5. It was labeled "AVR GCC Compiling", but I like my title better, since we really do just muck with some code and our serial interface some more. And that's cool with me, I have a little 16x2 serial display on the way; I need to get a handle on this stuff. I realized late last week that the subtext to last week's lab said we'd printf some foo to our monitor via a running program on the AVR, and somehow that never happened. Until now, of course.

I started by compiling and writing the "basic-out-atmega168" program to my micro. Of course I noticed right away that something wasn't quite right - The code was supposed run on the micro and output something like "Test it! x = 1Test it! x = 2Test it! x = 3Test it! x = 4Test it! x = 5" to my minicom (terminal emulator) screen. What I got was a bunch of garbled crap. Looked like the inventor of ASCII threw up in my term session. Good time to recap what we learned last week. I did a successful loopback test on the UART. Looking at the schematic for the max3232 indicated I tie RX and TX on the micro somehow to "R1OUT and T1IN".  A break in the drawing doesn't show which goes to which though. I guessed RX went to the transmit pin and TX to the receive pin. A basic crossover connection, right? Looking at the resultant garbled crap made me think about what the RS232 controller really does - it does some voltage foowankery, but basically it's a traffic cop, a pass through. That means the TX on the micro goes to T1IN and RX goes to R1OUT, and all would be fine. It was. Program now works. Just a note, Homework for this week is to see if I can manage 2 serial streams with this guy, cause I noticed a set of unused pins labeled R2xxx, T2xxx.

Can you spot my rookie screw up here? This setup can't work.

The tutorial goes over some basic methods used in C to twiddle bits, toggle GPIO pins, and set other options. After a while, it'd probably be good to spend some time rooting around header file avr/io.h to see what interesting AVR defines and directives exist. Even though the tutorial skirts around the subject, now is probably a real good time for me and anybody else who hasn't used a bitwise C operator since college to get a good refresher. They are of course used to enable things that could make life sweet, like the TX and RX pins (RXEN0 & TXEN0). More homework for lucky me. The author states that he never starts any code from scratch - he always modifies existing code. If I actually trusted other programmers, I might use this method. But since I trust neither the coders out there, nor coding contexts as germane to my efforts, I think I may spend more time getting familiar with the coding end of this whole thing. I can't recommend my way over Sparkfun Nate's, as it will be considerably more work, I imagine it just depends on whether you trust people or not. Damn, trusting people is a lot less work than my way. *sigh*


I won't discuss compiling and loading the second program, since it was uneventful, so that's it for now. Time to think about using the interface for more useful stuff. Like I said earlier, I have a 16x2 serial display en route. I'll see if I can get the micro to display to it next week.

The next 2 Sparkfun tutorials deal with soldering. I am probably going to skip these. This does not diminish the importance of good soldering technique, I am just already pretty good at this. Not sure about the CAD ones either. I have downloaded the free Eagle CAD software (good stuff! they have great Linux support!) and will use it to design my stuff, but I want to keep focusing on getting the micro to bend to my will, not peripheral stuff. So I guess that means I am pretty much done with the Basic Embedded tutorials at Sparkfun! Woooo! Be sure to check out their last one, which is basically things to do to prevent frustration and embarrassment. I should formally thank them for sharing all the learning material. I had fun and now know a little something about something.

*If one was performing an original oratory for the very first time, would that just be a "cital"? Or does one "cite" when first putting pen to paper? No, I would think it drafting or composing. And then everyone repeating it would then re-cite it? No, that would be speech, or speaking. But there is no "respeeching" or "respeaking", only recital. Strange word. Calling all linguists! Attack!

Installing and Testing a Serial Interface

As I wandered through the farmer's market in Urbana this morning, instead of thinking about tasty dishes I could cook, I was wondering if I could use the the old potato-battery trick to power a micro. So that pretty much tells you where my head is these days. According to this guy, we'd get 0.5V with 0.2mA, so that means we'd need what? A bakers dozen to safely power our ATMega168? Good to know if I ever get stranded without power in Idaho! Maybe for fun I'll do this later on.

Now, down to the business at hand: Today I hacked a serial interface onto the ATMega168, using a MAX232 IC, and tested it using Linux and minicom. I was loosely following Sparkfun's "UART and Serial Communications" tutorial, but with the normal diversions to use tools commonly used with Linux. In this case, the tutorial would have us test out the rs232 interface by firing up Hyperterminal (infernal Windows term thing). Yeah, you know me. I was all "we're totally not doing that."

Here's where I started: I have a max232 IC which is my serial interface. I really don't have to know much about it, other than the fact that it converts +/-12V signals to usable 0-5V signals for our micro and other UART magic (the charge pump link in the tutorial is pretty interesting though). I noticed again no mention of static guarding IC's; Am I just too anal about this? I still don't have a grounding strap for my wrist, but I grounded myself to the leg of the table before I carefully bent the pins and installed it on my breadboard.

It was nice to know about the decoupling caps - I suppose I should plan on keeping a bucket of 22 and 10 uF ceramics around. I noticed also we weren't using electrolytics anymore for decoupling. We used them for the 5V power supply, but not for the oscillator nor for this max232. Can anyone tell me when one is preferable over the other? The datasheets of course specify ceramics, and that's fine. I was just wondering.

When installing the caps, one thing jumped out at me. Caps decoupled pins 1&3, 2&6, 4&5. Pins 7&8 are unused. Sound familiar? It did to me. That is the wiring order for a CAT5 UTP crossover cable! And it made sense: Back in the day, the first ethernet cards I remember had serial-looking interfaces on the back and often required tranceivers to accept CAT5 with an RJ45 end. I should've made the connection back then, but probably had my mind on other crap! Just an interesting note.

I put a loop on the TX and RX pins of the IC, so whatever input I give it will be puked right back out. In this state, we are able test the proper functioning if the max232 by hooking up a terminal emulator or heck, even a real vt100 terminal if we want!.

The tutorial tells us to use Windows' Hyperterminal, or maybe TeraTerm. Nonsense I say! Linux! I used minicom. Minicom on my Linux laptop had no pre-set config, and defaulted to some bad defaults which I needed to change.

Welcome to minicom 2.3

OPTIONS: I18n 
Compiled on Oct 24 2008, 06:37:44.
Port /dev/tty8

              Press CTRL-A Z for help on special keys

You'll notice it defaults to tty8. We need to change that and switch the port speed to 9600bps. The quickest way to do this is to hit "ctrl-A O" once minicom starts.

+-----[configuration]------+
| Filenames and paths      |
| File transfer protocols  |
| Serial port setup        |
| Modem and dialing        |
| Screen and keyboard      |
| Save setup as dfl        |
| Save setup as..          |
| Exit                     |
+--------------------------+

I selected "Serial port setup" and made the following changes:

+-----------------------------------------------------------------------+
| A -    Serial Device      : /dev/ttyS0                                |
| B - Lockfile Location     : /var/lock                                 |
| C -   Callin Program      :                                           |
| D -  Callout Program      :                                           |
| E -    Bps/Par/Bits       : 9600 8N1                                  |
| F - Hardware Flow Control : Yes                                       |
| G - Software Flow Control : No                                        |
|                                                                       |
|    Change which setting?                                              |
+-----------------------------------------------------------------------+

I ran into problems here. It's worth noting that I spent a while troubleshooting a seemingly non-working serial connection. I would type and type; nothing ever got puked back to the console. I noticed that the wires running to the DB9 interface were a little too loose for my comfort, so I got out the soldering iron and a new slice of bread and fixed that mess. Still no worky. After beating my head on it for a while I figured out that somehow changing minicom on the fly does not always work. When I saved the settings to a minicom config file and restarted, all of the sudden the thing worked fine. Yesssssss! I took the loopback plug out and connected the RX and TX pins if the max232 to the RX and TX pins of the ATMega. Now we're ready for some cool I/O fun!

So next time I will be doing the AVR-GCC lab. Not sure if it will be me just going off on my own, but in any event I will be using my new serial interface to debug stuff, which is cool! Later for now, all - I'm gonna go look at cool 19x2 serial displays and russet potatoes!