Floating Point Unit support

I am looking at porting the Zero core to support the SAMD5x chip as I specifically want the FPU. Does the Arduino core "care" if there's an FPU or not? I know I have to change the compiler flags to tell it there's a hardware FPU.

There could be impact on interrupts. The ARM has an option not to stack FP registers if they haven't been used, or won't be used in the ISR, I think. Otherwise, interrupts are going to get slower.

Fortunately for my application getting an accurate calculation result is more important than the speed of an ISR... But on the flip side running at 120MHz means the whole thing is just faster in general.

Have you checked out the stuff that Adafruit has on Github. They seem very excited about SAMD5x, and apparently have made a bunch of progress already. I'm not sure whether that includes floating point considerations.

(It looks like a really promising set of chips. I like that it goes from Uno-sized to Mega-sized without major changes (unlike Zero vs Due.))

(Or "will", anyway. Atmel has never been particularly trustworthy in the "delivery schedule for new chips" department, and I doubt whether Microchip has fixed everything. There are currently a fair number of people upset about the Atmega328PB becoming "unobtainium.")

Thanks for the information about the SAMD5x. A 120MHz microcontroller with an ARM Cortex M4F core, huge memory (up to 1MB flash, 256KB RAM) and comes in a variety of small TQFP and QFN packages, it certainly looks interesting.

Adafruit have prototype on an Uno-sized PCB: Adafruit Metro M4 feat. Microchip ATSAMD51 : ID 3382 : $27.50 : Adafruit Industries, Unique & fun DIY electronics and kits, but like you say it could be used for Mega-sized boards as well.

Mouser does have the SAMD51G19A in stock, it's the 512KB Flash 48 Pin QFN variant. I am going to give the Adafruit core a look to see if they're supporting the FPU.

Looks like Adafruit will be using the SAMD51J20A (1MB flash, 256KB RAM in a 64 pin QFN package) for their Metro M4 Express board.

It doesn't look like they're supporting the FPU at the moment, (at least I couldn't find any reference to the -mfpu or -mfloat-abi flags on the compiler command line in the "platform.txt" file), but I'm sure they'll add this in due course.

At 120MHz it'll still go pretty quick though, with or without the FPU enabled.

I've just ordered some SAMD51J20As in both 64-pin TQFP and QFN packages.

Checking the SAMD51 datasheet it appears that, while it isn't quite a drop in replacement for SAMD21, it's very close. The power, debug, crystal and sercom port pin placement look the same. The main difference being the substitution of a pin called VSW for port pin PA28 (USB_HOST_ENABLE on the Arduino Zero), but this pin can remain unconnected, if powering the microcontroller's core using its internal linear regulator. The TCC and TC timer outputs have moved to other pins, but this can be worked around and hopefully won't be too much of an issue.

I'll use the TQFP devices as a drop in replacement on one of my SAMD21J18A (Arduino Zero) based custom boards for the purposes of evaluation. I'll try to get it going using Adafruit's new Metro M4 core code with the Arduino IDE.

I'll let you know how it goes...

Hey guys,
if you start working with the D51, you might want to take a look to the 21 pages of errata here (PDF).

How do you release a chip with the internal pull up for the reset line being broken?? Hopefully the get their act together as this chip shows promise with both Ethernet and CAN capabilities on the E51 version.

I'm making steady progress on modifying the Arduino IDE, in order to integrate the SAMD51.

There are three main issues:

1. Arduino IDE Boards Manager

The standard way to add new boards to the Arduino IDE, is to provide the web address (or URL) of a JSON file. The Arduino IDE uses this to configure its Boards Manager.

I couldn't find a JSON file in the Adafruit code and rasied the issue with them on Github. It turns out that they're currently not providing any JSON file support, so I'm currently in the process of writing my own.

I'll also eventually modify the "variant.cpp" file that defines the board's pin functions, as my SAMD51 target board pinout is closer to the Arduino Zero than Adafruit's Metro M4.

2. Atmel CMSIS

The Atmel CMSIS includes the register definitions for the microcontrollers.

The Arduino IDE also currently lacks the SAMD51 register definitions, so I've included them. These are the "samd51" directory, as well as modified "sam.h" and "samd.h" files.

3. Adafruit's Modified Bossa 1.7.0

Bossa is a program used by Arduino IDE to upload the code on to their boards using the native USB port.

Adafruit have also forked and modified Bossa Version 1.7.0, to make it compatible with the SAMD51. The bossac executable files are located in the "Tools" directory of their Metro M4 code. I've replaced the Arduino IDE's current "bossac.exe" file with the modified one. It appears to work OK with the SAMD21.

Did you see the pull request to add the SAMD51 CMSIS to Arduino CMSIS repository?

Hi dlabun,

Did you see the pull request to add the SAMD51 CMSIS to Arduino CMSIS repository?

adding support for SAMD51 by deanm1278 · Pull Request #8 · arduino/ArduinoModule-CMSIS-Atmel · GitHub

Yes I did. I guess it's likely that SAMD51 CMSIS files will be supported in the next version of the Arduino IDE, or maybe already are with the hourly builds.

For now I just got the SAMD51 files from the Adafruit's "ArduinoModule-CMSIS-Atmel" repo on Github.

By the way, I've got the boards manager going...

SAMD51 Board.jpg

SAMD51 Board.jpg

Have you figured out the differences between the SAMD5x and the SAME5x? They seem to have the same datasheet - I guess D5x is supposed to be an upgrade of D2x, while E5x is a cheaper E7x?

There's a development board for the E54... https://www.digikey.com/product-detail/en/microchip-technology/ATSAME54-XPRO/ATSAME54-XPRO-ND/7354381

Sketches on the Arduino IDE now compile for the SAMD51 without errors, but with warnings.

The warnings stem from the fact that Atmel rather than using the simple "ul" (unsigned long) suffix, as in their previous CMSIS register definitions, for example the SAMD21, they have decided instead to use _U(x), _L(x) and _UL(x) macros.

The macros themselves just use the ## preprocessor directive to move the parameter 'x' to the front and "UL" to the back:

_UL(x) x ## UL

However, the use of _U and _L naming is unfortunate, as these have already been defined in the ARM GCC Toolchain file "ctype.h", leading to a double definition that's causing the compiler warnings.

It appears that others are having the same issue:

...there is one more issue with the new header files we've just found. Chip header files like same70q21.h define _U, _L, _UL macros in the following manner

#if !defined(_UL)
#define _U(x) x ## U
#define _L(x) x ## L
#define _UL(x) x ## UL
#endif /* !defined(UL) */

However, some toolchains define _U but not _UL. That leads to a double definition of _U, _L macros.

It begs the question, why is Atmel using macro names that conflict with their own microcontoller's C++ code?

I'm trying to figure out if there's a simple workaround?

@westfw, According to Atmel the biggest difference is that the E series has the Ethernet and CAN controllers while the D series does not.

I amended the _U and _L macro names in the SAMD51 Atmel CMSIS file to _UI (unsigned int) and _SL (signed long) respectively.

A blank sketch (empty setup() and loop()) now compiles without warnings or errors.

The SAMD51D20A chips I ordered have arrived.

Adafruit have now added support for the SAMD51's hardware FPU.

Thanks for the update... I wonder if that's a sign they are going to be releasing their boards soon.

Finally managed to get the SAMD51J20A working with the Arduino IDE.

It'll certainly be interesting to see how this 120MHz, ARM-Cortex M4F microcontroller performs.

This is all thanks to the engineering effort by Adafruit, building upon the considerable work carried out by Arduino for the SAMD21 and in many ways shows the benefits, (at least in this instance), of open source development.

Getting it going at this early stage of development was quite involved though, I need to:

  1. Zip up Adafruit's SAMD51 code and write a JSON file, to create a new entry in the Arduino IDE boards manager, so that the new board and code could be installed.

  2. Copy the modified "sam.h" and "samd.h", as well as add the "samd51" directory from Adafruit's Atmel CMSIS Github repository, to the Arduino IDE's Atmel CMSIS directory.

  3. Copy Adafruit's modified bossac executable found their SAMD51 code's "Tools" directory, to replace the Arduino IDE's "bossac.exe" file in its "1.7.0" directory.

  4. Upload the bootloader to the SAMD51 board using an Atmel ICE programmer and Atmel Studio (Tools->Device Programming->Memories), then selecting the path to the "samdx1_sam_ba.bin" bootloader file.

As the code is still under development, I'd suggest that it's probably easiest to wait until Adafruit's Metro M4 board becomes available and there's full support for the Arduino IDE.

In terms of hardware, I simply soldered the 64-pin, SAMD51J20A in a TQFP package to my custom board designed for the SAMD21J18A. The main difference is that SAMD51's VDDCORE pin is located two pins down with respect to the SAMD21 and that it's now recommended to connect a 4.7uF capacitor from this pin to ground, rather than the 1uF that was there for the SAMD21. This just required a slight modification replacing the capacitor and re-routing it to the new VDDCORE pin.

I'm now rewriting the "variant.cpp" files to recofigure the pin functions, as my custom board more closely matches the Arduino Zero, rather than the Metro M4.

Thanks for the update... I wonder if that's a sign they are going to be releasing their boards soon.

Adafruit are currently saying that the Metro M4 is scheduled for November. Hmm..., perhaps one to add to my Santa's wish list?