Niklas Hauser
Niklas Hauser
Just for future reference, here are some machine-readable data sources I found over the time: - [Nuvoton **NuTool Suite**](https://www.nuvoton.com/tool-and-software/software-tool/general/nutool/): - **NuTool PinConfigure**: contains JSON files describing package, pinout and signals....
This is the initial exploration of what a shared API for accessing device file data could look like. The goal is to decouple the device file data from the underlying...
Parses and cross-references the clock tree data and formats it into device files. Currently outputs SVGs for understanding: https://salkinium.com/stm32/clock/index.html
This enhances the `lbuild build` and `lbuild clean` commands to detect modified generated files *before* deletion, via modified timestamp comparison (and content hash as backup) in the buildlog. The commands...
Currently the Readme contains the whole documentation, which is fairly complete, but not super useful to access. Wishlist: - Have a proper website at lbuild.modm.io or readthedocs with overview, install...
There is an issue where generated files that format paths generate different files on Windows (path separator `\`) vs the rest (path separator `/`). This should be solved at lbuild...
Like the `env.outbasepath` prefix, which is something like `repo/src` and duplicated in every module. cc @rleh
Currently `os.path` and `pathlib.Path` are spread all over the place, it would be nice to settle on using `pathlib.Path` for the vast majority of file operations and only use other...
`lbuild diff` builds in memory and displays the differences to what is on disk in the build folder. This makes it easier to compare what has changed when upgrading repositories.
At the moment there is a mix of use of both `os.path` and `pathlib.Path` which is really annoying to cast around interally. The goal is to only use pathlib interally...