ATXMega Keyboard Controller?

[epicepee]

Has anyone tried using an ATXmega-based board as a controller? I'm thinking something like this:
http://www.ebay.com/itm/Atmel-AVR-XMEGA ... 20d6dde11b

$22 buys a microcontroller built on the same architecture as the popular Teensy, but with more pins, memory, and twice the CPU clock. LUFA apparently works pretty well with the XMega series, too.

[vvp]

I'll try to use ATxmega128a4u with Katy. The chip itself cost about 3.7 €.
Preliminary tests indicate that LUFA works fine with it. Well not all of LUFA features work (e.g. mass storage does not) but the important ones (keyboard, mouse, serial) work. The keyboard which is going to use atxmega is not finished yet, so I cannot comment more now.

[xwhatsit]

xmega is a very different architecture than the plain old mega (as per DT's beloved Teensy). They're (partly) 16-bit and the registers are completely different. They're also 3.3V.

I struggle to see the point of them to be honest; if you're going to have to adapt to a new architecture (and move to 3.3V), why not just go the whole hog to 32-bit ARM which is far cheaper than the expensive xmega and very feature-complete. For example, in NZ with element14 the ATmega32U4 is NZ$12+; or you can get the STM32F107, which runs at 72MHz, has 80 GPIO, 128KB flash, 48KB RAM, built-in DAC, DMA... it's even got ethernet for goodness sake! To get close to that with an xmega you're looking at the ATxmega128A, but that's only got 8KB of RAM and runs at 32MHz. Oh yeah: and the STM32 is NZ$7.60, whilst the xmega is NZ$11+. Somebody remind me why I'm using the ATmega32U2 in my keyboard controllers again

[quantalume]

Somebody remind me why I'm using the ATmega32U2 in my keyboard controllers again

Because if the processor is too powerful, people will expect you to put too much in the firmware?

[Muirium]

I know a few people who were just getting started with all this stuff (keyboard converters and other USB HID stuff) who were tempted to buy a Teensy 3.1 when they saw the range because OMG 32 BIT ARM MOAR POWAH!! And most of them now have a spare Teensy they can't find software to run on, because Soarer, Hasu, etc. all build for Teensy 2.

We just buy whatever hardware you software writing guys tell us to! I mean, sir!

(In my imaginary software dev world, I assume you just pass different parameters to your compiler to support whatever architecture you like. Thoughts like this are why I can never get anything of my own to work…)

[matt3o]

partially OT: I have a teensy3 working firmware.

[Muirium]

Hasu's? Was it easy? What's the incantation? Do I need garlic?

[matt3o]

it's mine, it is based on pjrc general purpose keyboard code, very easy, 6nkro, no backlight of course, but it works.

[Muirium]

How do we customise the layout? (Editing source code I presume.) And have you got macros?

Of course, with a fancypants ARM processor, we expect a few extras. Besides, unused flash cells get lonely. How about a secret Eliza built into the board…

[matt3o]

the matrix is defined in the source, yes, but it's a pinch easier to edit than hasu's code. Macros would be possible, but there's not much interested in that kind of firmware so I'm just using it for my projects (actually just one project that runs on teensy 3).

[Muirium]

My favourite thing about Teensy 3, frankly, is the micro USB socket. That lower profile is why you're using it, right?

[matt3o]

yes, the micro usb spares a bunch of mm.

I hope they'll make a GB of the MCHCK sooner or later.

[Muirium]

Tasty little thing… we're living in interesting times for this stuff. I'd be all over a Bluetooth equivalent, when it comes.

[vvp]

Somebody remind me why I'm using the ATmega32U2 in my keyboard controllers again

I'm not sure why people want to use ATmega32u2. I'm running away from ATmega32u4 because it has too small flash for my goals. Anyway I built the first prototype with it because of numerous readily available firmwares. So it is an easy option to get something done quickly to verify the keyboard shape (I'm actually typing this on the first working Katy keyboard prototype).

I'll probably use ATxmega128A4U. The other option I consider is STM32L100RBT6 (ARM Cortex-M3). These are the two cheapest options easily available to me. The reason I prefer ATxmega, is the libraries with BSD or GPL like license for USB stack. LUFA is usable for keyboard/mouse support and has BSD like license. I did not find free enough USB library for the STM micro-controller. Although STM provides 3 products with royalty free USB libraries with source code but I cannot redistribute the source code, so it is not usable. I'm quite willing to write a lot of firmware code, but really, I'm not that eager to implement the whole USB stack too (or port LUFA). The result is that STM32L100RBT6 is not suitable for an OSS project without more work. .... hmmm ... or I could close firmware :-/ I would prefer the STM chip if there would be an OSS friendly USB library. Not because it is 32bit or because it has more ports. There is almost no 32bit arithmetic in keyboard firmware and the additional ports would be unused anyway. I would use it because it is a very little bit cheaper and because of dual voltage ports. That may be useful eventually. But not just now for Katy.

As for as prices: ATxmega128A4U is 3.64€ and the STM chip was 2.70€. STM is cheaper but not enough to bother with the USB stack library. (Btw, the last time I checked ATmega32u4 was about 5€).

As for as ATxmega being a new architecture compared to ATmega: I'm not sure what people are talking about. Looks like only a marketing claim to me. The instruction set is the same except few new instructions in ATxmega (crc compute, encrypt/decrypt). The access to IO is different but better. So that is a change for good. ATxmega being partially 16 bit is a marketing ploy. If six of your 8bit registers can be used as three 16 bit registers for addressing memory, then that does not represent a 16 bit CPU to me. The ALU is 8 bit only. There are still 32 8bit registers as they were before. There is hardly any difference in the CPU core. ATxmega looks only like ATmega with the worst atrocities fixed. And finally it's errata is short. Took them long enough

[xwhatsit]

For ARM USB stacks (along with rest of libraries etc.), check out libopencm3. It's LGPL, not BSD, but still fine for most purposes, even commercial. It's under fairly heavy development but the bits that I've used are very high quality, although you might occasionally need to read some source code to figure out some missing documentation. You have to do a bit more legwork when compared with LUFA; it's probably comparable with the Teensy USB libs in that respect.

xmega is close enough to mega, but if it's different enough to make you go back through your libraries and have to add a bunch of new code for timers/ADC/GPIO etc. (let alone need to add entire new swathes of stuff if you want to use the goodies like DMA), then at least in my case I'm better served by just picking one of hundreds of suitable ARM chips, rather than switching over to a rather unique and single-source platform like the xmega. It's a great chip but it sits in a funny niche. If they had introduced it as a mega and priced it accordingly then it would be very attractive...

Copy you on the limitations of the ATmega32U2. Although I'm only really hitting RAM and EEPROM usage problems with my controllers, even with all of the capsense stuff + four layers + macros + standard (bloated) DFU bootloader I've got ⅔ of my flash left. Would be nice to have a few more USB endpoints like the U4 though.

[vvp]

For ARM USB stacks (along with rest of libraries etc.), check out libopencm3. It's LGPL, not BSD, but still fine for most purposes, even commercial.

Thanks for pointing libopencm3 out. LGPL is fine. It seems less finished (for STM32L100RBT6) compared to LUFA (for ATxmega128A4U). Moreover the current firmware is based on LUFA so porting to ATxmega should be significantly easier. So I'll probably stay with ATxmega anyway, but I'll check out libopencm3 more. It is a pity LUFA is not ported for STM32L100RBT6

As for as ATxmega being more expensive than some ARM chips. It is not that bad. For the two chips I'm considering, ATxmega is about 0.9€ more expensive but it has more endpoints (iirc 30 to 9), event system, WaveEx, and AES engine. On the other side the STM chip has more ports (many of them are 5V tolerant) and LCD driver. Otherwise it is about the same. AES may be useful since I'm considering adding a password manager to the keyboard. The STM's 5V tolerance seems useful (though I do not need it in Katy). The other differences seem irrelevant. When I looked at an ARM with AES then the price was already higher than the ATxmega. The LCD driver is not that useful as it may seem since (if you want a small alphanumeric LCD) it is easier and cheaper to just get an LCD with a dedicated driver/controller included (which is what I did). Considering prices/features, ATxmega and ARM parts seem balanced to me. ATmega is different. It is expensive for what it does.

Thanks for informing me about the ARM options.

[vvp]

Kko ported Katy's firmware to ATxmega128A4U controller. it looks it was a good idea to try it instead of STM32L100RBT6 (ARM Cortex M3). The primary reason was that the firmware uses LUFA and the important parts of LUFA are already ported to ATxmega.
The summary is:

• studying the ATxmega architecture took about 20 hours,
• porting the firmware took about 12 hours.

Just to get an idea how much work it is to port a firmware from ATmega to ATxmega provided that the library your firmware is built on supports both ATmega and ATxmega. The firmware has hardware abstracted well enough. Except the LUFA update (to a newer version which support ATxmega) the changes were limited mostly to some parts of 3 files which define matrix scanning, LEDs, buzzer, LCD.
As xwhatsit pointed out, it was the code which does IO which is done differently (and in my opinion better) in ATxmega.