Open bsl opened 5 years ago
@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.
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.
@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.
This is probably related to the issue I just filed https://github.com/japaric/stm32f30x-hal/issues/35
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 hasidr
which can beread
, etc. In order to make types work in a newer example, I'm getting my gpioa fromGPIOA.split
, which I don't really understand, because it gives me aParts
. But that does have apa8
, 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??