This will be the final piece.

Essentially the same as: vkottler/yambs#65.

This helps prepare for yambs integration.

See: vkottler/workspace#29.

It's not necessary to publish documentation until finishing at least #1.

TODO: add example.

This helps validate HAL code generated from SVD.

https://arm-software.github.io/CMSIS_5/SVD/html/elem_registers.html

Tough to implement, arrays with a "stride" can't be regular struct fields (and also complicate struct sizing).

The silver lining here is that this wouldn't require any data structure changes. It would require adding an additional size_t index argument (that gets handled correctly in the bit math).

Probably makes sense to implement this after #23.

With something like this, we could go from SVD directly to HAL layer.

Can be added at any time, but will be needed for #24.

this is a bit obnoxious

It would be nice to generate some sample unit-test code as well.

If we're generating that kind of code, similar to yambs CI, we should build and run it on the Linux platform.

Shouldn't have to manually clean up defunct things.

Otherwise we need to add an explicit include path (which is probably not the end of the world..)

https://en.cppreference.com/w/cpp/header/stdfloat

is this any stronger of a guarantee that float32_t is 32-bits and float64_t is 64-bits? compared to just float and double

Currently we end up generating redundant peripherals:

I suspect this means we are generating redundant enums as well.

This comment example shows essentially what we're going for: https://stackoverflow.com/questions/1559254/are-there-binary-memory-streams-in-c

When using the >> / << read from some stream interface (???) the exact number of bytes in the struct, encode/decode, return.

Re-implement to use something like this:

Because we have a static const structure, we need to put this in a source file.

these methods don't need to be here

should be simple

Should leave behind some configuration option / feature flag when this is done.

Note: we should also make the JSON output for enums configurable the same way.

Once the JSON output is configurable we should disable it by default.

Right now we're detecting if methods for the current struct need to be marked volatile: if there is a volatile instance I believe? Or if there's an instance in general

Could we fix this by just spoofing instances?

This is required for: #24.

Use a regular C-style array for these.

Example:

Something to be able to specify the default value, then define it as a constexpr or something?

Shouldn't be too difficult. Example for why we need it:

Has to be done after: #21.

Should be trivial.

Criteria could be something like:

• same group name + same size and then check bit fields? if all of that checks out coalesce?

Maybe we just don't coalesce and deal with some of the duplication. We do end up with a huge amount of code though...

This is useful for when writing has a side-effect.

For completeness we should implement the reading end as well.

Once this is added, re-generate HAL documentation for:

• https://github.com/vkottler/hal-rp2040
• https://github.com/vkottler/hal-xmc4700

With volatile support and bit fields we should be able to implement bit-field generation

can draw inspiration from runtimepy

See this issue: vkottler/yambs#18.

Would it be simpler to just generate C?

Need to add a command-line command, schema data for the configuration input etc.