Finally I’ve got one of my most complicated “Hello World!”-applications working 🙂

After soldering the main components, it was time to do some coding. My old AVR programmer didn’t work with todays MCU’s, nor do my laptop have a parallell port, so I had to invest in a new programmer. The AVR Dragon seemed to be a good choice for a hobbyist like me. Switching to the (not so new anylonger) AVR Studio 5.1 seems to be a good way forward as well, though my old environment, with emacs and nice build scripts I had long ago, actually was a lot more streamlined. Being a .Net-developer nowadays, I think the Visual Studio-based AVR Studio will suite me better when everything is trimmed and running smoothely.

Though I have some experience with some of the old AVR 8-bit chips, like the AT90S8515, I haven’t worked with the newer mega-generation and the 8/16-bit xmega-generation MPU’s before. For a while, I was considering the AVR32-series, but when reading the specs, I thought that was a bit too much to undertake in this project. Instead I chose to go for the ATxmega256A3U because of its simple design, many I/O’s, UARTS, SPI/TWI’s etc.

I realize I have to do some performance tests, particular on floating point arithmetics, since that’s all implemented in software. Reading this blog post about math performance made me a bit worried about the performance after all. Maybe some skills from the demo scene back in the days could be useful.

One of the key modules in the application will be the UART driver. One port will be a console with a standard RS232 interface, one port will interface the RN-XV WiFi module, and one port will interface the PMB-648 GPS. There will be a lot of traffic on these ports, and it’s slow as well. Obviously there can never be a case where the application is waiting for a byte to be transmitted through the UART, so it has to be buffered and interrupt driven. I spent quite some time during the weekend to figure out how this really works on the xmega. Not having a debugger doesn’t make things easier. But I got it working after some time, and with a lot of help from the Atmel resource library.

So, now I have a nice buffered, interrupt driven, UART driver and it’s hooked into the stdin/stdout streams as well. Now this litte piece of code finally works!

uint8_t main() {
  console_init();
  puts_P(PSTR("Hello World!"));
  return 0;
}

I’ve been considering using DMA transfer in the UART driver as well, but at the moment I haven’t figured out a good way to implement it. Since DMA transfers are applied to an array of bytes, it’s not suitable for my current ring buffer implementation. Possibly it could work well with two separate buffers combined with flush mechanism. But I think I should spend my time on the sensors now instead.