Description

WIP! WIP! WIP!

This is the missing piece between IC manufacturers that just publish datasheets without SVDs and svd2rust. It uses tabula, an specialised OCR that recognises tables in PDFs.

This can also be used as the ideal companion for reverse engineering tools such as Radare2 or Ghidra SVD loaders.

Also, rust-embeeded's SVD crates might want to check out how SerDe and XML work beautifully in this repo.

Last but not least, it would be awesome to generate a PAC for the Renesas V850, but LLVM does not have such a backend and GCC-Rust is still WIP-ing at this point in time.

But at least we have a SVD for it now, that's a start :)

TODO

• [x]: Finish up the parsing and cleaning of the tabula peripherals IO CSV file.
• [x]: Identify other parts of the datasheet where @'s can be useful for the SVD.
• [x]: Pass minimal validation through cmsis-svd python parser/model.py.
• [x]: Validate more thoroughly via XSD with https://github.com/lumeohq/xsd-parser-rs ? WONTFIX: Current state of the art on this is a bit immature in Rust :/
• [x]: Make sure it loads well on radare2...
• [ ]: ...and Ghidra's SVD-Loader.
• [ ]: Collapse all the peripherals repetition into a single one and several registers inside it.
• [ ]: Cleanup/generalize for other ICs (RL78, Espressif ICs, etc...)
• [ ]: I should have used https://crates.io/crates/xml-schema-derive instead of manual structs, maybe?

$ cargo run -q > v850.svd

Rust XML state of the crates nation

This blogpost from simplabs explains a few of the pain points of XML with Rust in 2021. There's also a matrix of what's supported and what is not on different crates, which gives a more detailed idea on Rust's maturity w.r.t XML (de)serializing.

Default serde structs do not seem to be aware of the desired serialized structure (i.e child vs attrs) so we end up with an incorrect CMSIS-SVD definition:

<?xml version="1.0"?>
<xml version="1.0" encoding="utf-8">
  <device xmlns="http://www.w3.org/2001/XMLSchema-instance" schemaversion="foo" xsnonamespaceschemalocation="CMSIS-SVD.xsd">
    <devattributes vendor="Renesas" vendorid="Renesas" name="V850" series="E1/E2/CA2" version="1.2" description="NEC/Renesas V850 automotive grade ICs" licensetext="GPLv3" addressunitbits="8" width="32" size="32" access="read-write" resetvalue="0x00000000" resetmask="0xFFFFFFFF">
      <cpu name="V850" revision="r1" endian="LE" mpupresent="false" fpupresent="false" vendorsystickconfig="false"/>
      <peripherals name="Specific Registers" version="1.0" description="Specific Registers" groupname="MCU" baseaddress="0xFFFFF1FC" size="16" access="read-write">
        <registers name="PRCMD" description="This command register (PRCMD) is to protect the registers that may have a significant influence on the application system (PSC, PSM) from an inadvertent write access, so that the system does not stop in case of a program hang-up." addressoffset="0xFFFFF1FC" size="8" access="read-write" resetvalue="0x0000" resetmask="0xFFFF"/>
      </peripherals>
    </devattributes>
  </device>
</xml>

The XML above is inconsistent with CMSIS-SVD since most of the information is encoded as attributes when they should be child elements instead, that's why strong-xml, which is heavily typed, is a better fit for this particular XML schema.

Unfortunately it lacks good examples.

YaSerDe on the other hand, it's intuitive and just works. Every member of the struct gets labeled as either attribute or child and it has good docs.

There's also Rust embedded's SVD parser attempting to work with Minicom XML... my very much non-expert opinion is that they should take look at YaSerDe instead.