-
Notifications
You must be signed in to change notification settings - Fork 100
Project status #284
Comments
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? |
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 Okay, well, this is all chit-chat, the real plan is:
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. |
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 |
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 |
@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). |
Shiny is broken because I expected to move over to stainless, that has more features. But now stainless is broken too 😫 Should just fix shiny I guess. |
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 |
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@69a6062 |
@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...
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? |
@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 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. |
You actually end up needing to build libcompiler-rt as most cortex-m Now that 1.0.0 has landed I'll try to spend some time on Zinc. Thanks to |
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 #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:
Done. Ioreg compiles.
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.
(Open AFAIK)
Platformtree is building and working (at least for blink_pt) thnaks to the work done by @mcoffin.
(Open AFAIK) |
Just to stress this point, the only thing that autotools does in that branch is generate an mcu-specific To build a project that depends on zinc, you would just have to:
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 I just want to stress that this isn't a switch from Rake -> Autotools. This is a complete conversion to
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. |
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? |
@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. |
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?
The text was updated successfully, but these errors were encountered: