Suggest support for xmega32A4U

[aster94]

Hello,

I am sorry to open an issue but i am not familiar with github and is impossible to leave a private message.

Anyway which xmega is suggested? I would like to make a few boards based on the xmega32a4u

[zdjurisic]

A4U microcontrollers are fantastic, and it would be great having a proper support for it. I have recently added here a board and variant files for 128A4U. All the A4Us have the same pinout so you may peruse my files - if you find a flaw in my implementation, please let me know.

Keep in mind that this core, as well as the xmegaduino, are incomplete. Also notice my issue with unexpected I2C communication behavior (if it works for you, please say, so we know the core is OK, but from all I tested, the core has a bug). Since there seem to be no response and no progress with either this or xmegaduino core, I have moved on to well-supported (fully functional cores) and equally powerful ARM Cortex chips, Atmel SAM-D21G18 in particular, as close-to-perfect replacement for XMega A4U

[aster94]

I didn t bought the MCUs yet, and i m not sure i will buy them if at least spi and i2c doesn t work properly. For the samd are you using the core for the arduino zero or another?

[aster94]

I thought that if i had to go for a 32 bit i would directltñy use a stm32, so i would remain with the xmega if the core is enough complete

[zdjurisic]

Arduino folks have the cores for Cortex M0+, M3 and M4 (that's your STM32). It seems to me that all the board manufacturers are providing just the boards.txt entry, and some provide their own bootloader, but I think everyone is using Arduino cores. That's great because everyone provides feedback on the same core, and the team behind the Arduino cores actually works on the issues, which, from what I see, is unfortunately not the case with any of the XMega cores; too bad Arduino team never took on the XMega, but maybe it is not necessary between the Mega and Cortex. I'd still use it if there was a functional core, but I have no intention of writing a core myself, so I am off to Cortex-M0+ (the SAM-D implementation)

[bombasticbob]

nice to see activity in here. I'll have to check back more often.

I plan on doing an actual board with the xmega128A4U, and of course the smaller NVRAM versions would be supported as well. might have some problem getting a 'catarina' style bootloader into something with less than 8K of flash space, though. I'll have to check the chip specs to see what the boot flash size is for the 32 and 64 but if it's big enough I'd include bootloaders for those as well.

[GnuReligion]

Well, +aster94, I did take the plunge, and bought 5 of these atxmega32a4u chips from AliExpress earlier this year. Very cheap, about $2 each. They do something that is frankly, astonishing. They run USB 2.0 at full blast, and stay ice cold. Amazing.

I looked through all 8 forks of the XMegaForArduino project here, and I see no variant for the "a4" series. There are promising looking patches for the boards.txt file ... have tried that. The core must need some mods though, as I cannot compile anything. +zdjurisic: I see you have an Xmegaduino project, but where have you put your mods for XMegaForArduino to to make the 128A4U work?

The Akafuino-X uses an Xmega32a4, but the Xmegaduino project seems neglected. Some
functions work ...pinMode()/digitalWrite()/analogWrite(), but none of the timing related functions work. delay() just hangs. If that were the only thing wrong, could live with it. Sadly, <util/delay.h>'s _delay_ms() seems to be about 5% too fast, which is something that does not happen in avr-gcc.

My Xmega project has been an adventure. Had to build my own PDI programmer to put the DFU/Flip bootloader on the things. Mine weren't shipped with it. Had hoped the hard part was over, and go on compile all the LUFA projects (want a MKII JTAG-ICE clone), and adapt my Arduino sketches to debug through a virtual serial port. I mean, that is the real appeal here, right? You can bootload with avrdude's flip support, then debug sketches through a virtual serial port, all using just one chip running at 3.3v and one USB cable connection and no serial adapter. Why is the whole Arduino community not doing exactly this thing?

To my bitter disappointment, LUFA only has limited support for Xmegas. The examples work, but none of the killer projects. Cannot figure it. I have been able to get printf support though virtual serial USB though. Deriving a CDC class to do Arduino's write()/Print() functions using LUFA's virtual serial will be trivial ... if ... and a big IF ... there were support for my poor atxmega32a4u.

Well, +bombasticbob, I am willing to mail you a couple of verified all-pins-working atxmega32a4u chips, with DFU bootloader installed, and already soldered to PCB plate with male pins headers. If this is not enough, will send you one of my project boards running at 3.3v, with a microusb connector, 32khz watch crystal and reset/boot buttons, if this will help you will add support for these.

[bombasticbob]

I've been planning on doing experiments with 128A4U and similar. I have a 128A1U that I was using previously, but it appears that the A4U series is more practical to use [and less expensive].

(now to just find the time to make all of this happen)

[GnuReligion]

+bombasticbob ... I do agree that the A4U series is a better candidate for Arduino than the A1U. If I needed 100 pins on a chip, would probably need to quickly access external DRAM ... so I'd use an ARM or SBC for the task. If we could only convince Atmel to release the A4U in 28-pin DIP!

Alas, I may be the only person that uses the results of your hard work ... and can see why developers are reluctant to make the port. There are so many features of the Xmega that will simply be neglected in the Arduino environment (PWM and analogue read) ... and so many arbitrary decisions to make (clock source for microseconds/delay) ... and what will be the law when it comes to pins_arduino.h?

Had hoped to modify Akafuino-X's Xmegaduino ... but the subtle differences in the architecture between the A4 and A4U befuddle me with compilation errors. May be completely wrong about this, but I think the commercial A4 boards often use a 16mhz crystal to simplify the coding effort.

Well, +bombasticbob, my offer still stands ... will mail you one of my 32A4U dev boards, complete with PDI port, DFU bootloader, microusb port, watch crystal, and separate reset/bootload buttons, if it will help. My stuff is built on a 5x7cm perfboard though, so not as pretty as these: http://mdiy.pl/3-zgrabne-plytki-uruchomieniowe-dla-atxmega/?lang=en

[bombasticbob]

@GnuReligion

I have a board for 128A4U already designed that I was kicking around a while back, before being temporarily shelved. It needs some cosmetic work, but is a 2 layer board that is laid out like an Uno and has some additional pin holes for the extra I/O. It has problems with the silk screen and the necessary vias, which is where I left it. I may just build a few anyway. The idea is to make it a 3.3v Arduino clone board with an XMega on it and very few additional parts besides the XMega.

The 'pins_arduino.h' file really is a custom for whichever board type you have. I could add the header file for this board layout to the project 'as-is'. It's similar to what I've done for 64D4 and others, but completely untested at this point. I expect it would work, though.

[bombasticbob]

oh, one thing worth mentioning: if you use an external crystal, it messes up the clock configuration in wiring.c [it's set up to use the internal clock]. you could re-do this, of course, to use a crystal, but the whole point of doing it this way was to have a reasonably generated internal 32Mhz clock without using an external crystal nor resonator. Lower parts count, less expensive. that sort of thing.

FYI I built a couple of boards for other CPUs using Sparkfun's shield board and a breakout board from Adafruit, similar to this:

since the CPU layouts are identical for 32, 64, and 128, the only real difference is the bootloader. I'm inclined NOT to use ATMel's bootloader for a few reasons. So it means a re-write of the Arduino 'Catarina' bootloader, at least for now, but that shouldn't be a problem [as long as it fits in the bootloader space].

[GnuReligion]

Am not in love with the Uno layout because they place one row of outputs 0.4" out of square with an ordinary perfboard. The Nano is more elegant, but we would have trouble putting the 44-pin Xmega monsters on something that narrow.

Ah, it looks like your QFP-44 plate is wider than mine. Nice. Had to hammer my pin headers at 90deg to solidly solder them to the underside. My plate is too narrow to support thru-holes on those middle pins.

@bombasticbob : Here is the thing I want to send you, if you manage to leave me an address in an IM or email.

The microUSB's 5v is cut to 3.3v using an AMS1117 3.3. Hard to see, just below the USB. Just south of these, there is a PDI port necessary to install your own bootloader. My chips came with no boot loader (sigh). On the bottom right is a reset button, and the other button just above it will ground the PC3 pin, selecting boot mode with the Atmel standard flip/dfu-programmer/dfu-tool. They are close enough so you can rock your thumb across them to put it in dfu mode.

Have placed 104 caps across the four VCC/GND lines ... though if I were doing precision measurements, the AVCC can use an inductor in series, and perhaps a larger cap. PR[01] Has a 32768hz watch crystal attached ... just because I saw it included in schematics for other boards. Now this is not for the system clock, but rather, for syncing, calibration, and RTC. Factory calibration has worked fine on all 5 of my 32a4u's though, so you certainly do not NEED to use it, at all, ever ... but if you did:

// Enable external 32.768KHz crystal:
OSC.XOSCCTRL = OSC_XOSCSEL_32KHz_gc;
OSC.CTRL |= OSC_XOSCEN_bm;
while ( !(OSC.STATUS & OSC_XOSCRDY_bm) );

You can set the RTC source to it ...

// RTC source is 1024 Hz from 32kHz crystal oscillator on TOSC
CLK.RTCCTRL = ( CLK.RTCCTRL & ~CLK_RTCSRC_gm ) | CLK_RTCSRC_TOSC_gc | CLK_RTCEN_bm;
while( RTC.STATUS & RTC_SYNCBUSY_bm );

Then sync it with the system ...

// Sync 2Mhz with extern watch crystal:
OSC.DFLLCTRL = ( OSC.DFLLCTRL & ~OSC_RC2MCREF_bm ) | OSC_RC2MCREF_bm ;
DFLLRC2M.CTRL |= DFLL_ENABLE_bm;

And only then, start up the PLL to 32Mhz. I copied this from somewhere ...

// 32MHz System Clock
CCP = 0xD8; // DISABLE CCP "CONFIGURATION CHANGE PROTECTION"
OSC.CTRL = 0x02; // ENABLE THE 32MHZ OSCILLATOR
while( !(OSC.STATUS & 0x02) ); // WAIT FOR OSCILLATOR TO BECOME STABLE
CCP = 0xD8; // (again?)
CLK.CTRL = 0x01; // SELECT 32MHZ

Well, almost all of this code was copied from AVRfreaks and various other places.

Sadly, I have not figured out a good way to count milliseconds and microseconds without spending two of 5 TC registers ... TCC[01], TCD[01], TCE0. Would like to be able to use all 16 of the available PWM pins.

Well, instead of re-inventing the wheel, was hoping to just go through the compilation errors, and specific architectural differences between the 32A4 and 32A4U chips. Xmegaduino already supports the 32A4 on the Akafuino-X board.