# mmiogrok

Collection of Python libraries to parse, generate and convert between several
MMIO register definition files.

#### Parse and generate

* ARM CMSIS-**SVD** (ARM etc.)
* **Device tree** (source/binary, peripheral only, no registers) [*planned*]

#### Parse only

* NEC/Renesas **DVF** (78K, RL78, V830/RH830, RX)
* Lauterbach TRACE32 **PER** (misc) [*work in progress*]
* Atmel/Microchip **ATDF**/ATpack (AVR etc.) [*planned*]
* Texas Instruments **DSLite** (MSP430 etc.) [*planned*]

#### Convert

* DVF → SVD
* PER → SVD [*work in progress*]
* ATDF → SVD [*planned*]
* DSLite → SVD [*planned*]
* SVD → DTS/DTB (peripherals only) [*planned*]
* DTS/DTB → SVD (peripherals only) [*planned*]

## Usage

#### Libraries

* `dvf/dvfparse.py` is able to parse DVF files
* `svd/svd.py`, `svd/svdparse.py`, `svd/svdgen.py` handle SVD files

#### Utilities

* `dvf/dvf2h.py` is a quick DVF-to-headerfile converter
* `dvf2svd.py` converts DVF to SVD files using the above libraries

## Dependencies

Python stdlib only, though I've been using 3.10, it might be the case that some
things aren't in eg. 3.6.

## FAQ etc

#### Why is it Python? Why is the Python code so hacky?

I quickly wanted to get something to work so that I could import MMIO stuff in
Ghidra. Yes the code could be cleaner/faster (especially with a resp. Racket or
Rust rewrite), but I just wanted to Get Things Done.

#### Why is it not a proper Python module?

I started from a script and things evolved from there. I should probably
restructure the codebase a bit, the current method of importing stuff (by
adding things to the Python module path...) is, not a good idea.

#### Why are the converters inaccurate?

For DVF, the main problem lies in the file format: all registers are laid out
without peripheral associations, so no peripheral information (and peripheral ↔
interrupt) mapping is available. Furthermore, the file format is binary, so
figuring out which exact bits correspond to which register properties (eg.
'write-to-clear') is pretty hard. The basics are still there, though. The code
is currently untested for V830 and RX DVF files, which might differ in some
ways.

For TRACE32 PER, a large problem is that these files mix UI elements,
conditionals and loops, and actual peripheral and register definitions, in a
quite shitty to parse text-based format, making things quite complicated. The
conditionals depend on outside knowledge (eg. exact chip names, Xtensa TRAX
register bases, ...) which I don't have, so those are currently left ignored.

## License

Eh, idk yet.