ATxmega64D4 patches for the Arduino IDE

Projects Libraries
1

Some time ago, as part of a customer project, it was necessary to modify the Arduino IDE to compile for (and flash) a device that was originally based on an ATmega328 processor, and used the Arduino IDE to compile and flash the device. The original prototype, of course, used an actual Arduino, and the next step was to produce a circuit board with the ATmega328 CPU. The subsequent step was to IMPROVE the CPU.

this processor was chosen because a) it had a 32Mhz clock, b) it was compatible with the 3.3v board, c) it has twice the NVRAM for code, d) it has the additional I/O pins that were needed for the project, e) it uses a TQFP44 package which fit nicely on the board, and f) the avr processor is code-compatible, though the registers and I/O are obviously not (which means the 'cores' and 'variants' code had to change).

So to be able to retain the SAME code, I produced a set of 'core' and 'variant' files for xmega, as well as updating the FreeBSD, Debian Wheezy, and Ubuntu 12.04 avr packages to handle the ATxmega64D4 processor.

All of these files, including source, are available here:

It includes a bootloader that was derived from the standard Arduino bootloader (the original one) that's tailored for the ATxmega64D4. You could modify this for a different processor if you like, or add features. The license is GPLv2 or later, just like the ATmega version in the Arduino IDE. It lets you flash via the same serial protocol used by the Uno.

I also solved the problem of making 'analogRead()' work the SAME WAY as it does for the ATmega328 . You're welcome.

The web site includes a short description of an inexpensive prototype board for the CPU, and the basic process I had to go through to get it to work, as well as a description of how to include it into the Arduino IDE (patching boards.txt, patching avrdude.conf, symbolic links in the 'cores' and 'variants' directories pointing to the new code).

(There is no update for WinAVR, but you could try using the FreeBSD patches to update and build under Cygwin)

Just worthy of pointing out, there are a small number of Xmega boards, one of which has its own clone of the Arduino IDE. I didn't think it was necessary to clone and maintain THE! ENTIRE! PROJECT! like that, so I'd rather work WITH the installed Arduino IDE and just fix things with patches, then submit the fixes to maintainers. The less custom coding, the better.

I'd REALLY like to see an Arduino that uses the xmega, preferably NOT just an 'A series'. The header file I provide for 'variants' has an 'ascii art' description of a reasonable board layout, with pin mappings. Maybe someone could do a board for that, get the necessary gummint testing approval (CE, FCC) and sell it as a new type of Arduino?

2

Thank you. ALternatives are nice. I've been wishing that the Mega had an Xmega since it first came out. Not that xmegas actually existed at that time, but...

The license is GPLv2 or later

Bleh. Not really appropriate, unless you're trying to be viral. But "the same as the rest of it."

also solved the problem of making 'analogRead()' work the SAME

there was a problem?

[another xmega arduino project] has its own clone of the Arduino IDE. I didn't think it was necessary to clone and maintain THE! ENTIRE! PROJECT! like that

Ah, well, it was more difficult back before the current variant/cores system; I think cloning the whole thing was about the only choice. Did you do 1.0 style variants, or 1.5 style variants? When you say you patch the source code, your talking about the AVR source code in the Arduino binary release, NOT the source code of the Arduino IDE, right? And you're counting on the environment providing the basic avr compiler and tools, rather than the more modern approach of making them part of the arduino tree?

3

westfw:

also solved the problem of making 'analogRead()' work the SAME

there was a problem?

yes - the xmega has a completely different A:D setup, and in order to get a 'rail to rail' 0-1023 mapping it was necessary to jump through a few hoops. The short answer is that you do a SIGNED comparison against a Vcc/2 reference with a gain of 1/2, which gets you an 11 bit value, and then you bit-shift it by one to make 10 bits, which is then identical to an ATmega [so that the script code works without modification]. If you wanted something different, you could write your own version, but you'll at least have an example that works.

westfw:

[another xmega arduino project] has its own clone of the Arduino IDE. I didn't think it was necessary to clone and maintain THE! ENTIRE! PROJECT! like that

Ah, well, it was more difficult back before the current variant/cores system; I think cloning the whole thing was about the only choice. Did you do 1.0 style variants, or 1.5 style variants? When you say you patch the source code, your talking about the AVR source code in the Arduino binary release, NOT the source code of the Arduino IDE, right? And you're counting on the environment providing the basic avr compiler and tools, rather than the more modern approach of making them part of the arduino tree?

the compiler is a set of separate packages/ports [I prefer that, as I use FreeBSD and Linux, and that's the way they're structured]. The 1.5 version needs to include something that can compile for ARM, but they could have just as easily used arm-gcc or similar to do the work [rather than including 'their own']. Also I'm not sure that 1.5 would work with NON-windows machines, and there's no existing FreeBSD port for it [last I checked]. I'm also not sure enough that 1.5 will work with existing arduino scripts, and it's still a beta, so not good for production or customer projects. I know you need 1.5 for the DUE because DUE has an ARM processor. But everything else uses AVR.

And so, since I do not have the 1.5 version installed anywhere, I use 1.0.5 (or later) and everything's based on that one.