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.

[bombasticbob]

I've been trying to make my test boards as arduino-compatible as possible, which is why I stick with the layout. The inexpensive bare shield board from Sparkfun helps me do that.

FYI clock support is all done here:
https://github.com/XMegaForArduino/arduino/blob/master/cores/xmega/wiring.c#L319

I could modify it to allow for external clock but the idea was to minimize part count and leverage the capability of the device, which has a reasonably accurate clock without a crystal. It should end up being a different 'core', maybe 'xmega-crystal' or something similar. I'll consider it.

Additionally, two of the I/O pins won't be available when you use an external clock like that. It means re-defining how the LED pins are set up in the 'variant' files (so yeah "yet another variant" or a handful of "#if" sections around parts of the code).

in any case, not a bad idea, just extra work and I wouldn't have my own hardware to necessarily test it. I could consider building something later by plugging a crystal (or a resonator) into the I/O pins directly, but it also means modifying the bootloader to use different pins for the LEDs. So yeah a bit more work than I wanted to do.

then again - you could do a repo fork and just modify your own version [that would work, too]. That would also help if you want to submit patches. but you'd want to submit any clock modifications as a complete set for a different 'core', i.e. "xmega-crystal" or "xmega-extosc" or similar, and patches for all of the variant files and bootloader, so it applies across the board.

(yeah maybe too much work)

[bombasticbob]

while I'm thinking of it, I prefer not having to reformat code so this typically what I'd have as a style guideline (from another one of my projects):

https://bombasticbob.github.io/X11workbench/mainpage_2.html

[bombasticbob]

currently working on an xmega128A4U which is similar enough that the header file could be cloned.

this is the working 'variants' header file:
xmega128a4u_pins_arduino_h.txt

[GnuReligion]

+bombasticbob, I think you misunderstood me earlier. I certainly don't want the overhead of an external high-speed crystal -- that will mess up the 32/48mhz PLL clocks necessary for USB2. Merely pointing out that a working A4 core does use one: the Akafuino-X with Xmegaduino.

The last time I tried XMegaForArduino with my 32a4u in November, it just crashed with the most trivial programs that use delay(). Has this changed? The Xmegaduino core did not crash, but its timing was way off. Probably have to sacrifice one of the timers to implement delay(), delayMicroseconds(), millis(), micros(), and thus disable at least two potential PWM channels.

Certainly appreciate your public work here, but I am not pushing for any more coding effort on the a4u. For $2, you can get a "Black Pill" stm32 with 128mb flash on AliExpress. You don't have to build a bizarre PDI programmer to flash it -- it's native loader uses serial. It already works (mostly) with Arduino IDE directly supporting Serial.print() though ACM. With the Maple bootloader, you program a Black Pill without the need to push buttons or set jumpers. It is everything I wanted my atxmega32a4u to be, and more. Absolutely superior.

I do not regret building out 5 atxmega32a4u MPUs ... it was a learning process. Can still slap one one into a project, using avr-gcc to program it, and LUFA libraries for USB2 serial debugging and control. Xmega will simply never be a mainstream hobbyists' platform because it is has been eclipsed by little ARMs.

[bombasticbob]

I haven't noticed any problems with timers with respect to using USB, but it's possible you're using old code from this repository, or rolling your own on the clocks [which will affect a LOT of things].

Please try and repo that timing problem with the latest code (thanks) and create an issue for it.

Also check out the new header for the xmega128a4u, if you want to. You should be able to clone it for the 32a4u. I'm hesitant to post anything that has not actually been tested, FYI which is why I haven't created a header for the 32a4u specifically. xmega128a4u seems to be working ok so far.