Build Zinc with Cargo #219
Conversation
|
Would it be hard to drop-in replace rake build code with cargo invocation so that |
|
(replace for relevant parts, e.g. zinc crate) |
|
I'm playing with that at the moment. Cargo can handle tests and building |
|
After fighting with Cargo for a while, I gave up and created deps for libcore and librlibc. They are very simple at the moment, but once the new Cargo nightly lands I can make a |
|
So the plan at this stage is to have an apps directory for each platform, and to have a Cargo build for the apps in each. |
|
@bharrisau this seems a bit unfortunate as we will somehow need to duplicate the apps, some of which should at least in principle be platform independent (says the person responsible for duplicating |
|
Mostly because it make my life easier (happy to refactor later, this has been on my TODO for so long I just really want to get this done), plus each platform has different features so the example apps aren't 100% portable. |
|
How is this looking? I had to move the isr stuff out to the application level to get rid of all the linker stuff. Ideally a Zinc/PlatformTree macro will handle generating them. It builds a suitable ELF binary so I'm pretty happy. I'll port a blink example over to show peripherals and pinmaps next. |
|
I don't think the app layer is the proper placement for linker layout. The linker layout is not app dependent is it? The layout.ld for K20 is only for MK20DX32 , I would use more specific naming as it would allow us to add there another MK20Dxxxx. In general, looks better to me as it was. |
| #[link_section=".isr_vector"] | ||
| #[allow(non_upper_case_globals)] | ||
| #[no_mangle] | ||
| pub static ISRVectors: [Option<unsafe extern fn()>, ..ISRCount] = [ |
There was a problem hiding this comment.
I would name this ISRVectors as Core interrupts. Which tends me to an idea, even this could be added based on the core selected. Not part of K20 chip specifications. What do you think?
There was a problem hiding this comment.
The issue with interrupt handlers is that Rust doesn't do weak/optional functions very well. The implementation of interrupt handlers is app specific (as the app chooses to enable them).
Happy to take suggestions for this, should Zinc provide a generic handle that passes the interrupt to an event handler in the main thread?
There was a problem hiding this comment.
If there's nothing like weak linkage, there could be an interrupt manager. Dynamically reallocate vector table once the ISR are used. It would manage interrupts for HAL layer as well (To register interrupt, deregister).
I don't think isr handlers belong to an app layer.
I am yet not familiar with event handler, if you can point me to the source.
This (how are interrupts managed) might be suitable for separate discussion, to leave it out of this pull request.
| path = "src/zinc/lib.rs" | ||
|
|
||
| [dependencies.rlibc] | ||
| git = "https://github.com/bharrisau/rust-librlibc.git" |
There was a problem hiding this comment.
https://github.com/rust-lang/rlibc now has cargo metadata
|
This can probably be closed now that #285 has landed. |
Not finished, but I'm just working through it now. You can build the zinc rlib with
I've also removed the macro_ioreg crate and merged into the single ioreg crate as part of this. Next steps are doing the flexible target specification now that is has landed and also making changes to include all the static libs in the one go.