Provide access to gyroscope

[rubberduck203]

There is a L3GD20 gyroscope on board.
Provide access to this peripheral.

[sirhcel]

What about adding the l3gd20 crate as a dependency and a Madgwick orientation filter example like in the f3 crate? Maybe in conjunction with adding a device peripheral struct like the nrf52840-dk BSP has?

[rubberduck203]

There’s a lot going on there, so let me try to break it down.

What about adding the l3gd20 crate as a dependency

I was going to do just that and simply re-export it.

and a Madgwick orientation filter example

I’m honestly not sure I want to maintain that. It always felt a bit out of scope for a board support package to me. Seems like the kind of thing that should live in it’s own project.

Maybe in conjunction with adding a device peripheral struct like the nrf52840-dk BSP has?

What benefit do you feel like brings? I’m not necessarily opposed to the idea, but would like to understand the pros & cons better. Perhaps open a new issue with the rationalization for it?

[sirhcel]

I was going to do just that and simply re-export it.

Having slept over it several times, this actually looks like a worthy solution in the sense of Pareto. :)

I’m honestly not sure I want to maintain that. It always felt a bit out of scope for a board support package to me. Seems like the kind of thing that should live in it’s own project.

I read you loud and clear and I see your point here. Reviving this example in its own project might be the better idea. May be at least because this example includes a visualization component for the host as well.

What benefit do you feel like brings? I’m not necessarily opposed to the idea, but would like to understand the pros & cons better. Perhaps open a new issue with the rationalization for it?

I've worked with it in https://github.com/ferrous-systems/embedded-trainings and my gut instict liked it because I had not to think about how to configure pins and which ones to get a peripheral up and running. I just borrowed the peripheral from this struct. I have not experienced downsides in the little time I've worked with it, but I could imagine that one is loosing flexibility if one wants to use pins or peripherals in a different setup than the BSP made.

But I have not much experience with it yet. With just reexporting the l3gd20 crate, there is no hurry to decide this right now from my perspective. I could experiment with it and come back with a PR or at least open an issue for further discussion.

[rubberduck203]

because this example includes a visualization component for the host as well

That’s exactly my hesitation. I already neglect this crate enough as it is. =)

I’ll open another issue about the Board struct. The idea is growing on me, but I need to look further into it.

Let me know if you want to handle this issue.
Otherwise I’ll try to get to it sometime this year.

[rubberduck203]

Related to #42.
In August 2020 ST release a new board variant with a different gyro (I3G4250D).
They appear to be pin compatible, but I don’t know if their I2C interface is.

[cjheath]

Hi there, and thanks for your thoughts on this subject. I bought an STM32F3DISCOVERY some years ago in order to build (in C++) an IMU using the 9DOF sensors on-board. I never completed it, but when I saw the opportunity to learn Rust, I started to work through the F3 Discovery book https://docs.rust-embedded.org/discovery/f3discovery/ and found this board support package, but had not yet found japaric's f3 crate.

Anyhow, I was disappointed that the board support package didn't have handling for the gyro and shelved it for another year. Too many projects anyway, heh.

It would be really god to either add this support, or at least add a prominent note saying that it isn't implemented, and where to find code that does support the L3GD20.

Alternatively, I'd be willing to try to figure out how to add the support - but being a Rust newbie IDK how that might go... I have plenty of C++ and embedded background.

Your thoughts?

[rubberduck203]

I’m not sure what to say here @cjheath . I was disappointed the f3 crate didn’t compile, so I started work on this crate. Of course it would be good to have support for both of the different gyros.

This crate relies on jparic’s driver crate for the accelerometer, which he does not maintain, but seems to work okay. He also wrote one for the lgd320 (also not maintained).

https://crates.io/crates/l3gd20/0.2.0

Adding support for your revision should be as simple as adding a reference to that crate

stm32f3-discovery/Cargo.toml

Line 29 in 45c7f1b

lsm303dlhc = "0.2.0"

And then re-exporting it

stm32f3-discovery/src/lib.rs

Line 4 in 45c7f1b

pub use lsm303dlhc;

I just haven’t taken the time to do that yet. Since the pandemic, I’ve found it’s better for me to have hobbies that don’t look so much like my day job.

[cjheath]

Oh, I see. It's probably just my lack of familiarity with the ecosystem then. It looks like there is a solution, I just didn't know how to find it yet. Still, it would be nice to at least have a pointer on how to proceed :)

[rubberduck203]

For now, I would start with adding a reference to the driver crate in your project and reference the f3 source code to see how to wire it up properly. I do want to add it here. I just haven’t had the time to do so. PRs welcome, although I haven’t done a good job of getting them merged this year.