Hedge Court Robots

• Color Pong
• Overboard
• Philly
• Symet
• Sandwich
• Roverbot

Overboard

Overboard is a debugging tool intended to assist with developing other circuits. It is a daughterboard designed to allow a variety of output with minimal communication overhead on the motherboard sending input to the Overboard.

The name started out as Outboard, because the purpose is to provide human-sensable output to help debug circuits and microcontroller development. Once my imagination started going, I went overboard and kept thinking of more features and scope-creep was in full swing. Thus the name was changed from Outboard to Overboard.

Overboard is a work in progress, and will have several iterations. Each version will help me gain experience with some microcontroller concepts or fabrication techniques. The current "production" (completed) version is v0.1 (which is the first one), and version v0.2 is in the early design stage.

Someday, the vision for the configuration to include 8 LED indicators, an audio module with 8 built-in tones, and a 20x4 character LCD display. Communication with the Overboard is still being determined, as version v0.1 is a stand-alone board for me to practice doing schematics in Eagle and then fabricating PCBs. The instruction set is not developed yet, but will try to be simple for the LEDs and audio output, and I have no vision of how I want the LCD instructions to work yet (but will probably be built around a fixed display with various positions that bytes can be dropped into, like a mainframe green-screen form).

---

v0.2

Date: started on 24-Nov-2006, and still in progress. May sit for a bit because I'm working on Cubeulon first.

 

Pre-Construction Thoughts: This second iteration of Overboard is aimed at adding an EEPROM chip to store the music notes for the songs. At this initial point, I'm not sure what uC I'll use. I can use some public C libraries to bit bang the I2C connection to an EEPROM, but I think I'd like to use a chip that has hardware support for TWI. Also, I don't know how I'm going to write the data into the EEPROM. I'll have to investigate if avrdude and the AVRISP hardware can do it, or maybe the STK500 dev board. If not, then I'll have to build in the capability to write the EEPROM. For that, I'd probably want to have a serial connection to a PC, and some quick-n-dirty program on the PC that'll send serial bytes to the uC, and it'll then write that data to the EEPROM. I'll have to build some "mode" detection logic so the Overboard will know if it's in EEPROM writing mode, or normal music mode. And the ATtiny26 doesn't have UART support, so that serial connection would be bit-banged as well. Its looking like I've outgrown the tiny26. ATmega168 looks like it has the features I want, and it comes in a 28-pin DIP package, which isn't too much bigger than the 20-pin tiny26.

---

v0.1

Date completed: 23-Nov-2006 - Happy Thanksgiving!

This is the first iteration of Overboard. When I sat down to think about the features I wanted in the final version of Overboard, I quickly came to the conclusion that I'd have to build up to that, taking baby steps along the way. This first step was intended simply to gain experience with creating musical notes with Pulse Width Modulation (PWM), using Eagle for schematic and board design, and fabricating PCB's in my basement. I had a side goal of ending up with a more useful ATtiny26 Dev board than my first one, but that sort of came into my mind later, after I decided to use my first dev board during software development for this one.

When I started out, this first board was simplified in the following ways:

• eliminate inter-board communications, so its a stand-alone board.
• stick with a voltage regulator (LM7805) that I've used before, even if its got a bad voltage drop-out.
• don't include LED output so I can focus on PCB layout and fabrication in a slightly simplified environment

And once I got going, I learned tons about microcontrollers and Eagle and PWM and PCBs and memory management, and on and on and on. So I discovered more limitations in v0.1 that I didn't even know I was including when I started. For instance:

• The ATtiny26 has 2k RAM and 128 bytes of EEPROM. This limits the number of songs that can be stored. I made some software adjustments to be more efficient, but this is too little on-board storage for music applications.
• And then, a whole slew of limitations became aparent once I started looking into external EEPROMs. For instance, I'd want to edit music data on my PC and then upload it via serial cable to a uC which will then program an external EEPROM. From what I can tell, ATtiny26 has no TWI hardware, and also no UART, so connecting to external I2C EEPROM and PC via Serial will be rough.
• I started having trouble with getting exact frequencies for music notes via PWM. As it would turn out, ATtiny26 has 8-bit timers which gives you less resolution than 16-bit timer. Perhaps an ATmega168 would be nicer, while still keeping pin count low (28 rather than 20 for the tiny26).
• I got major bot-block and paralyzed myself with Eagle. But then I took the time to create my own component library, so all components on the board come from my lib. Much more intuitive now, and hopefully an investment that future boards will benefit from.

Overboard v0.1 Features:

1. Power Switch
2. Battery Connector
3. Jumper/Header for measuring total circuit current draw
4. LM7805 Voltage Regulator - with decoupling & bulk capacitors
5. ATtiny26 microcontroller - with decoupling capacitors
   • Reset pin connected to VCC with pull-up resistor and momentary push-button switch to pull it low
   • PB5 has an LED and current-limiting resistor connected to VCC (set the PB7 low to illuminate).
   • PB4 has a momentary push-button switch (MODE button) that can be used to pull the pin low.
   • Both Port A & Port B have a 10-pin header (8 port pins, plus VCC & GND).
   • PB2 has a special test point because it is OC1A which is the output for PWM for music. I made the special test point so as to not have to fiddle with the PORT B header when measuring PWM frequencies.
   • AVRISP, a 6-pin header for in-system programming.
6. LM386N audio amplifier
   • PWM signal from uC is passed to an audio (logarithmic) potentiometer for volume control
   • 8 ohm board-mount speaker
   • 2-pin header to enable/disable the 10x gain for amp'd volume (hidden behind a capacitor in the picture).
7. Make-shift silkscreen component outlines on the top layer using laser toner and an iron. Made component placement and air-wire creation a breeze, plus convenient labels for the port breakout headers and buttons. I learned about the Eagle SMASH command after I did this, so the labels are positioned some what silly.

The firmware I wrote is pretty simple, written with AtmanAVR C. To play music, populate an array with OC1C values which determine the frequency (note) to play. Populate another array with duration value for how long to hold the note. At first I had the durations stored as an array of integers, which hogged memory royally. To conserve RAM, I actually ended up packing the frequency value and the duration value into a single byte, with the stipulation that I would only support 32 notes and 8 durations (5 bits and 3 bits, respectively, fitting nicely into a single byte).

The effect when I used up available memory in the main() function was fun. It would play normal notes until it hit an index in the array that was outside what the memory manager liked, and then it would randomly choose a value, so random notes would play for the durations I wanted the real notes to play for. Then I came up with the packing described above.