Missing peripherals in the generated file

[nsabovic]

Using HEAD svd2rust on Atmel's SAMD10's svd file, quite a few peripherals are not generated, and no errors are issued.

I made a repo which contains the svd file.

Running the latest version of svd2rust as of 2/25/18, v0.12.0-8-g65482c2, the following peripherals which are in svd are not generated: pac1, pac2, port_iobus, rtc, sercom0, sercom1, sercom2, tc1, tc2, wdt. The svd passes SVDConv with few warnings, and svd2rust also outputs a few warnings like:

WARNING count_dith4 overlaps with another register at offset 52. Ignoring.

[kevinmehall]

Yes, svd2rust is missing a number of features needed to support the SVD files for the SAM D series. I've been trying to use svd2rust with the SAMD21, and I recently fixed one of the issues in #168.

Remaining missing features that I know of:

• derivedFrom on registers (blocked on Implement derivedFrom on cluster/register/field/enumeratedvalues element svd#21) -- this is the cause of some of the "overlaps with another register" warnings, because the register width defaults to 32bit when a register is derived from another 8 bit register and this attribute is ignored.
• register clusters (support clusters #107) -- the timers, RTC, SERCOM, and USB peripherals have their entire interface within clusters, which are currently ignored.
• overlapping registers ("overloaded" registers #16) -- the rest of the "overlaps with another register" is when there are legitimately two registers at the same address. They use this when the field layout of the register depends on the configuration. Some of them, like the count_dith4 are pretty useless though, as it's just changing the number of valid bits in the count field depending on the dithering setting.

[jamesmunns]

Hey @nsabovic - would you mind trying this with #182? I think it may fix some (but not all) of your issues.

[nsabovic]

@jamesmunns that fixed rtc, sercom0 and tc1, which is great! pac1, pac2, port_iobus, sercom1, sercom2 and tc2 require derivedFrom. I have no clue what's up with wdt. I think it would be nice to get some output when a peripheral is skipped.

[jamesmunns]

@nsabovic Hmm, thats a good point. I've opened #183 to track improvements in logging.

I actually added some while developing #182 to troubleshoot some issues, but pulled them out. It might be a good idea to add them back.

[nsabovic]

Cool—then I'll close this one out.