-
Notifications
You must be signed in to change notification settings - Fork 110
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
compiling for 32-bit arm targets #36
Comments
So it turns out that the standard library conditionally manifests the atomic types based on the Since For now, use this override in your project manifest: # Cargo.toml
[patch.crates-io]
radium = { git = "https://github.com/myrrlyn/radium.git", commit = "f37e569" } This ought to pull my patch of |
Thanks for the quick reply and explanation of the fix, makes sense. Unfortunately, I can't seem to override bitvec's version of radium with your patched one, since the former pins to 0.2 and the latter is at 0.3.
Re: targets you don't have --- I'd be more than happy to buy you a few boards and programmers if you ever want to play around with stm32 microcontrollers. |
This is what I get for doing minimal-effort support work over Christmas, I guess. When |
No worries, hope you had a great holiday. Once the bitvec patch release is up (on crates.io or github) I'll test compilation and close this issue. |
Commit 253143e (not currently on a tracked branch) is published to crates.io. I will incorporate it into trunk later. |
This closes #36, as the `bitvec` dependency tree is now able to compile for the `thumbv7m-none-eabi` target. See the `radium` project for more information. Tested locally: `$ cargo build --no-default-features --target thumbv7m-none-eabi` succeeds. I do not have the environment to run `bitvec` on this target; I presume that successful compilation means a correct artifact.
Hi @myrrlyn Just wanted to follow up and confirm that everything is working properly on my ARM-based microcontroller. Thanks again for the great library! |
I'm experiencing a regression on this bug when using version 0.19.0 or later with the target |
Hi @myrrlyn, thanks for this crate and blog post!
I'm a beginner bit-twiddler, so being able to access bits "normally" (instead of shifting and boolean ops) gives me a fighting chance for my project (parsing optical signals on an ARM microcontroller).
I've used the crate successfully for testing on my mac, but am unable to actually compile to to my microcontroller (an stm32f1 "black pill" / cortex m3;
target = "thumbv7m-none-eabi"
).I'm using:
and my lockfile shows I'm using bitvec
0.16.1
.I believe the issue from a transitive dependency, radium:
Looks like it's trying to import
AtomicI64
, but there's no such type on my 32-bit microcontroller.Any suggestions for how we should try to untangle this?
Perhaps we can:
bitvec
so that it doesn't depend onradium
?radium
to use Rust's feature flags and conditional compilation system to only import 64-bit types on the appropriate platforms?I haven't done much feature flag or no-std Rust development, but am open to learn and submit a patch if you can recommend a direction.
Thanks!
The text was updated successfully, but these errors were encountered: