Closed maxgerhardt closed 1 year ago
FWIW The Atmel SVD files generated by https://github.com/Rahix/avr-device do not parse correctly using the SVDConv tool (described here https://www.keil.com/pack/doc/CMSIS/SVD/html/index.html). As an example, I have prepared a test attiny85 svd file and stripped out all but one peripheral definitions such that it eventually produced no errors (but several warnings) when checked with SVDConv. The svd also need to feature an xml typedef header and a
ACK, we've already identified at least one spec violation (https://github.com/Rahix/atdf2svd/issues/25). Just as a bit of background: With https://github.com/Rahix/avr-device the intent was obviously just to get the Rust generation working so not much attention was paid to full SVD spec adherance - we just implemented the minimum subset required for this usecase. That said, I'm happy to improve https://github.com/Rahix/atdf2svd so it is useful here as well.
@Gasman2014, If you're able to run SVDConv, maybe you can open some issues on atdf2svd about further problems with the current output?
Retracted.
Output of the https://github.com/Rahix/avr-device tool (all
*.svd.patched
files renamd to*.svd
).Created as descripted in community post.
The SVD files are not yet referenced in the board JSON files because the parser in VSCode throws an error and in CLion it can parse the file but cannot read out the registers (possible
avr-gdb
issue). Other issues will be opened for this.For testing, you can e.g. modify the
uno.json
file withand then receive the same parsing error as in the linked topic -- CLion gets much further as said, but can't read out the I/O registers..