Add support for Atmels .atdf description files

[kunerd]

This ticket is intended for discussing on how to add support for Atmels .atdf files to svd2rust.

At first we should collect the work that already has been done by different people.

• ATDF Parser by @ecstatic-morse
• Fork of svd2rust with ATDF support added by @ecstatic-morse
• Proof of concept: atdf to svd

@dylanmckay: You have stated that you also have some .atdf parser implementation. Please add your link here.

@ecstatic-morse: Your current lib doesn't have a license, would you mind to add one?

[ecstatic-morse]

Hi, I'm the author of ecstatic-morse/atdf.

Unbeknownst to me, @dylanmckay already implemented a parser for .atdf files at dylanmckay/avr-mcu. A quick google search before writing my own library did not turn up anything, or I would have simply adapted the existing Dylan's. My implementation has not been thoroughly tested, and is based on serde-xml-rs, which means it's more brittle than the hand-written parser in dylanmckay/avr-mcu parser for certain edge cases like register-group unions. The only original work contained in my ecstatic-morse/atdf is the conversion to the data structures in japaric/svd which is currently the schema that svd2rust uses for code generation. These types don't define public constructors, so a bit of ptr::write based mischief was needed :smile:.

My opinion is that the easiest way to add support for architectures which don't provide conforming .svd files is to break the dependency of svd2rust on the data structures in svd.

Instead, svd2rust would define its own Register, Peripheral, etc. These types would be publicly constructible, allowing them to be converted from various hardware description formats. We would then split out the command line interface from svd2rust to a new crate (e.g. svd2rust-cli), which would delegate to various device description parsers, convert the resulting schemas to the one used by svd2rust, and generate code.

This solution may be over-architected considering the only device description formats that I'm aware of are .atdf and .svd. However, I have free time to make these changes if it is decided that this is the right direction to go.

On a personal note, I really appreciate all the work @japaric and @dylanmckay have done to advance the state of embedded programming in rust, and would like to contribute in some small way if possible.

[rubberduck203]

I've spent a couple of days working on transforming atdf files into svd files. Things were going well until I got to the differences in how register address locations are specified. If I understand correctly, SVD specifies a peripheral at a base address, then offsets the registers based on the peripheral location. ATDF makes no differentiation between the peripheral's address and the registers it contains. Everything is specified as an absolute address.

IMO this makes translating between the two file formats error prone at best. I think I'm in agreement with @ecstatic-morse here. In order to see atdf support, svd2rust would need to be split into a front and backend.

All in all however, it may be better for the avr community to develop it's own equivalent of svd2rust. svd is really designed and oriented around ARM processors. Here's an example of some of the weirdness that happens when attempting to convert atdf to svd.

  <cpu>
    <!-- name is restricted to a list of ARM chips and "other" -->
    <name>other</name>
    <!-- revision is limited to r[0-9]*p[0-9]* ATDF doesn't have this, but it's required by svd -->
    <revision>r0p0</revision>
    <endian><xsl:value-of select="address-spaces/address-space[1]/@endianness"/></endian>
    <mpuPresent>false</mpuPresent>
    <fpuPresent>false</fpuPresent>
    <nvicPrioBits>8</nvicPrioBits>
    <vendorSystickConfig>false</vendorSystickConfig> <!-- no avr is going to have this -->
    <deviceNumInterrupts><xsl:value-of select="count(interrupts/interrupt)"/></deviceNumInterrupts>
  </cpu>

[kjetilkjeka]

I've felt a lot of the pains with generating code directly from .svd and is currently working on something you could call an intermediate representation for compiling svd/atdf to rust code.

I've called the format Register Access Code for Rust RACR and will hopefully be ready to announce something in not too many weeks.

[rubberduck203]

@kjetilkjeka that looks interesting. Would you mind pinging me when you announce?

[burrbull]

Closing in favor of external utils like https://github.com/Rahix/atdf2svd