Split and publish stable parts of zinc to crates.io

[farcaller]

Back to do more coding!

The short-term plan is to split zinc into a few crates, including macro crates, dedicated crates for ioregs, hal. I've tinkered around the rust-libcore and managed to push volatile_cell with little issues.

Reasoning on ioreg is that it's better to have actual generated source in the repository, to make use of code completion and whatnot. SVD files (where applicable) are changing really slow so it's of little concern. The only thing that needs to be stabilized is field naming: i.e. should the names follow the documentation or rust style guide (minding that vendors have different documentation styles).

[rvlander]

Great news!

[lizardo]

I would welcome being able to generate readable code from ioreg!() macros, it would make easier to debug.

Update: I misunderstood your comment. From #359 , my understanding now is that the decision would be whether to keep using macros vs. standalone tool that parses from SVD and generates Rust code directly right? Personally, I'm a bit uncomfortable when macros generate a lot of code that I can't easily see/debug. For me, macros are very useful to avoid repetition of small/medium bits of code. For whole interfaces/modules that don't change much, I prefer "static" code generation.

By the way, I've noticed build errors related to the core -> rust-libcore crate rename (using zinc @ f8a35003053e541a7646bcfa8f6c3c99756cca46). Is that being worked on? (Just to make sure it is not an error on my side.)

[posborne]

CC @0xc0170

I like this idea. We can probably take some inspiration from what the mbed guys are doing with Yotta and the mbed-hal-* packages (https://github.com/ARMmbed?query=mbed-hal) an overview of which is provided in the README for mbed-hal here: https://github.com/ARMmbed/mbed-hal#porting. Interop with some of the mbed stuff might also be nice for some things, but I wouldn't shoot for it in the short term.

It might be possible to replicate the yotta target aspect for the rust/zinc ecosystem via a cargo subcommand that would do some work to ensure the proper target is set up. This could remove the need to have people remember long compile commands. For an application, the developer experience could look like this:

$ cargo install cargo-zinc
$ git clone <myproject>
$ cd <myproject>
$ cargo zinc target <github url to "target" repository>
$ cargo zinc build

cargo zinc build would be a pretty simple wrapper around cargo build but which would:

• Pass arguments for proper compilation for the configured target
• Possibly perform post-build operations like generation of bin/hex/list files

[farcaller]

By the way, I've noticed build errors related to the core -> rust-libcore crate rename (using zinc @ f8a3500). Is that being worked on? (Just to make sure it is not an error on my side.)

went to sleep before submitting the fix everywhere >_< I'll follow up on this in a few hours.

[farcaller]

It might be possible to replicate the yotta target aspect for the rust/zinc ecosystem via a cargo subcommand that would do some work to ensure the proper target is set up

This is exactly the idea I'm thinking about.

[0xc0170]

@posborne Thanks for sharing the idea. Having targets would be useful.

I am in favor of splitting to crates, benefit from what cargo provides.

@farcaller Can you provide an example if I am getting this right - follow the documentation as follow the naming in svd files?

The only thing that needs to be stabilized is field naming: i.e. should the names follow the documentation or rust style guide (minding that vendors have different documentation styles).

[farcaller]

Can you provide an example if I am getting this right - follow the documentation as follow the naming in svd files?

Sure. Let's take lpc111x. There's a register called I2C0MMCTRL with a bit MM_ENA that can be enabled or disabled. Based on the original unprocessed svd naming the values are: MONITOR_MODE_DISABLE and THE_I2C_MODULE_WILL_. It might make sense to rename the constants to Disabled and Enabled but then you'll have to rename 95% of the constants in that one given svd.