<cr1901>
Okay, I'll bite... how does the nightly generation remove the "mod generic" code from each top-level module in the nightlies? https://github.com/stm32-rs/stm32-rs
<diondokter[m]>
Would love it if people checked it out, it's been a lot of hard work and I'm really happy about its current state.
Ralph[m] has joined #rust-embedded
<Ralph[m]>
<diondokter[m]> "Hey all, just wanted to let y'..." <- > <@diondokter:matrix.org> Hey all, just wanted to let y'all know I've released a release candidate for device-driver 1.0: https://github.com/diondokter/device-driver... (full message at
<diondokter[m]>
There are other drivers that use older versions too
<Ralph[m]>
if you add example links to the README it might be great to have one each for I2C and SPI based devices (or of course one driver which supports both) as well as maybe 1-2 other things (always presuming that there are already drivers out there doing that with your crate!), e.g. UART-based
<diondokter[m]>
alexmoon: If you update to the release you can release your driver on crates.io too (not sure if you were planning that)
<diondokter[m]>
<Ralph[m]> "if you add example links to..." <- I added some to the preface together with a sneak preview :)
<Jubilee[m]>
<explodingwaffle1> "i wonder if it coould make sense..." <- The machine backend will reject normal calls. I think we should also.
<Jubilee[m]>
I think maybe we _do_ want to allow calls, but only "special" ones?
<Jubilee[m]>
e.g. I could see `become interrupt_fn();` being valid.
<Jubilee[m]>
but not unqualified interrupt_fn(), get out.
<Jubilee[m]>
an alternative would be to add extern "rust-save" and then people call into that.
<Jubilee[m]>
* machine backend (the architecture-specific backend to LLVM, I mean) will, * will usually reject normal
<Jubilee[m]>
yeah, become is a type of call that is inherently already sensitive to the signature of the function you call it from, which is why it makes sense to say "okay, you can become an interrupt handler".