Yet another "Getting Started With ARM" post...

[ignilux]

Hi, all-

I've been programming bare metal C on 8-bit ATmega, ATtiny, and PIC MCUs for the past 5 years or so, and have become very comfortable with the workflow, i.e. efficient scanning of the datasheet, set a handful of registers for a given peripheral, and write the program. Despite my enduring love for the 8-bit-ers, it's become increasingly apparent that I need to familiarize myself with the ARM Cortex-M family. However, every time I try I find the whole process quite discouraging.

It seems that what makes the architecture great (many manufacturers to choose from, tons of different peripherals available, etc) also makes it easy to get lost. For example, I picked up an NXP LPC54114 dev board a while back. There are diehard endorsements across the web of different software from Keil, IAR, Eclipse, stfu use emacs, etc. Well, NXP wants you to install their IDE, and their SDK. Fine, I'll do that. The SDK has a fairly hefty API, with functions that do a lot of register setting, peripheral configuration, etc. It also includes a number of CMSIS libraries, which initially looked like a great concept but it soon becomes clear that it isn't nearly as portable as it should be. The board itself includes a "Link 2" debug probe, but many will tell you to pick up a Black Magic Probe or J-Link EDU.

So now we have multiple compilers, multiple C library implementations,  many IDEs, three overlapping ways to write the code (SDK, CMSIS, register manipulation), and three ways to debug and program. I love having options, but I'm so used to having a cut-and-dry toolset that I'm rather overwhelmed. The worst part is that everywhere you look for help, all you find is tutorials about the SDK, mbed, FreeRTOS, proprietary vendor tools, etc. That, or a generic tutorial that gets WAY too entrenched in the ISA without anything practical. Contrast that with the 8-bit micros, where almost all of the information out there pertains to bitwise operations on registers in C.

Enough complaining. My question is this:
Is there any toolchain that will provide a workflow similar to that in MPLAB or Atmel Studio 7? I don't want 10k of program memory eaten up by vendor bloatware, but on the other hand I quite enjoy some level of abstraction in terms of SFR macros, etc. After all, I'd just use assembly if I was anti-abstraction. I'm not looking for an "Arduino solution", but I don't want to have to write my own reset vector with inline assembly. I hope this makes sense, and thanks for your time.

[ataradov]

You never have to write in assembly with ARM (Cortex-M specifically). Even reset handler is written in C and is typically just a few trivial lines of code.

If you just want the basic stuff out of the box, then use GCC and header files and startup code from the CMSIS package for the device. This is vendor and device independent part.

If you want peripheral libraries, then you would have to use vendor libraries, so it depends on the MCU you select.

All other tolls (programmer) are doing the same stuff, so it does not really matter what you pick as long as there is software for it for your OS.

[ignilux]

Thanks for your reply. Would the vendor libraries come from the SDK? I'm thinking of using either Eclipse or VS Code as an IDE, since they are both readily adaptable to other parts, families, languages, etc.

[ataradov]

That depends on the vendor. Some have just a straightforward download of a ZIP file, others have dedicated configuration tools that you can't avoid if you want to use their code.

[ignilux]

That seems to be the case. Looks like NXP has the former. Good thing, since one primary motivation here is avoiding proprietary tools and processes, such that I don't have to relearn another quirky IDE and debugger every time I move to a new ARM vendor.

[Doctorandus_P]

I am in the same boat as you.
I started using the AVR controllers about 10 years from before "arduino" existed and never understood why anyone would put up with such a piece of *&^%$#@! Especially the Java garbage they call an "ide".

Then I was looking for an "upgrade". Those 320x240 pixel TFT's from China are fun, but the AVR's do not have enough upmph to drive them comfortably. With the cheap ARM controllers (about same price as AVR) you get so much more for free:

* Much more MHz. (Thumb instructions seem to give Cortex-M about the same performance/MHz as AVR's. 32bit is not 4x faster then 8 bit, but 72MHz sure is a lot faster)
* Multiple ISR levels.
* Fractional baudrate generators.
* Motor timers for generating 3-phase PWM.
* Quadrature counters in hardware for the timers.
* More RAM / Flash.

I'm also a sort of cheapskate and I bought a bunch of "Blue Pills" and separate STM32F103C8T6 chips for even less money. ( I think about EUR1.2 each). With this combination I have both chips to put on self designed PCB's and simple development boards for quick prototypes, breadboards and one-off projects.
This chip is one of the oldest and apparently has some hardware bugs which makes me apprehensive to really dive into it's internals.

"Black Magic Probe" apparently also works with this chip, but I just bought a few "ST-Link V2" programmers for about EUR3 each. For those kind of prices I really do not care if I have to buy a separate programmer for each uC family. STM32 also has some other advantages. For example the DPS5005 power supplies use an STM32F100 (and "openDPS" is available as example software), so that is a good start for custom power supply firmware. For about EUR 20 you can also buy cheap PLC's form China (Search for FX2N). These boards have a pretty decent power supply (common mode filter, big elco's SMPS) and robust I/O (Optocouplers, Relay or Transistor outputs) These can be repurposed as excellent development boards for the STM32 family. You can also get TFT Lcd's with an STM32 on the back of them, so again, just put custom firmware in existing hardware.

The "Blue Pill" boards are also popular for hobbyists. Long before "arduino" i've written my own libraries for HD44780 I2C, UART, etc, and this takes a lot of time. I do not have much love for the whole "arduino" framework. It was never designed to be "useful" in complex applications. It also was not even intended as an educational tool. There is quite some usable code in the arduino framework itself though. Therefore it does seem a reasonable path to fork the arduino thing, remove all auto instantiated objects and the horrible "digitalWrite()". Then you can just link in the libraries you actually need. Also, by reading through code written by others (especially if it's well written) you learn some tricks you had not thought of yourself. I think that extracting useful libraries from "stm32duino" (stm32 fork for arduino) is less work than writing libraries from scratch. Same may be true for mbed. Mbed seems to want to fill up the whole uC with libraries and not leave any code for applications. Such fameworks are also written with not much thought in code efficiency. They are just stacked on top of lower level libraries such as CMSIS. It looks like a horrible mes to try to understand it all.

Because the "Blue Pill" is popular it's easy to find example projects for it. I currently have a CNC machine which runs on a STM32 port of GRBL. I've also tested an USB to 3 UART bridge with an example project from github for the STM32. My linux box sees all 3 ports, and loop back works if I put a wire between Tx of one port and connect it to Rx of the same or another port.

I very much enjoyed the STM32 tutorials from "PandaFruits"
http://pandafruits.com/stm32_primer/stm32_primer_hardware.php
It handles the very bare bones low level stuff to get going with C, such as writing your own linker scripts. It's a very concise and well written tutorial. It's just a few short pages with loads of info. If you're interested in low-level stuff and don't know much about it (yet) then it is worth reading it even if your main interest is in the LPC uC's.

Then there are also some other frameworks.
LibOpenCM3 may be interesting, but I have not looked into it yet.

Then there are also some projects that use C++ Templates. This stuff is a bit over my head unfortunately. It seems wonderful if you can use well written libraries based on templates, but they have a bad name for debugability. Some projects based on C++ Templates are:
* Kvasir
* bmptk
* XPCC

Here a video from the young Davey Jones:


Some other links I found worth saving:
http://www.stm32duino.com/viewtopic.php?f=42&t=4460&p=51937#p51937
https://jeelabs.org/projects/jeeh/
https://jeelabs.org/2018/getting-started-bp/

[uer166]

You never have to write in assembly with ARM (Cortex-M specifically). Even reset handler is written in C and is typically just a few trivial lines of code.

See, I keep reading this here, and yet in my experience (ST in this case), everything is still crt0 or whatever it's called. I did have to edit the reset handler assembly to copy some code to TCM.

[ataradov]

See, I keep reading this here, and yet in my experience (ST in this case), everything is still crt0 or whatever it's called. I did have to edit the reset handler assembly to copy some code to TCM.

Well, they are free to do so, but you don't have to. Never and for anything.

IAR and Keil also have their startup code in assembly. This is some legacy stuff and their insecurities. Nothing more.

All Atmel/Microchip code is in pure C and works fine, including with TCM.

[uer166]

Sure, but that statement is misleading at best. If one use Keil or IAR or STM32Cube, the startup code is all assembly. Of course you don't have to use it, but nobody will write their own reset handlers from scratch, especially not new people.

Your statement may be true specifically for Atmel/Microchip, bit that's a cherry-pick IMO.

[ataradov]

The statement was about the core. ARM spent a lot of effort to make sure their core is fully programmable with C.

If you are using someone's code, you are bound to deal with BS like that.

There is nothing hard about startup code, even new people can figure it out if they look at actually good examples.

The goal of frameworks writers is to lock you into their ecosystem, so the less portable the code is, the better it is for them. You need to recognize that pattern and avoid it when possible.

[Doctorandus_P]

The goal of frameworks writers is to lock you into their ecosystem, so the less portable the code is, the better it is for them. You need to recognize that pattern and avoid it when possible.

I've also bumped into this with ARM, and found it quite annoying.
I know I'm just a hobby programmer.
The first uC program I wrote in C was for the AT90S2313 somewhere in the late '90s or early 2000. Back then it was not very common to have a C compiler and lot's of people were still assembly only. Back then with GCC in the AVR you just started with int main( void){ }. There was no need to fiddle with startup code or linker scripts. It took me years to even realize these existed.

With those companies that try to force you into some IDE they indeed try to hide any decent info. You even have to search for the compiler they use, although gcc-arm-none-eabi has a big chance. Instead of just #defines for register names for the STM32 you get several different base adresses and offsets just to make stuff more complicated.

With my (limited) level of knowledge it's hard to judge and verify if the linker scripts and startup code that I found for my particular processor works the GCC compiler version I have installed.

With AVR-GCC you just tell the compiler for which variant of the AVR family you want to compile and it handles all the details for startup code and Linker scripts.

Do any of the vendors of ARM chips do something similar?
Or are they all trying to lure you into their underground dungeons with their mystery   wizards and "enhanced" ide's?

[ataradov]

Well, the linker scripts are necessary even in AVR world if you are doing bootloaders, or things more complicated than just simple code. You can avoid then for a long time, but sooner or later you will have to deal with them.

It is a really BAD idea to have the compiler know about your chip. The compiler only needs to know the architecture of the core. It does not need to know about the peripherals. One reason - your version of the registers would tied to the compiler. For AVR it was not a huge problem, since the number of registers was very limited and all the errors were more or less debugged. There are plenty of errors in ARM header files.

Linker scripts are not hard, and you will do yourself a great favor by spending a day and figuring them out. Again, don't look at universal swiss-army-knife scripts. Look at minimal reasonable versions. My typical standard linker script is ~50 lines and it covers almost all use cases I have. And once you write it, you just move it from project to project, from device to device.

[ignilux]

The goal of frameworks writers is to lock you into their ecosystem, so the less portable the code is, the better it is for them. You need to recognize that pattern and avoid it when possible.

Exactly what I'm trying to avoid, and why I'm interested in using a vanilla Eclipse / GCC / OpenOCD (maybe J-Link in the future) toolchain. Continuing with the reset handling example, it's not that I don't understand what's happening or that I can't figure it out. Instead, it just feels a little unnecessarily laborious to have to tell a microcontroller to turn it's clock on.

I very much enjoyed the STM32 tutorials from "PandaFruits"

I'll check that out, thanks. I won't be using STM32 since I'm allergic to shit datasheets, but good info nonetheless 

Then there are also some projects that use C++ Templates

Be careful when using the STL or other dynamic allocation in an embedded context.

Linker scripts are not hard, and you will do yourself a great favor by spending a day and figuring them out.

Any examples of good, concise scripts?

[ataradov]

Any examples of good, concise scripts?

Here is my typical script https://github.com/ataradov/mcu-starter-projects/tree/master/samd21/linker

And the whole project is an example of a simple, but complete ARM project.

In the startup code (https://github.com/ataradov/mcu-starter-projects/blob/master/samd21/startup_samd21.c) reset handler is only 10 lines of C code. Not sure why anyone would want to touch assembly at that point.

[westfw]

It also includes a number of CMSIS libraries, which initially looked like a great concept but it soon becomes clear that it isn't nearly as portable as it should be.

CMSIS is (or used to be - they keep changing things) divided into several parts:CMSIS-CORE defines common function definitions and stuff for dealing with the ARM parts of chips - SysTick. NVIC, Core registers, etc.  This prevents different vendors from having different names for the same thing (cli(), disable_interrupts(), etc.)  It should be very portable, and is IMO a good thing.Another part (CMSIS-SVD?) is (more or less) defining a standard style for peripheral definitions.  Arrays of Structures mapped onto memory addresses and a somewhat standardized naming scheme.  Also a reasonable thing, although vendors seem to have found many ways to bend things (Atmel's ".reg" and ".bits" on every field, for instance, is something I haven't seen elsewhere.)  Also reasonable and portable (alas, manufacturers don't seem to be overly consistent across different FAMILIES of chip, so that's annoying (SAM3 "Pio" vs SAMD "PortGroup", for instance.)CMSIS-DAP is standardized access to debugger.  Good, but not necessarily optimal?CMSIS-DSP is standardized access to DSP capabilities of (for example) the CM4...Where you get into problems is with things like CMSIS-DRIVER and CMSIS-RTOS, where ARM starts pushing particular models of peripherals and operating system primitives that don't (IMO) match very well with vendor capabilities or many people's idea of how things should work.  (the USART driver standard doesn't include a "getc()", for example.  Sized buffer and calllback; eww...)  I think most vendors have ignored the CMSIS-DRIVER spec in favor of their own peripheral libraries.

So now we have multiple compilers, multiple C library implementations,  many IDEs, three overlapping ways to write the code (SDK, CMSIS, register manipulation), and three ways to debug and program.

To be fair, the only reason that you didn't notice similar problems with AVR and PIC was that you settled on both chips and IDE that you liked and stuck with them.  (that, and the datasheets were a lot shorter.)  You didn't go through the multiple C compilers for either one, each with (generally) their own IDEs (or not.)  Studio4, Studio7, MPLAB, MPLABX, IAR, Imagecraft, Mikro, CCS, HiTech, SDCC, Arduino ...  Or the Xmega/Mega0/Tiny0/Tiny1 dramatic departures from traditional AVRs, or ASF versions changes, or ...

With the previous AVR/PIC experience, why did you switch vendors?  In theory, you could keep using MPLABX or Studio...

[techman-001]

<snip>
 Another part (CMSIS-SVD?) is (more or less) defining a standard style for peripheral definitions.  Arrays of Structures mapped onto memory addresses and a somewhat standardized naming scheme.  Also a reasonable thing, although vendors seem to have found many ways to bend things (Atmel's ".reg" and ".bits" on every field, for instance, is something I haven't seen elsewhere.)
<snip>

The Cortex Microcontroller Software Interface Standard - System View Description format gets mentioned a lot here but in my observation most people don't really know what it is.

What CMSIS-SVD is:
- CMSIS-SVD files are developed and maintained by silicon vendors, not ARM.
- Formalizes the description of the system contained in Arm Cortex-M processor-based microcontrollers, in particular, the memory mapped registers of peripherals.
- The detail contained in system view descriptions is comparable to the data in device reference manuals.
- The information ranges from high level functional descriptions of a peripheral all the way down to the definition and purpose of an individual bit field in a memory mapped register.
- Simply a XML file waiting to be processed by XSLT to provide any transform you care to design.

What CMSIS-SVD isn't:
- Arrays of Structures mapped onto memory addresses. The C compile vendors do that when they transform the CMSIS-SVD XML file to a include file to suit their needs.

CMSIS-SVD allows any programming language to obtain customized memory mappings via XSLT.
- I use it to transform FORTH memory mapped registers and bitfields
- RUST people use it for the same purpose but customized to suit them. They have even written tools to convert Texas Instruments device specs to CMSIS-SVD. 
- LUA people would use it
-eLISP folks would also use it

To my technicians mind, CMSIS-SVD is another level above limited proprietary vendor created tools as used by Microchip and Atmel etc.

With CMSIS-SVD I can generate the exact stats for a microprocessor :-

Code: [Select]

MCU Peripherals Registers Register Bitfields
MSP430G2553 17 113 503
STM32F0xx 37 413 3044
STM32F303x 38 549 3857
STM32F103xx 53 722 4833
GD32F103 ? ? ? ( I need a svd )
STM32F103C8 33 466 3503
GD32VF103Cx 46 1074 7713
TM4C129x 65 2137 7347
STM32F7x7 93 2093 17051

[ignilux]

And the whole project is an example of a simple, but complete ARM project.

A quick scan through that repo clarifies quite a few things about the different files and how they relate, so thanks for that. I've been seeing extensive use of __attribute__ all over the place, so looks like I have some reading to do with respect to GCC.

CMSIS-CORE defines common function definitions... and is IMO a good thing.

I agree, that does look to be a useful and necessary function. Browsing through the CMSIS API reference makes it look like CORE is one of the most mature and complete parts of CMSIS, which makes sense. I'll be digging in to CMSIS-DSP at some point. That was one of my primary motivations for switching to ARM.

With respect to your comments about the Atmel / Microchip tools, those are certainly fair points. The dramatic departure from traditional AVR that you mentioned all started to happen around the time that Microchip acquired Atmel (though I'm aware that many of those changes were pre-merger), and is a big reason that I've moved away from Microchip. Atmel made great AVR chips, and Microchip makes great PICs. The forced combination of the two that resulted in things like AVR registers that we all knew and loved suddenly having ".bits" stuck on the end. Very little documentation for that too, since Microchip just assumes everyone knows how PIC does this.

When I was first picking out an ARM development board, I had no idea which vendor to choose. I settled on NXP by reading a handful of datasheets from different manufacturers. If there were glaring omissions (e.g. SiLabs likes to NOT tell you the value of the S/H capacitance in its ADCs), I moved on. NXP seemed to have complete, coherent documentation, so I picked them.

To my technicians mind, CMSIS-SVD is another level above limited proprietary vendor created tools

That actually sounds really useful! So are you at the mercy of the vendors for the availability and quality of the SVD files? I'm somewhat familiar with XSLT for things like transforming XML to HTML, but I had never heard it being used in this manner.

[ataradov]

I've been seeing extensive use of __attribute__ all over the place, so looks like I have some reading to do with respect to GCC.

There are two places where it is used:
1. __attribute__ ((used, section(".vectors"))). This is used to place "vectors" array into its own section and also mark it as "used", so that optimizing compiler does not remove it.

This is necessary so that liker could place this variable first in the memory, since that is the only hard requirement for placing anything. In the liker script this is done in this part:

Code: [Select]

  .text : ALIGN(4)
  {
    FILL(0xff)
    KEEP(*(.vectors))
    *(.text*)
    *(.rodata)
    *(.rodata.*)

2. #define DUMMY __attribute__ ((weak, alias ("irq_handler_dummy")))

This is not 100% necessary. It is just a nice thing to have. This way any interrupt handler that is not explicitly defined will be aliased to irq_handler_dummy. You can just define all of them to be the same function and avoid using this attribute. Although all modern compiler support weak functions, but the exact syntax may differ.

So are you at the mercy of the vendors for the availability and quality of the SVD files?

Yes, but given that literally every tool uses them now, it would be impossible for vendors to not publish reasonable SVD files. If they don't, they essentially exclude themselves from being used in IAR and Keil ecosystems at least. And that's a significant part of the market, so no one in their right mind would do that.

[techman-001]

To my technicians mind, CMSIS-SVD is another level above limited proprietary vendor created tools

That actually sounds really useful! So are you at the mercy of the vendors for the availability and quality of the SVD files? I'm somewhat familiar with XSLT for things like transforming XML to HTML, but I had never heard it being used in this manner.

You are at the mercy of the vendors for everything as usual, but that hasn't been a problem so far. CMSIS-SVD is a game changer. Even ATMEL use it for their Cortex-M MCU's.

For instance Texas Instruments don't use SVD's as they have their own system, but the Rust people convert the Ti format to CMSIS-SVD which only required a few small changes in my XSLT stylefile to transform them into the format I use with Forth. This enables me to generate everything I need for the MSP430 and the

This is Forth centric but shows what I do with SVD's.
https://mecrisp-stellaris-folkdoc.sourceforge.io/register-generator.html#svd2forth

I'm a keen STMicro user and a SVD for all of their MCU's are freely available from Keil as a 'pack' plus there are projects on Github containing lists of SVD's. Keil seem to have SVD's for every manufafturer of Cortex-M silicon available for free on their site.

I have generated transforms for NXP processors with the SVD's they make, so no problems there either.

[wilfred]

I recommend this Youtube channel which has a good quality presentation of ARM on the Texas Instrument Stellaris (later renamed TIVA C) launchpad devboards.

https://www.youtube.com/channel/UCMGXFEew8I6gzjg3tWen4Gw

The resource is free and launchpads are pretty cheap. As an educational introduction to the concepts it is something I found accessible and helpful.

You can move to another device later if necessary and the skills learned will help in that.

The first few videos don't need a devboard and checking those out will give a good guide to what is on offer for free.

If someone knows of something similar then please post.

[ataradov]

Even ATMEL use it for their Cortex-M MCU's.

Atmel was among the first companies to embrace lower levels of CMSIS standard. SVD files were supplied for all Cortex-M devices.

Atmel is the only company that shipped CMSIS-DAP compliant debuggers on the board.

[T3sl4co1l]

Then I was looking for an "upgrade". Those 320x240 pixel TFT's from China are fun, but the AVR's do not have enough upmph to drive them comfortably. With the cheap ARM controllers (about same price as AVR) you get so much more for free:

That's marginal at best yeah, especially if it's SPI.  (And if it's parallel, you have to bit-bang everything, which uses up a ton of GPIOs and doesn't usually optimize well by the compiler.)

* Much more MHz. (Thumb instructions seem to give Cortex-M about the same performance/MHz as AVR's. 32bit is not 4x faster then 8 bit, but 72MHz sure is a lot faster)
* Multiple ISR levels.
* Fractional baudrate generators.
* Motor timers for generating 3-phase PWM.
* Quadrature counters in hardware for the timers.
* More RAM / Flash.

FYI, the XMEGA (and probably some of the newer MEGAs?) does all of these things, save for clock, which is only a modest 32MHz; or maybe some are a bit faster now.

The performance per buck is pretty pitiful compared to ARMs, though.

There's a top-of-the-line XMEGA with a parallel memory bus interface, actually, which would do very well for memory mapped LCDs, extra SRAM (or DRAM or SDRAM) and other things, but it's also like $10 and... just, get the STM32F103, y'know, or something STM32F4 for industrial interfaces plus enough CPU to run Quake?


I'm.....eventually, going to move to STM32 something or other as a primary platform.  I've been happily using Code::Blocks with avr-gcc, which wasn't much trouble to get working, and is a fuckoff huge sight more compact than anyone's "studio" bullshit...  I expect, or hope, that that will be as simple as loading up whatever flavor of arm-gcc, and learning the libraries and interfaces.  It'll be annoying, confusing bullshit, it always is when learning a new toolchain; but eventually I'll do it.  Afraid I don't have any actual experience to help with yet.

Tim

[Dubbie]

ataradov, thanks very much for posting your example here.
So much people talk a lot about what they do and why it is the only/best way. But you can't beat actually reading some code.
It's nice to see how other people do things.

[westfw]

    What CMSIS-SVD isn't:
    - Arrays of Structures mapped onto memory addresses.

Ah... It looks like this has moved into CMSIS-Core:
https://arm-software.github.io/CMSIS_5/Core/html/device_h_pg.html
https://www.keil.com/pack/doc/cmsis/Core/html/group__peripheral__gr.html
It used to have its own section (CMSIS-DPAL, according to the old tutorials I've dug up.)

Atmel was among the first companies to embrace lower levels of CMSIS standard. SVD files were supplied for all Cortex-M devices.

Atmel actually has something very similar for their AVRs, in the form of their ".ATDF" files.

With respect to your comments about the Atmel / Microchip tools, those are certainly fair points. The dramatic departure from traditional AVR that you mentioned all started to happen around the time that Microchip acquired Atmel

Nah.  It started with the XMega chips ~2010; the acquisition wasn't until 2016.  (I don't see the .bits stuff, but that's when they started with structure-based peripheral registers.)

The forced combination of the two that resulted in things like AVR registers that we all knew and loved suddenly having ".bits" stuck on the end.

It seems to be going the other way.  The SAM "packs" for MPLABX (version 3.x, while the ones with Studio are 2.X) get rid of the .bits and .reg stuff.I don't see any instances of ".bits / .reg" in the PIC packs.I'm not sure whether to be happy that Microchip seems to be heading toward "commonality" of PIC/ARM, or appalled at the magnitude of the changes.  (you can always get the older PACK versions, at least theoretically.)

[ataradov]

Ah... It looks like this has moved into CMSIS-Core:

Was not this always the case? SVD is just the XML part. Resulting headers files were always different.

Atmel actually has something very similar for their AVRs, in the form of their ".ATDF" files.

There are ATDF files for ARM devices too. They are actually used by many (all?) Atmel tools as a primary source of information. Both are automatically generated from primary sources, so contain exactly the same information. ATDF contains a bit more, like information on memory partitioning, which SVD does not define.

I'm not sure whether to be happy that Microchip seems to be heading toward "commonality" of PIC/ARM, or appalled at the magnitude of the changes.  (you can always get the older PACK versions, at least theoretically.)

I definitely don't like it, but I'm not too worried. I can always generate my header files from the SVD files