ATXmega support for Arduino

ATXmega ATMel Info Page
(formerly info for only the ATXMega64D4 processor; now info for ATXMega processors in general)
ATXMega64D4 on a TQFP44 breakout board from Adafruit

PROJECT STATUS (as of 8/21/2018)

  • 8/21/2018 - Web Site Update, include info on multiple CPU models, standardize around the XMegaForArduino Project
  • 5/2018 - Prototype for Arduino clone using ATXMega128A4U. Continuing previous work on USB, 2-wire.
    The 128A4U has USB support and comes in a TQFP-44 package. This makes it work very well for experimentation, and developing a proper 'Arduino clone' board layout.
  • 2/1/2017 - added IDE support for new Arduino IDE HERE.
    And here is the Package Manager URL.
  • 10/27/2014 - A slideshow presentation describes various aspects of the project, including how to modify the Arduino IDE
  • 10/4/2014 - added github project for support and continuing development for other XMega CPU's
  • 6/15/2014 - Fixed compatibility issues with PWM on port E, added 'Tone' support for certain pins
  • NOTE: source updates will be made here. I'll also add a WIKI and other useful stuff
  • Added support for hardware flow control on both serial ports. You're welcome.
    Requires a properly modified 'pins_arduino.h'. See 'pins_arduino.h' for more details. Basically, you set up a new board variant that has pre-assigned hardware flow control pins
  • Initial publication (beta) - 3/13/2014

General Project Features

  • Public project as of October 2014 (as mentioned before on github)
  • Generally feature complete. Additional libraries and other support (USB, TWI, Tone) still needed, in some cases for specific CPUs only
  • Simple, patch-based extension design - no need to maintain a separate development environment project for the xmega
    Uses 'boards.txt' which allows you to create your own pin and CPU definitions for your own projects
  • AVR compiler/library patches for ATXmega64D4, ATXmega32E5, and ATXmega16E5, and a patch for xmega startup code bug on the older FreeBSD compiler (debian and ubuntu have already been patched, as has the newest FreeBSD compiler)
  • GPLv2 boot loader for ATxmega64D4 that supports serial port flash via avrdude, a similar protocol to the Arduino Uno (for the 64D4, the existing 'stk500v2' protocol that is used by the Arduino still works since the image size is 64k)
    This code may be freely used and/or modified for other processors according to the GPLv2 [or later] license of the original Arduino bootloader source, as it's based on the standard Arduino bootloader (see comments in source file for license info)
  • Compatible analog I/O, digital I/O, timer, and interrupt support (with xmega extensions available)
  • Support for a compatible I/O pin mapping that should match most shield expectations, with a rough diagram of the basic board layout and pin mapping (see 'ASCII ART' comments in pins_arduino.h).


A customer of mine wanted to improve an existing ATmega device that ran on 3.3v (for various design reasons, such as hardware being controlled by an ATmega processor that only runs on 3.3v). That device used the Arduino development environment, as do several of my own projects. As Arduino lends itself to rapid prototyping, the next step is often to design a board of your own with an ATmega processor on it that duplicates what the Arduino board does, but is directly wired to your controlled hardware. In this case, that is exactly how it was set up.

Unfortunately, the existing customer device was too limited by the ATmega CPU. I suggested upgrading to an ATXmega device, based on information I received from an ATMel sales representative that I'd met some time ago at a San Diego Hardware Hackers user group meeting. The ATXmega devices are very much like the ATmega devices, except that they run on 3.3v and have internal clocks, additional capabilities, and completely different register mapping for I/O. So it wasn't a drop-in replacement, but the potential existed for 'dropping it in' so long as some additional software work was done.

Like with many small businesses that are developing 'electronic things' to sell, my customer had a limited budget. Unable to afford a pile of effort needed to support the desired processor, I volunteered to contribute to the open source community and do the work necessary to implement support for the ATXmega64D4 processor (a relatively simple modification, once I had a proper header file for that CPU) and the MORE DIFFICULT changes needed to support the CPU for Arduino, which included a bootloader that is capable of flashing firmware.

The ATXmega64D4 is probably the wisest choice of CPUs for this particular project. First, it has TWICE the code space of an ATmega328. Second, it's a TQFP44 footprint, only slightly larger than the ATmega328 (so it could still fit on the board, with a little effort). Third, it has the additional I/O pins that were required for the project, as well as 4 times the clock speed (the ATmega328 was restricted to 8Mhz due to the 3.3v supply). And as it all turned out, it worked VERY well, providing my customer with what he needed to present to the investors, and ultimately continue its development.

A Sample Project

To prototype the device, I searched for useful boards, and NONE were using this particular CPU. However, at the time there was an inexpensive generic TQFP44 breakout board (OK it used to be available from Sparkfun, see left, but isn't any more) that worked PERFECTLY for building a simple prototype. All I had to do was wire up the ISP header and a power supply, and provide some female headers for plugging wires into. I built two different versions of these, and 'upgraded' the one you see here to include extra LEDs and an 'FTDI Friend' compatible pinout. In any case, the end result of the original 2 prototypes was something that was a _little_ difficult to work with, but very effective for prototyping the customer's hardware being driven by an ATXmega64D4 processor, and to allow a 3rd party to write custom software to do firmware upgrades and data transfer, 2 months before the actual (assembled) boards arrived.

In the photo to the left, you can see one of the Sparkfun breakout boards with an ATXmega64D4 soldered on. There is also an ISP header (bottom, left), and a set of female headers exposing ALL of the device's pins. The 4 Vcc and 4 ground pins are soldered together under the board, and there are some 0.47µF filter capacitors across the power pins. Vcc is applied where the power LED is (at the right side) and must be 3.3V regulated. The breadboard at the top has a 3.3v regulator (left), some LEDs, and an 'FTDI Friend' (available from Adafruit) connected by jumper wires to one of the serial ports on the xmega. The default LED output is connected to an LED and resistor (to ground) on the breadboard. Some additional components are also on the breadboard, which had been used for testing, and aren't currently connected. The disconnected black wire (lower left) is connected to the reset pin on the xmega.

With a lack of TQFP-44 breakouts from Sparkfun, I checked elsewhere for something equivalent. I found something BETTER. Adafruit now has a breakout board that works VERY well. In fact, they have a LOT of breakout boards now (but unfortunately, no TQFP-100's). There is a photograph of a working prototype with an ATXMega64D4 on an Adafruit breakout board at the top of this page. To the right of the device is a small LED + ISP/PDI header and the power supply cable for 3.3VDC, taped on with white electrical tape. There are a handful of 'blue wires of salvation' on the board, basically wiring up the power and a couple of bypass capacitors, plus wires to the LED+ISP/PDI board at the right. And what you get is something that's mostly wired up for power and ISP programming that can be PLUGGED IN TO A BREADBOARD. In many ways it's like some of the breadboard-capable Arduino clones out there [and they are VERY handy for testing things]. But you can somewhat easily make your own ATXMega64d4 version, at a reasonably low cost, and that's the point.

Because the ATXmega series have a BUILT-IN 32Mhz clock (no external resonator or crystal required) there is no external oscillator nor resonant circuits needed. This makes it VERY simple to create a near-Arduino-compatible device using a simple breakout board and some extra wiring underneath the board to wire up the essential things (power, ground, filter caps, ISP header).

One important detail about the xmega series is that the old way of flashing a bootloader wasn't going to work. I was able to obtain an AVRISP Mk II from a well-known electronics distributor, however, and this device works for both the ATMega and ATXmega devices. Further, I am still able to use 'avrdude' (the open source AVR flash program, that Arduino also uses) to flash using the AVRISP Mk II, under FreeBSD even. So no problems at all getting the hardware to accept an image, once I had updated the AVRISP Mk II firmware to the latest version.

With that out of the way, it was just a matter of wiring up an ISP header (only 4 lines are used for the xmega, vs 6 for the ATMega devices, so the 'middle 2' pins are unconnected) and programming the device.

One caveat remained: The boot section requires a special programming method. In short, you can't use the normal address offset for the code section, since it will not write the boot section from there. Instead, you must specify the boot section. Even though the bootloader was correctly assigned a start address of 10000H, the boot section's offset starts at 0000H, so you must program the first byte of the image at 0000:0000H. To solve this problem, I did a simple text edit of the original 'hex' file, and created a modified 'hex' file in which the initial address offset of 10000H is "left out", thus (effectively) specifying 0000:0000H. The bootloader flashed perfectly.

Initially I flashed code images using the AVRISP Mk II, until I was able to get serial programming working with the bootloader. Following that, I was able to program applications using the Arduino environment itself, as if it were an Uno or other Arduino/compatible device. Therefore, the net result of my efforts was to be able to write an Arduino script and program it onto an xmega-based device using the Arduino IDE, just as I would any other Arduino/compatible device.

Building an actual Arduino Compatible Device

a hacked-up prototype of an arduino using an xmega64d4

As an experiment, I actually built an Arduino-compatible device using the ATXMega64D4 processor. As you can see at the right of the page, there's a board with Arduino-style pins and a 44-pin breakout board wired up to it, with an ATXMega64d4 on the breakout board. The red board underneath is a blank shield board from Sparkfun. Since I had no intent to actually use it as a 'shield' I just got the blank board, which is SO handy! The serial port pins on the side were for Sparkfun's bluetooth serial adaptor. But I need to use it for the Adafruit FTDI cable (same pinout as FTDI Friend) and so I had to 'hack' it a bit to make it work. So cut the power and ground pins, connect ground to one side, and hook a capacitor and resistor for the reset line, and VOILA! Now, the serial flash process works PERFECTLY! And I also have the ISP header already on the shield board on top of THAT. You couldn't ask for a better 'starting point' for setting up an Arduino clone board, except maybe an actual Arduino board (minus the CPU connections).

Of course, this is a 3.3v board. The ATXMega64D4 doesn't work at 5V. But for compatibility with my OWN shields, I wired the 5V and 3.3V pins together. 5V was already wired up to the appropriate Arduino pin and broken out as a bus, and also on ISP and a couple of other places. So wiring them together was the simplest way of making sure I power up with 3.3V, but have 3.3v available for shields on the 3.3v line. Ok so it's not 100% compatible, but there you go. It demonstrates the concept and works with my TFT shield. That and I didn't want to cut any traces. But it _IS_ something to be aware of if you make your OWN 'Arduino Compatible' with the Sparkfun shield board.

So with a bit of patience on the blue wires to each of the appropriate pins, I wired up the ATXMega64D4 processor to match the definition in the 'pins_arduino.h' header file for the 'xmega64d4' variant. There's an ASCII art diagram for it. Wiring up wasn't too hard, actually, and only took the better part of an afternoon to do it (with occasional profanity, of course, as I can't seem to solder anything tedious without it).

another view of a hacked-up prototype of an arduino using an xmega64d4

I tested this configuration with the ultimate test: a TFT 'shield' I created for an Arduino Uno. It has a color TFT device (that I got from Adafruit, probably 2 years ago) that also has an SD card slot on it. I've tested with this firmware before, and so it was just a matter of doing a build for the 'atxmega64d4' variant and VOILA! It works! Screen updates are twice as fast as the Arduino Uno because the clock is at 32Mhz, and that affects SPI speed and the time it takes to refresh the TFT and read files from the SD card. So in short EVERYTHING is twice as fast, and the SD card and TFT can both handle the higher clock speed.

FYI - the cable at the left is an Arduino-style power connector, and the cable at the right (with the 2 pins) is for the TWI pins. Arduino Uno Rev 3 and mega2560 Rev 3 both break out separate TWI connections that aren't in the pinout for the earlier devices. In this case I mapped the TWIC pins from PORTC, pins 0 and 1, to be unique TWI outputs on these 2 pins. Unfortunately the shield board didn't have pins for these (it uses the old layout). So I broke them out on a separate connector so that it wouldn't interfere with shields being plugged in, but I could still access them to experiment with TWI (I still need to work on it).

The board on the far right is similar to the xmega64d4 prototype shown above, except that it has an ATXMega32E5 processor on it. It has half of the NVRAM, and a bit less RAM and EEPROM, but comes in a TQFP32 package and costs considerably less than the ATXmega64d4. Additionally, it has a dual channel D:A converter and some additional peripheral hardware.

I have been told that the CPU model sufixes of '1' '4' and '5' refer to the number of pins and the case style; that is, the A1 series is an 'A' series CPU (for peripherals) that has 100 pins. The A4 series is an 'A" series CPU (for peripherals) that has 44 pins, a D4 series is a 'D' series CPU (for peripherals) with 44 pins, and the E5 series is an 'E' series CPU (for peripherals) that has 32 pins. So an XMega64D4 has 64Kb of NVRAM, is a 'D' series, and has 44 pins.

But in addition to the numeric suffix is the optional letter 'u', as in the case of the ATXMega128A4u, which is shown to the right and below the ATXMega32E5 prototype board. The ATXMega128A4u is an 'A' series [which defines the built-in peripherals], with 128Mb of NVRAM for code, a 44 pin package, and USB support. So the USB connector on the left of the photograph isn't just there for show. This current prototype is still under development as I continue working on the USB support in the XMegaForArduino, project, but I'm consider an actual board design.

On a related note, the picture at the right is of an ATXMega128A1U ('u' being for USB support) on an inexpensive 100 pin QFP breakout board, which is then 'stilt mounted' onto a Radio Shack proto board that supplies power and has plugs for the serial port and ISP header. Solid copper wires plug into the appropriate holes on the board. I'll need to add some ground and power busses (and a USB connector for testing the USB capabilities of the ATXMega128A1U) but for NOW this tests that particular CPU pretty well. And yeah, it's got 100 pins. The cpu really is a bit of a 'monster', with THAT many I/O pins, *AND* external RAM support, Yeah. Soldering the chip onto the breakout board was tricky. I messed one of them up, had it rotated 90 degrees 'cause there are THREE marks, not just one, and you can't see them all properly unless you shine the light on it 'just right', but if you get the text oriented right side up, the pin one mark is in the upper left corner. The chips are kinda pricey, too, so you want to know what you're doing. But it IS possible with a standard soldering iron, as long as you don't put too much solder onto the pads. Use a LOT of flux, a TEENY amount of solder 'on the iron', slide it back and forth until all of the pins look good under a loupe. YES, under a loupe. Normal eyes can't see these things without magnification.

If done carefully, you can use good quality solder wick to remove excess solder that is causing pin-to-pin shorts, if you can't merely 'slide it away' using a soldering iron. And a flux pen is mandatory for successfully soldering those 'too small to see properly' pins. Fortunately, flux pens are cheap, and so are loupes [digikey stocks plastic ones, I have 2 on hand], and if you work with modern electronics, you really SHOULD own a loupe and a good lighted magnifier.

All of the power pins on the CPU are connected to 0.1" male breakout pins, that plug into corresponding female pins underneath. The female breakout pins were individually cut and soldered onto the board. OK it was difficult doing it this way, but it make the board pluggable in case I need to switch it out or fix something, and also exposes EVERY! SINGLE! NON! POWER! PIN! on the ATXMega128A1U. [so I'll need power busses on the power supply 'support' board underneath, at some point].

I built this because I am currently adding support for additional ATMel 'xmega' CPUs, not just the ATXMega64D4, to the XMegaForArduino project. The ATXMega128A1U is one of those.

Customizing the Arduino Environment for use with the XMega processors

The Arduino IDE does not natively support the xmega processors, although the build tools do. However, since the Arduino IDE version 1.6, it is highly customizable using a well documented method. As such, the XMegaForArduino project has a setup file that you can download with the Arduino IDE's "Package Manager". You should open the Arduino IDE, then select 'File' 'Preferences' [in Linux, using 1.8; your mileage may vary] and then the 'Network' tab to access the Package Manager. Then, install this file using the Arduino IDE's Package Manager Manager. Additional Documentation on the Arduion IDE's Package Manager and environment can be found on the '' web site, and is somewhat beyond the scope of this web site.

OLD METHOD: Customizing the Arduino Environment

If you are using a version of the Arduino IDE newer than 1.6, you do not need to read this section. Otherwise, if all you have is an older Arduino IDE, such as from a Linux distribution that has not updated to the newer IDE, you may still need to do this.

Some time ago I submitted a short article to the Arduino Playground wiki site regarding customization of the Arduino IDE for different kinds of hardware. In short, I described what I had done so far with respect to the ATXmega64D4 processor and the customer's device. There are several specific modifications that need to be made, all of which are necessary to make the Arduino IDE work with a new type of processor.

Although there is already a GitHub project for an 'xmega' version of the Arduino IDE, I did not see the need to modify the entire thing just to handle a new CPU. In fact, it seems so easy to modify the existing Arduino IDE with a simple patch, that the need for modifying the entire environment was just too impractical. It also makes it VERY easy to update to a new version of the IDE. I based my modifications on Arduino 1.05 since that's what I had installed under FreeBSD.

The sub-directories I list here exist within the Arduino IDE directory tree. Typically this will be /usr/local/arduino (as on FreeBSD), or /usr/share/arduino (as on Ubuntu 12.04). On windows or OSX, your mileage may vary.

The 'boards.txt' file

The 'boards.txt' file resides in the Arduino IDE's 'hardware/arduino' sub-directory, and contains entries that describe the various board types, and the correct sub-directories and compiler CPU settings to use when compiling for that particular board. Using the supplied patch file (or manually editing boards.txt) allows you to specify a new board type for an ATXmega64D4 device. An appropriate entry would describe the 'cores' and 'variants' sub-directory as well as the flash method and CPU for your particular hardware. If you examine the 'boards.txt' file, you will find a number of different Arduino and compatible devices listed. When you look in the appropriate 'cores' or 'variants' sub-directory, you'll see CPU-specific and board-specific implementations of the Arduino API functions and definition files. Setting these correctly in 'boards.txt' allows you to customize the Arduino IDE to work with whatever board configuration you might have, so long as it is possible to map everything properly.

The 'cores' sub-directory

Within the 'cores' sub-directory are a number of CPU-specific sub-directories, each named according to the type of device. The main directory is 'arduino', and corresponds to the ATmega328p (and related) CPUs for Arduino and compatibles. The corresponding entry in the 'boards.txt' file will be '', where 'xxx' is the name for your boards.txt entries, and the entry value will be the sub-directory name (such as 'arduino'). The source and header files within this sub-directory implement the startup code (device initialization), the timer functions, the serial port, and both the analog and digital I/O, as well as a few other features (like the 'Tone' library). In short, it's a hardware abstraction for the type of CPU you are using, but is generally NOT board-specific.
On non-windows systems, it is possible to use a symbolic link to point to a directory containing your own implementation. This is recommended for OSX, Linux and BSD installations, so that you do not have to modify the actual Arduino directory structure.

The 'variants' sub-directory

Within the 'variants' sub-directory are a number of board-specific directories, each definining the pin-to-pin mapping for the various analog and digital I/O pins. In short, it implements the board-specific 'abstraction' header file 'pins_arduino.h'. For the 'xmega' implementation, D2 is mapped to digital pin 0, D3 to pin 1, and so forth, so that the serial port on port D will map to the same pins as the serial port on an ATmega328p.
On non-windows systems, it is possible to use a symbolic link to point to a directory containing your own implementation. This is recommended for OSX, Linux and BSD installations, so that you do not have to modify the actual Arduino directory structure.

The 'avrdude.conf' file

An additional file, one that is used by 'avrdude', is the 'avrdude.conf' file. It contains information that avrdude needs in order to flash a device. You can modify this file using the supplied patch file in the Arduino IDE patch tarball for the ATXmega64D4. Other ATXmega series processors should already implemented, though. It seems that only the D4 was missing, but as it is not supported by the existing avr compilers (without the patches I made), it is understandable.
The 'avrdude.conf' file is located in various places, depending upon your implementation. On FreeBSD, it is in /usr/local/etc/avrdude.conf . On Ubuntu 12.04, it is /etc/avrdude.conf . A symbolic link to this file is typically in the hardware/tools directory within the Arduino environment.

The 'sketchbook' sub-directory (in the user's 'Home' directory)

When you set up the Arduino IDE, you can specify a default sub-directory for your sketches. Typically this will be the 'sketchbook' directory within the user's Home directory. If you create a sub-directory 'libraries' within this sketchbook directory, and populate it with library sub-directories, the Arduino environment will search for libraries HERE, in addition to the default libraries in the Arduino IDE's directory tree. As such, if you need to customize a library (let's say the SD card library) to work with the xmega, you would need to make a copy of it into your own library tree, and modify the code accordingly. This also makes it possible to have customized library versions of just about any Arduino library, ones that contain fixes or implement specific functions that YOUR projects need. So if you do not want to modify the existing Arduino libraries to work with the xmega

My 'xmega' Implementation - The XMegaForArduino project

In support of the xmega processors (in general), and because of a customer project that needed it, I created the XMegaForArduino project, which is officially located on github.

Prior to a somewhat recent gcc version (4.8.3), there was no support for the atxmega64d4 for 'avr-gcc' (and related tools). As a result, I produced my own modifications for the compiler suite (which I then submitted to appropriate places). All of the necessary patches are available on the XMegaForArduino project in the 'patches' directory.

Here is a short list of features:

  • Startup code correctly sets up the internal 32Mhz clock
  • Support for both 'arduino' and 'wiring' flash protocol (USB bootloader in the works)
  • Compatible timers and time-related functions
  • Some additional xmega-specific features, like 'wait for interrupt' and advanced IO pin capabilities
  • Dual serial ports. The 'Serial' object uses port D, for easy mapping to digital pins 0 and 1.
  • Compatible Digital I/O as well as additional support for the xmega's more advanced pull up/down and open drain/source configurations, using bit flags
  • Support for asynchronous interrupts on pin '2' of each port, and synchronous interrupts on any other port's pin.
  • Additional support for xmega's advanced interrupt trigger types (high or low level, low-to-high, high-to-low, change).
  • Compatibility mode for analogRead, configured to behave as the ATmega328 would behave (10-bit value, 0 to Vcc).
  • Can generate PWM via analogWrite on nearly all of the digital I/O pins (on most xmega CPUs).

Here is a short list of items to be completed:

  • Tone library (part of the 'cores' source)
  • Two Wire implementation for xmega (using TWIC; TWIE does not appear to work properly at this time)
  • Ethernet and other standard library support (as needed)

Related ATXmega Projects and Breakout Boards

  • Akafuino X XMega32A4 Microcontroller Board
  • Xaduino Xmega128A3U Xmega Based Arduino System
  • ATXmega32E5 breakout board v2
  • Sparkfun ATXmega128A1 breakout board
  • MCU ZoneATxmega128A1U mini board (via Ali Express)
  • Adafruit TQFP44 breakout board
  • MC Pros Universal QFP breakout board (32-100 pins, 10-pack)
    This board should work with a LOT of different CPU case types, particularly a QFP-100. This one is 0.5mm pitch (others also available)
  • Robot Shop Cytron QFP breakout board (others also available), not as easy to solder as the one above, but much less expensive
  • Proto Advantage QFP-100 to 100 pin DIP breakout board (others also available HERE)
    With THIS you should be able to use a regular breadboard on all 100 pins. It's a little pricey but may be well worth it, depending on your project
  • Xmegaduino Development Environment: Github Page
  • Wikipedia Page on QFP packaging

Notes on Debian and Ubuntu 'source' packages

In the 'Source Download' section, below, there are some OLD packages for Ubuntu 12.04 and Debian 'Wheezy' that were pre-built for specific architectures. If your architecture is different, you can build from source using a procedure similar to the following:

  1. Download the appropriate package tarball and extract the tarball contents into an appropriate directory
  2. For each of the 3 packages, do '[sudo] apt-get build-dep {packagename}' where 'packagename' is 'avr-libc', 'binutils-avr', and 'gcc-avr'
  3. Use 'dpkg-source' to extract the '.dsc' similar to the following:
      dpkg-source -x avr-libc_1.8.0-2.1.dsc
  4. change directory to the package source directory (in this case avr-libc_1.8.0-2.1) and do the following:
      fakeroot debian/rules binary
    This will build the package as a '.deb' in the same directory you extracted the tarball into.
  5. once the packages are built, you can install the package as follows:
      [sudo] dpkg -i avr-libc_1.8.0-2.1_[your architecture].deb
    The build+install order is avr-libc, binutils-avr, and then gcc-avr.
    NOTE: since avr-libc is an 'all' package, you probably won't need to build this one, and can install the 'all' version as-is. But if you want to re-build it anyway, you still can.

Official site for the Arduino Uno
'Playground' wiki site for Arduino on Freebsd

(Original) Source Download (as-is, GPL, no warranty)

These very old patches and source files implement the necessary support for the ATXmega64D4 processor for very old gcc compilers and environments.
NOTE: for newer files and 'other CPU' support, see the github site.
Ideally, you should install the latest Arduino IDE and use the compilers and tools included with the IDE, along with the Board Support from the XMegaForArduino Project.
Back to S.F.T. Inc. home page

FreeBSD® is a registered trademark of the FreeBSD Foundation.
Debian is a registered trademark of Software in the Public Interest, Inc.
Ubuntu and Canonical are registered trademarks of Canonical Ltd.
Arduino brand is copyright of Arduino SA
AVR®, XMEGA®, and Atmel® are registered trademarks of Atmel Corporation

©2014-2018 by Bob Frazier and Stewart~Frazier Tools, Inc. - all rights reserved
last updated: 8/21/2018

Community projects are generally good, but socialism, in all of its forms, is always evil.
Human nature desires a reward for hard work, and socialism denies greater rewards to those who achieve more, by trying to equalize outcomes, NOT based on merit, nor on proper decisions, nor on hard work, but on a false sense of 'equality' measured by outcomes. Community projects themselves may be be viewed as a means of 'giving back', as if there's some kind of 'guilt' for success (which there isn't), but they accomplish so much more, including the ability to demonstrate what you are capable of to potential clients (my goal), and to enable an industry to thrive when it may not be profitable enough without some support from the community, like open source software.