how to actually read pins in Parts

[bsl]

Dude, I'm sure you are doing some very intelligent stuff in this API, but I am dying here trying to find out if an input pin is high or low. :(

In some older or lower-level API, I would do stuff like get a Peripherals::GPIOA, which has idr which can be read, etc. In order to make types work in a newer example, I'm getting my gpioa from GPIOA.split, which I don't really understand, because it gives me a Parts. But that does have a pa8, which is what I'm interested in, but is it actually possible to do anything with this? I seem to be able to configure it to be various alternate functions, but is there a way to actually read its value??

[little-arhat]

@bsl, you'll get back collections of pin that you can use yorself or pass them to other drivers. They implement bunch of traits from embedded-hal and among them OutputPin and StatefulOutputPin. Those traits have set_low or is_set_low.

Like everywhere in rust you need to bring those traits into scope to actually use their methods with use keyword. OutputPin and other useful traits are part of hal prelude and usually imported as use hal::prelude::*, where hal is hal implementation of your choice.

Speaking of implemntations, I suggest you to take a look at alternative HAL impl for stm32f30x and number of examples we've built on top of that crate.

[bsl]

Thanks for responding. I want to continue this thread in the hopes it will let you know what pain points users of these APIs might be experiencing.

In my current project, I need to talk to a peripheral using I2C. I found an example in f3, and, despite it using this constrain and split stuff, I went ahead with trying to integrate it. Immediately I needed to convert the line dp.RCC.cr.modify(|_, w| w.hsion().set_bit()); because rcc was moved during the constrain. OK... but I guess rcc is an Rcc, which doesn't have cr?

Update: OK, I think I see that I can mess around with dp.RCC to my heart's content before the constrain and freeze calls... but it looks as if freeze actually computes a bunch of stuff I wanted to mess with. I hope it's not undoing my work.

[little-arhat]

@bsl have you read this blogpost by author of this crate?

I'm not the author, and I don't belong to any of rust-embedded workgroups, but I think the idea behind embedded-hal is that you want to use hal implementation, like this crate, to setup up everything, and then use embedded-hal traits to actually use stuff: communicate via i2c, write to uart, switch pin states, etc.

So, when using hal crate, like this, after you've set everything up and has frozen, constrained, or splited peripherals, you should use embedded-hal traits.

I would say, that if you're not going to use any embedded-hal drivers and such, you may as well use svd2rust generated stm32f30x without any wrappers.

[leshow]

This is probably related to the issue I just filed #35