I was trying to work around a problem a while back that I though would be fixed by upgrading the version of AVR-GCC I was using. While I got the new version working (4.3.5), it had removed the old version (4.3.4) and for the past few months I’ve constantly had to ignore warnings about not being able to find include folders.

The error was something like:

"Include path not found" /usr/lib/gcc/avr {version specific etc...}

The fix is pretty simple.  I found the solution here, but I didn’t follow it exactly.  It asks you to delete the following file – I didn’t want to risk losing any workspace settings, so I modified it instead.

1. Open up your workspace.
2. Open the file:  ${workspace}/.metadata/.plugins/org.eclipse.cdt.make.core/${projectname}.sc
3. Find all the references to your old library path.  I found three references near the top of the file – simply delete those lines.
4. Restart Eclipse.

For just a paragraph or two, I’ve gotta spill some philosophy.  Even before you have a family, and especially after you start one, hopefully everything you’re doing is for their current or future benefit.  There is nothing that can replace the fulfillment of a loving family, and like all great things, it requires preparation.  An interesting point of fact that is that Sam Walton, someone who spent his whole life innovating and who founded the largest retail chain in the world Wal-Mart, determined that he failed in life.  His last three words, given on his death bed while surrounded by his family that he hardly knew, were “I blew it!”

No one’s perfect, it’s just important to be making progress rather than regress.  New goal in life for me: Don’t blow it.  I gotta make a little bit more effort in that area, and I’m thinking even just a random act of kindness or two a day for the people I love will help.  Now, go to your room and think about it for 10 minutes, then come back and read the rest of my post. ;)

I got to work with a great group of people on a really fun, agriculture related robotic project.  I’ll probably share more on that in the future, but it’s not for me to talk about yet ;).  Most of the people around me were working on the Google XPrize project, and it was awesome to see that and other jaw-dropping amazing projects in the bay I was in.

I’d like to share a follow up post on how the checker playing robot went.  It was pretty fun, albeit stressful.  We knew at the outset that the chances of successfully navigating this project was 3,720 to 1, but we decided the risk was worth it.  Plus, we figured we could call the support desk to help us get through any ID10T errors.

The robot was based on the new XMega AVR processor.  It has quite a few more features than the standard AVR chips, which also made it a bit more difficult to use.  I recommend AVR processors highly, but unless you need functionality only provided by the XMega series, I would recommend most beginners stick with AVR chips from the ATMega series.  This project, however, needed the higher processing power, the larger RAM, and the higher flexibility of peripheral hardware offered by the XMegas.

I don’t want to repeat too much of the description of the design and process that my lab partners and I went through to do this project – it’s already available on the project website here.  You can download the SolidWorks CAD, EagleCAD, C code, and other project files from there.

So it wasn’t quite capable of playing checkers at the end of the term.  Our grades took a bit of a hit because of that, too, but it was great to try something new and the reason for this design is as follows:  We tried tackling this problem from a user’s point of view, which is something I believe is left out of academic and commercial projects all too often.  Who likes to play checkers?  Children and old men in the park.  Most other robots in the class were gantry or industrial robot arm based and relied on a laptop tether to function, which could never be practical when used by children or the elderly for safety, expense, and ease of use reasons.

Our robot weighed in under a pound and was, at least theoretically, easy to use and setup.  It used AA batteries and would be safe for anyone to use, and not expensive to replace if broken.

Now, if only it had worked :D.  The robot performs computer vision by reading images in from a UART based camera directly into the RAM of the XMega.  The XMega then determines where the checker pieces are at, calculates moves, and then goes out onto the board to execute those moves.  We fell just short of what was needed for full functionality in most areas due to lack of time and lack of experience with certain components.  As you’ll see in the video, poor motor control and localization was the primary point of failure.  Check the project website for a more detailed synopsis of what worked and what didn’t.

In this video, the robot has just captured an image and is moving from the image capture location to the checker board to make a move.  All decisions were autonomous, but the bot was stepped through its motions one step at a time and assisted when its localization or movements were out of place.

In my defense, I’ve worked on bootloaders before.  But the errata sheet on the XMegas is longer than the list of men Princess Leia has broken the hearts of.  And I’ve become one of the many casualties of that list.  (Erm, the errata list…  awkward…)

Big thanks to Alex Forencich!  XBoot, a fantastic reincarnation of the AVR1605 app note, is open source and highly configurable bootloader, which at the time of writing is capable of UART or I2C bootloading XMega processors.  I believe his intentions are to expand both processor compatibility and protocol options, so visit the XBoot Google Code project for more info.

I’ll  be going through and explaining the options that I used, so this isn’t an exhaustive tutorial.  This guide assumes you have a working XMega development environment, AVRDude installed, and SVN (if you want to download the code this way).  WinAVR should work just fine with a few minor alterations, but I’ve only tested this on Kubuntu with the development environment described in this previous blog post.  Also, as a side note, I’ve been using XBoot with XBee Series 1 wireless modules and it works fantabulous (that’s so good, I had to come up with a new word for it).

Overview

Here’s the step-by-step big picture:

1. Download the code.
2. Pick a bootloader entry method.
3. Configure communication parameters (Port/Baud Rate/I2C addressing, etc.).
4. Compile & program XBoot onto the MCU.
5. Send main application via XBoot and AVRDude.

Download the Code

So let’s get started.  Download the code from the XBoot download page and uncompress it, or (my preference) use SVN to download the code:

svn checkout http://avr-xboot.googlecode.com/svn/trunk/ avr-xboot

Configure XBoot

Once the code is downloaded, find the file named “xboot.h”.  Most configuration changes, if not all, will be made here.  We’ll take it one section at a time.  Line item references are from Rev12 out of the repository, but you should be able to match them up to any version.  The idea is that all available options are enabled, so comment out what you won’t be using.

// AVR1008 fixes
// Really only applicable to 256a3 rev A and B devices
//#define USE_AVR1008_EEPROM

Uncomment this line if you’ll be using an XMega256a3.  This fixes certain problems (remember Princess Leia the errata list?). I’ve heard this has hit some people but not others, even on the same silicon revision.  It may be useful for certain other chips and families – YMMV.  Check with Google if concerned.

Line 64:
// bootloader entrance
#define USE_ENTER_DELAY
//#define USE_ENTER_PIN
#define USE_ENTER_UART
//#define USE_ENTER_I2C

Here I picked the “USE_ENTER_DELAY” and “USE_ENTER_UART”, hence I commented the other two out.  Note that the “USE_ENTER_DELAY” just puts a delay at the start of the program, and isn’t mutually exclusive with the other options.  Here’s what the options mean:

• USE_ENTER_DELAY: Delays entry by a timeout.  Timeout is set by “ENTER_BLINK_COUNT” and “ENTER_BLINK_WAIT”, but I found the default settings worked well.
• USE_ENTER_PIN: Select this option if you want to enter the bootloader when a pin is in a certain state at power on.  Ex: You press a switch when you power cycle to enter the bootloader.  You’ll have to configure which port/pin at line 95, at the section titled “ENTER_PIN”.
• USE_ENTER_UART: Select this option if you want to enter the bootloader if a character is received on the UART.  This requires using “USE_ENTER_DELAY” by necessity.  You’ll need to configure the UART options at line 111.
• USE_ENTER_I2C: Select this option if you want to enter the bootloader if a byte is received through I2C.  I haven’t used this option, hence I won’t try to elaborate.

On to the next section:

Line 73:
// bootloader communication
#define USE_LED
#define USE_UART
//#define USE_I2C
//#define USE_I2C_ADDRESS_NEGOTIATION
//#define USE_ATTACH_LED

I’ll be using the UART and LED, so everything else is commented out.  If you use the LED, configure the next section also:

Line 106:
// LED
#define LED_PORT                PORTA
#define LED_PIN                 0
#define LED_INV                 1

If you’re using the UART, configure this section:

Line 111:
// UART
#define UART_BAUD_RATE                  19200
#define UART_PORT                       PORTD
#define UART_DEVICE_PORT                D1
#define UART_DEVICE                     token_paste2(USART, UART_DEVICE_PORT)
#define UART_DEVICE_RXC_ISR             token_paste3(USART, UART_DEVICE_PORT, _RXC_vect)
#define UART_DEVICE_DRE_ISR             token_paste3(USART, UART_DEVICE_PORT, _DRE_vect)
#define UART_DEVICE_TXC_ISR             token_paste3(USART, UART_DEVICE_PORT, _TXC_vect)
#define UART_TX_PIN                     PIN7_bm

Should be pretty self-explanatory.  You should only need to change UART_BAUD_RATE, UART_PORT, UART_DEVICE_PORT, and UART_TX_PIN.  If you use an exotic baud rate (non-standard and/or fast), you might want to change the settings at line 51 and select the 32MHz clock option.

That’s pretty much it for this section!

Compile & Program

This should work if you’re using AVR-GCC in Linux.  I can’t vouch for WinAVR, but it shouldn’t take much to change it.  That said, the only thing that really needs to change in the Makefile is the programmer name and the chip you’re compiling it for:

Line 42:
# MCU name
## MCU = atxmega16a4
## MCU = atxmega32a4
## MCU = atxmega64a1
## MCU = atxmega64a3
## MCU = atxmega64a4
## MCU = atxmega128a1
## MCU = atxmega128a3
## MCU = atxmega128a4
## MCU = atxmega192a1
## MCU = atxmega192a3
## MCU = atxmega256a1
## MCU = atxmega256a3b
MCU = atxmega256a3
#MCU = atxmega64a3
#MCU = atxmega128a1
#MCU = atxmega32a4

For me, I’ve been using the XMega256A3 chip.  At random, I decided to uncomment the atxmega256a3 line.  YMMV.

Line 209:
#AVRDUDE_PROGRAMMER = jtag2pdi
#AVRDUDE_PROGRAMMER = avr109
AVRDUDE_PROGRAMMER = avrispmkII

And I’m using an AVRISP mkII programmer, which is pretty cheap for an authentic Atmel programmer.  It only does PDI programming (no debugging), and needs to be updated to the latest firmware using AVR Studio (sorry, penguins – you’ll have to boot into Windows), but it does the XMega trick right nicely.

To compile and subsequently program:

$ make
$ make program

This should compile and program XBoot into the programmer.  Shazaam!  If you get any errors, feel free to leave me a comment and I’ll try to help you out.

Programming an Application Via XBoot

So now that you’ve got XBoot loaded, you can use AVRDude again to program your application to your XMega:

avrdude -p atxmega64a3 -P /dev/ttyUSB0 -c avr109 -b 19200 -U flash:w:main.hex

For those of you who may have installed Eclipse as described in previous posts, you can make Eclipse use the bootloader by:

• Click on “Run -> Run Configurations…”
• Right click on “C/C++ Application” on the left and select “New”
• In the “Name:” textbox, enter “Program via XBoot”
• In the “C/C++ Application:” textbox, enter “/usr/bin/avrdude” (or where ever it’s installed if you’re using Windows)
• Click on the “Arguments” tab.  Enter the following line, modify to suit your needs, and then click “Apply” and “Close”

-c avr109 -p x256a3 -P /dev/ttyUSB0 -b 19200 -e -U flash:w:Debug/eclipse_project_name.hex

There you have it.  As always, if you need any help just ask in the comments below!

So what the heck have I been posting about?  As I mentioned previously, I’m taking a Mechatronics course where we have to build a checker playing robot.  Here’s a conceptual animation for the design that my team and I came up with:

I used Blender3D to animate this video.  I’ve found with several of my robotics projects that most people get confused when I try to describe it.  By making a rough 3D sketch and animating the intended functionality, I’ve been able to talk with people much more effectively and get faster and better feedback about what will or won’t work.  It also helps me get several jumbled and mixed together concepts in my head down to a single, better defined concept.  If you’re planning on doing robotics, especially if you’re working on it from an electronics point of view, I’d highly recommend learning a 3D sketching system.  But I digress…

So this checker playing robot needs to be able to play checkers completely autonomously.  Most teams used either a stationary robotic arm or gantry style approach.  I’ve never been a big fan of either, in fact, I’m pretty enamored with the concept of small autonomous mobile robots.  A big reason for this is the ability to quickly apply swarm concepts to these robots if you build a few up, which is something I always toy around with in the back of my head but never do.

Here’s some of the primary system components and a simple description of each of them:

• XMega256: Pretty powerful little chip.  I both appreciate this chip and its potential, and at the same time can’t believe how long the errata list is.  It’s pretty bad, but fortunately I haven’t run into too much trouble yet.  I’ll be using this for all of the checker-playing AI, computer vision, and localization tasks.  Yep, you heard me: computer vision on an AVR!
• C328: OK, so the computer vision isn’t as hard as it could be – the COMedia C328 is a pretty easy to use (relatively speaking) UART camera.  The datasheet sucks, and it looks like it’s being discontinued.  I’m sure other similar parts will crop up soon, though.  I’ve been reading in raw 565 RGB images into the XMega RAM and finding color blobs with it.  I can also transmit a JPEG to a computer via XBee.
• XBee: I use these for just about everything.  I usually write up a debug interface between the computer terminal and the robot so I can debug very quickly, and portably – it’s just as easy to debug and control from my desktop as it is my laptop, making presentations a lot easier.
• Servos: We went with servos for motor control.  As my other posts have alluded, I’m using some hacked for continuous rotation, and instead of controlling position I’m controlling their speed with a standard servo signal.  To maintain balance (I didn’t want to go down the inverted pendulum road…), the bot also has a servo with a “propeller” mounted in front.  The propeller slides over checkers as the bot goes forward and backwards, but rotates when the bot turns to avoid strafing the board and moving checker pieces all over the place.
• IR Sensors: There’s a bank of 6 IR emitter/detector pairs on the front of the bot.  These are used to detect where the bot is at on the checkerboard.    By monitoring the difference between when a left and IR detectors hit a checker square, you can also correct and maintain orientation so you don’t knock checkers all over the board.
• Odometer Sensors: More IR sensors, this time the QRE1113 reflectance sensors.  These sensors monitor a band of alternating light/dark colors on the inside of the wheel, so every time the wheel moves a certain distance, the XMega gets a “tick” that’s worth a certain distance.
• Chassis: A benefit of being in school, I have access to 3D printers that can take certain CAD files and actually “print” 3D objects in ABS plastic.  We used this for the chassis, which put all of our servo mounts, sensor mounts, and other typically difficult-to-make-precise-on-prototype features a lot more accurate.  It cost about $30 – not bad for what we get.

That’s the general idea.  Here’s a picture of where it’s at right now:

Here’s hoping that I get it done in time!  I don’t think it’ll get done in 12 parsecs, but that’s a measurement of space and not time anyway …

The method I’m going to line out below can drive up to 7 servos completely in interrupts.  It’ll use up your timers, but it’s easy peasy and will save you time if you don’t need all your timers for other tasks.

So, we’ve got a standard servo signal that’s composed of basically three stages:

1. A twenty millisecond low period.
2. A one millisecond high period.
3. A variable high period:  To turn the servo to one extreme, force the signal low immediately.  To turn the servo to the opposite extreme, force the signal low after a full millisecond.  To turn it to some point in between, just vary the signal at this point between zero and one milliseconds.

With the advent of the XMega, the AVR series of microcontrollers now have an plethora of peripherals, notably for this article eight 16-bit timers.  EIGHT!  That’s power, baby.  For this example, I’ll only do two servos, which will require three timers.  That seems like a lot because with most ATMegas, that was about it – you only had 4 timers, and only two of those were 16-bit (and 8-bit timers == headaches

I started from App Note AVR1306, which describes the timers.  BTW, app notes are the way to become familiar with the XMegas, especially if you’re coming up from the previous AVR families.  Download the drivers along with the PDF, they’re pretty useful.  Include these in your project.  I’ve used these with only a few modifications, and they’ve worked pretty well for me so far.

Set up a global array that can be used for servo position variables:

volatile uint16_t servo[3];

Note it’s declared volatile – this is necessary for all variables you’ll be using between the main loop and an interrupt service routine.  Also note that I declared 3 spaces for two servos – on this particular one, I liked labeling the servos “Servo1″, “Servo2″, etc. instead of base zero.  Personal preference, but adding the extra byte keeps the numbering consistent between labels and array index.

Next up is the timer initialization routine.  Let’s look at it first.  The comments are fairly explanatory, and I’ll go through it a little more afterwards:

/*! \brief This function initializes timers for use as servo PWM signal drivers.
 *
 *    This function initializes timers for use as servo PWM signal drivers.
 *    It probably wouldn't hurt to improve this by making it modular at some point...
 *
 *    - TimerD0: 20ms servo timer.  This timer triggers the rest of the servo position timers.
 *    - TimerD1: 1-2ms Servo1 position timer.
 *    - TimerE0: 1-2ms Servo2 position timer.
 *
 */
void init_timers()
{
    //! TimerD0: 20ms Servo Timer
    TC_SetPeriod( &TCD0, 2500 );                            // Set period (2500 ticks = 20ms)
    TC0_SetOverflowIntLevel( &TCD0, TC_OVFINTLVL_MED_gc );  // Set Interrupt on Overflow
    TC0_ConfigClockSource( &TCD0, TC_CLKSEL_DIV256_gc );    // Set clock and prescaler (8us per tick)

    //! TimerD1: Servo1 Position Timer
    TC1_SetOverflowIntLevel( &TCD1, TC_OVFINTLVL_OFF_gc );  // Set Interrupt on Overflow, but not yet
    TC1_ConfigClockSource( &TCD1, TC_CLKSEL_DIV256_gc );    // Set clock and prescaler (8us per tick)

    //! TimerE0: Servo2 Position Timer
    TC0_SetOverflowIntLevel( &TCE0, TC_OVFINTLVL_OFF_gc );  // Set Interrupt on Overflow, but not yet
    TC0_ConfigClockSource( &TCE0, TC_CLKSEL_DIV256_gc );    // Set clock and prescaler (8us per tick)

    PMIC.CTRL |= PMIC_MEDLVLEN_bm;
    sei();
}

So, as the above code lines out, TimerD0 is the 20 millisecond timer.  Every twenty milliseconds, it fires.  When it does, it raises the servo signal and then enables TimerD1 and TimerE0, which subsequently time out the 1ms period + position offset.  These functions all come from the application note mentioned above.  The three functions used to set up TimerD0 sets the period, enables the overflow interrupt at the medium tier, and then sets the prescaler.   Pretty straightforward if you use the driver functions.

Here’s the ISR for TimerD0:

/*! \brief Timer/CounterD0 Overflow interrupt service routine
 *
 *  TimerD0 overflow interrupt service routine.
 *  Set for a 20ms period.  Sets servo output port pin, enables TCD1 which resets the pin.
 */
ISR(TCD0_OVF_vect)
{
    uint16_t period;

    /// SERVO1 Timer Enable
    period = 63 + SERVO1_OFFSET + servo[1];                // Calculate period
    SET_SERVO1;                                            // Raise the servo pin
    TC1_SetOverflowIntLevel( &TCD1, TC_OVFINTLVL_MED_gc ); // Set Interrupt on Overflow
    TC_SetPeriodBuffered( &TCD1, period);                  // Start TCD1, set period
    TC1_ConfigClockSource( &TCD1, TC_CLKSEL_DIV256_gc );   // Set clock and prescaler (8us per tick)

    /// SERVO2 Timer Enable
    period = 63 + SERVO2_OFFSET + servo[2];                // Calculate period
    SET_SERVO2;                                            // Raise the servo pin
    TC0_SetOverflowIntLevel( &TCE0, TC_OVFINTLVL_MED_gc ); // Enable timer overflow interrupt
    TC_SetPeriodBuffered( &TCE0, period);                  // Start timer, set period
    TC0_ConfigClockSource( &TCE0, TC_CLKSEL_DIV256_gc );   // Set clock and prescaler (8us per tick)
}

So, it does the following for both servos:

• Calculates the period.  If everything were a perfect world, the constant 63 should be 125 (and a #define ;) which, with the prescaler given and a 32MHz clock, should be 1ms.  However, between natural delays in the code and the particular servos I was using, I calibrated that offset to be 63 to get the maximum range.  YMMV.
• Raises the servo signal pin.  This macro is defined in my header file, and is pretty simple: #define SET_SERVO1 PORTD.OUTSET = PIN5_bm
• Enables the interrupt
• Sets the period.  You must use the TC_SetPeriodBuffered for this particular application (can’t remember why off the top of my head).
• Set the clock source to enable the timer.

Did you notice a subtle difference between the TimerD1 and TimerE0 code?  There are two types of timers in the XMegas – Timer0′s and Timer1′s.  Hence, there are TC0_ prefixes and TC1_ prefixes that must be used for appropriate timers.  I’ll have to refer you to the datasheet, because once again I can’t remember what the difference is – it’s not relevant for this example.

Last, let’s look at the position timer ISR code:

/*! \brief Timer/CounterD1 Overflow interrupt service routine
 *
 *  Timer D1 overflow interrupt service routine.
 *  Ends the Servo1 position pulse and disables itself.
 */
ISR(TCD1_OVF_vect)
{
    CLR_SERVO1;                                            // Reset the servo pin low
    TC1_SetOverflowIntLevel( &TCD1, TC_OVFINTLVL_OFF_gc ); // Clear Interrupt on Overflow
    TC1_ConfigClockSource( &TCD1, TC_CLKSEL_OFF_gc );      // Stop clock
}

There’s not much to it:  Reset the signal low, disable the timer interrupt, and disable the timer clock source.  This all gets re-enabled in about 18-19ms!

Now, from just about anywhere in your program, when you want to update the servo position, you just have to change the value of the appropriate servo[] index.  Here’s an example main loop:

int main(void) {
    init_clock();
    init_io();
    init_timers();

    int i;
    for (i=0 ; i<20 ; i+=10)
    {
        servo[1] = i;
        servo[2] = i;
        _delay_ms(1000);
    }
}

I should mention that you need to include “pmic_driver.h” from the PMIC app note AVR1305, and “TC_driver.h” from AVR1306.  Also copy in the matching .c files into the same folder.

That’s really about it.  And it’s easy to add on to this and control another servo:

1. Add an extra index into the “servos[]” array.
2. Pick an unused timer and add it to the “timer_init()” function.
3. Cut, paste, and modify timer code for the new timer in the 20ms timer ISR.
4. Add an ISR for the new timer, again cutting, pasting, and modifying for the new servo.

That about does it.  It seems to work pretty well for my uses.  Make sure and calibrate the limits on your servo variables so that you maximize your reach (for the servos I tested it with, it was between 0 and 270) .  One problem I had was erratic behavior when it collided with another timer occasionally – this was fixed by adding lifting this up from the “LO” level interrupts to the “MED” level interrupts.  It could also be moved even higher to avoid problems even further.  This is an issue with the XMega, where it wouldn’t necessarily have been with an ATMega, because XMega interrupts have changed and a higher level interrupt can interrupt a lower level interrupt.  Good to keep in the back of your mind as you code…

As always, let me know in the comments if you need any help setting this up.

My setup is a SparkFun XMega breakout board ($25) and an AVRISP mkII programmer, which I bought from Mouser (~$35) specifically for the new PDI programming.  Seems Atmel ditched the venerable ICSP programming method with these new chips.  The AVRISP mkII can program over the new “Programming and Debugging Interface”, but can’t debug.  If you want to be able to debug over the PDI interface, go for the JTAGICE mkII or another programmer.

I’m running Kubuntu Linux 9.10.  This solution probably won’t be all that useful for that long, because I imagine (but haven’t checked so I don’t know for sure) that Kubuntu 10.04 will have these updated packages.  Regardless, some of the advice that follows will still be pertinent to some people.

So here’s what I’m going to do: Set up my Kubuntu 9.10 installation to be able to compile for XMegas using AVR-GCC, program XMegas using AVRDude, and use Eclipse as an IDE for all this.

Install AVR-GCC and AVRDude

Since the packages in the Kubuntu 9.10 repository aren’t up to date enough to work with the XMega, we’ve got to get them from somewhere else.  I default to the Debian repositories, which 9/10 times work with Kubuntu.  I’m not sure if there are other packages you need installed, because I started with a working standard AVR and GCC development environment already working.  If installing these packages complains about dependencies (beyond those in the list below), using “apt-get” to install them from the normal repository should be fine.

Download the following “squeeze” packages for your system from here:

• avr-libc
• avrdude
• avrdude-doc
• binutils-avr
• gcc-avr

NOTE: Just install these from the repository using apt-get if using Kubuntu version 10.04.

There’s a specific order you have to install these in – I can’t remember exactly what it is.  Right click on the files in Dolphin (or, as I prefer to use, Konqueror) and use the GDebi package installer to install these files graphically, or dpkg to install from the command line.  Once these are installed, you can compile and program your XMegas from the command line!

Install Eclipse and AVR Plugins

Eclipse has some features that I’ve heard are pretty nice.  Traditionally, I’ve used and really liked KATE (KDE Advanced Text Editor), and recently I’ve gotten hooked on VIM, but I’m not a bigot about things I haven’t tried.  So here’s me trying Eclipse for AVR programming.

First stop, install Eclipse.  You’ll want Eclipse CDT, which is geared towards C/C++ development instead of Java.  You can download it here.  Install it by extracting it, pretty much anywhere.  I installed it into my development tools folder – another standard place is the opt folder (/opt/eclipse).  Further instructions on this can be found on this UbuntuForums post.

Once Eclipse is installed, you’ll want to add the AVR plugin.  Follow these instructions.

Start a New AVR Project

To start a new AVR project for an XMega, follow these steps:

1. Click “File -> New -> C Project”
2. Enter a new project name, and under the “AVR Cross Target Application” select “Empty Project”.  AVR-GCC Toolchain should be selected on the right side.  Click “Next”.
3. Click “Advanced settings…”
4. Click the “AVR->AVRDude” option on the left.
   1. Under the “Programmer” tab, select your programmer.  If it’s not in the list, or the list is empty, click “New…” and select your programmer.  For me, it was “Atmel AVR ISP mkII”.  Click “OK”.
   2. The rest of the options under the tab should be left with defaults.
5. Click the “AVR->Target Hardware” option in the left pane.
   1. Select your processor.  For me, the “ATXMega128A1″.
   2. Select the frequency your processor will run at.  For me, 32MHz.
6. Click “C/C++ General->Indexer”, then click the link on the top right titled “Configure Workspace Settings”
   1. Check the “Index unused headers” option.
   2. Check the “Index source files not included in the build”.
   3. Check the “Allow heuristic resolution” option, then “OK”.
7. Click “Next”.
8. Select your MCU type and frequency (again, I know…)
9. Click “Finish” to create the project!

Setup Auto Programming

I think there’s another way to make this happen, but I couldn’t figure out how to make it program the chip.  So I did the following as well:

1. Click “Run->Run Configurations…”.
2. In the “Name:” box, type “Program Chip”.
3. In the “C/C++ Application:” box, type “/usr/bin/avrdude”.  Make sure the “Connect process input & output to a terminal” is checked.
4. Under the “Arguments” tab, type the following: “-c avrispmkii -p x128a1 -P usb -e -U flash:w:Debug/<project-name>.hex”
5. Click “OK”.

Now at this point clicking the “Run” button on the toolbar (or its shortcut, Ctrl-F11) will program the chip.  We’re not out of the woods yet, though.  By default, a program needs root privileges to access USB devices.  So when you hit Run, it will ask you to enter your password (which will, stupidly, appear in plain text).  To make the AVR-ISP mkII programmer available to mere mortal (non-root) users, do the following:

1.  Open a terminal.  Start a text editor as root to create the file “/etc/udev/rules.d/50-usbavrispmkII.rules”.  For example:

> sudo kate /etc/udev/rules.d/50-usbavrispmkII.rules

2.  Paste the following into the editor:

SYBSYSTEM=="usb", SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2104", GROUP="users", MODE="0666"

3.  Run the following command in the terminal:

> sudo udevadm control --reload-rules

Now there’s no need to enter the password!  To recap, to build without programming hit “Ctrl-B”.  To build and program, hit “Ctrl-F11″.

That’s about all I can think of for settings I use, but if I think of anything else I’ll update the post.

An update to the post:

I found a little item I forgot.  In order for Eclipse to output a hex file (needed for the above instructions to work), you need to go to the project properties -> Settings, then check “Generate HEX file for Flash memory”.  Hit the build button again, and behold the appearance of a hex file.

Conclusion

A very nice feature Eclipse has is that it hyperlinks variables,  functions, and defines when you hold the Ctrl button and click.  For files within your project, it works pretty nice, but usually you already know most of those well because you wrote them.  Step 6 above allows the  indexer to look through the AVR include folder as well.  This makes any standard definition of a port, register, enum, or struct (of which there are many) easy to find.

Also, you don’t have to manage your makefiles.  Eclipse will take care of all that for you, so you just have to worry about programming.  One thing I haven’t figured out yet is how to get it to get the equivalent of  “make clean && make all && make program” happen, which I typically use when doing AVR programming.  I periodically have to use the “Clean…” menu option when things start acting strange.

As a side, make sure to check out the XMega app notes on the Atmel website, and download both the PDF and the source code.  I’ve found myself primarily using their drivers, which has really sped up getting started with this chip (even though the drivers do have their limitations).

Happy programming!  I imagine this post will be the cause of a lot of late night hacking and Mtn Dew sales …

What I’m doing is changing a servo that normally has around 90-120 degrees of motion to have full 360 continuous rotation.  Instead of the servo reacting to the standard PWM signal as a position signal, it will now act as a velocity signal with full forward/stop/reverse control!  Best of all, when people tell you the servos on your YT-1300 look like a piece of junk, you can tell them you’ve made a few special modifications yourself.

Apology in advance for the images – I promise to never use my cell phone cam for blogging again!  It’s abysmally unfit for close up pictures of electronics.

Take the servo apart

The black circular piece with the shaft in it, next to the gears, is the potentiometer. Two stops are there, two more are on the case piece to the left of it.

Remove the sticky label (goo-be-gone is needed) and remove the screws.  You’ll likely need a jewelry screw driver.  Pull all three sections apart, remove the gears, and remove the white plastic cover over the potentiometer.  Easy peasy.

Cut out the stops

I’m running on memory, so feel free to correct me in comments if I’m wrong.  I recall this as the part that’s different from the standard sized servos.  There are stops on the potentiometer and you practically have to cut out half of the pot to get it to rotate properly.  This is because the pot shaft is used as the axis for the gears and external drive shaft.  Boo to the man that designed it this way, unless it made it significantly cheaper.  In that case, yay… but boo.

Warning: The plastic on the pot is EXTREMELY brittle.  If the pot case crumbles, your servo is trashed.

Proceeding onward.  You’ll see two plastic stops in the pot – cut it out in small pieces.  Once that’s gone, you’ve got to remove the potwiper.  The copper-colored middle terminal of the pot should come out with a little force at this point.  There are a couple of “C” shaped metal tabs that will come out with it.  Now cut the entire terminal off and leave the wire hanging for now.

On one of my servos, I cut it out without pulling the shaft out.  On another, the shaft hole cracked cand the whole shaft came out which made this easier – but I’ll have to report later as to whether it still works well or not.

You also need to cut out the springy piece.  You can’t remove it completely, it appears to be connected with the shaft itself, so you’ll need to cut it flush against the remaining metal flange.

The final stop that has to be cut is on the actual case, just inside the hole where the shaft exits the case.  Flush cutters make quick work of this, but an Xacto knife could probably work too.

Solder resistors in place of pot

With the middle terminal removed and cut off, solder resistors between the two terminals and then solder the middle terminal wire to the middle of the resistors.

So that the potentiometer has a reference point for its control loop, we need to solder resistors in place of the pot.  I used two 10K resistors, which will make the signal that would have centered the servo be the stop position.  Positions signals right from the signal will be forward, and positions left from the signal will be reverse.

Solder the two 10K resistors (surface mount or 1/8W or smaller should fit) in series between the two remaining posts.  Then solder the currently-floating middle terminal wire in between the two resistors.

Put the servo back together

Pretty straightforward.  Do step one in reverse.  The gears may feel like a puzzle, but there’s only one way they fit.  Lastly, be careful with the screws – they strip out pretty easy.

First, here’s what I “have” to be working on right now.  I’ve enrolled in the ME414 “Mechatronics” class here at OSU, where interdisciplinary groups of three CS, ECE, and ME students have to put together a checker playing robot.  Seriously!  It has to autonomously play checkers not only against humans, but other robots.  At the expense of my other relatively boring classes, this one gets most of my spare time.  I’ll keep you posted on how it’s coming, as there’s some overlap with other projects – in particular, I’ll be using the XMega controller on this project and I’ll be posting some tips on how to get started (as I’m figuring it out, no less ;).

Back to the ZephyrEye.  I’m currently working on the project with a kit manufacturer and we’re making good progress.  No promises of any kind, but I’m currently estimating they will be on shelves by this summer.  Oh, the heaps of gold I could have made if only I hadn’t open sourced this project ;).  Can’t wait to start coding this sucker up, make sure and sign up for the Google Code project if you’re interested in helping out!

Hopefully my summer schedule lets me work on the project!  It’s getting full.  I’ve landed an exciting internship at the Robotics Institute of Carnegie Mellon University, so I’ll be racking up frequent flier miles going cross-country to Pittsburgh.  Exciting stuff, I get to work with and get to know some crazy smart people who design bleeding edge robots.  I’ll be looking for the secret to the universe in the bookshelves, for sure …

And, the missus and I are expecting baby #2 in September.  Yay!

In case anyone was wondering if I was kidding about the cat and laser pointer thing, here’s a great chance to find out.  Download the schematic by itself, open it in EagleCAD, and click the “Board” button (5th from the left on the toolbar), and try laying out the board.  Make sure and give yourself some time (a day or two without sleep should do it), and dig in!

So here are the steps I use when laying out a board.  After the schematic has been reviewed several times (preferably by someone capable and also familiar with the project, not just by yourself), click the “Board” button (location described above).  What Eagle does here is it takes all of your components and puts them next to a random outline.

From here, let’s just go down the list.  Note that this is just what I do for boards like this.  It gets the job done very quick, with decent quality, but others do things different and may agree or disagree with this approach – I’d love to hear what others do in the comments!

1. Draw a circuit board outline
2. Group components into proper areas
3. Manually route critical traces
4. Autoroute remaining traces
5. Manually fix autorouter mistakes (sometimes, the autorouter makes no sense!)
6. Run Design Rule Checks against the board
7. Redo steps 3 through 6 if necessary
8. Send design to the boardhouse

1) Draw a circuit board outline.

If you don’t care what size your circuit board is, this is a very easy step.  Take the default, and shrink or expand it as you get closer to finishing step two.  Chances are, however, you should make careful considerations about your intended enclosure(s) for the circuit board.  Don’t skip this step lightly, or you’ll pay for it exponentially down the road.  Case in point: ZephyrEye Rev1, from the side as shown below.  Originally I thought I would use a different case, but it was too bulky and looked horrible.  But it didn’t exactly fit in my backup case, either:  I had to cut out the side just to get it to fit.

The result: Ugliness.

I’ve downloaded the manufacturer’s datasheet for the enclosure, and following it’s recommendation outlined the board to maximize the PCB surface area – I’m going to need it all to get it all the features packed into this tiny little enclosure.  Either modify the existing outline, or draw using wires on the “Dimension” layer 20.  The board house will router your PCB following this outline.

Another item I always forget (and actually just remembered while writing this), is mounting holes.  Some people use vias connected to ground, while others use drill holes.  I usually prefer vias, because you can set the diameter of the copper around the via and avoid routing other traces within range of the head of the screw.  It also lets you ground your circuit board to the enclosure, which is common with metal enclosures.

2) Group components into proper areas.

For most components this is pretty straightforward.  Put all the schematic elements in the same area: an IC, supporting passives, and related supporting circuitry.  But you’ll also need to take into account any special needs of that part of the circuit:

• Sensitivity to noise
  • The digital compass would potentially have issues if placed near the transmitter, or near any high current wires due to the magnetic field around a current-carrying wire.
• Proximity to the edge
  • The GPS circuit needs to be near the edge because it has an antenna.  You can’t trace antenna wires very far without serious signal degradation, so it gets a special spot.
  • Most components that need to be near the edge are there because they need to match up with enclosure features – measure these things out carefully when necessary.
• Proximity to other chips it needs to communicate with
  • If you can, put inter-communicating chips near each other.  There’s considerable flexibility on this point, depending on the protocol, the speeds they communicate at, and sensitive areas that these signals must avoid.
  • Example: If you were routing wires carrying USB 2.0 at 480MHz, it would be bad news for both other chips on the board as well as your USB signal integrity if these were long.  In fact, at this high of speed, there are very specific routing guidelines that must be followed.
• Speeds of signals that will travel on the signal wire
  • Crystal wires should always be very short.  Once you get a signal that will be up in the megahertz range, the shorter it can be the less noise you’ll get at other locations on the board.  The trace carrying the signal can act as an antenna if it is too long.
• Analog signals need special consideration.
  • Usually, you’ll want to avoid routing communication wires (RS232, SPI, or I2C) near analog wires.  These communication wires will put noise into your analog signals, causing headaches and very weird errors when debugging the board.
  • Antenna signals are analog of the most sensitive kind, and usually need to be a specific width if they travel very far.  You may also need to “impedance match” the trace to avoid distorting the signal.

That’s not an exhaustive list, and not detailed by any stretch of the imagination.  Google for more details on any above item you fear a board you’re laying out may have issues with.  Datasheets will have very specific layout requirements as well, many have a PCB layout guide for the chip.  Lastly, check for reference designs.  These are great to follow because you know they have been proven.

Prior to routing, all the components should be grouped into logical areas.

You’ll notice the schematic is already outlined in this way.  For example, the digital compass (HMC5843) should be placed somewhere within the outline that will be away from high-current lines (e.g., lines which may induce magnetism and noise).  I picked a corner away from everything else for this guy.  It was pretty easy to look at the schematic and see that I needed to pull in C31, C34, C40, R11, and R19.  Quickly looking at the air wires, I put them in an order that seemed like would work once the traces were routed.  Then I did more or less the same for the remaining component “groups”.

Notice the surface mount components are on top as much as possible – this makes it easier to assemble, particularly for pick & place machines and/or if you are going to bake it in a reflow oven.

3) Connect Vcc, GND, and critical traces

Vcc and ground traces go first.  Usually, I go for a ground plane on top.  Some people do Vcc planes on the bottom – I’m not a big fan of this, but I have done it.  Make sure the traces are wide enough to carry the current they need to (this calculator may come in handy) – in general, they are but it’s better to make wires that carry a lot of current be thicker anyway, no sense having a bunch of fuses around the board.  I estimated my max current delivered to this board to be less than 250 mA, but I still use .024″ traces for VBAT, and 0.16 for a few of the VCC traces.

For a few of the components, you’ll also want to trace things out before you let the autorouter have its way.  You can also quarantine areas as off-limits to the autorouter for sensitive areas.  For example, the GPS circuit is pretty sensitive, especially with regards to the RF ground plane and the antenna trace.  I routed this area up ahead of time.  To make sure  areas like this aren’t touched, you can then place polygons on the top and bottom restrict, keepout, and vRestrict (for vias) layers to manage the autorouter.

4) Autoroute remaining traces

This step has a few tricky items that can make the difference between a successful autoroute and a complete failure autoroute.  Pay close attention to the setup!  Here are the steps I used:

• Save before you start! You will NOT be allowed to use “Undo” commands after you start the autorouter.  I usually save a separate copy before I start just to be safe.
• Make sure your design rules are set up correctly as the autorouter follows these rules while routing traces.  Use the toolbar or click “Edit -> Design Rules…” to open the DRC dialog.  Set up the rules to follow your intended board house’s manufacturing guidelines and minimum tolerances (check their website).  Here are the ones I modified from the default:
  • Clearance Tab:
    • I set all clearances to 8 mils.
  • Distances Tab:
    • Copper/Dimension: This is the minimum distance between any copper (whether a trace, polygon, or component) and the board outline on the dimension layer 20.  I set it to 10 mils.  If you route traces too close to the edge of the board, they may get cut or damaged.
    • Drill/Hole: Distance from anything to a hole on the board.  Set to 8 mils.
  • Sizes:
    • Minimum Width:  This is the minimum width of a trace, and the autorouter will use this for everything.  10 mils is a good minimum if you have plenty of space – I used 8 mils.
    • Minimum Drill: This is the smallest drill size available from your board house.  20 mils for me.
  • The rest of the defaults generally work fine for me, but make sure you’ve met all your board house requirements before continuing.
  • Click “Apply” and then either “Check” or “Cancel”.  It’s a good idea to check your work so far to make sure you pass off a clean board to the autorouter.
• Now click on the “Tools -> Auto…” (or use the toolbar) to open the Autorouter Setup dialog box.  Make the following changes according to your design needs:
  • Routing Grid: Here’s the deal.  The larger the grid size, the less time it takes.  But the autorouter will only consider trace joints and intersections every 50 mils.  So for surface mount components pins at, say, .5mm pitch (pin centers are .5mm apart), the autorouter will fail to connect most pins.  It will also have issues in congested routing areas.  On the other hand, using a 1 mil grid will take forever.  I used 2 mil routing grid – It took about 30 minutes.
  • Change Top and Bottom preferred routing directions if desired.  I haven’t found this to make a big difference in actual implementation, just make sure you don’t pick two parallel directions unless you want issues.
  • To be honest, I’ve never bothered playing around with rest of the settings, or the optimization settings.  I’m sure there are some advantages that can be made here, but I’ve never dove in.  Feel free to comment if you know how to change these to some advantage!

The Rev2 Main Board after being autorouted and cleaned up. Notice a few parts have moved a little to allow better routing, but not many.

Once everything is set up, save again and then hit the “OK” button.  Alternately, if you only want the autorouter to work on a particular subset of traces, use the select button and then hit the green stoplight button on the toolbar to go.  Be forewarned that the autorouter will ripup and retrace ONLY its own traces, and traces there prior to beginning the autoroute will remain untouched.  This can be a problem, especially if you have cut off certain sections of the board with traces on both the top and bottom, or have routed so close to surface mount pins the autorouter cannot place  a via to get around it.

In situations like this, and sometimes just due to trace density, sometimes the autorouter just can’t find a path for all the traces.  These will be left as airwires for you to manually route…

5) Manually fix autorouter mistakes

The Autorouter makes as much sense sometimes...

Sometimes, the autorouter just doesn’t make any sense.  I couldn’t help but post this picture – it’s a classic.

But seriously, sometimes the autorouter just does ridiculous things.  Traces have random and startling paths, take weird angles, overshoot and then overcorrect, etc.  Check through the history of the Rev2 cad files for examples.  You’ll want to shorten most of these traces if you can, take out the weird angles, and fix any traces that went through places they shouldn’t have.

And the autorouter generally uses a LOT of vias.  Vias can actually cost you extra if you use too many from some board houses, because they take extra time to drill and plate in the manufacturing process.  So minimizing vias is important.  You can usually clean a few off manually with a little effort.

It took about 30 minutes to finish the autoroute, because my routing grid was so small.  Before the first optimization step, it had around 320 vias.  Youch!  By the end, however, it was down to around 170.  Go optimizer!

It also left about 7 traces for me to finish by hand.  Most of them were because the ground plane polygon had “fallen apart”, meaning there were so many traces that parts of the ground plane had become separated and were not longer interconnected.  Many were fixed by pushing and pulling vias and traces around.  On a few, though, I had to place vias and bottom side traces that jump under traces that cut up the ground plane to make the connection.

6) Run Design Rule Checks against the board

This step is CRITICAL!  Don’t even consider sending the board off without checking your board against the design rules.  Since you’ve already got the DRC rules setup, just hit the “Design Rule Check” button on the toolbar to run it.  It’s pretty straightforward: Anywhere you have traces that are too close or overlap, parts off the boundary, or drill holes that go through traces or components, you’ll get an error that you’ll have to fix by hand.

This isn’t too bad usually, but in densely routed areas can sometimes be a little tricky.  Just use your elbows, push things out, and make some room.

7) Redo steps 3 through 6 if necessary

Well, as hard as all this has been, you may find something that needs changing.  Say you forgot a critical component, or left off a significant number of traces.  Sometimes you can add these things in after the fact, sometimes this is as practical as putting Jabba the Hutt on Jenny Craig.

If you have to, don’t resist starting over.  The command to get this to happen quickly can be typed into the command bar: “ripup ! ;”.  This will ripup everything, so if there were certain traces you wanted to keep the alternative is selecting the traces to leave alone one signal at a time by leaving off the semicolon, then hitting the green stoplight to execute the command.

If you’re happy with the board, then congratulations!  The next step is to get someone to review your board layout.  A fresh set of eyes makes all the difference.  But don’t be disappointed if, even after several reviews, it comes back with a few hardware bugs.  Have Xacto knife and patch wire ready ;)

8) Send board to boardhouse.

There are a lot of boardhouses, each with different pros and cons.  Here’s a list of other houses I’ve heard good things about:

• Personally, I use PCBExpress because of proximity – They do small, low-feature two layer boards for pretty cheap, and they ship ground for free.  Since they are also located in Oregon, I get them in two days.  They also accept Eagle files directly – no need to generate Gerbers.
• I’ve heard good things about Advanced Circuits.
• BatchPCB is related to SparkFun.  This one is pretty cheap @ $2.50/sq in (plus setup fee), but takes a while to get your boards back.  Time flexibility = lower cost boards.

All of the above have Internet order options.  Just upload your file, answer a few questions (usually about layers), pay for it, and you’re done.  Usually, this is when I put together my final bill of materials and get the parts ordered so they arrive about the same time as the board.

Well, that just about covers it.  I’m sure I forgot something, so as usual feel free to remind me or ask questions in the comments.

The Rev2 circuit is nearly complete.  It looks AMAZING if I do say so myself.  That’s the problem, though:  I’m inundated with excitement and therefore am unable to find things that are wrong because I don’t want to find any reason that might delay getting the circuit boards back as soon as possible.

I’m calling out for a few extra set of eyes to look over the schematic   If anyone could please go to the Google code, download the Eagle CAD files and take a look, I’d really appreciate it.  If you want to make changes, let me know so I can arrange for them to be merged back in properly.  Even if you’ve never looked at schematics before, take a look and as always, feel free to ask what’s going on in the comments.

This is also a great chance to give suggestions on functionality.  I should add, it may be your LAST chance!  Please give some comments if you think you might ever build one, if nothing else just to say you think it works for what you’d like to use it for.

If you’re not familiar with CAD schematics and circuit board layouts, it might be interesting to look at the history of the .sch and .brd files in the Google Code repository.  By looking at older revisions, you can see the steps taken along the way chronologically.  I commit changes at least at the end of almost every day I work on the project.

The current Bill of Materials can also be found at this Google Docs spreadsheet.  It includes estimated pricing – it currently comes in at just under $200.  A little bit higher than I was hoping, but about the same cost as Rev1 and Chuck Norris (adverbicized) packed with new extra features!

The schematic is hopefully organized well enough for someone not intimately familiar with this project to try and understand one section of the schematic at a time.  The capacitive touch schematic is separate, because it will be a separate board.  The way it works is you put copper pads on the board, glue it to the inside of your enclosure, and it senses you touching it on the outside of the enclosure.  Pretty nifty, and a great way to avoid milling the enclosure.

Please post comments below, or add to the Google Groups discussion page.