dcz has joined #rust-embedded
<re_irc> <@josfemova:matrix.org> Any guide on how to do adc reads in atsamd51/21 MCU's?
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
<re_irc> <@9names:matrix.org> Have you looked at the examples in the atsamd hal repo?
<re_irc> <@josfemova:matrix.org> 9names: Yup but missed that one it seems, thnx a lot
<re_irc> <@sajattack:matrix.org> josfemova: we have a dedicated room at #atsamd-rs_community:gitter.im if you have more questions
dcz has quit [Ping timeout: 265 seconds]
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
<re_irc> <@jorgeig:matrix.org> For all the STM32WL fans: I'm trying to get LoRaWAN to work on an STM32WL, first try is here: https://github.com/jorgeig-space/lorawan-wl
<re_irc> <@jorgeig:matrix.org> it doesn't work yet, of course 😆
dcz has joined #rust-embedded
fabic has joined #rust-embedded
dfgweb has quit [Quit: Leaving]
gsalazar has joined #rust-embedded
gsalazar_ has joined #rust-embedded
gsalazar has quit [Ping timeout: 265 seconds]
fabic has quit [Ping timeout: 260 seconds]
gsalazar_ has quit [Remote host closed the connection]
gsalazar_ has joined #rust-embedded
<karlp> man, these svd's have got some absolute garbage in them sometimes don't they...
<re_irc> <@firefrommoonlight:matrix.org> Haha yeah. Props to the PAC team for all the work fixing them
<karlp> it makes you feel like you've gotten a lot done, but there's a lot to be said for transcibing by hand from the ref man after having done it this way too...
<re_irc> <@adamgreig:matrix.org> Yea... when I started I really thought all the work would just be adding the enumerated values (the permitted values for each field and their names and descriptions)
<re_irc> <@adamgreig:matrix.org> The ability to also make structural changes was secondary and seemed like it would be more occasional, ha ha
fabic has joined #rust-embedded
<re_irc> <@adamgreig:matrix.org> Problem with doing it by hand is the unloved peripherals probably wouldn't ever get done, there are just thousands and thousands of fields and it's pretty boring doing the hdmi-cec when you'll never use it
<re_irc> <@adamgreig:matrix.org> At least the svds have something for them I guess
<karlp> true, in libopencm3 the unloved periphs can take a long time to turn up, but at least when we have a peripheral, it's done.
<karlp> in this stm32wb svd, tim17 has completely garbage register offsets, instead of jsut being tim17. so it _looks_ like it works, because all the code is there, but it doesn't. so yeah, yay, got tim17 code from the svd, but... is that really better than nothing?
<re_irc> <@firefrommoonlight:matrix.org> irc_libera_karlp:psion.agg.io: That becomes untenable across MCUs, or even across the breadth or peripherals and their functionality
<re_irc> <@adamgreig:matrix.org> In that specific case no, but at least completely wrong peripherals like that are very rare
<karlp> yar, I know. and also, it's esaier to find people to fix a broken SVD periph than to create the raw periph.
<re_irc> <@firefrommoonlight:matrix.org> Doing the reg access by hand is fine for a specific project where you know what peripherals you're using, and what functionality of the periphs.
<re_irc> <@firefrommoonlight:matrix.org> I like the PAC approach because it doesn't tie you to those specifics
<re_irc> <@firefrommoonlight:matrix.org> IIRC I parched that WB tim17 thing, and agg merged it
<karlp> i've nearly finished, i'll send it when it's done.
<re_irc> <@firefrommoonlight:matrix.org> Ah - those offset errors were my mistake, which Adam fixed. The SVD regs were missing or something for those regs
<re_irc> <@firefrommoonlight:matrix.org> Unfortunately, I think the most practical approach is playing wack-a-mole with these. When you hit a problem, make an issue and/or PR. The more-common MCUs and periphs will be fixed faster
<karlp> be nice if ST was at all interested in fixing the svds themselves...
<karlp> firefrommoonlight who are you on github?
fooker has quit [Ping timeout: 240 seconds]
<re_irc> <@firefrommoonlight:matrix.org> David OConnor
<karlp> thanks
fooker has joined #rust-embedded
fabic has quit [Remote host closed the connection]
fabic has joined #rust-embedded
DepthDeluxe has joined #rust-embedded
fabic has quit [Ping timeout: 265 seconds]
<re_irc> <@richarddodd:matrix.org> Question about embassy: is it poll a future without awaiting it? I'm writing some stuff over SPI and I want to fill the next buffer while the previous one is DMA'd. I want to set the DMA off, but only await it after the next one is ready.
<re_irc> <@dirbaio:matrix.org> nothing guarantees the DMA will be started with a single poll, or that DMA is even in use (an SPI impl could do CPU copy, needing one poll per byte)
<re_irc> <@dirbaio:matrix.org> if you want to run things concurrently, it's better to use `join` or `select`
<re_irc> <@dirbaio:matrix.org> or maybe two tasks with a channel as a "queue of buffers to send". More flexible but more heavyweight
<re_irc> <@richarddodd:matrix.org> I'll try making a 'fake' async fn that does the cpu work, and then joining on them both. Hopefully the executor will organise things reasonably.
<re_irc> <@richarddodd:matrix.org> It's not a lot of CPU work, but would be nice to run concurrently with the DMA if possible.
<re_irc> <@dirbaio:matrix.org> if one fut is waiting on DMA and the other does CPU work it'll probably work if you put the DMA one first in the join/select, so that it gets polled first
<re_irc> <@dirbaio:matrix.org> if you really really want to make sure DMA gets priority then yo ucan do that with two executors + two tasks, spawning the "SPI send" in the higher prio executor
<re_irc> <@dirbaio:matrix.org> but it's probably not worth it
<re_irc> <@richarddodd:matrix.org> An alternative is changing the semantics of Spim::write to say "will make as much progress as possible without blocking, including starting DMA". Then you could do your other work and await at the end.
<re_irc> <@richarddodd:matrix.org> (And Read/Transfer if you wanted to go down that route)
<re_irc> <@dirbaio:matrix.org> yeah but that's leaking implementation details
<re_irc> <@dirbaio:matrix.org> the Future contract is just "you must poll every time you get a wake"
<re_irc> <@dirbaio:matrix.org> so the async SPI trait contract is "write() returns a future that does a SPI write"
<re_irc> <@dirbaio:matrix.org> that implies that the future MUST be polled according to the Future trait contract
<re_irc> <@dirbaio:matrix.org> ie it's NOT ok to poll it just once and expect that to kick off the whole write
<re_irc> <@richarddodd:matrix.org> You'd still have to poll it. It's just that it might have made more progress before the first poll.
<re_irc> <@richarddodd:matrix.org> ie. how you use it wouldn't change,
<re_irc> <@dirbaio:matrix.org> ah you mean making Spim::write itself start the write, NOT the first poll?
<re_irc> <@richarddodd:matrix.org> Yesss
<re_irc> <@richarddodd:matrix.org> If it can be done in a wait-free way
<re_irc> <@richarddodd:matrix.org> if not, then do nothing.
<re_irc> <@dirbaio:matrix.org> this violates the convention that async fns do not do any work, only polling the future does work
<re_irc> <@richarddodd:matrix.org> The function isn't async: it returns a future.
<re_irc> <@richarddodd:matrix.org> I guess if you want it to be like an async fn, you couldn't do any work
<re_irc> <@dirbaio:matrix.org> it's not an async fn because you can't have async fns in traits yet, otherwise it would be
<re_irc> <@dirbaio:matrix.org> it's "conceptually" still an async fn
<re_irc> <@richarddodd:matrix.org> Ok so the question is: do we gain anything from it being a fn that does nothing until polled that we would lose if it set off a DMA?
<re_irc> <@dirbaio:matrix.org> no, it's the other way around
<re_irc> <@dirbaio:matrix.org> even if you specify in the SPI trait contract "write() may start the write before the first poll"
<re_irc> <@dirbaio:matrix.org> impls might not do so. For example an impl that does CPU copy can't do so (or maybe it can, but just the first byte)
<re_irc> <@dirbaio:matrix.org> so a generic driver can't rely on that anyway
<re_irc> <@richarddodd:matrix.org> ahhh I see I think
<re_irc> <@dirbaio:matrix.org> so it's not very useful
<re_irc> <@dirbaio:matrix.org> and
<re_irc> <@dirbaio:matrix.org> d if you specify in the SPI trait contract "write() MUST start the write before the first poll" then you're ruling out impls that do CPU copy which is not
<re_irc> <@richarddodd:matrix.org> so it's fine for my use case where I know my hardware, but if someone wants to write a generic driver and they want the parallelism, they need to use another method?
<re_irc> <@dirbaio:matrix.org> if you do the "poll once" thing you're violating the Futures cotract
<re_irc> <@dirbaio:matrix.org> in the case of embassy-nrf it'll work because how it works internally (it does start DMA on the first poll)
<re_irc> <@dirbaio:matrix.org> but you're relying on these implementation details
<re_irc> <@dirbaio:matrix.org> which 1. may change at any semver-minor release
<re_irc> <@dirbaio:matrix.org> and 2. may not work at all with other HALs
<re_irc> <@richarddodd:matrix.org> Ok lemme argue this another way: we do it as an implementation detail on nrf.
<re_irc> <@richarddodd:matrix.org> hmm maybe not
<re_irc> <@richarddodd:matrix.org> hmmm. it would be nice if a generic driver could achieve this parallelism (where possible)
<re_irc> <@dirbaio:matrix.org> it can, with poll/select
<re_irc> <@dirbaio:matrix.org> not with "poll just once"
<re_irc> <@richarddodd:matrix.org> dirbaio:matrix.org: Separate question: How do you do a bit-banging impl? Do you not need to have interrupt priority so you can get the timing right? How does that play with the executor?
<re_irc> <@richarddodd:matrix.org> Like, you can't rely on the work getting poll'd in time.
<re_irc> <@dirbaio:matrix.org> yeah a bitbanging impl would have to use a classic interrupt-driven timer
<re_irc> <@richarddodd:matrix.org> How does the CPU copy work? Is that copying into some small buffer?
<re_irc> <@dirbaio:matrix.org> then just wrap that in a future that gets woken when it's done
<re_irc> <@dirbaio:matrix.org> by "cpu copy" I mean an impl that manually writes to the "DR" registers, not using DMA
<re_irc> <@richarddodd:matrix.org> dirbaio:matrix.org: Yeah I'm definitely not advocating this under any circumstances. :)
<re_irc> <@dirbaio:matrix.org> nrf52 doesn't have such thing in the new DMA-enabled peripherals
<re_irc> <@dirbaio:matrix.org> but it's super common in stm32 and other chips
<re_irc> <@richarddodd:matrix.org> cool thnx
<re_irc> <@dirbaio:matrix.org> there's a "tx buffer empty" interrupt
<re_irc> <@richarddodd:matrix.org> I'm looking forward to playing with the GIO on the pi for learning more about protocols like SPI
<re_irc> <@dirbaio:matrix.org> then you have to write data into the DR to push more bytes in the tx buffer
<re_irc> <@dirbaio:matrix.org> so there could be an impl that wires "tx buffer empty" into "wake", and "poll" does the "write into DR"
<re_irc> <@dirbaio:matrix.org> it would suck, it would slow down if polls don't come fast enough
<re_irc> <@dirbaio:matrix.org> DMA is way better
<re_irc> <@dirbaio:matrix.org> but still, it should be allowed by the async Spi/i2c/uart traits contract
<re_irc> <@richarddodd:matrix.org> I might have a go at writing a ST7789 driver for embassy, to see how it goes making it board-agnostic.
<re_irc> <@dirbaio:matrix.org> fun
<re_irc> <@dirbaio:matrix.org> not sure how would it wokr
<re_irc> <@dirbaio:matrix.org> turning the entire embedded-graphics into async is probably not worth it
<re_irc> <@jamwaffles:matrix.org> Wouldn't the iterators it produces work reasonably well with an async driver? I don't think e-g itself needs to be fully async
<re_irc> <@jamwaffles:matrix.org> Maybe it could provide some async stream adapters though?
<re_irc> <@dirbaio:matrix.org> dunno
<re_irc> <@dirbaio:matrix.org> I guess to get it to go faster you want "SPI tx" and "CPU calculating lines/text/whatever" to be done in parallel
<re_irc> <@dirbaio:matrix.org> if the embedded-graphics DrawTarget impl waits for SPI you're not getting that
<re_irc> <@dirbaio:matrix.org> even if it's an "async wait" instead of a "blocking wait"
<re_irc> <@dirbaio:matrix.org> so
<re_irc> <@dirbaio:matrix.org> the embedded-graphics impl would have to "enqueue" the display commands into a pipe in RAM
<re_irc> <@dirbaio:matrix.org> and then a higher-prio task would drain that pipe into SPI with DMA
<re_irc> <@dirbaio:matrix.org> that way you do get parallel "SPI tx" and "CPU drawing stuff"
<karlp> I'm trying to extract functions for code currently in my "init" and running into all sorts of problems with per port types and things, am i missing something basic? https://paste.jvnv.net/view/VZk3v
fabic has joined #rust-embedded
<re_irc> <@dirbaio:matrix.org> karlp: which HAL is it?
<karlp> this is stm32wb, but ~same gpios as l4.
<re_irc> <@richarddodd:matrix.org> dirbaio:matrix.org: I'm just trying to get a method that takes a u8 iterator and writes it to screen. Not even worrying about endianness.
<re_irc> <@dirbaio:matrix.org> karlp: what you want to do is unfortunatley not possible :(
<re_irc> <@richarddodd:matrix.org> I've already got the code - just need to make it generic
<re_irc> <@dirbaio:matrix.org> because `into_pullup_input` is defined for all the individual GPIO pin types with a macro
<karlp> dirbaio: this does not give me warm fuzzies :)
<re_irc> <@dirbaio:matrix.org> and it's not part of any trait
<karlp> this seems common in the stm32 hals, yet decidedly unhelpful?
<re_irc> <@dirbaio:matrix.org> so there's no way to say "I take any type that has a `into_pullup_input` function`, you need a trait for that
<karlp> same with the ports as a whole as far as I can tell?
<re_irc> <@dirbaio:matrix.org> yeah
<re_irc> <@dirbaio:matrix.org> This is why the macro-based gpio sucks
<karlp> there's a GpioExt->Parts that is a trait, so nominally that's what could be passed for the port param,
<re_irc> <@dirbaio:matrix.org> kinda, but the "parts" is an associated type you know nothing about, so you won't be able to get the individual pins out of it either
<karlp> as best I can tell, ~all the periphs on ~all the families are implemented like this, and the "use embassy" solution isn't appealing yet, rust is niche enough...
<re_irc> <@dirbaio:matrix.org> hehe I was about to say that
<re_irc> <@dirbaio:matrix.org> embassy's gpio design doesn't have this problem
<re_irc> <@dirbaio:matrix.org> but yeah
<re_irc> <@dirbaio:matrix.org> everyone keeps copypasting the macro-based GPIO around
<re_irc> <@dirbaio:matrix.org> :(
<karlp> so... spaghettic code all in the same init function... like all the examples in all the repos...
<re_irc> <@richarddodd:matrix.org> dirbaio: I don't think a driver is feasible atm. The problems I had were around actually initializing: the driver needs to have some control over the SPI config, and also the Pin config for chip select etc. I think it would need generic versions of `embassy_nrf::gpio::Output::new`.
<re_irc> <@richarddodd:matrix.org> Was interesting to look at it :)
<re_irc> <@dirbaio:matrix.org> karlp: you *can* avoid copypasting the gpio setup in your code, but with a macro instead of a generic function
<re_irc> <@dirbaio:matrix.org> MOAR macros
<re_irc> <@dirbaio:matrix.org> that's the problem with macro-based HALs, they don't work well with generics/traits so then user code needs more macros :(
<karlp> dirbaio: yeah, I thought of that, but none of that makes me want to use rust.
fabic has quit [Ping timeout: 252 seconds]
<karlp> if I wanted to get into template meta programming, I just... wouldn't get into that.
<re_irc> <@dirbaio:matrix.org> hehehe
<re_irc> <@dirbaio:matrix.org> totally understandable!
<re_irc> <@dirbaio:matrix.org> :(
<re_irc> <@richarddodd:matrix.org> Rust (the language) is really good for newcomers now, but go back to 2014 when I started and it was definitely not! I think the embedded community will get there eventually as well.
<re_irc> <@richarddodd:matrix.org> It will probably take a rethink of the HALs
<re_irc> <@richarddodd:matrix.org> (IMO)
<re_irc> <@dirbaio:matrix.org> I find it quite disappoiting that people see stm32-rs, nrf-rs etc as the "official" HALs and then don't want to even consider using other HALs
<re_irc> <@dirbaio:matrix.org> they're *not* "official" as in they're not a rust-embedded working group project
<re_irc> <@dirbaio:matrix.org> it's just an opensource project that was the first and had the luck to grab the stm32-rs name
<re_irc> <@dirbaio:matrix.org> and as seen above this is hindering embedded rust adoption
<karlp> well, if I go by active forks, and commits, it's also indiciative of community size.
<karlp> embassy is "you're going to like coroutines right?" which is not for everyone, right off the bat,
<re_irc> <@dirbaio:matrix.org> embassy started out as "let's make an async runtime for embedded"
<re_irc> <@dirbaio:matrix.org> for that to be useful, it needed "stm32 HALs that support async"
<karlp> and beyond that it's a couple of one person shows? Sure, they're rust, so they're awesome, and there's some really good code around, but... I mean, starlightmoon's "hal2" looks like a nice idea, but it's a one person show with a handful of users.
<re_irc> <@dirbaio:matrix.org> first attempt was to build `embassy-stm32f4` on top of `stm32f4xx-hal`, etc etc for each family
<karlp> I'm not really looking for a new project to build foundations, I was hoping that I could use rust as a serious alternative to c+freertos.
<re_irc> <@dirbaio:matrix.org> it was soon clear that that was NOT going to be maintainable: macro mess AND copypaste for each stm32 family
<re_irc> <@therealprof:matrix.org> I think const generics provide a way out of macro hell... Look at how small the current gpio instantiation macro in `stm32f4xx-hal` is now: https://github.com/stm32-rs/stm32f4xx-hal/blob/979ff1555f79e3e268a600caa5c43b8d3de95217/src/gpio.rs#L592-L630
<re_irc> <@dirbaio:matrix.org> so the project shifted to "OK let's make an `embassy-stm32` HAL from scratch, fixing the technical decisions that led to the current stm32xxxx-hal state"
<re_irc> <@dirbaio:matrix.org> AND while we're at it, make `embassy-stm32` support async AND blocking operation, because once you setup all the scaffolding to support all families etc, adding blocking support costs nothing
<re_irc> <@dirbaio:matrix.org> so you *can* use embassy-stm32 without async (without coroutines)
* karlp runs into more errors in the svd.
<re_irc> <@dirbaio:matrix.org> I'm not very convinced of the F4 const-generics gpio either :S
<re_irc> <@dirbaio:matrix.org> it still has copypaste for full/erased pins
<re_irc> <@dirbaio:matrix.org> 300 lines of From impls
<re_irc> <@dirbaio:matrix.org> and has 3 (or more?) ways to change mode
<re_irc> <@dirbaio:matrix.org> using From/Into, using into_xxxx methods, using the closure-based with_mode
<re_irc> <@dirbaio:matrix.org> and the const generics make it so that `Pin<_, 'Z', 123>` is a valid type even though `PZ123` is not a thing
<re_irc> <@dirbaio:matrix.org> it's 2126 lines total
<re_irc> <@therealprof:matrix.org> Is it perfect? No, but it's a lot better than what we had in the past and could be used as a foundation of a generic GPIO driver... (sans the legacy stuff).
<re_irc> <@therealprof:matrix.org> And it shows that improvements are possible without having to reinvent the wheel...
<re_irc> <@dirbaio:matrix.org> if the wheel is broken it HAS to be reinvented
<re_irc> <@dirbaio:matrix.org> having 15 HALs with everything copypasted from each other is broken
<re_irc> <@dirbaio:matrix.org> it's not maintainable
<re_irc> <@dirbaio:matrix.org> PRs are stuck for months because maintainers (understandably) don't have time to review the same thing 15 times
<re_irc> <@dirbaio:matrix.org> improvements to one HAL stay in that one HAL the contributor personally uses (such as the F4 gpio)
<re_irc> <@dirbaio:matrix.org> because why would that contributor do 15x the work of porting that to 15 copypasted HALs?
<re_irc> <@therealprof:matrix.org> I don't think there was a good solution in the past which is why all the copy-pasta exists. I agree it's not maintainable but as I said, with const generics we now have better ways to address this and in a backwards compatible way.
<re_irc> <@dirbaio:matrix.org> const generics is not the solution
<re_irc> <@dirbaio:matrix.org> const generics add new problems such as the PZ123 thing
<re_irc> <@therealprof:matrix.org> It is part of the solution because you maintain the efficiency of a direct implementation without the cognitive and maintenance overhead of a multiple thousand lines long macro.
<re_irc> <@dirbaio:matrix.org> embassy unifies all STM32 HALs without const generics
<re_irc> <@dirbaio:matrix.org> and it doesn't have the PZ123 problem
<re_irc> <@dirbaio:matrix.org> nor the AF200 problem
<re_irc> <@thejpster:matrix.org> What's the PZ123 thing?
<re_irc> <@dirbaio:matrix.org> if you do `struct Pin<const PORT: char, const PIN: u8>`, then `Pin<'Z', 123>` is a valid type, when it shouldn
<re_irc> <@dirbaio:matrix.org> same as `AlternateFunction<const AF: u8>`, you can have AF200 which makes no sensse
<re_irc> <@dirbaio:matrix.org> the stm32-rs problems aren't caused by lack of const generics
<re_irc> <@thejpster:matrix.org> I see.
<re_irc> <@thejpster:matrix.org> What does embassy do then?
<re_irc> <@dirbaio:matrix.org> `trait Pin { fn port() -> u8, fn pin() -> u8 }`
<re_irc> <@dirbaio:matrix.org> then generate `PA1, PA2...` singletons, impl Pin for them
<re_irc> <@dirbaio:matrix.org> also do `struct AnyPin { pin_port: u8 }`, impl Pin for it
<re_irc> <@dirbaio:matrix.org> then you build everything on top of Pin
<re_irc> <@dirbaio:matrix.org> `struct Input<P: PIn>`, impls InputPin
<re_irc> <@dirbaio:matrix.org> `struct Output<P: PIn>`, impls OutputPin
<re_irc> <@dirbaio:matrix.org> etc
<re_irc> <@dirbaio:matrix.org> - no `PZ123` problem
<re_irc> <@dirbaio:matrix.org> - No copypaste between concrete `PA1` and type-erased `AnyPin`, everything such as`Input` and `Output` etc Just Works with both
<re_irc> <@thejpster:matrix.org> So the pin mode is a type containing the pin, rather than having a pin containing the mode as a ZST?
<re_irc> <@dirbaio:matrix.org> yep
<re_irc> <@dirbaio:matrix.org> `PA1` represents ownership of PA1, in an "unconfigured" state
<re_irc> <@thejpster:matrix.org> How do you deal with IP block versioning?
<re_irc> <@thejpster:matrix.org> As in F4 has GPIO v4 and F3 has GPIO v1.3, or whatever
<re_irc> <@dirbaio:matrix.org> `Input<PA1>` represents owneship of PA1, configured as input
<re_irc> <@dirbaio:matrix.org> and you can create an `Input` with a `&mut PA1` too if you want to use it as input only temporarily
<re_irc> <@dirbaio:matrix.org> GPIO is identical in all stm32's except F1
<re_irc> <@dirbaio:matrix.org> but for other stuff
<re_irc> <@dirbaio:matrix.org> there's cfg's to pull in the right driver
<re_irc> <@dirbaio:matrix.org> the source of truth is these yamls https://github.com/embassy-rs/stm32-data/blob/main/data/chips/STM32F030CC.yaml#L622
<re_irc> <@dirbaio:matrix.org> so you don't need 1000s of handwritten lines to wire up everything in Rust
<re_irc> <@dirbaio:matrix.org> these yamls are generated from XMLs from stm32cube, so they're correct (they're MUCH more reliable than SVDs)
theJPster has joined #rust-embedded
theJPster has quit [Changing host]
theJPster has joined #rust-embedded
<re_irc> <@dirbaio:matrix.org> once you have that, you write impls for UARTv1, UARTv2 and GPIO
<re_irc> <@dirbaio:matrix.org> and everything gets wired up automatically according the yamls
theJPster has left #rust-embedded [#rust-embedded]
<re_irc> <@dirbaio:matrix.org> which GPIO pins are usable for which USARTx in which AF, etc
<re_irc> <@dirbaio:matrix.org> and boom, you get USART support for ALL stm32 chips
<re_irc> <@dirbaio:matrix.org> it's wayyyyyyy more maintainable
<re_irc> <@jamesmunns:matrix.org> I'm going to start streaming to do an update on the PowerBus stuff, probably more hardware than firmware this week, but feel free to come hang out if that's your kind of thing:
<re_irc> <@jamesmunns:matrix.org> Off topic:
<re_irc> <@jamesmunns:matrix.org> https://youtu.be/1qF0x7jpfs0
<re_irc> <@dirbaio:matrix.org> but
<re_irc> <@dirbaio:matrix.org> it gets dismissed as "reinventing the wheel" 🤷‍♂️
<re_irc> <@lulf_:matrix.org> dirbaio:matrix.org: I think this part is undercommunicated and we can do a better job with examples of how to use it without the embassy “runtime”
<re_irc> <@dirbaio:matrix.org> yeah, we could do better "marketing"
<re_irc> <@lulf_:matrix.org> I do websites this week 😅
<re_irc> <@dirbaio:matrix.org> what's embassy? "async for embedded" or "next-gen embedded hals"?
<re_irc> <@dirbaio:matrix.org> (that as part of being "next gen", support async in addition to the classic blocking)
<re_irc> <@dirbaio:matrix.org> also therealprof I *would* work on contributing stuff to stm32-rs to unify the HALs to make them maintainable if you didn't dismiss my work as "reinventing the wheel"
<re_irc> <@dirbaio:matrix.org> the reason why I'm doing the work on embassy instead of stm32-rs is I don't feel it's welcome in stm32-rs, with you as a maintainer dismissing it
<re_irc> <@lulf_:matrix.org> Though I have little experience with existing HALs, I find the “peripheral version centric” structure very sensible when I see how easily one can reuse gpio, spi etc implementations across the different stm32 families with barely adding any special code for each.
<re_irc> <@dirbaio:matrix.org> stm32-rs needs two things
<re_irc> <@dirbaio:matrix.org> 1. unifying the HALs
<re_irc> <@dirbaio:matrix.org> 2. cleaning up the HALs (mostly changing from ubermacros to generics)
<re_irc> <@dirbaio:matrix.org> doing 2 without doing 1 first is a giant waste of time, it's literally 15x the work
<re_irc> <@dirbaio:matrix.org> and doing 1 HAS to be a "clean break": start a new HAL with a structure that accomodates per-IP-version organization, then port over all the functionality until it has caught up with the legacy HALs
<re_irc> <@dirbaio:matrix.org> there's no way to do that while maintaining backwards compatibiltiy
<re_irc> <@dirbaio:matrix.org> the wheel HAS to be reinvented
<re_irc> <@therealprof:matrix.org> dirbaio:matrix.org: You're interpreting the world in your own unique way. Nothing I can say will stop you from misrepresenting me and my words so I'm not going to even try and give up.
<re_irc> <@firefrommoonlight:matrix.org> I tried patching the stm32yxx HALS and moved on when my issues and PRd went ignored for weeks-months. Started fresh when it became the only viable option
<re_irc> <@firefrommoonlight:matrix.org> A less discussed downside is their code is generally poorly documented
<re_irc> <@firefrommoonlight:matrix.org> Ie not something you can easily QC against a RM. And have more code related to obfuscating abstractions than documented reg writes
<re_irc> <@dirbaio:matrix.org> therealprof: as a stm32 maintainer: do you agree the stm32yxx-hals have to be unified, yes or no?
<re_irc> <@firefrommoonlight:matrix.org> They will never be suitable for a commercial or otherwise serious project without ground-up rewrites and leadership changes
<re_irc> <@therealprof:matrix.org> Yes, I agree. And I mentioned it some minutes ago.
<re_irc> <@dirbaio:matrix.org> okay, we're on the same page on that
<re_irc> <@therealprof:matrix.org> And BTW: I am one of *many* maintainers of *parts* of the repos in the org.
<re_irc> <@dirbaio:matrix.org> next question: how do you propose we proceed with the unifying
<re_irc> <@dirbaio:matrix.org> firefrommoonlight has explored making a unified HAL on top of the existing stm32-rs PACs
<re_irc> <@dirbaio:matrix.org> embassy has explored making a unified HAL by unifying the PACs first
<re_irc> <@therealprof:matrix.org> People are using the legacy interfaces, any approach that will preserve those interfaces will work.
<re_irc> <@firefrommoonlight:matrix.org> Btw, even though I took a diff approach, I think the Embassy approach of unifying PACs for STM32 is great. The only reason I don't use it is never having been comfortable with Async with workflows
<re_irc> <@dirbaio:matrix.org> how are you going to preserve the interfaces if stm32f4xx-hal and stm32f7xx-hal GPIO interfaces are completely incompatible?
<re_irc> <@therealprof:matrix.org> As mentioned the F4 has been refactored in a backwards compatible way and also as mentioned I see that as a possible options to come to generic GPIO driver.
<re_irc> <@firefrommoonlight:matrix.org> Probably from being burned in JS and Python and no giving it a fait shake in Rust/embedded
<re_irc> <@dirbaio:matrix.org> okay, another example, the H7 hal handles peripheral `new()` in a completely different way than other HALs
DepthDeluxe has quit [Ping timeout: 260 seconds]
<re_irc> <@therealprof:matrix.org> No doubt there different APIs out there.
<re_irc> <@dirbaio:matrix.org> so
<re_irc> <@dirbaio:matrix.org> you're saying the unified HAL must be a drop-in replacement for *all* legacy stm32yxx-hals
<re_irc> <@dirbaio:matrix.org> backwards-compatible with every single different API flavor?
<re_irc> <@therealprof:matrix.org> In a way.
<re_irc> <@lulf_:matrix.org> That seems a bit contradictory... they don't even have the same interface even today
<re_irc> <@dirbaio:matrix.org> that's not feasible
<re_irc> <@dirbaio:matrix.org> and you know it
<re_irc> <@therealprof:matrix.org> The only thing I know is that this is not a greenfield situation.
<re_irc> <@dirbaio:matrix.org> and it also strikes me as contradictory with the fact that almost every stm32-rs release is semver-major
<re_irc> <@dirbaio:matrix.org> stm32f4xx-hal is at 0.9, so there's been 8 semver-breaking releases
<re_irc> <@lulf_:matrix.org> therealprof:matrix.org: I'm curious why you say that. Afaict, there are not many 'production' users of rust embedded anyway?
<re_irc> <@therealprof:matrix.org> Any new PAC is semver incompatible, so yes.
<re_irc> <@dirbaio:matrix.org> and the const-generics GPIO will have to be released as 0.10 because it is NOT semver-compatible even if you say "the F4 has been refactored in a backwards compatible"
<re_irc> <@therealprof:matrix.org> lulf_:matrix.org: As was pointed out a few pages ago, people keep on using stm32-rs HALs instead of going embassy or other alternatives despite them being arguably better.
<re_irc> <@almindor:matrix.org> i don't think we need to be backwards compatible, I'd for one love things like GPIO "stack" be unified over hals even if it meant a breaking change from existing stuff
<re_irc> <@lulf_:matrix.org> therealprof:matrix.org: Embassy HALs haven't really stabilized until recently, and I think we can do a better way of showing its use with non-async as well. Maybe that will help. I think it suffers a bit with users wanting to use whatever seems the most official
<re_irc> <@almindor:matrix.org> we're not even on v1+ backwards compatibility is meaningless right now (provided you keep the versioning logical)
<re_irc> <@ryan-summers:matrix.org> As both a maintainer, contributor, and production user of stm32h7xx-hals, I can confirm we really would like backward compat of any rewrites, and rust is definitely used in production.
<re_irc> <@ryan-summers:matrix.org> It's also unfair to put all of this on therealprof
<re_irc> <@firefrommoonlight:matrix.org> H7xx is easily the nicest
<re_irc> <@dirbaio:matrix.org> it's backwards compat XOR unified hal
<re_irc> <@ryan-summers:matrix.org> That being said, I think the best approach is to just go greenfield for now and see if you can make something better
<re_irc> <@almindor:matrix.org> when you say backwards compatible, let's first define that. Are we talking at level of embedded-hal traits, or at level of individual xyz-hal crates and their "organizational" logic? (e.g. accessing GPIOs from resources and so on)
<re_irc> <@ryan-summers:matrix.org> If that proves true, the ecosystem starts shifting. The problem is, there's already a lot of apps using the existing HALs that won't be able to merge without significant financial investment
<re_irc> <@ryan-summers:matrix.org> And a lot of companies won't want to do that
<re_irc> <@dirbaio:matrix.org> the new HAL would impl the e-h traits of course
<re_irc> <@ryan-summers:matrix.org> That's only relevant on the interface to e.g. peripheral drivers
<re_irc> <@dirbaio:matrix.org> the breakages would be in the part that's not covered by the e-h traits
<re_irc> <@dirbaio:matrix.org> gpio/uart/spi/i2c setup etc
<re_irc> <@ryan-summers:matrix.org> From the perspective of an app using stm32h7xx-hal as a dep, the e-h isn't super relevant
<re_irc> <@ryan-summers:matrix.org> I still would need to rewrite our whole repo to use the new APIs
<re_irc> <@ryan-summers:matrix.org> and I don't think I could sell that
<re_irc> <@ryan-summers:matrix.org> So we'd probably just keep using the existing stm32h7xx-hal for example
<re_irc> <@ryan-summers:matrix.org> Unless, as was mentioned, it _was_ a perfect replacement, which we've already stated is pretty much impossible
<re_irc> <@dirbaio:matrix.org> is gpio+peripheral setup such a high % of your code?
<re_irc> <@ryan-summers:matrix.org> So at this point, given it's not a greenfield implementation, I think you need to be okay with taking the hit of diverging
<re_irc> <@ryan-summers:matrix.org> It's definitely non-trivial
<re_irc> <@therealprof:matrix.org> lulf_:matrix.org: Nothing is really officially blessed by the WG. The existing crates have earned their reputation by existing for some time and being usable "enough", alternative approaches will have to do the same. Stability is a definitely a reputation concern, it's hard to build trust when reinwhenting the wheel is the name of the game.
<re_irc> <@dirbaio:matrix.org> therealprof: newcomers see "stm32-rs" and they go "Okay, that's THE rust stm32 hal"
<re_irc> <@ryan-summers:matrix.org> From Quartiq's perspective, all of the code in https://github.com/quartiq/stabilizer/tree/master/src/hardware would have to be rewritten
<re_irc> <@firefrommoonlight:matrix.org> ryan-summers:matrix.org: Yea - I don't use EH at all in my projects, and it's feature-gated in HAL
<re_irc> <@almindor:matrix.org> the e-h traits only help with drivers IMO
<re_irc> <@almindor:matrix.org> not board unifying at all
<re_irc> <@ryan-summers:matrix.org> ^ And that's what it was designed for
<karlp> well, I'm going to push up the last of what I've managed to fix on my way, but I've got no more time to put into this experiment. I was _very_ happy with some of how this has gone, but too much has been too much pain.
<re_irc> <@dirbaio:matrix.org> also you could mix stm32-unified-hal with stm32h7xx-hal
<re_irc> <@almindor:matrix.org> for board/mcu level stuff I think we should implement a new "hal"
fabic has joined #rust-embedded
<re_irc> <@dirbaio:matrix.org> having a "graceful transition period"
<re_irc> <@dirbaio:matrix.org> you can definitely mix stm32-rs and embassy hals today
<re_irc> <@ryan-summers:matrix.org> You could, but it's just more work on our end honestly
<re_irc> <@dirbaio:matrix.org> using unsafe to steal stuff, just making sure you don't use the same peripheral with both at the same time
<re_irc> <@therealprof:matrix.org> dirbaio:matrix.org: Uhm, stm32-rs contains a wild assortment of things. I have zero issue with you putting an "embassy-hal" in there.
<re_irc> <@ryan-summers:matrix.org> I think you need to be okay with the fact that not everyone would transition
<re_irc> <@dirbaio:matrix.org> therealprof:matrix.org: such "thing I would put there" would be the unified hal, which you just said MUST be backwards compatible with all HALs
<re_irc> <@dirbaio:matrix.org> so you DO have issues with it
<re_irc> <@almindor:matrix.org> is the problem unifying something like "I need physical pin2 of this thing" or are we talking something else?
<re_irc> <@dirbaio:matrix.org> ryan-summers:matrix.org: yeah, but at least the rust embedded would have a solid value proposition to newcomers that are not already invested in the legacy HALs
<re_irc> <@therealprof:matrix.org> dirbaio:matrix.org: Again you're misrepresenting me.
<re_irc> <@ryan-summers:matrix.org> I would argue it already does
<re_irc> <@dirbaio:matrix.org> the current stm32-rs HALs are driving people away from Rust
<re_irc> <@ryan-summers:matrix.org> I would soundly disagree personally
<re_irc> <@ryan-summers:matrix.org> No one is forced to use a HAL if they don't like it
<re_irc> <@ryan-summers:matrix.org> In fact in C, you often never have a HAL in the first place
<re_irc> <@lulf_:matrix.org> How about creating something like stm32-rs/stm32-unified-hal
<re_irc> <@ryan-summers:matrix.org> So the HAL is purely value added, and you can work around it and work register-level whenever you want anyways
<re_irc> <@ryan-summers:matrix.org> I do that a lot when HALs don't expose all the stuff I need
<re_irc> <@therealprof:matrix.org> lulf_:matrix.org: I kind of just proposed that. 😉
<re_irc> <@dirbaio:matrix.org> ryan-summers:matrix.org: see the conversation with karlp above 🤷
<re_irc> <@lulf_:matrix.org> Ok, so what I mean by that is that == embassy-stm32
<re_irc> <@dirbaio:matrix.org> and it's a recurring thing in this channel
<re_irc> <@lulf_:matrix.org> and just move it there
<re_irc> <@therealprof:matrix.org> lulf_:matrix.org: Yes.
<re_irc> <@lulf_:matrix.org> wdyt about that dirbaio ?
<re_irc> <@lulf_:matrix.org> maybe it would increase adoption/visibility for people wanting to take part
<re_irc> <@lulf_:matrix.org> (i haven't given a thought how easy/hard it would be to move it yet)
<karlp> ryan: I cna't really just skip the hal, not without a lot more investment. I need the bluetooth stack, which depends on the hal, but the hal causes pain. I could rewrite chunks of it, but the goal was "look, rust is advanced, I can write my _application_ and _not_ spend my time rewriting hal-type-layering foundational blobs"
<re_irc> <@dirbaio:matrix.org> - What about the older HALs? Are they deprecated? Which one should newcomers use? Which one should contributors contribute to?
<re_irc> <@dirbaio:matrix.org> - What about the decision making process? For example embassy-stm32 has typestate-less GPIO, which therealprof has spoken very strongly against that in the past.
<re_irc> <@almindor:matrix.org> could we maybe split this problem into parts and document the issues separately? I feel like a lot will just get lost here if we keep it matrix only
<re_irc> <@therealprof:matrix.org> dirbaio:matrix.org: Nope, those will continue to exist.
<re_irc> <@dirbaio:matrix.org> The problem is not whether the hal is under the embassy org or the stm32-rs org
<re_irc> <@therealprof:matrix.org> > - What about the decision making process? For example embassy-stm32 has typestate-less GPIO, which therealprof has spoken very strongly against that in the past.
<re_irc> <@therealprof:matrix.org> You have free reign about everything.
<re_irc> <@almindor:matrix.org> well I see a couple mentioned 1. GPIO traits/structure 2. deprecation strategy/making onboarding new users easier 3. similar mcu hal unification strategy
<re_irc> <@dirbaio:matrix.org> The problem is newcomers trying to use the legacy stm32xxx-hals and getting frustrated
<re_irc> <@dirbaio:matrix.org> newcomer learning effort will still go to stm32xxx-hal and get wasted
<re_irc> <@dirbaio:matrix.org> contributor effort will still go to stm32xxx-hal and get wasted
<re_irc> <@almindor:matrix.org> I'm just proposing to split this into subissues make something more permanent like github issues and keep a civil discussion there, at least on the higher level, otherwise I feel like this will just fizz out and nothing will get done
<re_irc> <@therealprof:matrix.org> dirbaio:matrix.org: You said it's a visibility problem because everything unter stm32-rs is automatically blessed. You might as well take the advantage. 😛
<re_irc> <@dirbaio:matrix.org> yeah but there's still the old HALs with more stars and more downloads and no "this HAL is deprecated" message
<re_irc> <@therealprof:matrix.org> (and of course I shouldn't make too many promises here since it's Adams org)
<re_irc> <@dirbaio:matrix.org> so newcomers will still use those
<re_irc> <@lulf_:matrix.org> Re: the existing HALs, whatever people want to maintain is their choice, also what users want to use. However, having the unified hal in the stm32-rs org I think signals that this is an stm32-rs community thing and not async only etc, and also lower the barrier for trying it out
<re_irc> <@thejpster:matrix.org> dirbaio:matrix.org: The current stm32 HALs are driving me away from STM32.
<re_irc> <@lulf_:matrix.org> Ultimately, examples and docs are important as well
<re_irc> <@dirbaio:matrix.org> the purpose of unifying the HALs is avoiding wasting effort in maintaining 15 HALs in parallel
<re_irc> <@therealprof:matrix.org> dirbaio:matrix.org: I told you that those HALs need to remain compatible. But if embassy HALs are really the greatest thing since sliced bread then people will quickly adopt it and everything HALs will be declared deprecated in favour of the better approach.
<re_irc> <@dirbaio:matrix.org> if you add the new unified HAL but don't deprecate the old HALs now you're mainaining 16 HALs in parallel
<re_irc> <@firefrommoonlight:matrix.org> Hey, this isn't a giant problem
<re_irc> <@dirbaio:matrix.org> it does NOT solve the problem
<re_irc> <@therealprof:matrix.org> dirbaio:matrix.org: No, I'm maintaining 3 HALs, and you maintain 1 HAL.
<re_irc> <@lulf_:matrix.org> dirbaio:matrix.org: sure, people are free to use their time as they wish. I think unified-hal will demonstrate its advantages over time
<re_irc> <@dirbaio:matrix.org> it's still wasted effort
<re_irc> <@dirbaio:matrix.org> you+me could maintain 1 HAL
<re_irc> <@therealprof:matrix.org> dirbaio:matrix.org: I somehow doubt that.
<re_irc> <@firefrommoonlight:matrix.org> I'm not convinced TRP maintains any HALs
<re_irc> <@dirbaio:matrix.org> if there's N people using rust+stm32, this one HAL would get the work from N people
<re_irc> <@dirbaio:matrix.org> currently we have 15 HALs getting the work from N/15 people
<re_irc> <@henrik_alser:matrix.org> What amazes me is how these inconsistencies be a reason to drive people away from embedded rust while the C competition has NONE of the above and is way behind in this regard, despite having 40 years head start
<re_irc> <@dirbaio:matrix.org> henrik_alser: with the C STM32 HALs you can write a function that configures a pin by number. With the Rust stm32xxx-hals you have to write a macro or copypaste the code for each pin
<re_irc> <@dirbaio:matrix.org> they're WORSE than C's in many aspects
<re_irc> <@firefrommoonlight:matrix.org> henrik_alser Good point. I think there just isn't much interest in Rust embedded atm
<re_irc> <@dirbaio:matrix.org> and these aspects are immediately and painfully obvious to people trying to switch from C to Rust
<re_irc> <@firefrommoonlight:matrix.org> And I expect that to change gradually over the next few years
<re_irc> <@lulf_:matrix.org> dirbaio:matrix.org: I share your frustration in this, but again people are free to decide what they want to spend time on. We just have to make stm32-unified-hal seem like the better way to spend the time, but that also takes time :)
<re_irc> <@henrik_alser:matrix.org> For me the experience was the opposite
<re_irc> <@lulf_:matrix.org> anyone got any extra time to hand me, let me know :)
<re_irc> <@dirbaio:matrix.org> so
<re_irc> <@henrik_alser:matrix.org> I can’t imagine going back to my ~20 years with C
<re_irc> <@henrik_alser:matrix.org> Ymmv
<re_irc> <@henrik_alser:matrix.org> :D
<re_irc> <@firefrommoonlight:matrix.org> IMO Dirbaio and I have already solved this
<re_irc> <@dirbaio:matrix.org> so, therealprof agrees the stm32 hals should be unified, agrees they're not maintainable in the current state, but doesn't want to deprecate them in favor of a unified HAL
<re_irc> <@firefrommoonlight:matrix.org> And the answer is just to incrementally improve functionality and documentation on these, for Async and non respectively
<re_irc> <@dirbaio:matrix.org> "make a stm32 unified HAL" is a solved problem
<re_irc> <@thejpster:matrix.org> dirbaio: I feel you'll have more success here if you stop dragging other people
fabic has quit [Remote host closed the connection]
<re_irc> <@thejpster:matrix.org> work the problem, not the people
<re_irc> <@dirbaio:matrix.org> There's 2 problems
<re_irc> <@dirbaio:matrix.org> 1. make a unified hal => SOLVED
<re_irc> <@dirbaio:matrix.org> 2. Newcomers to Rust see 3+ competing HALs and the ones that looks "more official" are the worst maintained => NOT SOLVED
<re_irc> <@dirbaio:matrix.org> I'm trying to solve problem 2
<re_irc> <@thejpster:matrix.org> OK, so where do newcomers see this?
<re_irc> <@dirbaio:matrix.org> google "stm32f4 rust", you get stm32f4xx-hal
<re_irc> <@firefrommoonlight:matrix.org> Sounds like a SEO issue!
<re_irc> <@thejpster:matrix.org> OK, so all you have to do is do better in the google rankings
<re_irc> <@firefrommoonlight:matrix.org> I think the answer is to publish content demonstrating what you built
<re_irc> <@thejpster:matrix.org> Hell, buy stm32-rust.org and write all about it
<re_irc> <@dirbaio:matrix.org> that would be quite hostile IMO
<re_irc> <@firefrommoonlight:matrix.org> Publish source code for a project you made, either a DIY demo or something commercial
<re_irc> <@dirbaio:matrix.org> the solution is: have the ecosystem agree on one HAL, invest efforts in make that the best one, deprecate the others
<re_irc> <@dirbaio:matrix.org> the thing is I gain nothing from people using embassy instead of stm32-rs hals
<re_irc> <@firefrommoonlight:matrix.org> I think competition is important
<re_irc> <@firefrommoonlight:matrix.org> For drawing out the best features and new ideaa
<re_irc> <@thejpster:matrix.org> but that's the problem. you can't force what other people do.
<re_irc> <@dirbaio:matrix.org> Why would I invest effort in SEO and making shady domains trying to position embassy as the "official stm32 rust" project?
<re_irc> <@dirbaio:matrix.org> I'm pointing out that this is bad for the *rust embedded ecosystem*
<re_irc> <@dirbaio:matrix.org> therefore it's in the *rust embedded ecosystem*'s interest to fix it
<re_irc> <@dirbaio:matrix.org> it's not bad *for me*
<re_irc> <@dirbaio:matrix.org> I'm shipping stuff with embassy just fine
<re_irc> <@firefrommoonlight:matrix.org> I don't mean SEO in a manipulative way. I mean publish content. Get those backlinks legitimately
<re_irc> <@dirbaio:matrix.org> why would I invest time in that? As I said, I have zero commercial interes in people using embassy
<re_irc> <@xiretza:xiretza.xyz> thejpster:matrix.org: aww man, stm32.rs is already taken by ST
<re_irc> <@dirbaio:matrix.org> I have commercial interest in embassy *existing* so I can use it to ship stuff, that's it
<re_irc> <@dirbaio:matrix.org> so I bring it up to the wider rust embedded community
<re_irc> <@dirbaio:matrix.org> but the community wants to do nothing about it
<re_irc> <@henrik_alser:matrix.org> (My point was, how come newcomers have so much higher demands for the Rust ecosystem while at the same time having no problems with all the crap associated with C?)
<re_irc> <@dirbaio:matrix.org> the ones that have the "authority" (hard authority or soft authority) to improve this don't
<re_irc> <@dirbaio:matrix.org> henrik_alser: as I said the current HALs are worse than C's in many things
<re_irc> <@firefrommoonlight:matrix.org> dirbaio:matrix.org: This is all you need!
<re_irc> <@dirbaio:matrix.org> yeah
<re_irc> <@firefrommoonlight:matrix.org> At least, that's how I look at it. I have a robust platform that let's me build whatever I want
<re_irc> <@dirbaio:matrix.org> but then people will keep coming to this channel with stm32-rs hal issues
<re_irc> <@dirbaio:matrix.org> struggling with the ubermacros
<re_irc> <@firefrommoonlight:matrix.org> For existing, planned, and non-yet-planned projects. I couldn't do what I needed with what existed, so I fixed that
<re_irc> <@dirbaio:matrix.org> and they'll give up and tell their engineering teams and bosses "Rust embedded sucks, let's stick with C"
<re_irc> <@dirbaio:matrix.org> and once you hear that from a coworker
<re_irc> <@dirbaio:matrix.org> rust is dead for you
<re_irc> <@dirbaio:matrix.org> you won't look "oh maybe it was the *HAL* that sucked, not Rust, and oh look! there are other HALs!"
<re_irc> <@firefrommoonlight:matrix.org> I agree that's a concern. It's easy to conflate the ecosystem with Rust if you're new. It took me a while to separate then
<re_irc> <@dirbaio:matrix.org> you won't try Rust again *at all*
<re_irc> <@thejpster:matrix.org> OK, but why are people finding the 'classic' stm32-hals instead of this new one?
<re_irc> <@thejpster:matrix.org> one answer to that might be the Discovery book.
<re_irc> <@thejpster:matrix.org> Although isn't that changing to use the nRF5x Micro Bit?
<re_irc> <@dirbaio:matrix.org> yep that's a very official "blessing" from the REWG
<re_irc> <@firefrommoonlight:matrix.org> There was a Reddit Rust post yesterday where a newcomer worried Rust's easy dependency management would lead to abuse and bloat. It does! But this isn't a fault in the language; just how some people use it. Solution: Use rust, and don't use dependencies that are bloated it have too many sub deps
<re_irc> <@henrik_alser:matrix.org> dirbaio:matrix.org: I prefer every second of it compared to my WAY longer C history, but maybe it’s just me then :)
<re_irc> <@thejpster:matrix.org> Not really. It was basically the only thing that existed when jorge wrote it
<re_irc> <@dirbaio:matrix.org> henrik_alser: you prefer it now that you've learned all the workarounds with macro tricks and stuff :D
<re_irc> <@dirbaio:matrix.org> yes many (most) things are way better in Rust hals than C hals
<re_irc> <@dirbaio:matrix.org> but the basic things such as GPIO should be "at least as good"
<re_irc> <@dirbaio:matrix.org> something as basic as obtaining the GPIO singletons and configuring 5 pins as exti input without copypasting the same code 5 times
<re_irc> <@xiretza:xiretza.xyz> honestly I prefer typed GPIOs over untyped ones - how often do I really have to select *any* GPIO at runtime?
<re_irc> <@dirbaio:matrix.org> - You have to know what "extension traits" are (GpioExt) to call .split(). You search the docs for GPIOA and you do *not* see `.split()` listed as a method. Discoverability in the docs is *awful*
<re_irc> <@dirbaio:matrix.org> - You have to be fairly proficient in generics to use the typestates
<re_irc> <@almindor:matrix.org> I agree to ^ it was definitely a blocker to me when I started
<re_irc> <@almindor:matrix.org> it's still scary when I switch platforms since each one does it slightly differently
<re_irc> <@dirbaio:matrix.org> - Then you finally get it working for the 5 pins, copypasting the same code 5 times
<re_irc> <@firefrommoonlight:matrix.org> I even forked the nRF HAL to avoid the GPIO syntax
<re_irc> <@dirbaio:matrix.org> - You then want to DRYfy that code, by making a "setup GPIO" function and calling it 5 times. And surprise, YOU CAN'T. AT ALL.
<re_irc> <@dirbaio:matrix.org> You have to write A MACRO
<re_irc> <@thejpster:matrix.org> I agree split/constrait are a terrible API and it is poorly discoverable. I don't, however, have a particular need to set my IO pins in a for loop.
<re_irc> <@firefrommoonlight:matrix.org> Have y'all read the Rust Docs for an Stm32 or nRF GPIO module?
<re_irc> <@thejpster:matrix.org> I much prefer it when the compiler tells me that I've got a pin wrong.
<re_irc> <@dirbaio:matrix.org> Macros are the MOST CURSED thing of Rust. And one of the value propositions of Rust to C devs should be "throw away all the C preprocessor/macro shit because you have a real type system now"
<re_irc> <@dirbaio:matrix.org> and still
<re_irc> <@dirbaio:matrix.org> one of the FIRST things you see with stm32xx-hals is "you can't do this without macros at all"
<re_irc> <@dirbaio:matrix.org> thejpster:matrix.org: you can still get full type-level safety while still not having the giant papercuts I'm describing above
<re_irc> <@thejpster:matrix.org> and still set the I/O pins in a for loop?
<re_irc> <@dirbaio:matrix.org> what do you mean?
<re_irc> <@xiretza:xiretza.xyz> thejpster:matrix.org: yeah, I'm curious how that would work
<re_irc> <@thejpster:matrix.org> dirbaio:matrix.org: ^^
<re_irc> <@thejpster:matrix.org> Can you DRYfy code with the embassy HAL?
<re_irc> <@firefrommoonlight:matrix.org> Someone new to Rust posted this gem of GPIO code yesterday: https://github.com/caemor/epd-waveshare/issues/49#issuecomment-916589039
<re_irc> <@firefrommoonlight:matrix.org> Questions on why GPIO typestates as implemented are unsat!
<re_irc> <@firefrommoonlight:matrix.org> Docs: https://docs.rs/stm32l4xx-hal/0.6.0/stm32l4xx_hal/gpio/index.html
<re_irc> <@dirbaio:matrix.org> thejpster:matrix.org: sure you can
<re_irc> <@dirbaio:matrix.org> ```rust
<re_irc> <@dirbaio:matrix.org> fn main() -> ! {
<re_irc> <@dirbaio:matrix.org> #[cortex_m_rt::entry]
<re_irc> <@dirbaio:matrix.org> info!("Hello World!");
<re_irc> <@dirbaio:matrix.org> - No `.split()`, no need to know what "extension traits" are
<re_irc> <@dirbaio:matrix.org> - No `.into_af6_push_pull(&mut gpioc.moder, &mut gpioc.otyper, &mut gpioc.afrh);`
<re_irc> <@dirbaio:matrix.org> - No copypaste between concrete (PA4) and type-erased (AnyPin) pins
<re_irc> <@thejpster:matrix.org> If I make an SPI object, can I restrict at compile time which pins you can pass to it?
<re_irc> <@dirbaio:matrix.org> Yep!
<re_irc> <@dirbaio:matrix.org> #[cortex_m_rt::entry]
<re_irc> <@dirbaio:matrix.org> fn main() -> ! {
<re_irc> <@dirbaio:matrix.org> ```rust
<re_irc> <@dirbaio:matrix.org> info!("Hello World!");
<re_irc> <@dirbaio:matrix.org> Spi::new takes `impl SckPin` and co
<re_irc> <@henrik_alser:matrix.org> I don’t mean the Rust hals are fine as is and i truly support all these unifying efforts, i just mean i think it’s interesting why C can get away with any crap associated with it while details like this can be a dealbreaker for choosing Rust
<re_irc> <@dirbaio:matrix.org> so if you try to create an SPI with the wrong pins, it won't build
DepthDeluxe has joined #rust-embedded
<re_irc> <@dirbaio:matrix.org> and also interesting: no `.into_alternate_af5()`. SPI switches it to the right AF automatically
<re_irc> <@dirbaio:matrix.org> there's no typestates for AFs at all
<re_irc> <@dirbaio:matrix.org> they're useless, AFs are a SPI implementatino detail
<re_irc> <@dirbaio:matrix.org> you just do "Gimme an SPI with these pins", it does the right thing
<re_irc> <@thejpster:matrix.org> How about if the README for your HAL acknowledges the existences of stm32-rs and links to it, and we ask the stm32-rs devs to put a link in each HAL readme to your "unified" HAL?
<re_irc> <@thejpster:matrix.org> Does that solve the discoverability issue?
<re_irc> <@dirbaio:matrix.org> 🤷
<re_irc> <@dirbaio:matrix.org> maybe
<re_irc> <@thejpster:matrix.org> It doesn't involve deprecation or telling people their code sucks. It just improves discoverability, and allows the best ideas to get the most visibility.
<re_irc> <@dkhayes117:matrix.org> Embedded rust was very hard when I first started and there are still things about it that make me scratch my head. Despite that, I really enjoy using it, and much rather use it than C.
<re_irc> <@dkhayes117:matrix.org> The unifying hal sounds like the way to go.
<re_irc> <@dirbaio:matrix.org> You get people that have been coding in C forever, and probably have even limited C++ experience
<re_irc> <@dirbaio:matrix.org> so they're learning Rust (borrow checker, generics, traits...) AND rust embedded at the same time
<re_irc> <@dirbaio:matrix.org> while the people writing HALs are proficient rust experts
<re_irc> <@dkhayes117:matrix.org> Macros are what I hate the most, except for writing tests
<re_irc> <@dirbaio:matrix.org> current HALs make insanely extensive use of generics, typestates, traits, extension traits (and yeah... macros), which is OK for a rust expert
<re_irc> <@dirbaio:matrix.org> but is absolutely brutal for a newcomer
<re_irc> <@dirbaio:matrix.org> and there's no reason whatsoever to use such advanced things
<re_irc> <@dirbaio:matrix.org> embassy uses only basic generics (traits, generics with trait bounds)
<re_irc> <@dirbaio:matrix.org> and is still equally type-safe as stm32-rs hals
<re_irc> <@dirbaio:matrix.org> No typestates, no extension traits, no const generics, no ubermacros
<re_irc> <@dkhayes117:matrix.org> Riscv could be a good platform for change, much less production users, buy has a high ceiling. At least me thinks so. 😄
<re_irc> <@dirbaio:matrix.org> it seems to me sometimes it's a "when you have a hammer everything looks like a nail" problem
<re_irc> <@dirbaio:matrix.org> Rust has typestates, so let's put typestates in EVERYTHING
<re_irc> <@dirbaio:matrix.org> and now the latest fancy hammer we have is const generics
<re_irc> <@thalesfragoso:matrix.org> Wow, seems a lot of discussion happened, haven't read it, but let me share a quick opinion:
<re_irc> <@thalesfragoso:matrix.org> stm32-rs' HALs probably made the right choices for the time they were written, I started my rust journey with them and it wasn't bad, some boilerplate, but I really don't mind that.
<re_irc> <@thalesfragoso:matrix.org> embassy-stm32 could leveraged all the baggage learned from all of that and decided to turn things upside down, the real change isn't in the HAL itself, far from it, we actually re-used a lot of code from stm32-rs' HALS. The real catch is in svd2rust, by removing singletons, which in turn allowed the HAL to use "freestyle" singletons to not need `split` and family. It also went the route of...
<re_irc> ... "hand-crafted" registers definitions, which allowed the HAL to work better for different devices families
<re_irc> <@dirbaio:matrix.org> so let's rewrite GPIO to use typestates AND const generics!
<re_irc> <@dirbaio:matrix.org> Surely newcomers from C will appreciate that!
<re_irc> <@thalesfragoso:matrix.org> Neither of them sucks
<re_irc> <@thalesfragoso:matrix.org> In the end we just be discussing svd2rust instead of the HAL, because most of the changes in embassy-stm32 were only possible because of that
<re_irc> <@thalesfragoso:matrix.org> Of course, embassy-stm32 also had some good ideas by itself, the `Unborrow` trait that allows for drivers to not store all pin type-states because we don't need to free them, since the user can provide just a borrow instead of owned types
<re_irc> <@thalesfragoso:matrix.org> And some other ideas that maybe aren't a clear win for some people, like the driver configuring the pin itself instead of expecting the user to configure it
<re_irc> <@thalesfragoso:matrix.org> Which means that the driver must de-configure it on drop, otherwise the user don't have the correct pin configured type stated
<re_irc> <@thalesfragoso:matrix.org> Which in turns means that `mem::forget` can leave people a bit confused
<re_irc> <@dkhayes117:matrix.org> dirbaio when you start on RV embassy, I will be happy to help however I can. mabez mentioned some people he knows is working up a new esp32-c3 dev board 😁
<re_irc> <@dirbaio:matrix.org> porting the executor to riscv should be trivial
<re_irc> <@dirbaio:matrix.org> the hart part is async hals
<re_irc> <@thalesfragoso:matrix.org> dirbaio:matrix.org: maybe not the "InterruptExecutor"
<re_irc> <@dirbaio:matrix.org> but there's no reason "async hal that works with embassy" has to be part of the embassy project
<re_irc> <@thalesfragoso:matrix.org> I'm still to understand how interrupts really works on riscv, it seems that it might be different from chip to chip
<re_irc> <@dirbaio:matrix.org> I am definitely planning to look at the esp32-c3 though :D :D
<re_irc> <@dirbaio:matrix.org> I have one in the mail coming
<re_irc> <@newam:matrix.org> thalesfragoso:matrix.org: There is no NVIC/GIC equivalent, so your interrupt controller is always vendor defined. At the lower levels it works the same way.
<re_irc> <@thalesfragoso:matrix.org> yeah, but even the interrupt vector itself seem a bit different and vendor defined
<re_irc> <@newam:matrix.org> Oh, interesting. That would make life difficult.
<re_irc> <@newam:matrix.org> In what ways are they different?
<re_irc> <@thalesfragoso:matrix.org> But don't take me too serious, I didn't dig it too much
<re_irc> <@thalesfragoso:matrix.org> just tried to use riscv-rt for interrupts and got real lost
<re_irc> <@thalesfragoso:matrix.org> and went to read some manuals on the gd32v which probably got me a bit confused w.r.t all this
<re_irc> <@dirbaio:matrix.org> isn't htere a few standard interrupt controller "models"?
<re_irc> <@thalesfragoso:matrix.org> IIRC there was 2 models, yeah
<re_irc> <@dirbaio:matrix.org> so you could add support for each and be "done"?
<re_irc> <@thalesfragoso:matrix.org> anyway, lunch time is over, back to work. But remember, stm32-rs and embassy-stm32 should be friends, and we probably should discuss (again) removing singletons from svd2rust and make it all unsafe, and probably add a pac implementations that behaves like today's pac, so adam can keep not using HALs without needing unsafe everywhere
<re_irc> <@thalesfragoso:matrix.org> or maybe stm32-rs can just change to use stm32-metapac and stm32-data once they're more complete
<re_irc> <@almindor:matrix.org> dkhayes117:matrix.org: I'm definitely open to changes here. The hal is not too complex we should be able to "Test out" some of the new unifying concepts in riscv-land. The SPI change was a big success for example (at least in my book)
<re_irc> <@almindor:matrix.org> as for GPIO I agree that anything outside of Input/Output state is useless, the driver/user will switch to what they need, but that's a separate issue I guess.
<re_irc> <@almindor:matrix.org> for GPIO specifically I think we should consider writing a proposal for the new API. There are a lot of things a good GPIO wrapper should do e.g. `GPIO.pin_physical(usize)` to get a physical pin, or `GPIO.pin_spi_sck(usize)` to get SPIx clock pin etc. We did a lot of these things with macros. I wrote them, and I still hit my head on them
<re_irc> <@almindor:matrix.org> this goes deeper into specific board crates too
<re_irc> <@dirbaio:matrix.org> embassy generates the singletons from the yamls in stm32-data
<re_irc> <@almindor:matrix.org> we could use something like that sure
<re_irc> <@almindor:matrix.org> main thing is to provide the expected interface definition and list of accessors (in this specific case)
<re_irc> <@dirbaio:matrix.org> so you can do a `foreach pin that exists { struct $pin {... } }`
<re_irc> <@dirbaio:matrix.org> but ALWAYS making the codegen'd structs "dumb". JUST the singleton, no functionality
<re_irc> <@dirbaio:matrix.org> so there's no actual "logic" code inside the macro-generated code
<re_irc> <@dirbaio:matrix.org> ONLY one trait impl, then everything else is non-macro code using the traits
<re_irc> <@dirbaio:matrix.org> it's like
<re_irc> <@dirbaio:matrix.org> you take the YAML, which is like a "database" describing the chip
<re_irc> <@almindor:matrix.org> it's sad that traits don't support const fn yet
<re_irc> <@dirbaio:matrix.org> and you "translate" that to the "database" of the rust type system
<re_irc> <@almindor:matrix.org> I mean the yaml approach makes it possible to just do this directly, you could just codegen rust code so it's more readable
<re_irc> <@dirbaio:matrix.org> and then the HAL makes use of that via trait bounds
<re_irc> <@almindor:matrix.org> i just wished we could have trait X { const fn accessor() }
<re_irc> <@dirbaio:matrix.org> yea
<re_irc> <@dirbaio:matrix.org> it's been proposed but it's not likely to happen soon
<re_irc> <@dirbaio:matrix.org> in practice the compiler will inline and const-propagate everything though, so you're not losing performance
<re_irc> <@almindor:matrix.org> true, so on top of the yaml generator we could have things like trait GpioSpiPins, trait GpioI2CPins etc.
<re_irc> <@almindor:matrix.org> combine with const generics and you can get what I described above
<re_irc> <@dirbaio:matrix.org> for example embassy's `Pin` trait has `port*16 + pin`, and everything else is calculated from that
<re_irc> <@dirbaio:matrix.org> to get the register address it needs to do some maths
<re_irc> <@dirbaio:matrix.org> but if you do `.set_high()` on a concrete pin type such as PA5, the compiler inlines everything
<re_irc> <@dirbaio:matrix.org> it ends up compiled as `*CONST_ADDR = const_value`
<re_irc> <@dirbaio:matrix.org> same as the macro-based gpios
<re_irc> <@dirbaio:matrix.org> *you don't need const generics* for this!!
<re_irc> <@dirbaio:matrix.org> let's stop putting const generics in everything just because it's the new shiny hammer we just got :D
<cr1901> This but without a hint of irony
gsalazar_ has quit [Ping timeout: 260 seconds]
<cr1901> The moment you bless a shiny new feature, lots of ppl will use it whether they actually need it or not.
<re_irc> <@dirbaio:matrix.org> I wasn't being ironic
<cr1901> Oh... sorry
<re_irc> <@dirbaio:matrix.org> I legit think typestates are ultra overused (and now const generics)
<re_irc> <@dirbaio:matrix.org> in places where *you don't need them* and make the APIs much harder to learn and unergonomic
<re_irc> <@dirbaio:matrix.org> it's like when Go was new
<re_irc> <@dirbaio:matrix.org> everything was FULL of goroutine/channel spaghetti
<cr1901> (What's a typestate?)
<cr1901> Hard to tell in general, because the reception I saw to const generics was "it was an unmitigated good"
<re_irc> <@dirbaio:matrix.org> it is good for array lenghts
<re_irc> <@dirbaio:matrix.org> it is not good for pin numbers
<re_irc> <@dirbaio:matrix.org> or peripheral addresses
<re_irc> <@dirbaio:matrix.org> which are uses people are legit proposing
<re_irc> <@dirbaio:matrix.org> or even shipping
<re_irc> <@dirbaio:matrix.org> builders are overused too
<re_irc> <@dirbaio:matrix.org> everything you can do with a builder you can do with a `#[non_exhaustive]` Config struct
<re_irc> <@dirbaio:matrix.org> with 5x less lines of code
<cr1901> I'm asking if that's what you meant by >(3:12:54 PM) re_irc: <@dirbaio:matrix.org> I legit think typestates are ultra overused
<re_irc> <@dirbaio:matrix.org> `Pin<Analog>`
<re_irc> <@dirbaio:matrix.org> `Pin<Input<Floating>>`
<re_irc> <@dirbaio:matrix.org> `Pin<Input<PullUp>>`
<re_irc> <@dirbaio:matrix.org> `Pin<Input<PullDown>>`
<re_irc> <@dirbaio:matrix.org> these typestates
<re_irc> <@dirbaio:matrix.org> or stuff like Foo<Initialized>, Foo<Enabled>, Foo<Disabled>
<re_irc> <@dirbaio:matrix.org> *you don't need them at all*
<re_irc> <@xiretza:xiretza.xyz> how are the pin types in embassy defined? every pin does have its own type, right?
<re_irc> <@dirbaio:matrix.org> There's a struct for each pin, like `PA5`, and a type-erased `AnyPin` struct
<re_irc> <@dirbaio:matrix.org> and an `Input<T>` and an `Output<T>` driver, and that's it. No typestates on the pin structs
DepthDeluxe has quit [Ping timeout: 252 seconds]
<re_irc> <@pinealservo:matrix.org> You don't *need* types on pins, either. Wanting various things to be apparent in the type system is a preference that's going to vary. I really like seeing different approaches to satisfying these preferences being explored, but I get really turned off by people talking crap about the alternatives other than their preferred one.
<re_irc> <@almindor:matrix.org> I didn't mean const generics by the numbers I just meant pin numbers as mapped for given use case
<re_irc> <@almindor:matrix.org> so e.g. GPIO.pin_physical(1) becomes GPIO.pin6 or something while GPIO.pin_spi_sck(0) becomes GPIO.pin10
<re_irc> <@almindor:matrix.org> with a generator we could avoid the const number problem to and just opt for something like GPIO.pin_physical_1() etc. it'd make things super straightforward, if not nice to look at
<re_irc> <@dirbaio:matrix.org> yeah, when eg SPI can only use some pins and not others, you need them to be different types
<re_irc> <@almindor:matrix.org> the return type should be the specific actual Pin
<re_irc> <@almindor:matrix.org> so GPIO.pin_physical1() == GPIO.pin5 == GPIO.pin_spi_sck_0() or such
<re_irc> <@dirbaio:matrix.org> you lose compile-time checking if you make all pins `struct Pin { num: u8 }`
<re_irc> <@dirbaio:matrix.org> you do *not* lose compile-time checking by removing the typestates though
<re_irc> <@almindor:matrix.org> no no each pin its own type for things like Spi::new(PINS) where PINS enforces the right combo
<re_irc> <@dirbaio:matrix.org> so imo the sweet spot is "individual type per pin yes, typestates no"
<re_irc> <@almindor:matrix.org> state is useless
<re_irc> <@almindor:matrix.org> each peripheral abstraction or driver should switch their pins to what they need and we should always consider them as unknown state
<re_irc> <@pinealservo:matrix.org> "state is useless" is a bad take, and "each peripheral abstraction or driver should switch their pins" is just not going to fly in all scenarios either. Any simplifying assumptions you make are going to be vehemently disagreed with by people with legitimate use cases. Not saying you shouldn't make them, but you can't expect that you're going to bring everyone along with you.
<re_irc> <@almindor:matrix.org> they can keep using the old hals, I'm not forcing anything
<re_irc> <@dirbaio:matrix.org> State is useless in types
<re_irc> <@dirbaio:matrix.org> Why would you care whether it's `Pin<Input<Floating>>` or `Pin<Input<PullUp>>`?
<re_irc> <@almindor:matrix.org> but it really makes sense to prepare state in the outer context before handing off resources to the user/driver
<re_irc> <@dirbaio:matrix.org> it's an input, you can read from it
<re_irc> <@almindor:matrix.org> s/sense/no sense/
<re_irc> <@dirbaio:matrix.org> same for `Pin<Output<PushPull>>` vs `Pin<Output<OpenDrain>>`
<re_irc> <@almindor:matrix.org> why should the main() be concerned with switching pin5 to "iof0" (named differently on each setup btw) before handing that pin over to Spi::new ?
<re_irc> <@dirbaio:matrix.org> one usecase for distinguising is i2c MUST be opendrain, so in today's HALs typestates are used by the SPI driver to force the user to set the pin to OpenDrain
<re_irc> <@dirbaio:matrix.org> BUT
<re_irc> <@dirbaio:matrix.org> if the i2C driver knows it has to be OpenDrain, why can't it switch it itself?
<re_irc> <@dirbaio:matrix.org> you're forcing the user to write useless boilerplate
<re_irc> <@almindor:matrix.org> yes exactly, that's my whole point
<re_irc> <@dirbaio:matrix.org> it doesn't make the HAL any safer
<re_irc> <@dirbaio:matrix.org> just harder to use
<re_irc> <@almindor:matrix.org> if you're consuming or borrowing (mutably) a resource, it's your playground
<re_irc> <@pinealservo:matrix.org> I'm not saying that's an invalid perspective, I'm just saying it's not the only one.
<re_irc> <@almindor:matrix.org> I think the alternative which is currently "mainstream" was a mistake that just got used too much
<re_irc> <@almindor:matrix.org> this typestate concept is basically a coincidental rustism
<re_irc> <@dirbaio:matrix.org> a proverbial hammer :)
<re_irc> <@pinealservo:matrix.org> I agree that not everyone needs or wants the typestate stuff, so I'm happy that you're working on alternatives.
<re_irc> <@xiretza:xiretza.xyz> not really applicable in this case, but forcing the consumer to do the setup unconditionally means you may do unnecessary work
<re_irc> <@almindor:matrix.org> also AFAIK the typestate is not part of embedded-hal in any form, it's just a strange standard that got adopted by the implementors
<re_irc> <@almindor:matrix.org> copy paste fossil
<re_irc> <@dirbaio:matrix.org> one register write that takes one clock cycle, and only at program startup? it's negligible
<re_irc> <@xiretza:xiretza.xyz> dirbaio:matrix.org: exactly
<re_irc> <@dirbaio:matrix.org> plus how often do you destruct+construct the i2c like that? you usually construct it once, so you're doing the "set as opendrain" once both with and without typestates
<re_irc> <@almindor:matrix.org> if you have a peripheral controller or driver construction in hot path I suspect the design is non-standard at best, but I'm open to being shown a good use case with this kind of problem
<re_irc> <@dirbaio:matrix.org> and if it's such a hot path and you really really need the optimization you'll use the PAC directly
<re_irc> <@almindor:matrix.org> also, in those cases you can code your way out of it by splitting construction from init
<re_irc> <@dirbaio:matrix.org> SPI/i2C construction alerady does many other expensive things that you'll want to get rid of too
<re_irc> <@dirbaio:matrix.org> for example it often calculates baudrates/dividers/frequencies, which often involve expensive divisions
dcz has quit [Ping timeout: 260 seconds]
<re_irc> <@pinealservo:matrix.org> So, a while back, I wrote a bunch of drivers for a family of chips that would eventually get integrated into a project using some 3rd party runtime that I had no access to or information about for about the first half of the project. Turned out that the integration required separating out all the initialization stuff so it could go in the system startup vs. the "driver" interface. If I'd baked either...
<re_irc> ... way into my interfaces, I'd have been up a creek at integration time.
<re_irc> <@dirbaio:matrix.org> if you're creating/destroying your SPI in a hot loop you're gonna have a bad time
<re_irc> <@dirbaio:matrix.org> with or without typestates :D
<re_irc> <@eldruin:matrix.org> hmm I have not followed the discussion, and cannot discuss right now, but that about drivers configuring their own resources seems non-tenable to me. It makes sense that configuring (read: transform/modify the nature of) a resource requires more power/knowledge than merely using it. For me it does not seem obvious at all that a generic piece of software (e.g. a driver) should need to know about how to...
<re_irc> ... configure a pin to be an output. I would rather prioritize code that needs to know _less_, not _more_
<re_irc> <@dirbaio:matrix.org> the "drivers" we're talking about are the in-hal drivers such as i2c, spi, uart
<re_irc> <@dirbaio:matrix.org> stm32f4 i2c driver can change stm32f4 pins to opendrain no problem
<re_irc> <@dirbaio:matrix.org> hal-independent drivers take `T: OutputPin/InputPin` which the user has to manually configure with the HAL, that makes total sense
<re_irc> <@almindor:matrix.org> yes, the states are input/output, any "functional switched pins" are out keeping it simple. any top level driver should be ok with input or output
<re_irc> <@eldruin:matrix.org> ok, I call that MCU peripherals
<re_irc> <@dirbaio:matrix.org> the "mcu peripheral driver"
<re_irc> <@dirbaio:matrix.org> yeah terminology is confusing :D
<re_irc> <@eldruin:matrix.org> alright that makes sense
<re_irc> <@eldruin:matrix.org> anyway the discussion seemed pretty heated
<re_irc> <@dirbaio:matrix.org> that was the stm32 unified HAL, which is something else :D
<re_irc> <@eldruin:matrix.org> I see there are a bunch of people passionate about the success of Rust in embedded here but I think the tone needs to be lowered an inch
<re_irc> <@eldruin:matrix.org> we are all in for the same thing
<re_irc> <@dirbaio:matrix.org> I've been repeatedly accused of "forking by default", "reinventing the wheel" and "not caring about the community" 🤷‍♂️
<re_irc> <@oddstr13:matrix.org> dirbaio:matrix.org: Can confirm, Arduino -> embedded rust is a major pain. I'm longing for the the point where embedded rust is as mature as the Arduino ecosystem!
<re_irc> <@oddstr13:matrix.org> As for which package to pick, I tend to look at downloads, last updated and dependents on crates.io and github.
<re_irc> <@oddstr13:matrix.org> As for promoting the HAL you think is best, just make a good collection of examples to copypasta from. That's how people probably are used to doing things coming from Arduino (or stackoverflow 😆).
<re_irc> <@dkhayes117:matrix.org> I have no pronlem with *reinventing the wheel* if we get a better wheel 🙂
<re_irc> <@oddstr13:matrix.org> dirbaio: and, yes, things like this is downright exhausting when first starting to learn a new language and ecosystem, all the boilerplate 😭
<re_irc> <@almindor:matrix.org> I wonder if peripheral drivers that use GPIO should just take the pins out themselves now :D
<re_irc> <@almindor:matrix.org> Spi::new(p.GPIO) with possibly a "which SPI" selection
<re_irc> <@pinealservo:matrix.org> The "Arduino -> embedded rust" leap is crossing both a language and and abstraction level boundary; we don't really have anything that's aiming to be equivalent to Arduino yet.
<re_irc> <@dirbaio:matrix.org> almindor: that works if SPI2 can only use a fixed set of pins
<re_irc> <@almindor:matrix.org> right, the CS problem
<re_irc> <@oddstr13:matrix.org> almindor: nah, that doesn't sound like a good idea, some chip allows 3+ I2C peripherals on any pins
<re_irc> <@almindor:matrix.org> gt run bb in 20
<re_irc> <@dirbaio:matrix.org> in most MCUs there's at least some choice, like SPI1 CLK can pick 1 out of 4-8 pins
<re_irc> <@dirbaio:matrix.org> and in some there's full choice: in nrf (almost) all peripherals can use any pin for any function
<re_irc> <@pinealservo:matrix.org> Arduino to standard embedded C or C++ can be a pretty daunting leap itself.
<re_irc> <@almindor:matrix.org> the way I rewrote it for the e310x-hal was to split Spi bus from SpiDevice as GrantM11235 suggested, it works nicely
<re_irc> <@therealprof:matrix.org> pinealservo:matrix.org: I don't think "being like Arduino" is a desirable outcome.
<re_irc> <@almindor:matrix.org> anything I saw for C embedded was always terribad
<re_irc> <@almindor:matrix.org> we're leaps ahead already, just a bit tedious at places
<re_irc> <@oddstr13:matrix.org> pinealservo:matrix.org: Keyword here being «yet», I think it should be a goal to get the rust ecosystem up to a state where you could point a noob at it and say it's just as easy to get started as with Arduino, while also being more suited production
<re_irc> <@dirbaio:matrix.org> lol, Arduino does make lots of choices that do sacrifice performance for ease of use
<re_irc> <@almindor:matrix.org> oddstr13:matrix.org: there's a ton of IDE level abstraction in the arduino land, we'd have to either build something like that, or be compatible to it which, I think is unattainable
<re_irc> <@dirbaio:matrix.org> Rust embedded will never be as easy as arduino
<re_irc> <@dirbaio:matrix.org> Well I guess you could make a HAL specifically with the goal of "being as easy as Arduino but in Rust"
<re_irc> <@oddstr13:matrix.org> almindor: I actually think that vscode + embedded rust is getting close to what Arduino was 10-15 years ago
<re_irc> <@dirbaio:matrix.org> but it probably wouldn't be a good hal for "production" use
<re_irc> <@almindor:matrix.org> I'm not sure I want to go where arduino is today tbh. it's just so hazy on what's happening. Similar with things like "freedom studio" from sifive etc.
<re_irc> <@almindor:matrix.org> huge abstractions on top of even bigger "tools" that are super cumbersome and hard to properly understand (when it comes to how it works at least)
<re_irc> <@newam:matrix.org> Arduino is generally not suitable for production because of expensive abstractions to make the hardware sort of work the same (re-labeling pins as 0-13, A0-5 for example). I see rust as a competitor for things like STM32-Cube, Atmel studio, and other vendor-provided C/C++ ecosystems that are suitable for production.
<re_irc> <@newam:matrix.org> I don't think there is anything necessarily wrong about leaving the embedded newcomer problem to projects like Arduino and circuit python.
<re_irc> <@therealprof:matrix.org> "ease of use" is very relative. It's outright oversimplified which causes a ton of hidden issues, especially for uncommon chips.
<re_irc> <@almindor:matrix.org> therealprof:matrix.org: +1, and when you do hit an actual upstream snag you're stuck completely
<re_irc> <@almindor:matrix.org> I think we can get very "easy to start with" if we standardize the "how" of implementing the main embedded-hal for each mcu
<re_irc> <@oddstr13:matrix.org> Well, I guess what I want from Arduino is the ease of getting a project started, an extensive library of examples and so on
<re_irc> <@oddstr13:matrix.org> also the boilerplate stuff, reducing that would be great
<re_irc> <@newam:matrix.org> Rust is pretty much there, no? It took me just as long to get going with Arduino (back in 2009) as it did rust a year ago.
<re_irc> <@newam:matrix.org> That being said I know a lot more now, but it was pretty much install rustup, install probe rs, run example, vs install arduino IDE, run example. One extra step for rust isn't too bad.
<re_irc> <@pinealservo:matrix.org> Arduino being used in production is very much "scope creep"; it was originally intended to help artistic folks put some simple lights and servos in their art projects without having to really dive deep into embedded systems. And I think there's room for something that makes it really easy to do those sorts of things in Rust on top of the base abstractions that'd make porting the higher-level stuff to a...
<re_irc> ... lot of chips feasible.
<re_irc> <@oddstr13:matrix.org> newam:matrix.org: Indeed, This is starting to look like the Arduino examples! :3 https://github.com/embassy-rs/embassy/blob/master/examples/nrf/src/bin/uart.rs
<re_irc> <@pinealservo:matrix.org> A lot of the "magic" of Arduino was just scoping things really narrowly at first and shipping a set of stuff that worked together.
<re_irc> <@pinealservo:matrix.org> You had one MCU family, the base tools to work with it, a bootloader for the MCU, some easy-to-learn abstraction layers over some of the core peripherals, and a template project to start from that assumed you'd be doing really simplistic code. The "Arduino" ecosystem of today happened very gradually over a long period of time.
<re_irc> <@therealprof:matrix.org> True.
<re_irc> <@oddstr13:matrix.org> I guess the main pain-point for embedded rust *right now* is this weird state between embedded-hal 0.2 and 1.0, which bit me enough to put rust on the shelf for a while at least a couple of times now (one component implement one, but the other component implements only the other)
<re_irc> <@oddstr13:matrix.org> for me anyways
<re_irc> <@therealprof:matrix.org> I agree. We should definitely put a lid on and ship it finally.
<re_irc> <@oddstr13:matrix.org> trying to hook up the modem bits of particle boron/argon (some months ago) was very much not fun, and I spent a week getting nothing done and gave up
<re_irc> <@therealprof:matrix.org> It has been simmering for a long time, some things have been discussed and tossed over multiple times.
<re_irc> <@oddstr13:matrix.org> therealprof:matrix.org: I'm aware, been following along for almost a year now (I think)
<re_irc> <@oddstr13:matrix.org> haven't been touching rust in a while, but when usb-uart hit nrf-hal, I couldn't help but play with it some :P
<re_irc> <@oddstr13:matrix.org> here's my playground for that, in case someone are interested in taking a look 🙈 https://github.com/oddstr13/rust-radio-usb-dongle/blob/master/src/main.rs
<re_irc> <@pinealservo:matrix.org> When it comes down to it, industrial embedded systems coding and hobby/prototype Arduino coding are very different use cases, and it's super difficult to design one set of development tools and libraries that are going to serve both of them well. I find it pretty impressive how well the embedded-wg folks have straddled the divide so far, but I think there will eventually need to be some higher-level...
<re_irc> ... thing for hobby stuff once there's more experience with the lower level stuff.
<re_irc> <@oddstr13:matrix.org> (I've messed a bit with the HAL to get async, so it won't run out of the box right now https://github.com/nrf-rs/nrf-hal/pull/355)
<re_irc> <@therealprof:matrix.org> Oooh, 802.15.4.
<re_irc> <@oddstr13:matrix.org> pinealservo:matrix.org: I personally think a good set of *stand-alone* examples will help at least some hobby/prototype people along quite a bit
<re_irc> <@therealprof:matrix.org> 6LoWPAN?
<re_irc> <@oddstr13:matrix.org> therealprof:matrix.org: I'd love ZigBee, but I don't think we have that stack up and running properly yet
<re_irc> <@therealprof:matrix.org> ZigBee is tricky, I'd probably skip that and go straight to Thread.
<re_irc> <@oddstr13:matrix.org> I've got a small stack of IKEA TRÄDFRI stuff up and running with Home Assistant already, and I'd love to be able to get my own custom stuff hooked up to the same mesh
<re_irc> <@oddstr13:matrix.org> Thread is also an alternative, yea, altho I haven't been able to find much more documentation on that either. There's also that new IoT protocol from google and friends, I forget what it's named
<re_irc> <@oddstr13:matrix.org> oh, wait, Thread was the one with a NDA/don't share this file kinda thing to download the specs wasn't it?
<re_irc> <@dirbaio:matrix.org> smoltcp will soon get 6lowpan support! https://github.com/smoltcp-rs/smoltcp/pull/469
<re_irc> <@therealprof:matrix.org> oddstr13:matrix.org: Was called CHiP at some point. No idea what they're at at the moment.
<re_irc> <@dirbaio:matrix.org> Matter
<re_irc> <@oddstr13:matrix.org> therealprof:matrix.org: There was at least one rename, yea >.<
<re_irc> <@therealprof:matrix.org> oddstr13:matrix.org: Uhm, that sounds more like ZigBee.
<re_irc> <@oddstr13:matrix.org> therealprof:matrix.org: nah, ZigBee specs you can't even get without being a organization and joining the work group for a non-insignificant slump of money iirc
<re_irc> <@oddstr13:matrix.org> I could be mixing things up tho
<re_irc> <@oddstr13:matrix.org> Bit tired of the «this totally awesome, "open" standard» that you can't get your hands on without being a corporation
<re_irc> <@therealprof:matrix.org> Strike that. You have to accept an EULA for Thread.
<re_irc> <@oddstr13:matrix.org> therealprof:matrix.org: yep, and the downloaded PDF is plastered with your name.
<re_irc> <@dirbaio:matrix.org> lol
<re_irc> <@therealprof:matrix.org> There's an open implementation but the specification is closed...
<re_irc> <@dirbaio:matrix.org> and you need CeRTiFicaTioN
<re_irc> <@oddstr13:matrix.org> wouldn't take too much to strip all that out, but just gimme a god damn well documented, actually open one that's also used by commercial products
<re_irc> <@ryan-summers:matrix.org> Sounds like USB with VIDs...
<re_irc> <@oddstr13:matrix.org> > «Matter, formerly Project Connected Home over IP (CHIP), is a proprietary, royalty-free home automation connectivity standard.» … «Although the Matter code repository is open-source under the Apache license, the Matter specification is licensed by CSA.»
<re_irc> <@oddstr13:matrix.org> Urgh, yep, yet another not really accessible protocol
<re_irc> <@dkhayes117:matrix.org> Have you heard of Wi-SUN?
<re_irc> <@oddstr13:matrix.org> can't say I have
<re_irc> <@dkhayes117:matrix.org> https://www.silabs.com/wireless/wi-sun
<re_irc> <@therealprof:matrix.org> Matter also has no interest of collaborating with other standardisation organizations. It's pretty much dominated by a fusion of the patent pool and existing implementation of the big whales...
<re_irc> <@dirbaio:matrix.org> matter works on wifi or iee802154+6lowpan, presumably the only "new" layer is the "application" layer
<re_irc> <@therealprof:matrix.org> ... and the management.
<re_irc> <@thejpster:matrix.org> newam:matrix.org: Arduino is not suitable for production because the core is LGPL
<re_irc> <@oddstr13:matrix.org> dkhayes117:matrix.org: I did a quick search, and it looks interesting, but sounds like it's in the same space as LoRaWAN?
<re_irc> <@oddstr13:matrix.org> A few nodes with low frequency/data rate per house kinda thing?
<re_irc> <@oddstr13:matrix.org> What I'm aiming for right now is more of the ZigBee kinda thing, with many devices per room (one per light, heating, sensors, window shutters etc)
<re_irc> <@dkhayes117:matrix.org> There are differences. Its been a while since I looked, there are great talks on both from Moores Lobby podcast
<re_irc> <@thejpster:matrix.org> If they can all hear each other, you can just use Enhanced Shock Burst
<re_irc> <@oddstr13:matrix.org> short-medium range, sensor readings at least once per minute
<re_irc> <@thejpster:matrix.org> Ferrous use it for the Decawave based rust workshops
<re_irc> <@oddstr13:matrix.org> the plan for initial implementation right now was actually something like UKHASnet; simple flood style mesh
<re_irc> <@oddstr13:matrix.org> https://ukhas.net/
<re_irc> <@therealprof:matrix.org> 6LoWPAN? 😉
<re_irc> <@oddstr13:matrix.org> already got a few 868MHz RFM69 radio nodes running that protocol, but it's more suited for lower frequency longer range stuff (same as lora)
<re_irc> <@oddstr13:matrix.org> therealprof:matrix.org: I haven't looked enough into the specifics, but it's certainly been on my radar more than once
<re_irc> <@oddstr13:matrix.org> I'd still need to handle the mesh bit tho, which is what's nice about ZigBee – it's built into the protocol xD
<re_irc> <@therealprof:matrix.org> Yeah, OpenThread provide that on top.
<re_irc> <@therealprof:matrix.org> But you don't necessarily need the mesh if you want to cover one household.
<re_irc> <@jamesmunns:matrix.org> thejpster:matrix.org: The old (Decawave based) ones use 802.15.4 over the UWB radio, the newer ones use 802.15.4 over the 2.4GHz radio built in to the nrf52s
<re_irc> <@jamesmunns:matrix.org> but we just use "raw" 802.15.4 to do point-to-point packet transmission
<re_irc> <@thejpster:matrix.org> oh, my bad
<re_irc> <@jamesmunns:matrix.org> no worries :D
<re_irc> <@jamesmunns:matrix.org> It's been... two years since you gave that training?
<re_irc> <@jamesmunns:matrix.org> (how long has it been since the first Oxidize? 2019?)
<re_irc> <@thejpster:matrix.org> yes, 2019
<re_irc> <@jamesmunns:matrix.org> so yeah, close to 2.5 years
<re_irc> <@oddstr13:matrix.org> therealprof:matrix.org: 4 floors (basement included), people moving around. I could possibly get away with one central master node, but I think it would be more reliable with a mesh topology of sorts.
<re_irc> <@oddstr13:matrix.org> Then we add the fact that I live on a farm, and that there's multiple buildings :P
<re_irc> <@dirbaio:matrix.org> time to implement RPL? 😜
<re_irc> <@oddstr13:matrix.org> not the typical household, and a bunch of space for fun wireless gadgets :3
<re_irc> <@oddstr13:matrix.org> dirbaio:matrix.org: That sounds like a relatively large project :P
<re_irc> <@dirbaio:matrix.org> indeed
<re_irc> <@therealprof:matrix.org> Yeah, I have also 4 floors with concrete floors; good old ZigBee (without repeaters) works just fine.
<re_irc> <@therealprof:matrix.org> In 6LoWPAN you can also increase the reach by throwing in more routers.
DepthDeluxe has joined #rust-embedded
<re_irc> <@oddstr13:matrix.org> therealprof:matrix.org: oh, but you most likely do have repeaters, even if it isn't used much
<re_irc> <@therealprof:matrix.org> No, the devices inbetween are connected to a hard switch and powered on only rarely.
<re_irc> <@therealprof:matrix.org> So no repeating happening. E.g. right now with the kids in bed I can still control the lights just under the roof top. 😉
<re_irc> <@oddstr13:matrix.org> Anything with mains power acts as a repeater (if needed)
<re_irc> <@therealprof:matrix.org> Right, but they're not connected to mains power at the moment. 😉
<re_irc> <@oddstr13:matrix.org> dirbaio:matrix.org: Anyways, this looks like it may be a interesting alternative, thanks for the link!
<re_irc> <@dirbaio:matrix.org> :D
<re_irc> <@dirbaio:matrix.org> help is welcome, even if just testing!
<re_irc> <@dirbaio:matrix.org> It can talk to Linux fine, and the author has successfully tested it against Contiki too :D
<re_irc> <@therealprof:matrix.org> Hm, I just noticed the latest OpenWRT release still has support for the rotting Ci40 hardware...
<re_irc> <@therealprof:matrix.org> dirbaio:matrix.org: Using wireless or Ethernet? Which hardware?
<re_irc> <@dirbaio:matrix.org> to linux using ieee802154_hwsim
<re_irc> <@therealprof:matrix.org> I mean how was Contiki tested, simulator only?
<re_irc> <@dirbaio:matrix.org> Contiki was on real hardware *I think*, on this https://github.com/Zolertia/Resources/wiki/RE-Mote
<re_irc> <@dirbaio:matrix.org> both the smoltcp and contiki nodes
<re_irc> <@dirbaio:matrix.org> it'll be cool to get it up and running on nrf's :D
<re_irc> <@oddstr13:matrix.org> I've got a small stack of nRF52840 devices, so if I could use those to test… :P
<re_irc> <@therealprof:matrix.org> Ah, I know the Re-Mote.
<re_irc> <@adamgreig:matrix.org> omg, I go on holiday for one day 😭
<re_irc> <@therealprof:matrix.org> I do have the abandonware CreatorDev CI40 Kit lying around http://summit.riot-os.org/wp-content/uploads/2016/07/4-Hardware-Session-Imgtec-MIPS-Keno1.pdf
<re_irc> <@oddstr13:matrix.org> adamgreig: haha, welcome back to the 300 messages wall of text! 🙈
<re_irc> <@adamgreig:matrix.org> 💀
<re_irc> <@adamgreig:matrix.org> I'm still on holiday for a week, so please try to restrain yourselves to one fight a day
<re_irc> <@adamgreig:matrix.org> In seriousness, I should clarify that stm32-rs, in addition to obviously not being officially blessed by the wg in any sense, is basically a disparate group of separate projects; (almost) all the hals were started by one person and later asked to move into the org and retained autonomy which I don't interfere with, but I run the PAC project and am the only one with administrative access to the org
<re_irc> <@adamgreig:matrix.org> (started by different people, I should say)
<re_irc> <@adamgreig:matrix.org> So, it's not like there's some cabel behind the scenes deciding anything should be one particular way and enforcing everyone copy and pasted the ubermacros
<re_irc> <@adamgreig:matrix.org> Conversely there's no central planning and the hals developed at different times and more or less independently, which is the cause of the sorts of concerns identified earlier
<re_irc> <@adamgreig:matrix.org> I think it's fair to say they enjoy a first mover advantage in terms of popularity and perception of being the main active hals, but I think that same first mover effect is also why they have a lot of these issues that newer hals are much more easily able to identify and do something about
<re_irc> <@adamgreig:matrix.org> (embassy's stm32 pacs started by ingesting all the stm32-rs svds too, right?)
<re_irc> <@dirbaio:matrix.org> yep
<re_irc> <@adamgreig:matrix.org> I can't imagine successfully doing something like embassy-stm32 back in 2017 or whatever when f1xx-hal and f4xx-hal started; rust didn't even support generating no_std binaries on stable, many stm32 families didn't exist yet, etc etc, the aim was to get support going for just one family as best as people could imagine then
<re_irc> <@adamgreig:matrix.org> These days there are clearly much nicer ways to solve a lot of these problems and support all the stm32 families at once, and maybe it's clearer that it's worth doing too
<re_irc> <@adamgreig:matrix.org> I'm really not involved in the HALs and can't speak for them, all I know about is the PACs and svd2rust side of things, where I agree with thalesfragoso earlier about trying to bring some of the chiptool improvements back upstream
<re_irc> <@adamgreig:matrix.org> If people think the current hals need more unified leadership then perhaps we can work together with their various maintainers to organise something
<re_irc> <@adamgreig:matrix.org> I think their concerns around backwards compatibility are legitimate, the new HALs desires for interoperation and newer designs are good, and it doesn't worry me in the grand scheme of things to have multiple competing HALs either
<re_irc> <@adamgreig:matrix.org> But I appreciate the confusion for newcomers to rust and we could probably do a better job there, one way or another
<re_irc> <@adamgreig:matrix.org> It does seem unfair that people apparently don't have the same confusion between libopencm3 and stcubemx and chibios and freertos despite them all having very different and competing HALs in C, but I think that's just how it is with a new language alas
<re_irc> <@adamgreig:matrix.org> I'm monologuing too much and I don't want to restart the heated arguments from earlier so I'll leave it there I think, with a gentle reminder to everyone to assume good intentions and that we're all working to make embedded rust better
<re_irc> <@thalesfragoso:matrix.org> Tbh the change I proposed to svd2rust was more to allow different HALs to work together (by having a very simple crate just for the singletons shared by different HALs), and not to transform everything into a single HAL implementation
<re_irc> <@adamgreig:matrix.org> 👍 I was wondering if something along those lines could work well, e.g. a stm32-gpio-v1 crate that a bunch of HALs can re-export, as intermediate steps towards reducing code duplication without just outright scrapping everything for a new thing
<re_irc> <@adamgreig:matrix.org> The same model as is used for ethernet and usb and sdmmc etc
<re_irc> <@adamgreig:matrix.org> Certainly becomes much much easier with the new owned peripherals
<re_irc> <@dirbaio:matrix.org> The more I think about the "singletons" crate the more I think it won't work... HALs may want to split things differently
<re_irc> <@dirbaio:matrix.org> embassy splits pins, DMA channels, EXTI lines in the singletons
<re_irc> <@thalesfragoso:matrix.org> Yeah, I was thinking about that, but without it, using two different HALs become unsound :/
<re_irc> <@adamgreig:matrix.org> I guess I more meant having the lack of owned peripherals and just unsafe access
<re_irc> <@dirbaio:matrix.org> that's too opinionated to put in a "blessed singletons crate" to coordinate all HALs
<re_irc> <@dirbaio:matrix.org> ah just for safe PAC use? so it would be one singleton per SVD peripheral?
<re_irc> <@dirbaio:matrix.org> then aren't we back to the problems with the current PAC singletons?
<re_irc> <@adamgreig:matrix.org> dirbaio:matrix.org: You could probably work around it to some extent, like a DMA singleton that gets consumed if you want individual DMA channels instead or whatever, but it's not as clean
<re_irc> <@dirbaio:matrix.org> well, the purpose of pre-splitting was to reduce `.splt()` boilerplate
<re_irc> <@dirbaio:matrix.org> which is very confusing because you need an extension trait to do it, because the singleton is from another crate
<re_irc> <@adamgreig:matrix.org> Use features 🙈
<re_irc> <@dirbaio:matrix.org> you have to do `p.GPIOA.split()`, but you look up the docs for GPIOA (in the PAC) and the `split` methods in nowhere to be seen
<re_irc> <@dirbaio:matrix.org> features won't allow the crate to coordinate HALs that have done incompatible choices...
<re_irc> <@thalesfragoso:matrix.org> split is being dephased for some time now, giving space to a Gpio::new, etc
<re_irc> <@thalesfragoso:matrix.org> It's just that there is a lot of code using it, and you need some work to fix it
<re_irc> <@dirbaio:matrix.org> ah yeah nrf-hal does this
<re_irc> <@dirbaio:matrix.org> it's nicer, but not having to split at all is nicest
<re_irc> <@thalesfragoso:matrix.org> But I don't think anyone would oppose to remove split in favor of a new on a new type
<re_irc> <@thalesfragoso:matrix.org> Hmm, now Im thinking if the status quo is that bad ?
<re_irc> <@thalesfragoso:matrix.org> embassy-stm32 is already an alternative for people that want something different
<re_irc> <@dirbaio:matrix.org> yeah, it's probably how it's going to stay
<re_irc> <@thalesfragoso:matrix.org> embassy-stm32 plays with a lot of trade-offs that aren't a clear cut for everyone
<re_irc> <@dirbaio:matrix.org> we just have to release it, and \market it more :P
<re_irc> <@thalesfragoso:matrix.org> For people that just want to use the PAC for their chip, stm32-metapac is definitely not as nice as the current ones
<re_irc> <@adamgreig:matrix.org> With my wg hat on instead of the stm32-rs hat, it seems like some completion in HALs is not necessarily a bad thing
<re_irc> <@adamgreig:matrix.org> Certainly it is driving innovation in hal technology
<re_irc> <@dirbaio:matrix.org> yeah metapac's goal is just "support writing a cross-family hal"
<re_irc> <@thalesfragoso:matrix.org> We just need to get rid of the de-referenceable problem on svd2rust...
<re_irc> <@adamgreig:matrix.org> "check it out, our language is mature enough to have three different HALs for your chip, although admittedly the authors do all hang out in the same three matrix rooms"
<re_irc> <@adamgreig:matrix.org> As the pac maintainer I feel the metapac competition much more keenly :p
<re_irc> <@thalesfragoso:matrix.org> "And some maintainers are the same..."
<re_irc> <@adamgreig:matrix.org> Can't wait for stcubers, that will show us
<re_irc> <@dirbaio:matrix.org> the svd2rust derefereanceable fix will be a big breaking change D:
<re_irc> <@adamgreig:matrix.org> When I started stm32-rs, the typical thing was lots of separate PACs, one per svd file, with hand updated svd files, chunks copy pasted from each other
<re_irc> <@dirbaio:matrix.org> 😱
<re_irc> <@adamgreig:matrix.org> So there was an stm32f303 crate and so on, and i was like yep I should make one thing to do every stm32, and then once that's done I'll write one hal for them all using it
<re_irc> <@dirbaio:matrix.org> you'd have needed like 400 PACs :D
<re_irc> <@adamgreig:matrix.org> As usual if I knew then what I know now I probably wouldn't have started it but it's amusing how similar it is
<re_irc> <@adamgreig:matrix.org> I only split it into one pac per stm32 family because of the 10mb crates.io limit
<re_irc> <@adamgreig:matrix.org> The original plan was one single crate with all the PACs, which I guess I layer got to with stm32ral too
<re_irc> <@adamgreig:matrix.org> It sure seemed like writing a new hal was the next step at the time anyway
<re_irc> <@thalesfragoso:matrix.org> Hah, imagine the compile times...
<re_irc> <@adamgreig:matrix.org> It wouldn't be any worse would it? It's feature gated to a single device each time anyway
<re_irc> <@thalesfragoso:matrix.org> Hmm, yeah, only sad for docs.rs
<re_irc> <@adamgreig:matrix.org> In many ways stm32ral was an attempt to do automatically the shared identical structs of metapac
<re_irc> <@adamgreig:matrix.org> Anyway I finished my phd and got a job instead and didn't write the hal companion
<re_irc> <@adamgreig:matrix.org> So basically I am in favour of unified support :p
<re_irc> <@adamgreig:matrix.org> But I think it basically became apparent in 2018(19?) that a single unified hal was going to be very hard and in the meantime the per family HALs provided a lot of things that people wanted and were getting widely used and starting to use the single family PACs from stm32-rs instruct of single device PACs and HALs from before, so it made sense to create an org for them ( therealprof especially pushed for...
<re_irc> ... it), and people kept making new HALs for the family they were using, so many of them moved into the org too, and it was basically the only practical way at the time to coordinate enough people to develop enough support for lots of stm32 families: separate groups for each, with some overlap, doing their own thing and copying each other's good ideas
<re_irc> <@adamgreig:matrix.org> More history monologue 🙈
<re_irc> <@firefrommoonlight:matrix.org> adamgreig: The PACs and SVD2Rust are outstanding
<re_irc> <@firefrommoonlight:matrix.org> The inconsistencies etc I run into are almost all rooted in the SVDs
<re_irc> <@firefrommoonlight:matrix.org> Which stm32-rs, nrf-rs etc fix with YAML patches
<re_irc> <@dirbaio:matrix.org> nrf doesn't even patch anything
<re_irc> <@adamgreig:matrix.org> For all six of their chips ;p
<re_irc> <@dirbaio:matrix.org> nordic's docs and C headers seem generated from the svd's, maybe that has something to do with it too :D
<re_irc> <@dirbaio:matrix.org> or docs, headers, svd's generated from some internal source of truth
<re_irc> <@adamgreig:matrix.org> I only jest because I'm jealous of it, sounds great
<re_irc> <@dirbaio:matrix.org> stm32's svds seem handwritten by interns
<re_irc> <@dirbaio:matrix.org> typos in reg names
<re_irc> <@adamgreig:matrix.org> Some of the new ones actually have some enumerated values in the svd
DepthDeluxe has quit [Ping timeout: 260 seconds]
<re_irc> <@adamgreig:matrix.org> But they're wrong or worse so we had to add a feature to svdtools to remove existing enumerated values lol
<re_irc> <@dirbaio:matrix.org> what a luxury :D
<re_irc> <@adamgreig:matrix.org> More excitingly the new ones are explicitly released under an Apache 2.0 license
<re_irc> <@adamgreig:matrix.org> But yea they're not necessarily much better data quality