<re_irc> <@n​ewam:m​atrix.org> > Looks like the Error trait is moving to core
<re_irc> <@n​ewam:m​atrix.org> I saw that earlier and they mentioned this was a benefit for embedded, but why?
<re_irc> <@n​ewam:m​atrix.org> Unwrap behaves the same on std and no_std as far as I can tell.
<re_irc> <@n​ewam:m​atrix.org> In fact, now that I think about it... beyond boxing and `dyn Error` what purpose does that trait serve in `std`?
<re_irc> <@l​achlansneff:m​atrix.org> It'll probably be useful here or there
emerent has quit [Ping timeout: 256 seconds]
emerent has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc> <@b​radleyharden:m​atrix.org> I think they are trying to change it to be more useful.
<re_irc> <@b​radleyharden:m​atrix.org> Can they change the behavior of unwrap without breaking backwards compatibility? Seems like they could
<re_irc> <@b​radleyharden:m​atrix.org> I think they said that. They want to implement a specialized unwrap for Error
<re_irc> <@b​radleyharden:m​atrix.org> But they'll need to stabilize specialization first
<re_irc> <@b​urrbull:m​atrix.org> therealprof: I changed this to use `char`s for port names. But I still find better names for generic types. https://github.com/stm32-rs/stm32f4xx-hal/pull/266
tokomak has joined #rust-embedded
<re_irc> <@t​herealprof:m​atrix.org> burrbull: `char` seems like a good fit.
<re_irc> <@t​herealprof:m​atrix.org> burrbull: I'm not quite sure what the external use of those `P` types is, aren't they degraded into an implementation detail? Do we actually need to publicly expose them?
<re_irc> <@b​urrbull:m​atrix.org> They can be usefull if you want to write generic implementation of something across all or part of pins. On the other hand you can't construct incorrect pin as fields and construction methods are private.
starblue has quit [Quit: WeeChat 2.3]
<re_irc> <@t​herealprof:m​atrix.org> So I'm hearing we want/need them? 😉
<re_irc> <@b​urrbull:m​atrix.org> I just saying it makes no sense to hide them.
<re_irc> <@t​herealprof:m​atrix.org> Fair enough. I don't have actual naming ideas. Maybe if they're only useful for very special applications the current names are good enough.
<re_irc> <@b​urrbull:m​atrix.org> Let's merge this then. I have several other improvements based on this.
<re_irc> <@t​herealprof:m​atrix.org> I take it you're happy with the current run of commits on the PR?
<re_irc> <@b​urrbull:m​atrix.org> Don't understand.
<re_irc> <@t​herealprof:m​atrix.org> Do you want to rework the commits on the PR or get it merged as is? I'm fine either way. 😉
<re_irc> <@b​urrbull:m​atrix.org> I
<re_irc> <@l​achlansneff:m​atrix.org> What was the reasoning behind making the alternative function functions implicit?
<re_irc> <@b​urrbull:m​atrix.org> What you mean implicit? `into_alternate()` instead of `into_alternate_af4`?
<re_irc> <@b​urrbull:m​atrix.org> You can still pass `into_alternate::<4>()` if you need
<re_irc> <@b​urrbull:m​atrix.org> auto-inference of types works now and I see this wonderful as `af4` don't say something useful.
<re_irc> <@b​urrbull:m​atrix.org> Next part https://github.com/stm32-rs/stm32f4xx-hal/pull/325
<re_irc> <@a​damgreig:m​atrix.org> oh man, `into_alternate()` and then the compiler completes the type based on the driver you pass it into is great
<re_irc> <@t​herealprof:m​atrix.org> Hell yes! 😀
<re_irc> <@t​herealprof:m​atrix.org> burrbull: Can I leave the computer now or is more coming my way? 😀
<re_irc> <@f​irefrommoonlight:m​atrix.org> Yea - that's a great idea a, given there's 0 degrees of freedom of which alternate to use, if you've paired the pin to a periphi. I've gone with a more explicit approach since I don't do the pairing in software
<re_irc> <@f​irefrommoonlight:m​atrix.org> I also like how the example in that PR (Based on code in an earlier one?) doesn't rely on the fallible EH GPIO traits
<re_irc> <@j​amesmunns:m​atrix.org> How does it look inside of an rtic resource?
<re_irc> <@j​amesmunns:m​atrix.org> Something like `Pin<Alternate<4>>`?
<re_irc> <@j​amesmunns:m​atrix.org> (just asking, as sometimes things that lean too hard on type inference can look... funky, when you have to actually name their type, which is typically for statics and rtic resources)
<re_irc> <@j​amesmunns:m​atrix.org> Slick!
<re_irc> <@t​herealprof:m​atrix.org> jamesmunns: I think that's correct. We don't have an example using `Alternate` pins as a ressource at the moment.
<re_irc> <@j​amesmunns:m​atrix.org> (I'm thinking more like `Spi4<Pin<AF<4>>, Pin<AF<4>>, Pin<AF<4>>, Pin<AF<4>>>` or something, which is usually what gets put in Resources)
<re_irc> <@t​herealprof:m​atrix.org> Is passing a initialized AF pin common? Wouldn't you pass around a fully initialized peripheral handle in most cases?
<re_irc> <@j​amesmunns:m​atrix.org> I mean for SPI ports that are generic over the pins they take
<re_irc> <@f​irefrommoonlight:m​atrix.org> IMO sigs like that needs to be in the Readme, and examples. Ie include use as a global, struct field, or fn argument
<re_irc> <@j​amesmunns:m​atrix.org> But I guess if you've type erased, maybe not?
<re_irc> <@j​amesmunns:m​atrix.org> But I guess you could also have `Spi4<Pin<AF<4>>, Pin<AF<6>>, Pin<AF<4>>, Pin<AF<2>>>` or something if you use alt pins
<re_irc> <@j​amesmunns:m​atrix.org> (this is not a criticism of this change, by the way! This is no better or worse than the verbose types we had before)
<re_irc> <@n​ewam:m​atrix.org> ```rs
<re_irc> <@n​ewam:m​atrix.org> fn set_spi1_sck_af(&mut self) {
<re_irc> <@n​ewam:m​atrix.org> impl Spi1Sck for A0 {
<re_irc> <@n​ewam:m​atrix.org> self.pin.set_alternate_function(5);
<re_irc> <@j​amesmunns:m​atrix.org> and can be fixed by the same techniques, e.g.:
<re_irc> <@j​amesmunns:m​atrix.org> type MainSpi = Spi4<Pin<AF<4>>, Pin<AF<6>>, Pin<AF<4>>, Pin<AF<2>>>;
<re_irc> <@j​amesmunns:m​atrix.org> ```rust
<re_irc> <@j​amesmunns:m​atrix.org> once at the top of your program
<re_irc> <@j​amesmunns:m​atrix.org> newam: that pin is sck af!
<re_irc> <@t​herealprof:m​atrix.org> jamesmunns: Not seeing this criticism at all. I'm thinking of other ways we can use this vastly improved method to improve even further.
<re_irc> <@n​ewam:m​atrix.org> Source here if you want to take a look - I am still tweaking it, I need to remove some more of that boilerplate
<re_irc> <@t​herealprof:m​atrix.org> Interestingly this change bloats no-opt binaries even more. Oh rustc...
<re_irc> <@b​urrbull:m​atrix.org> sorry i was offline myself
<re_irc> <@b​urrbull:m​atrix.org> jamesmunns: I'll see what I can do about it
<re_irc> <@t​herealprof:m​atrix.org> jamesmunns: Type syntax is `PD11<Alternate<AF4>>` or `Pin<Alternate<AF4>>` for a fully erased Pin.
<re_irc> <@t​herealprof:m​atrix.org> Very little (if anything) has changed in the usage itself, just needed to doublecheck whether that's actually true for RTIC, too. 😅
<re_irc> <@b​urrbull:m​atrix.org> Mayby we can make `PD11<Alternate<4>>`
<re_irc> <@f​irefrommoonlight:m​atrix.org> Someone proposed using the type checks in constructors only. Then you could ditch the args from the Spi struct
<re_irc> <@f​irefrommoonlight:m​atrix.org> `Spi`, or `Spi<SPI1>` if it's generic over Deref regblocks
<re_irc> <@f​irefrommoonlight:m​atrix.org> I use the syntax above, but that's unchecked
<re_irc> <@f​irefrommoonlight:m​atrix.org> `type MainSpi = Spi4<Pin<AF<4>>, Pin<AF<6>>, Pin<AF<4>>, Pin<AF<2>>>;`
<re_irc> <@f​irefrommoonlight:m​atrix.org> Feels wrong, since that struct is responsible for setting up and configuring the Spi peripheral, primary with reg reads and writes to the `SPI4` etc reg block. It has no interactions with pin configs. That type signature is a byproduct of ensuring the correct pin is used and configured properly, but it...
<re_irc> ... should end there
<re_irc> <@f​irefrommoonlight:m​atrix.org> This causes #1: Code that's more difficult to read and write, and extraneous data that implies use where there is none
<re_irc> <@b​urrbull:m​atrix.org> This is draft PR. It let's you pass pin in any mode to Serial. It will be transformed to Alternate internally after serial initialization.
<re_irc> <@b​urrbull:m​atrix.org> https://github.com/stm32-rs/stm32f4xx-hal/pull/327
<re_irc> <@a​damgreig:m​atrix.org> firefrommoonlight: the main tradeoff here is you can't then return the pins in a `free` sort of method, since you don't know what they are any more
<re_irc> <@f​irefrommoonlight:m​atrix.org> Maybe this is something that could be resolved by a Rust language update... It would be nice to have the compile checks without the added code complexity
<re_irc> <@f​irefrommoonlight:m​atrix.org> I don't have an idea of what that would look like
<re_irc> <@f​irefrommoonlight:m​atrix.org> You could have the struct take the pin as a borrow. This wouldn't be as strong of a guarantee the pin's set up correctly though
<re_irc> <@f​irefrommoonlight:m​atrix.org> I think the crux of this is "what is the intended use case of the pin checks", and validating the model of situations where someone misconfigures a pin
<re_irc> <@f​irefrommoonlight:m​atrix.org> Ie, the questions to ask: "Is this a new user who's never programmed in embedded and doesn't know how to configure a pin?" "Is this for a complex project worked on by multiple teams, and we need to catch cross-team errors between iterations?" etc
<re_irc> <@f​irefrommoonlight:m​atrix.org> Then you can figure out which approach to take, given the tradeoffs
<re_irc> <@n​ewam:m​atrix.org> firefrommoonlight: There was a post on reddit showing crates that were downloaded the most during weekdays/weekends.
<re_irc> <@n​ewam:m​atrix.org> At the moment the embedded rust crates have many more downloads on weekends than weekdays, I think there's a lot of hobbiests here.
<re_irc> <@f​irefrommoonlight:m​atrix.org> And consider teh consequences of a misconfigured pin: "Is this a sublte error that will waste people's time and be tough to find?" "Will the first step when button 1 isn't working is to check the wiring and config for PA5 it's connected to?" "Will the product short out and break?"
<re_irc> <@f​irefrommoonlight:m​atrix.org> newam: That's a neat inference
<re_irc> <@f​irefrommoonlight:m​atrix.org> Overall, I think a lot could be done in these packages by describing who they're for, what the intent is. Your classic "Requiremetns and Specifications"
<re_irc> <@f​irefrommoonlight:m​atrix.org> In my projects, the type checks make no sense because they make parts of the code messy, and a misconfigured pin will be obvious. But maybe that's not the intent here
<re_irc> <@f​irefrommoonlight:m​atrix.org> That's really neat
<re_irc> <@f​irefrommoonlight:m​atrix.org> I wonder if it's arduino spillover? Or Raspberry Pi? (Implied by i2cdev?)
<re_irc> <@f​irefrommoonlight:m​atrix.org> It fits with the F1 and F4 being the most stalked about STM32s here, due to the cheap dev boards
<re_irc> <@n​ewam:m​atrix.org> Maybe? I am curious too, but only have theories.
<re_irc> <@n​ewam:m​atrix.org> I think there is also a lot of embedded developers doing rust on weekends for projects; we never touch rust at my workplace, but there are quite a few of us who use it for personal projects.
<re_irc> <@f​irefrommoonlight:m​atrix.org> That's where I fit
<re_irc> <@f​irefrommoonlight:m​atrix.org> Well, non-coding day job, and have a side-hustle selling electronics
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'm suspicious there's a larger contingent of embedded Rust users that dont' get involved with the OSS community
tokomak has quit [Read error: Connection reset by peer]
<re_irc> <@n​ewam:m​atrix.org> firefrommoonlight: That could also be true. There is a tonnnn of red tape at my work to get involved in any OSS project; you have to schedule a meeting with the OSS team, give an hour-long presentation about what/why you want to contribute, no exceptions (even if you are just fixing a typo in the docs).
<re_irc> <@d​irbaio:m​atrix.org> Hahaha embedded-hal and nb are there in the top unprofessional 🤣
<re_irc> <@l​achlansneff:m​atrix.org> burrbull: You're right, looking at it again, this is sick
<re_irc> <@l​achlansneff:m​atrix.org> I don't think I saw it in the diff, but might have missed it, are the Pins still different types, or do they use const generics to differentiate?
<re_irc> <@l​achlansneff:m​atrix.org> e.g. `Pin<'A', 5, AF5>`
<re_irc> <@b​urrbull:m​atrix.org> We have 3 type of pins. Basic are different types
<re_irc> <@b​urrbull:m​atrix.org> You can take erased and partially erased pins by `downgrade` and `downgrade2` from basic
<re_irc> <@l​achlansneff:m​atrix.org> Great, sounds awesome
<re_irc> <@b​urrbull:m​atrix.org> jamesmunns: https://github.com/stm32-rs/stm32f4xx-hal/pull/328
<re_irc> <@d​irbaio:m​atrix.org> if USART automatically changes the pins to the right state (#327), why not get rid of typestates completely? :P
<re_irc> <@d​irbaio:m​atrix.org> (assuming all drivers do that, not just usart)
<re_irc> <@d​irbaio:m​atrix.org> also what's the purpose of partially degraded pins? usually oyu eitehr want degraded or not
<re_irc> <@t​halesfragoso:m​atrix.org> adamgreig: That's where `Unborrow` comes in
<re_irc> <@t​halesfragoso:m​atrix.org> But better still ask for the pins so you can configure them
<re_irc> <@t​halesfragoso:m​atrix.org> And then drop the type after that
<re_irc> <@a​damgreig:m​atrix.org> how do you handle NoSck etc pins in that case?
<re_irc> <@d​irbaio:m​atrix.org> impl SckPin for PA4, PB3, PC1, .., NoPin
<re_irc> <@d​irbaio:m​atrix.org> so that a driver can take T: SckPin
<re_irc> <@d​irbaio:m​atrix.org> and then do
<re_irc> <@d​irbaio:m​atrix.org> if let Some(pin) = sck_pin.pin() {
<re_irc> <@d​irbaio:m​atrix.org> pin.configure_af(4);
<re_irc> <@d​irbaio:m​atrix.org> }
<re_irc> <@a​damgreig:m​atrix.org> but the AF depends on the pin
<re_irc> <@a​damgreig:m​atrix.org> (well, the (pin, peripheral) combination, anyway)
<re_irc> <@d​irbaio:m​atrix.org> yeah that's simplified
<re_irc> <@d​irbaio:m​atrix.org> the actual trait is
<re_irc> <@d​irbaio:m​atrix.org> ```rust
<re_irc> <@d​irbaio:m​atrix.org> pub trait SckPin<T: Instance>: Pin {
<re_irc> <@d​irbaio:m​atrix.org> fn af_num(&self) -> u8;
<re_irc> <@d​irbaio:m​atrix.org> }
<re_irc> <@d​irbaio:m​atrix.org> it doesn't have optional wired up yet though
<re_irc> <@f​irefrommoonlight:m​atrix.org> dirbaio: I'd considered automatic pin config by periph. Ultimately, I think this is a bad plan for most uses, since it hides config that can be tough to troubleshoot, and there are edge cases where the standard pin config isn't suitable
<re_irc> <@a​damgreig:m​atrix.org> why not have SckPin::into_af that configures the pin when impl for a legit pin and nops when impld for NoPin?
<re_irc> <@d​irbaio:m​atrix.org> > tough to troubleshoot
<re_irc> <@d​irbaio:m​atrix.org> tough if the type system enforces you can only pass the right pins?
<re_irc> <@a​damgreig:m​atrix.org> anyway yea fair enough having the SckPin trait resolve it for you, makes sense
<re_irc> <@a​damgreig:m​atrix.org> shame the AF number can't always be the same for any given peripheral
<re_irc> <@a​damgreig:m​atrix.org> at least when you can pass in NoSck etc it means in those edge cases you can take care of the config yourself
<re_irc> <@t​halesfragoso:m​atrix.org> adamgreig: At least we just scrape them from ST's files
<re_irc> <@f​irefrommoonlight:m​atrix.org> dirbaio: Maybe your I2C line isn't open drain. Or you're checking why a certain pin isn't working right but can't find where you set it up. I think it's best to be explicit with how the pins are set up
<re_irc> <@t​herealprof:m​atrix.org> burrbull: I'm not totally convinced by this change. It might be necessary to useful to use a custom configuration without the `into` implementation magically changing it behind the users back. Or would this automagically turn into a no-op if the user already provided a pin in the correct mode?
<re_irc> <@d​irbaio:m​atrix.org> adamgreig: that'd work too, but it's more stuff in the macro'd impls
<re_irc> <@f​irefrommoonlight:m​atrix.org> I really think you need to write down reasoning of why you're doing the type states before continuing work on this
<re_irc> <@f​irefrommoonlight:m​atrix.org> And what the intended problem they solve is
<re_irc> <@f​irefrommoonlight:m​atrix.org> But Dead horse is dead. Sorry
<re_irc> <@f​irefrommoonlight:m​atrix.org> Agree to disagree
<re_irc> <@b​urrbull:m​atrix.org> therealprof: It does nothing if pin in correct mode
<re_irc> <@f​irefrommoonlight:m​atrix.org> The complexity they hide isn't trivial. And not providing examples or docs of this complexity is a mistake.
<re_irc> <@t​herealprof:m​atrix.org> Interesting. Is this guaranteed by Rust?
<re_irc> <@b​urrbull:m​atrix.org> Of cource. It uses common `From` which is autoimplemented for Self
<re_irc> <@t​herealprof:m​atrix.org> Right, but I wasn't sure whether that is still the case for specialised implementations.
<re_irc> <@b​urrbull:m​atrix.org> But you are rigth. `release` returns pins in alternate mode.
fabic has quit [Ping timeout: 252 seconds]
<re_irc> <@b​urrbull:m​atrix.org> #328 is ready
neceve has joined #rust-embedded
GenTooMan has quit [Ping timeout: 240 seconds]
GenTooMan has joined #rust-embedded
starblue has joined #rust-embedded
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
<re_irc> <@a​damgreig:m​atrix.org> therealprof: no rush but any thoughts on https://github.com/rust-embedded/cortex-m/pull/345 (releasing cortex-m v0.7.3 with the two recent changes)?
<re_irc> <@t​herealprof:m​atrix.org> adamgreig: Sure, let's go for it. Wanna change the date?
<re_irc> <@a​damgreig:m​atrix.org> sure
<re_irc> <@a​damgreig:m​atrix.org> pushed
<re_irc> <@a​damgreig:m​atrix.org> published
<re_irc> <@a​damgreig:m​atrix.org> tagged
<re_irc> <@t​herealprof:m​atrix.org> (y)
<re_irc> <@d​irbaio:m​atrix.org> 🚀
<re_irc> <@d​irbaio:m​atrix.org> > The Delay struct now offers direct delay_us() and delay_ms() methods
<re_irc> <@d​irbaio:m​atrix.org> without having to go through the embedded-hal traits
<re_irc> <@d​irbaio:m​atrix.org> Oh that's cool! :D
<re_irc> <@d​irbaio:m​atrix.org> in line with the "e-h is only for drivers, impls can have infallible inherent methods" thing
<re_irc> <@a​damgreig:m​atrix.org> robyoung: cortex-m 0.7.3 released with those fixes for building it on native non-x86 hosts
<re_irc> <@a​damgreig:m​atrix.org> dirbaio: yep, firefrommoonlight's recent work
<re_irc> <@a​damgreig:m​atrix.org> nice to do a small simple cortex-m release really
starblue has quit [Ping timeout: 240 seconds]
<re_irc> <@a​damgreig:m​atrix.org> can't wait to discover how i've somehow broken every cortex-m-using device on the planet again though 😅
* re_irc @a​damgreig:m​atrix.org glances at c-m-rt...
<re_irc> <@y​atekii:m​atrix.org> hah, now I know who to blame for all my bugs!
<re_irc> <@a​damgreig:m​atrix.org> 🎯
<re_irc> <@f​irefrommoonlight:m​atrix.org> dirbaio: With that change, HAL maintainers can remove Delay modules and use cortex-m instead
<re_irc> <@f​irefrommoonlight:m​atrix.org> I've made this change on my end
<re_irc> <@d​irbaio:m​atrix.org> hehehe
<re_irc> <@d​irbaio:m​atrix.org> end user has to know the core freq though, right?
<re_irc> <@f​irefrommoonlight:m​atrix.org> Reduces fragmentation
<re_irc> <@f​irefrommoonlight:m​atrix.org> Yep
<re_irc> <@d​irbaio:m​atrix.org> which is something that the hal should know if it's done rcc setup
<re_irc> <@f​irefrommoonlight:m​atrix.org> I do it with a `clock_cfg.systick()` method. Not sure what the other HAL apis are
<re_irc> <@f​irefrommoonlight:m​atrix.org> Yea
<re_irc> <@d​irbaio:m​atrix.org> nice
<re_irc> <@a​damgreig:m​atrix.org> you should check it's accurate though
<re_irc> <@f​irefrommoonlight:m​atrix.org> What do you mean?
<re_irc> <@a​damgreig:m​atrix.org> oh, wait, sorry
starblue has joined #rust-embedded
<re_irc> <@a​damgreig:m​atrix.org> I was thinking of asm::delay
<re_irc> <@a​damgreig:m​atrix.org> but the Delay impl using systick is fine
<re_irc> <@f​irefrommoonlight:m​atrix.org> Yea. Adding an ASM::delay is always an option
<re_irc> <@f​irefrommoonlight:m​atrix.org> I tried at one pt; don't remember why I abandoned it
<re_irc> <@a​damgreig:m​atrix.org> it doesn't guarantee accuracy, it will delay "at least" the number of cycles
<re_irc> <@a​damgreig:m​atrix.org> but it can be (many) more
<re_irc> <@f​irefrommoonlight:m​atrix.org> That might be why!
<re_irc> <@f​irefrommoonlight:m​atrix.org> Anecdotally the systick delay feels accurate to the second
<re_irc> <@f​irefrommoonlight:m​atrix.org> Probably far better (?)
<re_irc> <@f​irefrommoonlight:m​atrix.org> I guess it depends on your oscillator
<re_irc> <@a​damgreig:m​atrix.org> yes
<re_irc> <@a​damgreig:m​atrix.org> but pretty much anything you use should feel totally accurate to a human
<re_irc> <@a​damgreig:m​atrix.org> anyway it counts clock cycles so (except for the small number of extra cycles due to it doing some maths and entering/leaving the method) it should be exactly as good as your oscillator
starblue has quit [Quit: WeeChat 2.3]
<re_irc> <@s​ympatron:m​atrix.org> It's not accurate if it's interrupted by interrupts. Then the asm::delay could be much longer and a systick delay would be much more accurate.
<re_irc> <@a​damgreig:m​atrix.org> that too, yea
<re_irc> <@f​irefrommoonlight:m​atrix.org> Another thought on HAL design, after a discussion with newam : I've just followed his example, and featured-gated the EH trait implementations
neceve has quit [Ping timeout: 240 seconds]
<re_irc> <@f​irefrommoonlight:m​atrix.org> adamgreig: Regarding `stm32-ral` - I just looked at this again. Compared to PACs, is this intended to be a nicer user-facing API, for writing code at a lower-level than HAL? Eg, PACs for building HALs on top of, and RAL for writing project code, with a nicer API?
<re_irc> <@a​damgreig:m​atrix.org> why feature-gate the EH traits?
<re_irc> <@a​damgreig:m​atrix.org> re RAL, I guess both, but I wrote it originally with application code in mind
<re_irc> <@n​ewam:m​atrix.org> I did it for a W5500 crate. I made the device a trait that people could implement by providing read_reg/write_reg.
<re_irc> <@n​ewam:m​atrix.org> There's a number of things that can't be done with EH (at the moment); so makes sense to have it optional with default EH implementations provided if desired.
<re_irc> <@n​ewam:m​atrix.org> Brings the dependencies down to zero by default which is nice.
<re_irc> <@a​damgreig:m​atrix.org> but in principle no issue beyond pulling in an extra dependency? do you have it as a default dependency?
<re_irc> <@n​ewam:m​atrix.org> it isn't a default, but that's just preference.
<re_irc> <@n​ewam:m​atrix.org> No issues in principle; I just like to give options for other use-cases that are difficult to capture with the EH (e.g. a share SPI bus)
<re_irc> <@a​damgreig:m​atrix.org> sure, makes sense, was just curious if there was a particular problem always providing the e-h impl too
<re_irc> <@f​irefrommoonlight:m​atrix.org> Feature-gate the EH traits so you don't need the dependency unless you need the traits; it's more of a philosophical decision be clear they're not the primary API; they're opt-in. I'm not sold 100% on it, but leaning that way, and have already made the code change.
<re_irc> <@d​irbaio:m​atrix.org> feature-gating only makes sense if the dep is fat imo
<re_irc> <@d​irbaio:m​atrix.org> and e-h is not fat
<re_irc> <@f​irefrommoonlight:m​atrix.org> That's a good point
<re_irc> <@f​irefrommoonlight:m​atrix.org> And was my initial reaction
<re_irc> <@f​irefrommoonlight:m​atrix.org> I'm leaning 60% on this being the right approach
<re_irc> <@a​damgreig:m​atrix.org> it does also make sense if you are releasing a 1.0 crate and don't want a <1.0 dependency
<re_irc> <@a​damgreig:m​atrix.org> but in general it seems like a pretty slim dependency
<re_irc> <@f​irefrommoonlight:m​atrix.org> Re RAL: if used as an underlying layer, what are your thoughts on RAL vs SVD-generated PACs?
<re_irc> <@f​irefrommoonlight:m​atrix.org> For application-layer, RAL seems like the winner
<re_irc> <@a​damgreig:m​atrix.org> I'd be interested in seeing how well it worked, I think the current inability to abstract over registers might make some HAL operations more annoying than they could otherwise be
<re_irc> <@a​damgreig:m​atrix.org> I'd like to revisit the concept at some point for sure but there's a lot of other experimentation in this space now anyway I guess, like the various svd2rust mods and also the metapac stuff the embassy folks are working on
<re_irc> <@f​irefrommoonlight:m​atrix.org> I have `eh` as an optional dependency, that's only pulled in if you use the `embedded-hal` feature
<re_irc> <@f​irefrommoonlight:m​atrix.org> But as you and dirbaio said, it's a very light dep
<re_irc> <@f​irefrommoonlight:m​atrix.org> So not a big deal
<re_irc> <@a​damgreig:m​atrix.org> in principle I don't see why it couldn't work and indeed my own per-project small HALs use it
<re_irc> <@f​irefrommoonlight:m​atrix.org> To avoid a conflation: You can actually use EH SPI etc traits without worrying about bus sharing; that's more an issue of regblock owning than traits-vs-native. Ie, you can easily take `&mut S`, where S is the EH trait
<re_irc> <@n​ewam:m​atrix.org> firefrommoonlight: Yeah, I made it optional on a peripheral crate, it is difficult to make a concrete type that accounts for shared SPI bus'; no problem there for the HAL crates.
<re_irc> <@n​ewam:m​atrix.org> Also feature gating becomes a lot less painful for users with the docs.rs features to highlight what features are required to enable what code; e.g.
<re_irc> <@f​irefrommoonlight:m​atrix.org> In the past, I've forked EH drivers to borrow SPI etc instead of own. In some cases, got PRs merged; in other cases didn't and used forks. Currently, I do the SPI etc writes directly in my application code, to make it easier to troubleshoot, and ensure the functionality I need is there. Ie simpler, and...
<re_irc> ... more functional, but I had to spellunk the datasheets myself
<re_irc> <@f​irefrommoonlight:m​atrix.org> Rahix's shared-bus is nice too, but IMO there's a smell when a bus is being owned, since buses are by nature multi-device
<re_irc> <@f​irefrommoonlight:m​atrix.org> While owning a timer reg block for example, doesn't seem wrong
<re_irc> <@f​irefrommoonlight:m​atrix.org> newam: I agree on the docs. And in general, Trait-first APIs can make the docs tough to read
<re_irc> <@f​irefrommoonlight:m​atrix.org> eg: https://docs.rs/stm32f4xx-hal/0.9.0/stm32f4xx_hal/spi/struct.Spi.html
<re_irc> <@f​irefrommoonlight:m​atrix.org> Doesn't really show you how to use SPI
<re_irc> <@n​ewam:m​atrix.org> firefrommoonlight: Eh, I would disagree with this one; you need some sort of ownership to track who is using the bus at the very least.
<re_irc> <@f​irefrommoonlight:m​atrix.org> https://docs.rs/stm32-hal2/0.2.9/stm32_hal2/spi/struct.Spi.html This docs page, where the underlying struct does similar things, shows the actual fns without digging
<re_irc> <@f​irefrommoonlight:m​atrix.org> I've dealt with the ownership tracking by rust's limit on one &mut ref at a time
<re_irc> <@d​irbaio:m​atrix.org> firefrommoonlight: you can easily share an SPI bus with a RefCell
<re_irc> <@f​irefrommoonlight:m​atrix.org> Yep - I've been doing that!
<re_irc> <@d​irbaio:m​atrix.org> no need to fork HAls
<re_irc> <@f​irefrommoonlight:m​atrix.org> Oh I see waht you're saying - nice approach. I've been using RefCell since I often need SPI in interrupts
<re_irc> <@d​irbaio:m​atrix.org> nor drivers
<re_irc> <@d​irbaio:m​atrix.org> struct MySPI<'a>(&'a RefCell<HalSpi<...>>)
<re_irc> <@d​irbaio:m​atrix.org> impl embedded_hal::blocking::spi for MySpi {..}
<re_irc> <@d​irbaio:m​atrix.org> then you can give MySPI to multiple drivers
<re_irc> <@f​irefrommoonlight:m​atrix.org> That's a great idea
<re_irc> <@f​irefrommoonlight:m​atrix.org> Would have done it previously if I'd known!
<re_irc> <@d​irbaio:m​atrix.org> if you want it to be Send use `&'a Mutex<RefCell<HalSPI>>>`
<re_irc> <@d​irbaio:m​atrix.org> that's kinda what `shared-bus` does, although it's a bit overengineered imo
<re_irc> <@n​ewam:m​atrix.org> dirbaio: Mutex is specific to the target (or execution framework) though :/
<re_irc> <@n​ewam:m​atrix.org> Works well for HAL crates, less so for peripheral crates.
<re_irc> <@d​irbaio:m​atrix.org> driver crates just take a `T: blocking::spi::Transfer` as usual
<re_irc> <@d​irbaio:m​atrix.org> it's the user that chooses to pass an impl that allows sharing
<re_irc> <@n​ewam:m​atrix.org> Good point.
<re_irc> <@d​irbaio:m​atrix.org> so user will use whatever one that'll work on the current hardware
<re_irc> <@d​irbaio:m​atrix.org> or pass the HAL SPI straight through if no sharing is wanted