HLL - High Level Languages?

Here's a cool idea: The turtle is programmed by having the brain (ATmega128) read scripts off of an SD card. So, this can't be C. I need a simple (s-i-m-p-l-e) scripting language running on the ATmega128. Something Lisp-y would be nice. Forth is a bit too low level (I don't want to hack the hardware with this language, I just want to use it to send commands to the turtle).

Still searching....

Simplicity

Software is tricky stuff. I do it for a living. Integrating lots of open source code is very tricky stuff. Nothing ever quite configures the way you exactly need it.

Circuit design and soldering is tricky stuff to. Even breadboarding gets tricky when you have to hunt down that 48 ohm resistor and mail order it. Then, half way through the delivery time you realize that you need a 22pf cap too.

I'm going to try and minimized the tricky stuff for my iRobot (turtle) hacking. Where I can buy a "module" I will (rather than code up work-a-rounds or do any major soldering).

For example, I decided to go with a simple ATmega128 board rather than the butterfly. Why? Well, the butterfly already required me to solder header pins (for UART, JTAG and ISP to start). Plus the UART has a voltage converter (14v RS232) where the turtle wants TTL level serial. I would have to hack the butterfly (either with solder: put another level converter in or through software: utilize the SPI ports for UART). Hacking the butterfly was starting to look ugly.

With the ATmega128, so far everything is about jumper cables. This is simple and clean. I should be able to just hook it up directly to the turtle.

Now, regarding software...
I want the turtle's brain (the ATmega128) to be able to take instruction from files on an SD card. I need an SD card holder that has header pins I can connect to the SPI on the ATMega128. Okay, that was simple. But... How do I interface the SD and 128? Well, I need an SD driver and a FAT file system. There are some free implementations out there (of varying quality), but the real question is whether or not I want to take the time to "port and integrate" as well as if I want to suck away a significant portion of my precious 4K RAM (on the ATmega128).

Sigh. Money to the rescue? I am looking at this. It does everything I would normally do on the ATmega128 (regarding filesystem and driver mgmt). I have to think about this. Simplicity = Money? Complexity = Time/Effort?

The Butterfly has been set free.

The Butterfly will be freed to work on other projects. The new brain for the turtle is an ATmega128 from MicroController Pros:

Alternates to the Butterfly

Creating a decent DSL that consumes no more than 1K RAM is a challenge (for me at least). Certainly coding the runtime/VM in C adds to the challenge (and bloat).

However, all I really need is a looping facility, conditionals and some primitive form of global variable creation (1K is not a lot of space to get fancy and do closures, recursion and other forms of state capture).

First, thing is first: I need to study the iRobot Create Open Interface and see what kind of commands I need to send and responses I need to react to.

In the meantime, I stumbled upon this ATMega128 board. Nice price, more memory (4K RAM) and perhaps more suited to my task than the Butterfly.

DSL for Butterfly/Turtle

So far, the few languages I've seen for the AVR chipset are too general. I want to program the Butterfly to manipulate the Turtle. This is the only domain that I need to deal with. I could use a Domain Specific Language (DSL) that only addresses fundamental language constructs such as iteration and branching. The domain specific part just needs to manipulate the Turtle by way of the iCreate command set... And, all of this in 16K program (flash) space and 1K dynamic (RAM) space.

This should get interesting.

The little problem of RS-232 interfacing...

The turtle wants 0-5V (TTL) serial communications. The AVR butterfly has a level shifter that brings it's UART to RS-232 levels. A simple jumper between the butterfly and turtle would have been nice. Instead I have to look into using the turtles level shifting DIN connector.

But wait! According to this I can use the USI pins to emulate UART. This would be nice. Just 3 plain jumpers between the butterfly and turtle and a lot of tricky software ;-)

How to program a butterfly..

The AVR Butterfly is based on the Atmel AVR ATMega169. This mcu has 16K of program space and 1K RAM. That 1K of RAM isn't too bad when you consider that this chip is expected to be programmed in C.

I'm getting pretty good at cutting C for the AVR chips. But, this would prove to be too cumbersome to really do anything "interesting" with the iRobot iCreate (which I refer to as "the turtle"). I could write C code to do some basic tasks, but I'd rather have a means of scripting the turtle. On a bigger mcu (ARM7, etc) I'd just load up Lua or Tcl (or some implementation of Scheme). But, 1K isn't a lot of space for dynamicism.

So, I am going to scour the web for any decent alternative programming languages for the AVR (but not BASIC and what FORTHs I've seen don't do much for me). If I can't find one, I may have to roll my own!

Scratch!

It has finally been released to the public. This is very cool and (hopefully) very important. I always thought that Logo was tremendously interesting and important as a tool for kids to learn modeling and problem solving, but the reading/typing requirements were to high for, say, a 6 or 8 year old.

So, a graphic oriented way to program sounds about right these days, especially if capable of doing multimedia. Squeak Etoys seemed to have to high of a bar for beginners, but Scratch seems just about right...

Jumper wires?

How come these simple things are so hard to find? I see vendors that sell jumper pins. I see vendors that sell controller boards with mounted jumper pins. But these same vendors never carry jumper wires.

Okay, found one.

I need about 25 jumpers for the Turtle's cargo bay connector.

Choosing an AVR C compiler

This blog is lacking in pictures. I need to fix that. Unfortunately, for this post, C compilers don't make good photo material...

Choosing a C compiler should be a trivial matter, right? Hobby project? Limited budget? WinAVR or the GCC/AVR toolchain under linux are the sane choices.

Unfortunately, at work, I am using the world's most expensive C compiler (IAR) for my AVR work (its over $2000 for a full version; a "free" version is limited to 4K of code) and I am more familiar with it than the GCC/AVR toolchain.

A couple of other vendors offer 2K code limited "free" versions and aren't too pricey, but we are still talking about over $500.

Then, there is Rowley Crossworks AVR.

Rowley comes with a 30-day evaluation and a "personal" edition costs $149. From what I can tell it is the full blown version, but you can't use it for non-hobby projects. And, it has some "migration" compatibility with IAR! Plus, it is supported under Linux as well as Windows.

But, why in the world would I pay for a compiler?

Let's look at the potential negatives and my answers to them:

1. My source code won't be of use to those without the commercial compiler. True, but I am emphatically NOT trying to do a software project here. Binaries are royalty free and people will be able to "port" my code to GCC if they wish.
   
2. There are more libs (and support) for GCC/AVR out there. Arguable. Besides, I am going with "lightweight" here. No external libs, no OS.
3. No Emacs. Well, IAR supports external editors, but the other IDEs don't. I've been using emacs for 20+ years now... hard to give it up.
   

A big plus for a commercial IDE/compiler: JTAG support. Sure, I could use Atmel's free AVR studio with WinAVR to do this, but I am looking to spend less time hacking my development environment and more time hacking robots.

I'm currently evaluating the Rowley compiler.

Potential Butturtle Project

I won't kid myself and think that people actually read this blog, which makes it all the more unusual that I actually wrote this sentence....

But, I digress. While I am waiting for parts, I have started thinking about what I would have the AVR Butterfly do to the iRobot Create (which I re-christened "Turtle").

One thought is to have the butterfly use its new host (sounds parasitic, eh?) to roam around a room. I could mount a simple proximity sensor and have it head toward any object it detects until it hits it (and then it veers off to another direction). This would meant to model a butterfly flitting from flower to flower.

Or maybe it should have "moth-like" behavior and use the AVR Butterfly's built in light sensor to head toward light -- no wait, I would need 2 sensors (one left and one right) to do this, but you get the idea.

I don't have any practical plans for this Butterfly/Turtle hybrid, which makes it all the more fun.

Interfacing hardware needed

It looks like I'll be able to butcher the RS-232 shifter cable that came with the Turtle to adjust line levels between it and the Butterfly. Rather than use the DIN connector, I'll just remove the inline shifter board from the cable and hook it up to the Cargo connector (DB25). (Picture coming soon.)

Now, about that DB25... I am ordering this to provide an easy breakout to standard header pins.
So, I'll be waiting for USPS snail mail to arrive (this week?).

The Turtle has arrived.

The iRobot Create has arrived. It looks pretty durable and steady. The AVR butterfly will swim in the cargo bay.

The first thing I've noticed that I'll have to deal with is that the Cargo DB-25 connector supplies 5vDC (TTL) for serial communication. The butterfly has an RS-232/TTL level converter on board, so they are currently mismatched.

I'll either need to route around the butterfly RS-232 level converter or bring the Cargo connector up to RS-232 levels (blech). Temporarily, I can use Create's serial cable (which plugs into a side mounted DIN) -- it has a built in level converter.