<MathiasKoch[m]>
I would have assumed AllowAnyAuthenticatedClient to atleast check that it was presented a client cert, and it was valid in the context of the given root store?
<thejpster[m]>
uhhh ... I read the docs and I have no idea how that works or how I replace shared_bus with it.
<thejpster[m]>
Before I made a shared_bus::BusManager<MyI2cController> and I called `.acquire_i2c()` to get a temporary device handle I could pass to my I2C driver.
<JamesMunns[m]>
Put your i2c device in a Mutex refcell
<thejpster[m]>
Ah, I was looking at the CriticalSectionMutex page
<thejpster[m]>
which doesn't have an example
<thejpster[m]>
and now my codec is unhappy because it needs an eh0.2 trait
<thejpster[m]>
so I tried embedded-hal-compat and it is still on embedded-hal 1.0-rc.1 so it doesn't build
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
update the driver 🙃
<dirbaio[m]>
for i2c it's almost always trivial
<thejpster[m]>
drivers plural
<dirbaio[m]>
just change the trait bound
<thejpster[m]>
and do a pr, and get it reviewed and merged, then prepare a release and have that reviewed, and then get it published
<JamesMunns[m]>
and then it'll be done! 🎉
<diondokter[m]>
Yeah, we're gonna be feeling this for a while...
<thejpster[m]>
or I could just give up and go and do something else
<dirbaio[m]>
something something help the ecosystem evolve
<thejpster[m]>
my application had some weird and funky Spi bus sharing stuff and porting that over was painful enough. I don't have the spoons to go and update all my I2c device drivers too.
<JamesMunns[m]>
diondokter[m]: One breaking change every 5 years seems reasonable
<JamesMunns[m]>
(0.2.x was first released May 2018)
corecode[m] has quit [Quit: Idle timeout reached: 172800s]
Guest7282 has joined #rust-embedded
pauldotsh[m] has quit [Quit: Idle timeout reached: 172800s]
Ralph[m] has quit [Quit: Idle timeout reached: 172800s]
Guest7282 has left #rust-embedded [Error from remote client]
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
Guest7282 has joined #rust-embedded
Marcuss2[m] has joined #rust-embedded
<Marcuss2[m]>
Hey, I am about to fully embark into the embedded Rust journey.
<Marcuss2[m]>
I do have a question or two about what is standard. Like how are clocks dealt with? Modern chip have quite complex clock systems feeding into everything. Does every HAL just assume to have its configuration?
<JamesMunns[m]>
Most hals will have an interface for configuration specific to the chip or family, it varies a little from HAL to HAL.
<JamesMunns[m]>
for example, embassy-stm32 has a fairly consistent interface for RCC for all stm32 devices, but there are certain PLL or other settings that might be specific to some subset of devices.
<Marcuss2[m]>
I do feel that GUI configurators for clocks are one of the few things which GUI makes sense for.
<JamesMunns[m]>
With respect to "portability", we usually admit in Rust that different chips are so special, that setup of the chip and peripherals are usually not portable, but once you have things set up, and have a UART or SPI port, those can be handled portably.
<JamesMunns[m]>
Marcuss2[m]: yep! for example you can use stm32cubemx, get your clock settings, then feed them into the configuration struct
<Marcuss2[m]>
Makes me wonder if it could be extracted somehow into something at least somewhat compatible across chips
<JamesMunns[m]>
Maybe! But even between say - stm32 and nrf52, how those chips handle clocks are pretty wildly different
<JamesMunns[m]>
in stm32 it's more "central" in RCC, in nrf52 you actually handle it "on the edges" for each peripheral.
<Marcuss2[m]>
Aware of it, already read into it when implementing a flashing algorithm for CH32V307 - Peripherals look the same as STM32F series
<JamesMunns[m]>
so - I will never say never! At the moment, we've generally just said "it's way easier to let each chip be a little special at setup time, and not try to abstract over that part, because it's complex enough that it's more work than it's worth".
<Marcuss2[m]>
I feel that it could be somewhat abstracted as "thing that divides clock", "thing that multiplies clock", "thing that produces a clock" and "thing that consumes a clock"
<JamesMunns[m]>
if you come up with something and have a demo that works on couple different chip families, I think that would be very interesting to look at!
<Marcuss2[m]>
I have too many ideas.
<JamesMunns[m]>
I think you'll find you're not alone here :)
<JamesMunns[m]>
But yeah, there is no central planning department here. The last 6 years or so have just been waves of different people going "hey I think I found a better way to do X, check it out"
<JamesMunns[m]>
We try and codify the current best practices in various docs and common libraries, but's it's definitely more "collect the best ideas and polish them up" than "design from scratch"
GenTooMan has quit [Read error: Connection reset by peer]
GenTooMan has joined #rust-embedded
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
<firefrommoonligh>
<Marcuss2[m]> "I do feel that GUI configurators..." <- That's what I do. I set up a sane `default::Default()` (generally full speed on the sys clock) in HAL, then let the firmware override various scalers and other settings. Requires using a GUI clock tool or other tree)
<firefrommoonligh>
How easy setup is varies wildly between MCUs. Espressif and nordic is easy
<firefrommoonligh>
STM32 varies greatly by family
<firefrommoonligh>
I work mostly with stm32 G4 and H7. G4 I usually use the default clocks with maybe a few adjustments, eg to make CAN timings more flexible, enabling a 48Mhz oscillator for USB etc.
<firefrommoonligh>
On H7, generally some degree of customization is required. For example, SPI, CAN, and the ADC all generally require some combination on enabling additional PLLs, additional PLL dividers, or changing their default clock. Very flexible, but takes clock tree view and config.
<firefrommoonligh>
* the default (as set in HAL) clocks with
<firefrommoonligh>
Enums and integers work well for scalers and clock features, depending on how fine-grained the control is.
<firefrommoonligh>
This is generally the only thing I use CubeIDE for.
eigenrick[m] has joined #rust-embedded
<eigenrick[m]>
hey, smartled people, I opened https://github.com/smart-leds-rs/smart-leds/issues/20 to address supporting additional color counts and orderings. I am happy to make the necessary changes, but I'm looking for ideas on how best to define the types to allow more flexibility in the schema.
<eigenrick[m]>
I reckon the best crates to look to for this would be the Linear Algebra and related ones that have to interop things like Vector3, Vector4, etc.
SunClonus has joined #rust-embedded
SunClonus has quit [Quit: Leaving]
SunClonus has joined #rust-embedded
jcroisant has quit [Quit: Connection closed for inactivity]
SunClonus has quit [Quit: Leaving]
IlPalazzo-ojiisa has quit [Remote host closed the connection]