M762spr[m] has quit [Quit: Idle timeout reached: 172800s]
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
cinemaSundays has quit [Quit: Connection closed for inactivity]
cinemaSundays has joined #rust-embedded
<Mathias[m]>
<dirbaio[m]> "yeah but that's for reproducibil..." <- Bazel is not singling out Cargo, it’s the same for autotools / CMake projects: they are converted to be built with Bazel.
<Mathias[m]>
So as an example, if you have foo-sys which either finds the pre-built libfoo library or uses cc in build.rs to (cross-)compile libfoo with autotools. The Bazel users were saying: we want an environment variable that will disable the cc path, I will provide libfoo (built with Bazel) and if it’s not found an error is expected.
<Mathias[m]>
I hope I understood it correctly, but the approach with Buck2 seems to be interesting in that there is a some form of adapter that uses cargo to generate the Buck2. It’s true that if you had to « vendor » all dependencies manually that would be a big headache. But with some tooling that understands crates, it can be much easier.
emerent has quit [Ping timeout: 260 seconds]
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
cinemaSundays has quit [Quit: Connection closed for inactivity]
wassasin[m] has quit [Quit: Idle timeout reached: 172800s]
apirkle has quit [Ping timeout: 252 seconds]
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
mali[m] has joined #rust-embedded
<mali[m]>
If we use an accelerometer on an embedded linux environment and can reach it through its kernel driver, the chip visible on /dev/iio/, what is the best way to reach this device through a rust application?
<JamesMunns[m]>
Maybe depends on what sort of sample rate you want
<JamesMunns[m]>
(never used iio before)
<M9names[m]>
there's a crate for IIO - i ran across it the other day. i haven't used it either, but it's been around for a few years and is still maintained so it's *probably* good enough.
<mali[m]>
Aah, thank you both! We are using imx and
<mali[m]>
so both of them are relevant. We can read the data through reading files, and iio rust crate seems to be a wrapper of the AD code that is mentioned in the first blogpost.
<mali[m]>
And I think losing multiple channels with continuous conversion is an issue.
<scorpion2185[m]1>
is there a book/video or something that i can use to learn to how make some os from scratch?
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
<scorpion2185[m]1> "is there a book/video or..." <- I haven't read all of it, but I have heard good things about this series https://os.phil-opp.com/
cgc17[m] has joined #rust-embedded
<cgc17[m]>
hi everyone, i am just getting back into embedded rust and saw rtt-target has a later version than i was using previously, but no longer has the cortex-m feature so i needed to use an older version. is there a newer crate i should be using for rtt these days?
<scorpion2185[m]1>
>In this post, we create a minimal 64-bit Rust kerne
danielb[m] has joined #rust-embedded
<danielb[m]>
> but no longer has the cortex-m feature so i needed to use an older version
<danielb[m]>
why do you need a cortex-m version to exist?
<danielb[m]>
s/version/feature/
<cgc17[m]>
well, i may not. without it, and using 0.6.1, i get an error when building: error: linking with rust-lld failed: exit status: 1
<danielb[m]>
do you have any more details in that error message?
<cgc17[m]>
>>> referenced by lib.rs:202 (/home/cgc/.cargo/registry/src/index.crates.io-6f17d22bba15001f/critical-section-1.2.0/src/lib.rs:202)
<cgc17[m]>
several lines like the above
<danielb[m]>
which MCU/HAL are you using, and does it provide a critical section implementation?
barafael[m] has joined #rust-embedded
<barafael[m]>
try adding the dependency "portable-atomic"
<barafael[m]>
sth. like:
<barafael[m]>
portable-atomic = { version = "1", features = ["critical-section"] }
<cgc17[m]>
danielb[m]: nrf52833 (on the microbit v2) - no PAC/HAL in use yet. just a quick setup test to print a message with `rprintln!()` - got it working on the older `rtt-target` but wanted to use the latest if possible.
<cgc17[m]>
barafael[m]: will try this
<danielb[m]>
cgc17[m]: at the very least you should add a dependency to cortex_m with critical-section-single-core enabled
<danielb[m]>
portable-atomic won't help you here
<cgc17[m]>
i have cortex-m but not the critical-section-single-core; i was not familiar with that one. let me try
<danielb[m]>
usually a HAL would define an actually fitting critical section implementation for you
<danielb[m]>
* for you, so it's rarely needed I think to set that yourself
<cgc17[m]>
same error, but looking at the docs now i see it may be because there are two competing critical section implementations; one in rtt-target and one in cortex-m; (saw that suggestion here https://github.com/rust-embedded/critical-section)
<danielb[m]>
do you have any imports in your rust code from cortex_m? just adding use cortex_m as _ may help you here.
<danielb[m]>
cortex-m is a critical-section provider, rtt-target is a critical-section user, and your error is undefined symbol: _critical_section_1_0_acquire meaning there is no definition present
<danielb[m]>
having multiple would give a different error
<cgc17[m]>
danielb[m]: well.. this worked! haha i feel silly now. thank you for your help!
<danielb[m]>
you're welcome, rust has a few quirks like this that can bite you in the ankle
<danielb[m]>
hmm the critical-section readme also has a troubleshooting section 🙃 well anyway, we got there without it ^^
<cgc17[m]>
wow and only 3-4 lines above what i read and posted from the same readme 🤦
<danielb[m]>
:D don't worry about it
<danielb[m]>
just keep in mind that three hours of debugging can save you from 5 minutes of documentation reading
PhilMarkgraf[m] has quit [Quit: Idle timeout reached: 172800s]
cinemaSundays has joined #rust-embedded
doom_potako[m] has quit [Quit: Idle timeout reached: 172800s]
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
cinemaSundays has quit [Quit: Connection closed for inactivity]