| 19 Apr 2024 |
|  @tzerie:matrix.org left the room. | 21:24:51 |
| 22 Apr 2024 |
 jo_we | hm where's outputPin coming from? I cant seem to find it in stm32f4xx_hal doc? | 12:29:31 |
| jo_we | this does look like something i could use | 12:30:42 |
 ryan-summers | In reply to @jo_we:matrix.org
hm where's outputPin coming from? I cant seem to find it in stm32f4xx_hal doc? It's from the embedded-hal traits | 12:36:43 |
| ryan-summers | In reply to @jo_we:matrix.org
hm where's outputPin coming from? I cant seem to find it in stm32f4xx_hal doc? * It's from the embedded-hal traits I believe: https://docs.rs/embedded-hal/latest/embedded_hal/digital/trait.OutputPin.html | 12:37:12 |
| jo_we | Thanks again
still unsure, how i could store a dynamic pin of different banks in a n array?
Like let x : [DynamicPin<_,_>;3] | 13:13:40 |
| jo_we | I currently have something like [dyn hal::gpio::PinExt<Mode = Output<PushPull>>; N], which doesnt compile since it needs to be sized | 13:58:15 |
| ryan-summers | My best recommendation is to make an enum of your different pins so they all have the same type. Otherwise, it's quite hard with the current HAL designs | 14:04:32 |
| jo_we | rp2040_hal has a DynPinId that does the job like
Pin<DynPinId, FunctionSioOutput, PullDown>
now, given that rp2040 has only one gpio bank, makes some things easier. I was looking for something like that in stm32f4xx_hal
a la
Pin<DynPinPort, DynPinId, Mode = xyz> | 14:07:48 |
| jo_we | though, admittedly my rust and stm32f4xx_hal skills are not quite there, so i dont trust myself that i could implement it myself for a PR | 14:09:13 |
| jo_we | they also dont have port and ID as generic, but rather store it as pin member
pub struct Pin<I: PinId, F: func::Function, P: PullType> {
id: I,
function: F,
pull_type: P,
}
| 14:12:16 |
| jo_we | I think to have something like that work in stm32f4xx_hal, one cant store bank and pinID as generic to the pin structure, no? | 14:12:43 |
 James Munns | If you make generics, you wont be able to put it into an array, as each GPIO will have a different type. | 14:12:54 |
| James Munns | The way embassy_stm32 does it is to just store an index (or pointer? I forget) so there's only a single Output pin type (no generics at all) | 14:13:28 |
| James Munns | It does runtime checks instead (or checks at construction time, if possible), because they are reasonably cheap, and it makes things much easier to use. | 14:14:12 |
| jo_we | is that why you made it generic? to have it completely compiletime checked? | 14:15:40 |
| James Munns | it's one reason. typestates were an early attempt to move more checks to compile time, but we were pretty heavy handed in the early days, and later realized it made some things harder than it needed to be.
These days (for example with embassy, which is more modern/'cutting edge' and maintained), we use generics and type states much less.
| 14:19:31 |
| jo_we | so it wouldnt be wished / a usecase to have it as member to allow storing pins in an array? | 14:22:35 |
| ryan-summers | I had to do exactly this for a project, and ended up doing the enum approach I recommended for an STM32F4: https://github.com/quartiq/booster/blob/main/src/hardware/rf_channel.rs#L85 | 14:27:29 |
| ryan-summers | I definitely would rather that the embassy approach were used for these older HALs. It's something most C HALs do as well | 14:27:52 |
| James Munns | most other HALs have some kind of erase() method that does something similar to what embassy does. Or using an enum like Ryan said. | 14:28:07 |
| ryan-summers | But even the erase is usually not sufficient because they still only erase down to the port-level | 14:28:29 |
| James Munns | like Output<Whatever, Whatever, Whatever> to DynamicOutput or so | 14:28:25 |
| ryan-summers | So you get ErasedPin<GPIOA> or something similar | 14:28:35 |
| ryan-summers | Depends on the HAL, but this is what I've generally seen | 14:28:50 |
| James Munns | yeah, some of the stm hals had like a "double erase" or something? | 14:28:53 |
| James Munns | like you could get a fully erased one. But the stm32... hals aren't very consistent.
I'd probably suggest looking at embassy_stm32 if you don't have a reason not to. It's also totally usable without async.
| 14:30:01 |
| jo_we | In reply to @jamesmunns:beeper.com
like Output<Whatever, Whatever, Whatever> to DynamicOutput or so nothing like that in stm32f4xx_hal sadly? Id take a DynamicOutput, at this point, even if i cant constrain it to hardwareNSS pins | 14:32:24 |
| James Munns | yeah, as Ryan said, only down to the port level, so like "DynamicPin<PORTA>or whatever, which means you can't putPA4, PB6, PC0` in an array. | 14:34:05 |
| jo_we | ohymgod i think ErasedPin works
are there any disadvantages to an erased pin, apart from not knowing which bank/id it is? | 14:35:02 |
