<re_irc>
<yruama_lairba> firefrommoonlight: i don't have a SAI device
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
gsalazar has joined #rust-embedded
<re_irc>
<Etienne Assoumou Mengue> Hi guys, my company and I are embedded enthusiast. we are playing/learning/developing with embedded rust since 2 year on stm32 & nrf52 MCUs. We would like to contribute and be part of the community. Could you guys please guide us how to do it and also to become a member of the embedded rust team(Cortex-M team).
<re_irc>
Thank you.
<re_irc>
<caspinol> Hello all, i'm using the stm32f4xx hal crate and i'm having trouble to find a way to configure a time running in a output compare mode where the timer drivet the external pin directly. I can of course emulate it with interrupt or by using the PWM but its not obvious to me how to do this directly with timer API. Can anyone share some pinters to the documentation or example perhaps?
<re_irc>
<therealprof> Etienne: 👋 Also thanks for your email. I'm replying here because it might be interesting for others as well. We do have a few pointers on how to get started with the embedded WG here: https://github.com/rust-embedded/wg. There are no formal requirements for contributions to our projects, except for die abidence of the CoC (https://www.rust-lang.org/policies/code-of-conduct). I would, given your mentioned interest...
<re_irc>
... in Cortex-M, highly recommend you look around the related projects and just dive in by commenting or creating new issues and PRs. You're also very welcome to join the discussion in our weekly meeting (every Tuesday, i.e. today at 8:00 PM right here) and maybe introduce yourself and give a little bit of details on what you're planning to work in particular.
<re_irc>
<Imran K> Hello all, I am writing a flash driver for "stm32h723zg" which is a "256 bit" data align, if I am trying to write a single byte it is not working. Can you help me with how to write single byte data in Flash? My board architecture is "32 bit" but it is working on 32 byte align data How is it?
<re_irc>
<caspinol> * timer
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 260 seconds]
diagprov has quit [Quit: diagprov]
cr1901_ has quit [Remote host closed the connection]
cr1901_ has joined #rust-embedded
creich_ has joined #rust-embedded
creich has quit [Ping timeout: 240 seconds]
cr1901_ is now known as cr1901
lowq has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
<re_irc>
<adamgreig> hi room, meeting time again! we'll start in 5 min, agenda link on its way...
<re_irc>
<adamgreig> ok, let's start! I've only just got my computer back up yesterday so haven't seen anything to announce, did anyone see anything last week?
<re_irc>
<therealprof> I was hoping we could announce a blog post. 😉
<re_irc>
<adamgreig> hah, yea, shall we publish the current newsletter-next this evening then?
<re_irc>
<adamgreig> anyone feel like cutting a PR for it?
<re_irc>
<adamgreig> I'll take a look later otherwise
<re_irc>
<adamgreig> ok, otherwise mostly a few items closed since last week
<re_irc>
<adamgreig> currently there aren't many big changes in 0.8, mostly around the debug peripherals (and of course swapping to stable "asm!()", but it's not breaking), so it might be worth thinking about other changes before cutting it
<re_irc>
<adamgreig> though having not thought about it for a little while i'd need to revisit some old discussions to have any plans live in my head...
<re_irc>
<therealprof> Are there other changes?
<re_irc>
<adamgreig> we remove the deprecated "ptr()" in favour of the const "PTR"
<re_irc>
<adamgreig> but no significant changes to other peripherals, afaik
<re_irc>
<adamgreig> there are a few pending PRs that should definitely get in first, 377/383/387/389/422
<re_irc>
<adamgreig> but they are mostly debug related, finishing up the earlier debug changes
* cr1901
has nothing to add on his end, so is just catching up on the ARM changes
* re_irc
adamgreig waves at cr1901
<re_irc>
<adamgreig> at least the bridge is working 😓
<re_irc>
<adamgreig> I guess the other thing with cortex-m 0.8 is whether to do the semver hack thing or otherwise try to think of a way around it
<re_irc>
<newam> Are there any plans to change/remove the singletons in the future?
<re_irc>
<adamgreig> they're such a nuisance, so yea, maybe
<re_irc>
<adamgreig> things we've considered in the past include splitting into a pac and hal crate, or a separate crate just for singletons that won't need version bumping often
<re_irc>
<dirbaio> I'd go singleton-less PAC + singletoned HAL
<re_irc>
<adamgreig> like, imagine cortex-m-singletons gave out instances of DWT, TPIU, NVIC, whatever: we could add new peripherals as Arm adds them, but basically the list is fixed and known, and the HAL crate can do breaking changes whenever it likes, but an application could happily have multiple HALs/HAL versions
<re_irc>
<adamgreig> the problem with singletoned HAL is you now need to enforce a single instance of the HAL?
<re_irc>
<adamgreig> but that's the part that changes most
<re_irc>
<dirbaio> yeah... I've given up on that in embassy
<re_irc>
<adamgreig> indeed
<re_irc>
<adamgreig> perhaps you could have singletons in their own singleton crate and the HAL consumes them, though?
<re_irc>
<adamgreig> if you wanted to keep them, I mean
<re_irc>
<dirbaio> it's "single instance of singletons" xor "allow mixing HAL versions"
<re_irc>
<adamgreig> (and the PAC would also consume them separately/instead of the HAL, if you wanted direct access? or more like, the HAL would consume them via the PAC)
<re_irc>
<dirbaio> the singletons crate might work but then you're committing to a particular way of splitting up the peripherals
<re_irc>
<adamgreig> yea
<re_irc>
<adamgreig> well, you could imagine someone consuming the NVIC singleton and providing 32 new IRQ singletons or whatever
<re_irc>
<adamgreig> but obviously that's going to be less inter-compatible
<re_irc>
<dirbaio> for example in MCU HALs I've found a singleton per gpio pin is wayyyy more ergonomic than a singleton per gpio port
<re_irc>
<dirbaio> and with NVIC there's the similar thing yup
<re_irc>
<adamgreig> sure, but it doesn't reflect the required synchronisation, right?
<re_irc>
<adamgreig> if you have a singleton per pin you can't be sure you have exclusive access to the port registers
<re_irc>
<adamgreig> so you gotta do something else - critical section, platform specific atomic ops, whatever
<re_irc>
<dirbaio> if your registers allows atomic access then yes, otherwise you do critical sections
<re_irc>
<dirbaio> it's a tradeoff
<re_irc>
<adamgreig> of course the practical reality is that all the HALs just have to do this anyway because of course ultimately they offer per-pin singletons
<re_irc>
<dirbaio> different HALs might want to do that tradeoff differently, and you can't if you want all HALs to use the same "singletons crate"
<re_irc>
<adamgreig> inside the cortex-m crate(s) though the main thing would be to stop having to do semver hacks and breaking the whole ecosystem with each version bump
<re_irc>
<adamgreig> so even if it was an implementation detail of cortex-m as-is, it might still be a big improvement
<re_irc>
<dirbaio> so I don't think the "singletons crate" idea solves 100% of the problems
<re_irc>
<dirbaio> so I'm not sure it's worth the extra complexity
<re_irc>
<dirbaio> it does solve many
<re_irc>
<dirbaio> dunno
<re_irc>
<newam> dirbaio: Yeah, this is currently a messy problem for the STM32WL where ST expects you to compile two separate binaries for each CPU.
<re_irc>
<dirbaio> oh yeah you can't enforce singleton singletonness at all in the multicore case 😂
<re_irc>
<dirbaio> same for nrf53
<re_irc>
<newam> -two
<re_irc>
<adamgreig> yea, the multi-arch multi-core is a whole other problem too...
<cr1901>
singleton as in e.g. the PERIPHERALS struct from a PAC?
<re_irc>
<adamgreig> so I think we could do the cortex-m-singletons very soon and then later split into cortex-m-hal and cortex-m-pac and at least that might mean that for 0.8 we never need future semver hacks
<re_irc>
<adamgreig> we could even do a 0.7.5 release that used the new -singletons crate
<re_irc>
<adamgreig> which would then become back-compat down to 0.5 or whatever (horrifying thought)
<re_irc>
<adamgreig> cr1901: yea, exactly
<re_irc>
<adamgreig> execpt the PERIPHERALS struct from cortex-m crate in this case
<re_irc>
<adamgreig> dirbaio: do you just give up on having exclusive access to a peripheral, then, and assume all access needs other synchronisation?
<cr1901>
Yea, I thought we punted on the multi-core case- no way to explain between two cores w/o some sort of runtime that one core owns the singleton
<re_irc>
<adamgreig> or does it just become unsound if your users end up with two versions?
<re_irc>
<adamgreig> cr1901: yea, for now that's the status, it's just "no official support, DIY, it's not yet clear how it might fit into rust send/sync, though people have various ideas around modelling it as separate processes needing IPC except they share a memory space and some singletons..."
* cr1901
nods
<re_irc>
<dirbaio> adamgreig: gave up on safety when mixing HALs, or multiple major versions of the same HAL. If you don't mix, it's all safe
<re_irc>
<dirbaio> some people do want to mix
<re_irc>
<adamgreig> that's the same as cortex-m except we use the "links" field to break the build if they would have had multiple major versions
<re_irc>
<adamgreig> and it wrecks the ecosystem every time
<re_irc>
<dirbaio> allowing mixing unsafely is better than completely failing the build...
<re_irc>
<newam> cr1901: You can do it at compile time too, if you split up peripherals into individual singletons. Requires a number of hacks though since rust isn't great at handling compile-time options.
<re_irc>
<adamgreig> if we didn't do that, you'd get extremely regular multiple major versions
<re_irc>
<newam> * singletons, and assign each to a core statically.
<re_irc>
<adamgreig> and I suspect you'd end up with a lot of people passing a 0.6 NVIC to a driver that wants 0.8 or whatever on top
<re_irc>
<dirbaio> not many drivers out there taking cortex-m singletons though?
<re_irc>
<dirbaio> usually it's the user configuring the irqs
<re_irc>
<adamgreig> yea, true, mostly the problem is PACs and HALs using old cortex-m and applications wanting to use new cortex-m
<cr1901>
newam: Ack. Maybe one day we'll have a const-fn Peripherals.split for all possible permutations of peripherals :P
<re_irc>
<adamgreig> well that's probably enough ink spilled on cortex-m for tonight, is there anything on embedded-hal?
<re_irc>
<GrantM11235> re: performance: I don't think that multiple calls to "write" will inline with opt "s" or "z", will they?
<re_irc>
<therealprof> "depends"
<re_irc>
<GrantM11235> > > This will also allow us to add new methods in the future with default implementations as a non-breaking change.
<re_irc>
> Why is that not the case already, with the current slice-based methods?
<re_irc>
For the most part this is true (aside from possible performance concerns), however there are some case where this could lead to problems.
<re_irc>
For example, if we add a write_iter method, it could have a default impl using len=1 slices. Unfortunately, it would then be impossible to then give write_slice a default impl based on write_iter
<re_irc>
<dirbaio> > impossible to then give write_slice a default impl based on write_iter
<re_irc>
> for that to
<re_irc>
<dirbaio> * for that you'd have to make write_iter mandatory (no defualt impl) which would be breakin
<re_irc>
<GrantM11235> But with the word methods, you could add write_iter in a non breaking way that uses write_word, and you could switch the write_slice method to use write_iter by default (also non-breaking)
<cr1901>
GrantM11235: Rust has a non-zero threshold for inlining even at opt-level="z"
<re_irc>
<dirbaio> and you can tune with "inline-treshold"
<cr1901>
At "s" it's 95, "z" it's "75"
<cr1901>
at "3" it's 285 or 275
<cr1901>
There's a page in the official docs for it
<re_irc>
<dirbaio> i'm not a fan of write_iter either
<cr1901>
dirbaio: Oh, cool, TIL
<re_irc>
<dirbaio> people love doing stuff like "spi.write_iter(slice1.iter().chain(slice2.iter()))"
<re_irc>
<dirbaio> which generates bloated code and performance craters with DMA
<re_irc>
<dirbaio> vs something like "spi.write(slice1); spi.write(slice2);"
<Lumpio->
Specialize it for an iterator of slices :-)
<Lumpio->
...if only we could specialize
<re_irc>
<therealprof> cr1901: There're multiple levels of inlining...
<re_irc>
<GrantM11235> Sometimes you need to accept an iterator and send it via spi, like in display-interface-spi
<re_irc>
<therealprof> You can also use a slice but since e-g uses iterators...
<re_irc>
<GrantM11235> Or any display driver that uses embedded-graphics
<re_irc>
<dirbaio> on some chips like nrf, you _can't not use DMA_ :P
<re_irc>
<dirbaio> which makes display-interface is quite slow on nrf
<re_irc>
<dirbaio> and in async you get horrible performance without DMA as well
<re_irc>
<GrantM11235> dirbaio: Yeah, the hal will need to copy to a buffer, same as when sending data that is in flash instead of ram
<re_irc>
<therealprof> Well, nothing prevents you from specialising the impl for nrf by buffering and using DMA.
<re_irc>
<dirbaio> yeah yeah I know you can workaround
<re_irc>
<dirbaio> but should the e-h traits mandate functionality that _requires_ workarounding?
<re_irc>
<dirbaio> vs if you have slice "write" only
<re_irc>
<dirbaio> you impl write_word, write_iter on top of that
<re_irc>
<dirbaio> you get good performance with the right compiler flags to get "write" to inline
<re_irc>
<therealprof> The problem is if you're coming from an iterator interface you don't know how much data there will be.
<re_irc>
<dirbaio> and oyu're not encouraging use of apis that are _impossible_ to make fast on some chips or on async
<re_irc>
<GrantM11235> dirbaio: They should allow you to do what you need to do for your driver. If workarounds are required, it is better to do that in the hal IMO
<re_irc>
<dirbaio> the producer of the iterator is in the best position to know the len
<re_irc>
<therealprof> Not reaally.
<re_irc>
<therealprof> * really.
<re_irc>
<dirbaio> if someone knows, it's whoever created the iter
<re_irc>
<dirbaio> lower layers just know "it's an "impl Iterator""
<re_irc>
<therealprof> If you're drawing a circle, how would you know how much pixels that would create?
<re_irc>
<dirbaio> so higher layers are in the best position to size buffers etc
<re_irc>
<therealprof> Those assumptions can only be wrong.
<re_irc>
<GrantM11235> The higher layers don't even know if a buffer is required at all
<re_irc>
<therealprof> GrantM11235: Exactly.
<re_irc>
<dirbaio> imo _if_ EH has write_word, write_iter they should be default-impl'd on top of write_slice
<re_irc>
<dirbaio> and users who care about perfromance set the right compiler flags for write_slice to get inlined
<re_irc>
<GrantM11235> dirbaio: I don't think that makes sense for anything other than nrf
<re_irc>
<therealprof> dirbaio: Inlining is not enough to get perfect performance all the time. If you write a slice you will have to determine a usable buffer size, those can only be wrong.
<re_irc>
<therealprof> If you're not using DMA, NOT copying to a buffer is often more efficient.
<re_irc>
<eldruin> I would also see writing slices as the common denominator for default impls but let's not forget that anyone that cares about performance should rather look into a dedicated implementation and not a default.
<re_irc>
<dirbaio> with this, you could have write_word, write_iter with ok prformance without dma, and bad performance with dma
<re_irc>
<therealprof> Iterating the buffer can take a significant amount of CPU cycles which you could use to fill the send buffer.
<re_irc>
<dirbaio> if you're using write_Iter there's no way to get good performancew tih dma
<re_irc>
<dirbaio> * performance with
<re_irc>
<dirbaio> but at least it'll work
<re_irc>
<eldruin> * who
<re_irc>
<GrantM11235> eldruin: Exactly. I think that default impls using word methods are perfect for very simple non-dma hals
<re_irc>
<eldruin> I meant having a default impl for write_word and write_iter that just calls write_slice(&[word])
explore has joined #rust-embedded
<re_irc>
<eldruin> HALs can provide real implementations where the slicing is skipped for performance
<re_irc>
<adamgreig> (oops, we're a bit over time for meeting, thanks everyone! I have to run but feel free to keep discussing this)
<re_irc>
<GrantM11235> The hal probably already has a private write_word function that it uses to impl the e-h trait
<re_irc>
<therealprof> That's possible, but I don't see how that performance would be any better than having a direct implementation of write_iter doing the same internally.
<re_irc>
<eldruin> GrantM11235: exactly
<re_irc>
<dirbaio> even if "write" doens't get inlined and gets called with len=1, I don't think it'd make a difference for performance
<re_irc>
<dirbaio> it's, what, 20 extra clock cycles?
<re_irc>
<dirbaio> sending one byte over SPI will probably be slower
<re_irc>
<GrantM11235> The main motivation of the pr is so that simple non-dma hals can impl write_word (which they usually already do) and they don't need a bunch of extra "for word in slice" boilerplate
<re_irc>
<dirbaio> but then DMA hals have to impl both "write", and "write_word" with "write(&[word])" boilerplate
<re_irc>
<GrantM11235> A dma hal can easily override write_word with write_slice(&[word])
<re_irc>
<dirbaio> AND the blocking trait becomes inconsistent with the async one
<re_irc>
<GrantM11235> dirbaio: That is true. An async write_word would likely have too much overhead unless the spi speed was very slow, so I wouldn't recommend adding it
<re_irc>
<dirbaio> if it was just the blocking one, i'd be 50/50 (both have boilerplate in some cases, and performance should be the same given sane compiler options)
<re_irc>
<dirbaio> but consistency with async tips the balance in favor of having just slice "write" imo
<re_irc>
<dirbaio> and there's the "encourage users to do the fast option" too
<re_irc>
<dirbaio> slice "write" is fast both with and without DMA
<re_irc>
"write_iter" is slow with DMA, fast without
<re_irc>
<dirbaio> if you make "write_iter", "write_word" first-class stuff you encourage people to write stuff like "spi.write_iter(slice1.iter().chain(slice2.iter()))"
<re_irc>
<dirbaio> due to that I think EH should not have "write_word", "write_iter" at all
<re_irc>
<dirbaio> make the higher-level code write the "for byte in my_iter { spi.write(&[byte]) }"
<re_irc>
<eldruin> maybe we should publish a new alpha with this spi redesign to see how it performs with displays and so on in reality
<re_irc>
<dirbaio> this way you're making it very very obvious that it might be slow on some hardware
<re_irc>
<dirbaio> and encourage using slices _if possible_
<re_irc>
<dirbaio> if not possible (like e-g drawing a circle) then it's not
<re_irc>
<dirbaio> but at least you're not _encouraging_ code that _can't be made fast_
<re_irc>
<dirbaio> * fast on some hardware_
<re_irc>
<dirbaio> if not possible (like e-g drawing a circle) then it's not, let them do N 1-byte writes
<re_irc>
<dirbaio> same goes for linux-embedded-hal, doing a zillion 1-byte writes is sloooooow
<re_irc>
<dirbaio> +too
<re_irc>
<GrantM11235> I was on the fence about it before this meeting, but I think I am mostly convinced now that this is not worth it
Shell is now known as concha
concha is now known as Shell
<re_irc>
<dirbaio> :D
<re_irc>
<GrantM11235> You are very persuasive :)
<re_irc>
<GrantM11235> Thanks everyone for the interesting discussion
<re_irc>
<eldruin> I meant making a new release including 351
<re_irc>
<eldruin> not yet
<re_irc>
<eldruin> mutantbob: that seems like a different problem caused by an implementation decision in the atmega-hal itself I would say. I know nothing about it though
<re_irc>
<eldruin> Being it from rahix I am sure there is some reason behind that, otherwise he is probably grateful for improvements
<re_irc>
<eldruin> Alright, I need to leave now, thanks everybody for the nice discussion!
<re_irc>
<rahix> mutantbob: please check the answer I wrote in your issue, it should hopefully clear things up