Modifying the existing Arduino IDE

In order to implement the changes for the XMega for Arduino project, you will need to modify the Arduino IDE.

Typically this will be stored in '/usr/local/arduino' or '/usr/share/arduino' for operating systems like FreeBSD and Linux.

For Windows, it is typically stored in "C:\Program Files\Arduino" (or, if you hate 'spaces in file names' like me, you put it into "C:\Arduino").

The Arduino consists of some specific directories that contain information about the various board types, the 'core' code for these, and the 'variant' code that applies to specific 'variants'. The XMega for Arduino project adds the 'xmega' core and several variants for the various processors.

The Arduino IDE directory structure

BASE: /usr/local/arduino or /usr/share/arduino
    (On windows, typically C:\Program Files\Arduino)

--  hardware/arduino  -  contains 'boards.txt'
   +-----  cores
            +-----  arduino  -  built-in
            +-----  robot    -  built-in
            +-----  xmega    -  added (symlink or copy)
   +-----  variants
            +-----  arduino  -  built-in
            +-----  mega     -  built-in
              etc.
            +-----  xmega64d4   -  added (symlink or copy)
            +-----  xmega32e5   -  added (symlink or copy)
            +-----  xmega128a1  -  added (symlink or copy)
              etc.

The 'cores' sub-directory is what it says on the tin. It contains the 'core' files for a series of processors or board types, implementing the startup code and basic peripheral support (digital and analog I/O, interrupts, hardware serial, etc.). The xmega is different enough that it cannot use the existing 'core' support code.

In the case of the 'avrdude.conf' file, it is typically in /usr/local/etc or /usr/etc depending on your OS. For Windows, it will be in the 'hardware/tools/avr/etc' directory (on non-windows OSs the 'hardware/tools/avr' directory is typically a symbolic link to /usr or /usr/local depending on where avrdude stores the avrdude.conf file).

---

The 'boards.txt' file

The 'boards.txt' file is located in the 'hardware/arduino' directory (as described above). It contains one set of entries for each 'board type' described in the file. These are the board types that show up when you use the 'Tools / Board' menu in the Arduino IDE, in case you ever wondered where all of those come from.

A typical 'boards.txt' entry might look like this:

xmega64d4.name=ATXMega64D4

xmega64d4.upload.protocol=arduino
xmega64d4.upload.maximum_size=65536
xmega64d4.upload.speed=115200
xmega64d4.build.mcu=atxmega64d4
xmega64d4.build.f_cpu=32000000L
xmega64d4.build.core=xmega
xmega64d4.build.variant=xmega64d4

The 'xmega64d4' prefix identifies this as a unique board type.
The '.name' entry is the name used in the 'Tools / Board' menu
The '.upload.protocol' entry identifies the flash protocol (arduino or wiring)
The '.upload.maximum_size' entry identifies the flash image size
The '.upload.speed' entry identifies the baud rate (115k for xmega)
The '.build.mcu' entry identifies the correct CPU for gcc
The '.build.f_cpu' entry assigns 'F_CPU' for the CPU frequency (in Hz)
The '.build.core' entry assigns the correct 'core' implementation (xmega)
The '.build.variant' entry assignes the correct 'variant'. In this case, xmega64d4.

additional entries for USB might include

xmega64d4.build.vid=0xVVVV
xmega64d4.build.pid=0xPPPP

where

  '0xVVVV' is the vendor ID assigned to your project, and
  '0xPPPP' is the product ID you have assigned to this project

---

Basic Modification Procedure (summarized)

• Download 'XMega For Arduino' source
• Apply 'patch.boards.txt' and the appropriate 'patch.avrdudeXXX.conf'
  (Optionally you can manually modify these files)
• Create symbolic links for (or copy, on windows) the 'cores' and 'variants' trees from 'XMega For Arduino'
• Apply patches for compilers and tools (including 'avrdude') as needed
  NOTE: this may require some significant effort on your part
• Re-start the Arduino IDE. New board types should now be visible (and fully supported)

---

Applying patches

To correctly apply a patch using the supplied patch files, you will need the 'patch' utility. Under Cygwin, this means installing the 'patch' package.

• Change the working directory to the root of the Arduino IDE, namely /usr/local/arduino (or similar) as described above
  Under Cygwin, this is likely to be something like
  /cygdrive/C/Program\ Files/Arduino
• Apply the 'boards.txt' patch as follows:
  patch -p0 <boards.txt.patch
• Apply the 'avrdude.conf' patch as follows (use the correct version):
  patch -p0 <patch-avrdude.5.11-avrdude.conf (for avrdude 5.11)
  - or -
  patch -p0 <patch-avrdude.6.1-avrdude.conf (for version 6.1)
• 'Your Mileage May Vary' if you've modified the files or have different avrdude.conf files than the ones I created patch files for

---

The 'WinAVR' sub-project under 'patches'

Under the 'patches' repository there is a 'work in progress' project to support xmega processors under Windows, located at the following URL:
    https://github.com/XMegaForArduino/patches/tree/master/WinAVR

This project is basically MY attempt to build all of the patched compiler+tools binaries (and avrdude) using the latest available stuff and my 'xmega' patches [as needed].

At this point the plans are to create an installer that will overwrite the 2008 WinAVR binaries with updated and patched binaries that support xmega (and are also 'new' and 'improved'). Currently the project will build under cygwin and install to '/usr/local'. However, making this work with the Arduino environment would require quite a bit of manual effort (hence the installer), and since I would be able to install the xmega core and variants (and patch up 'boards.txt') wouldn't it make total sense to just do it all in one shot?

So basically THAT is the plan for the future. In the mean time, you're more or less on your own. Building these applications under Cygwin is (unfortunately) PAINFULLY slow. This seems to be the fault of Windows, since SUA aka SFU aka Interix has the SAME! PROBLEM! with configuration scripts and compiling performance that Cygwin does. (The problem appears to be the way Windows handles program startup). Since every OTHER OS type out there (which are vastly '*nix' variants or derivatives, including OSX) rapidly load and run applications out of need, because of the signficant use of I/O piping (it's part of the original philosophy after all, 'lots of lightweight trivial utilities'), the configure scripts and compiles go MUCH quicker than under Windows. And since both Cygwin AND Microsoft's 'Services For Unix' have the SAME problem, I can only surmise that it's a basic design flaw within the Windows kernel that causes the slowness. You'll just have to live with it, unfortunately.