Project status

[andrey-gvrd]

So, what's the status of the project right now?

I've noticed that there has been a period of silence for some time now. Are there technical issues with zinc, or is it the luck of contributors, or something else entirely?

[posborne]

I too am curious as to the current status. I have some supported hardware (LPC1768 and kit; teensy 3.1) am would be willing to donate some time if the project has a moderately clear direction. If not, what is the general consensus on the best approach for Rust on embedded micro-controllers?

[farcaller]

Here's the current state of things.

Zinc is mostly based around transformation macros: ioreg and platformtree, it also depends on too complex and barely scalable build system written in ruby (which is broken right now). I think it's a bit more than a year now since I'm writing this project, and it satisfied my curiosity in terms of what is possible to do on bare metal with rust, and now it surely needs much more straightforward plan. I've been holding zinc off until 1.0, although realistically, zinc needs nightly (it's hard to keep up with zinc and other rust projects breaking every so often, and others at least need less maintenance).

The reasonably stable parts of zinc tree are svd parser and ioreg, and that's what I'm planning to build on now, basically providing "safe" APIs to metal and letting end user deal with that. My original plan of utilize static dispatch anywhere where at all possible ended up a failure with too much macro code, so I'll be looking into simpler dynamic dispatch and unified traits for peripherals.

With all the curious breakage, we need a much more sophisticated test system, as the code quality in zinc is low and full of unwrap() and relevant hacks. I tried to solve it with testing, coverage and more testing and I still think this is the way to go. I got a hardware setup where a linux box can run tests, get coverage data with gcov and then run e2e tests on a real hardware via swd.

Okay, well, this is all chit-chat, the real plan is:

1. Make ioreg compile again
2. Port more code over to crate-based compilation chain (so far it's ioreg and support code)
3. Make dynamic-dispatch API for uart and gpio based on two LPC MCUs I mainly work with
4. Start thinking about how to make platformtree again
5. Unbreak the scheduler, that should be more simple with vtables

Long-term goal is to bring more sense into PT. I tried to rewrite it with macros that simplify the generator code but it ended up in even bigger mess, which is really more prone to errors than arduino-like code.

[bgamari]

I, for one, have been busy finishing my thesis, moving to Germany, and starting a new job. If it weren't for this I'd be trying to get ioregs! building.

[posborne]

Ah, looks like @mcoffin is off to the races on his fork: https://github.com/mcoffin/zinc/tree/new-build. I was able to build the ioreg crate on his tree. I'm thinking much of the work done by @bharrisau may still be relevant for item 2: https://github.com/hackndev/zinc/pull/219/files

[mcoffin]

@posborne Haha. I'm glad someone noticed. Unfortunately, that version of the ioreg crate is pretty freaking broken, so I'm getting the tests back up and running before I do too much more with it.

It's not too bad converting the tests over to just manual tests from the shiny test platform which no longer builds (and I think it'd be less work to just port the tests rather than fix the tiny build).

[farcaller]

Shiny is broken because I expected to move over to stainless, that has more features. But now stainless is broken too :tired_face: Should just fix shiny I guess.

[mcoffin]

Also: if anyone wants to figure out whats wrong with the super basic test in https://github.com/mcoffin/zinc/tree/new-build I've been kinda banging my head over it. There's some error in the AST builder I'm pretty sure.

It was probably introduced when quote_method! was changed to quote_item!.

[mcoffin]

If anybody still cares, my version of ioreg now builds and passes all of its old unit tests!

Here is a hardlinked version, since I'm going to be doing more iterating and you probably want a semi-stable copy if you want to use it for something. mcoffin/zinc@69a60628300bd78dcd200588cd7a53376ed80e21

[posborne]

@mcoffin, I'm trying to get your stuff built and am having trouble linking against libcore. That led me down a rabbit hole that I think @bharrisau has been down before of...

1. Using a crate for libcore (which is not supported in upstream): https://github.com/bharrisau/rust-libcore/pull/1
2. Forking rlibc to depend on the libcore crate explicitly: https://github.com/posborne/rlibc/tree/test-libcore-dependency
3. Change zinc to depend on the forked rlibc

How are you building? Is there some trick I am missing. I couldn't figure out how to build rust from source with a triple that just has a JSON specification. Is there some trick there? What makes sense long term?

[mcoffin]

@posborne The depth of that rabbit hole is one of the reasons I chose to build libcore out of tree.

With the new build system, I wanted to make it as much just like a regular Cargo package as possible, with only a little Makefile on the top to close the gap. That way, it'll be more maintainable and easier to approach for someone that's new.

In a "normal" Rust compilation environment, a version of libcore is built for the target and kept in /usr/local/lib/rustlib/$(TARGET)/lib. So... I just manually built libcore out of the rust tree and put it there to create that "normal" environment. I did this because that's what rustc's build system would do it you were to build it with a thumbv7m-none-eabi target enabled at the time of the build.

I think it might be useful to include some kind of Makefile task or at the very least instructions on how to do that, but I don't think that moving libcore in to the actual tree again is a good idea as that moves away from the canonical rust project structure that you'd expect. For example, you wouldn't move libgcc or libcompiler-rt in to the tree of a project... as that's part of an expected environment.

I'm open to either way, just my 2 cents.

If you want a simple libcore build command then see http://antoinealb.net/programming/2015/05/01/rust-on-arm-microcontroller.html.

[bharrisau]

For example, you wouldn't move libgcc or libcompiler-rt in to the tree of a project... as that's part of an expected environment.

You actually end up needing to build libcompiler-rt as most cortex-m toolchains only give you a libgcc. Just one more thing I had trouble making a create for.

Now that 1.0.0 has landed I'll try to spend some time on Zinc. Thanks to everyone that has kept the ball rolling in the last few months.

[posborne]

I would really like to see zinc master be something that can be used by people interested in Rust again, particularly in the embedded space. I think the work that @mcoffin has done that is open for review at https://github.com/hackndev/zinc/pull/285 is our best shot at moving things forward. It just needs some review from the core team.

As far as those changes on the plan proposed by @farcaller, here's the status on the new-build branch as I understand it:

(1) Make ioreg compile again

Done. Ioreg compiles.

(2) Port more code over to crate-based compilation chain (so far it's ioreg and support code)

This is improved on the new-build branch. I think things, especially for projects looking to use zinc as a dependency, could be improved further, but the work has been done to replace the rakefile build system with, for the time being, autotools.

(3) Make dynamic-dispatch API for uart and gpio based on two LPC MCUs I mainly work with

(Open AFAIK)

(4) Start thinking about how to make platformtree [work] again

Platformtree is building and working (at least for blink_pt) thnaks to the work done by @mcoffin.

(5) Unbreak the scheduler, that should be more simple with vtables

(Open AFAIK)

[mcoffin]

Just to stress this point, the only thing that autotools does in that branch is generate an mcu-specific <mcu>.json file with the correct linker (detected by autotools just as if you were cross compiling for arm-none-eabi) and generate a Makefile that just runs objcopy on the executables from cargo.

To build a project that depends on zinc, you would just have to:

• Get a copy of zinc and run ./configure to generate a rust target-spec file
• Put the resulting <target>.json file in your project
• Add zinc (from github... or even maybe crates.io someday?) to your cargo dependencies.

I could whip up a quick example maybe? The current problem with this is the hard-coding of the paths to linker scripts in the <target>.json files, but that could probably be fixed somehow.

I just want to stress that this isn't a switch from Rake -> Autotools. This is a complete conversion to cargo, at least as much as is possible, with a small ./configure script for doing just that... generating configuration the project for a specific MCU. If you already have a <target>.json target-spec, and don't want to use a Makefile to build the examples, then you don't even need to run ./configure! Cargo is all you need. That actually took me a bit to figure out how to work the ISR code in to the zinc crate because an internal compiler assertion fails if you declare the same extern symbol as two different types in two different mods, even if they know nothing of each other (see __STACK_BASE stuff... makes for one call to transmute(...) but that's a small price to pay for getting zinc core down to one library).

Start thinking about how to make platformtree again

I got the impression that was more of a re-design than just "getting it to work" but that could be how I read it.

That said, if people don't like it or have better ideas, shoot and lets do it.

[ghost]

Hi people,

I'm familiar with ARM platform, but not so much with Rust. What exactly does the platform tree provide? I don't really understand what is meant by compile-time verification of hardware.

Also, is it still possible to reconfigure the hardware during runtime?

[mcoffin]

@jayrandez: The compile-time configuration of hardware means that some computation normally done at runtime can be done at compile-time (for example computation of clocks based on other clocks). The verification just means that you know you're not trying to, for example, instantiate two pins at the same index.

Closing because I think the question about the status of the project has been adequately answered.