Suggestion: from `aux` to lower-level modules

[David-OConnor]

I'm too new/bad at this to PR atm, so maybe later. I think a good bet for a follow-on lesson would be how to navigate the modules the aux modules depend on. It seems like there's a layer of general-to-specific Hal modules going on, and if you detangle, it gets confusing due to how many layers there are, and that things are renamed. For example, the f3 crate is a thin wrapper of stm3230x_hal, plus some high-level code. But the way it structures its imports is awkward. The variables rcc, gpioe, and tim6 are used to mean different things/types depending on where you import it from. f3 rexports stm32f30x_hal as hal, and the aux module abstracts a layer farther.

In aux9:

let mut rcc = p.RCC.constrain();
//...
let rcc = unsafe { &*RCC::ptr() };

gpio in f3 can mean:

stm32f30x_hal::gpio::gpioe
// or
p.GPIOE.split(&mut rcc__.ahb)

The aux module is great for the lessons as they're structured, but we need a weaning off. Ie a conversion of one of the modules to the same result, but without aux, and perhaps without things like f3. Here's a detangle of some of the imports on the timers lesson.

use stm32f30x_hal::{
    prelude::*,
    stm32f30x::{self, RCC, TIM6, rcc, tim6},
    gpio::gpioe
};

There's a grey area between useful abstractions, and thin wrappers. I think perhaps it may be best to, towards or at the end of the series, dive from aux right to stm32f30x_hal or lower. And show that you can use cortext_m_rt::entry instead of aux::entry: They do the same thing, aren't syntactically different, but the latter is provincial, while the former is general.

[David-OConnor]

Here's what I've come up with, using an example from the timers module. Others should be similar. This is more general and current than aux:

Cargo.toml:

[dependencies]
cortex-m = "0.6.2"
cortex-m-rt = "0.6.12"
stm32f3xx-hal = { version = "0.4.2", features=["stm32f303xc", "rt"] }
panic-itm = "0.4.1"

Imports:

pub use cortex_m::asm; // or cortext_m::asm::{bkpt, nop} etc
use cortex_m_rt::entry;

use stm32f3xx_hal as hal;
use hal::{
    prelude::*,
    stm32,  // or stm32::{RCC, Peripherals, TIM6, tim6::RegisterBlock} etc
};

use panic_itm; // panic handler

What I recommend: Start with aux modules that handle everything. Part way through the series, switch to using modules cortext_m, cortex_m_rt, and stm32f3xx_hal. The only parts of the code that should need to be changed are Cargo.toml, and imports. Continue using f3::Led to abstract the on-board LED code.

[bahrozjaved]

yeah you are right but what i can do with that project is that i can control the 5v relay module connected with stm32f3 and the bluetooth hc-05 also connected through the jummper wirees and controlled my rooms lights that runs on 220v

[David-OConnor]

After getting more experience with rust on embedded, and the embedded-hal ecosystem, I think a better approach would be to ditch the aux modules entirely, and use hal traits/modules directly, eg my above post . It'd make it more like a real program, and easier to dive from this book into a project. Abstractions are nice when they make things general, not specific.

[bahrozjaved]

by seeing your repository I know that you are senior than me.Yes you are right but I am new in rust programming language at the initial level and I am. Leraning the embedded Hal crate that how it works so that's what this is my first milestone of real life project so that why I can store it and make public for all the developer who wanted to study rust.

On Thu, 30 Apr 2020, 10:24 PM David-OConnor, [email protected] wrote:

After getting more experience with rust on embedded, and the embedded-hal ecosystem, I think a better approach would be to ditch the aux modules entirely, and use hal traits/modules directly, eg my above post . It'd make it more like a real program, and easier to dive from this book into a project. Abstractions are nice when they make things general, not specific.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rust-embedded/discovery/issues/222#issuecomment-621992594, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALNEMSWIU57REIMCXLCFXSDRPGX5LANCNFSM4L7YVLPQ .