Dangerous Prototypes

[attachment=0]I recently assembled the first revision of my XMega breakout board. The idea was to create a very simple breakout board that fit well on a breadboard, used the Arduino IDE and libraries, and had a USB bootloader. In order to make the board as thin as possible, I used the QFN version of the XMega. I re-flowed the board in a toaster oven and the QFN soldered without any trouble. The basic features of the board are

0.1'' headers spaced to fit on a breadboard.
Narrow board leaves enough space to connect wires and components next to the pins
Uses the ATXMega32a4u
32k Flash
4k RAM
2k EEPROM
16 Digital I/O
12 16 bit PWM channels
9 12 bit ADC
2 12 bit DAC
4 Serial UARTs with independent baud control. One can be used for IR comm
3 SPI, 1 capable of master/slave operation. 2 of the UARTS can act as SPI master
2 12C interfaces
1 USB port that can be used for loading code. Will eventually emulate a serial port for the arduino IDE
5 16 bit timers. Two timers can be combined to create one 32 bit timer.
an RTC timer capable of waking the XMega from deep sleep. Uses 500 nano amps while sleeping.
3.3V voltage regulator with 500ma max current

I've begun porting the Arduino IDE to the board. Thanks to the XmegaDuino project, this shouldn't be too hard. So far I have a serial bootloader, digital I/O and serial UARTs working. Once I have more of the API working, I'l start work on a USB based bootlaoder, and emulating a comm port for serial communication. I'm considering another revision of this board. I'd probably break out the clock pins, and add an LED and reset button.

Eagle schematic and board files can be found here http://http://github.com/brendan0powers/Designs/tree/master/protomega

---

Awesome work on the breakout board! It looks well done, and the logo is interesting. Is that by any chance the OSHW logo? I presume that the connector on the top right of the board is USB? Is that a standard USB port or some very thin non standard one?

Good job with soldering the QFN chip, I once tried that by hand using a soldering iron, and it was my first time soldering SMT, so I failed horribly ruining the board and chip. Glad it worked for you. Also, you stuck a vreg on there, I have seen many boards that don't have something like a voltage regulator, which means that every time I want to use the breakout, I have to go find a voltage regulator, which is not always successful.

Also, I see this is your first post! Welcome to dangerous Prototypes! :)

Thanks! That is the OSHW logo, and the USB connector is just the normal Mini-B connector. I used solder paste and a toaster oven to re-flow this board. I don't think I could hand solder the QFN chip.

As for the voltage regulator, it's an important part of the project. The idea is to create a breakout board where you can just stick it on a breadboard, add an LED, and have the Arduino blink example running with no extra components. I'm thinking of adding an LED to the next board, so you don't even need to do that:)

Once I've got the Arduino runtime and USB bootloader working, I plan to develop some additional libraries for power management, RTC, and the event system.

Yes! Thank you for being one of those people that provide the real essentials for a breakout board, like the voltage regulator! I have seen time and time again breakout boards where all that is done is putting the foot print to headers on the side of the board, with no decoupling caps, leds, voltage regulators, or even labeling the pins, even from the big guys.

Putting a led or two on the board would be nothing short of fantastic! I personally made full fledged breakout boards for a PIC32 and the dual core Xmos chip, and each board had 3RGB leds. The propellor board only had one RGB led due to the lack of IO with the propeller. Each board also had the appropriate voltage regulator which takes (if I remember correctly) 24v down to 6v and spits out the required voltages like 5v and 3.3v to the mcu and header pin. That way the user has almost everything needed to demo the MCU directly on the PCB. Stick it on a breadboard, give it a voltage or connect it to USB, and you are good to go!

This is like why breakout board looks like. Apologies for the horrible markings everywhere, this incomplete project has been put down indefinitely a year ago, so I never got around to fixing the markings. The leds are L1, L2, and L3, each having a button on top so when the user gets around to playing with buttons, he/she will be able to have instant feedback. Also, if the leds are on the PCB, the user knows for sure that something is wrong with the code when they don't light up, instead of when on a breadboard you have to worry about if you put the led in with the wrong polarity, is the led dead, too little current, or if it is even with the right pin.


http://http://hak8or.com/pictures/leds.PNG

In short, if you put a led or two on there then you will make your self a lot happier and possibly less frustrated when something goes wrong.

I've thought about putting an RGB LED on the board, but I don't have enough I/O left. At least, none that can do PWM. I was thinking of putting a bi-color LED on the board though.

One of the attractive features of the XMega for me is the Direct Memory Access (DMA). With this, I suspect I can rapidly access video frames from OmniVision cameras (or similar) via their Digital Video Port (DVP). I'm a software type that dabbles in hardware. Would love to see an arduino library for the XMega that easily lets me do that.

With this, you could easily build a miniature web cam. An OmniVision CameraCube, a wi-fi module and this XMega board would do it. And it would all fit inside of an Altoids can.

That sounds like a really cool project. I'm not sure that it will be fast enough to process video though. What kind of bit rate are you thinking of? You can calculate bit rate by W*H*ColorDepth*FPS. One thing to keep in mind about the XMega DMA is that it's not really true DMA. It steals time from the CPU when accessing memory. However, it's still more efficient at transferring data than the CPU is.

You also have to add in the bits for the H/V sync! Negligible, but still important.

And from what I see, most MCU's (specifically the PIC's) have a DMA that also steal time from the CPU, not to mention that the CPU would have to wait for the DMA to finish working with the RAM. Though, I had no idea people can do video with the Xmega's!

And I agree with the above responses, a simple easy to use library for quick prototyping with the xmega's would be fantastic.

As far as I can tell, the XMega's DMA doesn't actually steal clock cycles from the CPU. It does tie up the data buss while doing transfers. It's got some logic to sort priorities, and breaks the transfer up into small chunks(1-8 bytes). The CPU takes priority over the data bus, and the DMA transfers data when the CPU isn't asking for data from memory. I'm not sure if in practice this is any different than a clock stealing design.

I don't think you could do any useful video work with the XMega, It's still an 8 bit CPU, and probably wouldn't be able to sustain a data rate of much over a couple megabytes a second. It's still only an 8bit CPU running at 32MHz. However those data rates are useful for audio. You can play and record audio, and possibly do some very simple compression.

A friend and I have been working on getting the Arduino framework ported over. We're using the XMegaduino port from Akafugu. We've had to do some clean up work and bug fixing, the base APIs are almost done. After porting the bundled libraries(EEPROM, Wire, etc...), I hope to write some new ones. I'l probably go for power and RTC management first.

My impression is that you could setup the DMA transfer so that it goes from the camera directly to the wifi. AVR1304 (http://www.atmel.com/dyn/resources/prod ... oc8046.pdf (http://www.atmel.com/dyn/resources/prod_documents/doc8046.pdf)) states,

"By default the source and destination addresses are fixed during all transfers, which means each data transfer for the channel copies data to and from the same memory locations. This is useful for e.g. piping data from one peripheral to another".

And you can trigger the transfer off of an interrupt, so you wouldn't even need anything in your main loop(). Just set up the transfer and interrupt in the setup() and go. Now your loop can sit and wait for commands coming in from wifi.

Let's say you had all that working. Now would you:

1) Spin a board that had all three components on it and make it as small as possible to make the worlds smallest wireless webcam?
2) Define a "Standard" XMega footprint and build a wifi shield and a webcam shield?
3) Make an XMega board with the same footprint as the Arduino and reuse all their shields?

I like the idea of the smallest webcam, but I also like the idea of leveraging all the Arduino work out there, and adding DMA capability to it. Imagine a DMA library that you just chuck into Arduino's libraries directory.

Unfortunately, this really wouldn't work. Lets say you want to stream 320x240 video at 30FPS. That's 320*240*24*30, or 55.296 megabits per second. That's far higher than the clock rate of the XMega. Now, if you wanted to go for still image capture, or a much lower frame rate it may work. Some other important things to consider,

1) Most WiFI modules are SPI based, so data needs to be transferred via serial.
2) You generally need a TCP/IP stack on the XMega, so you can't just do DMA transfers and lave the CPU out of it
3) You'd need to pick a camera that supported SPI, or use one of the XMegas that has an external bus interface. You can't do DMA from an arbitrary set of pins. It must be done from a peripheral, such as SPI, or the memory controller.
4) Also keep in mind that 55Mb/s is above the data rate for 802.11g.

To do this properly you'd need a processor capable of doing video compression. That probably means an ARM processor running at a couple hundred megahertz, and some external RAM. I expect a real hardware manufacture would use a DSP, or custom ASIC for the task. Another possible option is to find a camera module that will compress the video for you. It probably wouldn't be cheap, but if you can get the data rate down to about a megabit per second, you could probably do it.

I plan to do lots of cool stuff with this board. 2 DACs, 16 PWM, and USB means you can do some pretty cool stuff with it. Unfortunately, uncompressed streaming video isn't one of them. As far as hardware configurations, I may produce a few if people are interested. The breadboard form factor works well for me, but I'd be open to other designs.

Great job!

Is there an option of plugging other 44 pin XMega processors?
these are great options,
ATxmega128A4U
ATxmega64A4U

the difference is in more SRAM and connectivity,
but they have Full speed USB support.

How do you do it with USB connection? MAX or FTDI ? What would be the advantage of using the other processors against the Xmega 32 ? Could you save the FTDI chip?
I have no idea if the ATxmega64A4U & 128 are programmable through the full speed USB device.
I guess, the 3.3V supply comes from the FTDI as on Arduino?

Thanx!

I am currently using the ATXmega32A4U, so you can easily change that for the 64A4U, or the 128A4U. However those variants aren't available at the moment. Since I'm using a *U series chip, I get full speed USB. Also, the U series is a bit like the XMega Rev 2, and it fixes many of the issues of the first series.

I plan to use the XMega's built in USB to do all programming and communication. I plan to write a virtual serial driver for the USB interface, and use that to emulate the normal Arduino serial API and bootloader. So, no FTDI or other chip is needed. The 3.3V is provided by a separate voltage regulator capable of delivering up to 500mA.

Hi Brendan,

it has been a while since there was a post in this thread, but I was wondering if you have made any progress on the bootloader that would allow for direct USB programming via XMegaduino?

Thanks in advance!