<Lumpio[m]>
I used to be all for "zero runtime cost do everything at compile time" too but then I had to write `DataMode<sh1106::interface::SpiInterface<&'static SharedSpi<Spi<pac::SPI1,(PA5<Alternate<PushPull>>, PA6<Input<Floating>>, PA7<Alternate<PushPull>>, )>>, PA2<Output<PushPull>>, PA1<Output<PushPull>>>>`
<Lumpio[m]>
Now I'm all for "small amount of runtime cost, most of which is likely optimized away"
<danielb[m]>
Type state is fun, I once managed to implement a no-alloc GUI, where the view tree was completely encoded in the type of the gui. I don't recommend 🙃
starblue[m] has joined #rust-embedded
<starblue[m]>
You could use type aliases to make it more readable, like type MOSI = PA.....
dkm has quit [Ping timeout: 276 seconds]
dkm has joined #rust-embedded
Makarov44 has joined #rust-embedded
Makarov44 has quit [Client Quit]
Makarov44 has joined #rust-embedded
Makarov44 has quit [Quit: Client closed]
<bogdan[m]>
<dirbaio[m]> "keep in mind the compiler is..." <- Maybe I misunderstood your point, but I'd expect a lot of checks to involve reading from memory mapped registers, which means they are volatile, which means there's not much chance of the check getting optimized away
<dirbaio[m]>
no, you check the config the user passed you (which is in a plain old struct) is correct, and then you write to registers
<dirbaio[m]>
to do this the API needs to be a single big function configure_clocks(config: ClockConfig)
<dirbaio[m]>
s//`fn /, s//`/
<dirbaio[m]>
instead of many small functions like fn enable_hsi(); fn disable_hsi(); etc that incrementally mutate the hw configuration
<bogdan[m]>
ah ok, got it
<dirbaio[m]>
a single big fn also makes the API simpler, because now the user doesn't have to care about order. they just specify the "end state" they want in the config, the HAL takes care of the right order to apply it to the hardware.
<bogdan[m]>
<dirbaio[m]> "a single big fn also makes the..." <- hmm, this also means that the configs for each peripheral can be dynamically saved and loaded at runtime. this is interesting
<bogdan[m]>
... and a set of all peripheral configs would define a particular system config. yes, I like this :)
thejpster[m] has joined #rust-embedded
<thejpster[m]>
see also - Device Tree
<dirbaio[m]>
something something abstraction aiming to abstract the entire world
JamesMunns[m] has joined #rust-embedded
<JamesMunns[m]>
"code is data", or "data is code", take your pick :)
<danielb[m]>
dirbaio[m]: can we have abstraction over our abstraction?
<danielb[m]>
and then abstraction at home is a PAC
<dirbaio[m]>
trait Abstraction
<dirbaio[m]>
trait MyThing; impl Abstraction for MyThing
<dirbaio[m]>
wait no that's not how it works
<danielb[m]>
impl Abstraction for T where T: AnotherAbstraction {}
<danielb[m]>
Abstractception
<bogdan[m]>
<thejpster[m]> "see also - Device Tree" <- at some point you need to decide if you're going the Linux or the TempleOs way :)
<bogdan[m]>
... but getting back to the point, I was looking at someone configuring betaflight to work on their home-built drone so use such-and-such pins for motor PWMs, and uart-n for GPS, etc -- and was thinking "oh, that seems nice, but rust would prevent you from doing that"
<bogdan[m]>
... which is obviously wrong, but my mindset was on compile-time checks