Mention s32k144 crate (generated with svd2rust)

[kjetilkjeka]

Mentioned s32k144 crate

[therealprof]

Would be great to have some using create, too. Otherwise we might end up will a flood of unused automatically generated register definition crates.

[kjetilkjeka]

I'm planning to make embedded-hal for this crate and for s32k144 to be the first MCU supported by uavcan.rs. I'm not sure when, so feel free to hold on merging untill something more is produced.

[Disasm]

Any progress on this?

[Disasm]

Ping from triage: at the moment both bsp and quickstart crates exist, but bsp crate is not embedded-hal-compatible. @therealprof can we merge this?

[therealprof]

@Disasm I'd be fine with adding this if the quickstart crate is at least prominently mentioned in the description of the bsp. Otherwise an interested party might look at the BSP link and think "Now what?".

@kjetilkjeka Would that be an option for you?

[kjetilkjeka]

Sorry for taking some time to respond. Have moved twice in a month for my new job.

Any progress on this?

I'm currently using several different evaulation board in the S32K series. This really shed a lot of light on how inflexible the generate code for one particular MCU is. I'm currently working on a method of defining peripherals that can allows reusing drivers between several MCUs using the same peripheral.

This is actually very close to working as a POC. If it seems promising, I will write more code for the whole S32K series including embedded HALs using this as a base. Until active development is unblocked I will mostly reply to issues and merge code.

@Disasm I'd be fine with adding this if the quickstart crate is at least prominently mentioned in the description of the bsp. Otherwise an interested party might look at the BSP link and think "Now what?".

The quickstart crate is mentioned in the readme. I'm adding the readme to Cargo.toml now, meaning it will be rendered on crates.io after next version is published.

@kjetilkjeka Would that be an option for you?

If this crate, with the mentioned status, is something you would like to have on the list, I'm happy with it.

[therealprof]

@kjetilkjeka

Not sure you've seen it already but for a few vendors we made a move to unified hal-impls, like https://github.com/nrf-rs/nrf52-hal and pretty much all families of STM32 in https://github.com/stm32-rs .

The quickstart crate is mentioned in the readme. I'm adding the readme to Cargo.toml now, meaning it will be rendered on crates.io after next version is published.

Great. Thanks.

[kjetilkjeka]

Not sure you've seen it already but for a few vendors we made a move to unified hal-impls, like https://github.com/nrf-rs/nrf52-hal and pretty much all families of STM32 in https://github.com/stm32-rs .

Thanks for pointing this out, it seems like a clean and pragmatic way to do deal with the modularity issues of .svd files. It's good to know that there is a decent way to achieve this if my "research project" should fail.

Perhaps a bit off topic but what I'm currently attempting is to generate modular register description based on aggregation of .svd files and similar formats like the one atmel uses. I'm attempting to make it useful for doing things like equivalence analysis of registers, enabling automatic recognition of reuse of peripherals between MCU families. I think it will be both useful as an intermediate representation for svd to code generation, and as a stand-alone format to describe embedded hardware as the format is way more human editable than SVD.

[therealprof]

@kjetilkjeka That sounds very similar to the approach of stm32-rs. There YAML is used to patch up the SVD files in order to equalise them and add missing bits.

[kjetilkjeka]

@kjetilkjeka That sounds very similar to the approach of stm32-rs. There YAML is used to patch up the SVD files in order to equalise them and add missing bits.

You're right, this solves a lot of the same problems. Thanks for sharing this approach.

I think by solving these problems on a lower level, maintaining the register definitions becomes easier. I also think due to the decreased repetition and amount of code, it becomes much simpler for humans to inspect and reason about. A different advantage is that identical codegen backends can be used for both .svd and the atmel format, and that different codegen backends can be used for the same processed format suitable for generating code.

I hope (and believe) the effort of introducing this format is worth it, compared to the yaml patch method and other simpler methods. I'm currently working on a compiler from this new format to identical rust code that svd2rust produces, as using it as a drop in replacement for svd2rust will make comparison easy.

[berkus]

SVD IR yay, that sounds fun! Keep it up!

[jamesmunns]

I'm going to go ahead and close this. Please feel free to re-submit this again in the future.