<re_irc_> <@w​illeml:m​atrix.org> Oh, sorry, I should have specified it’s all open and up to date on GitHub, I think I posted the repo a few times, but that was a long time ago
richardeoin has quit [Ping timeout: 252 seconds]
<re_irc_> <@w​illeml:m​atrix.org> (if you prefer I do not mind posting the code in here, I just think its probably easier to read on github)
richardeoin has joined #rust-embedded
<re_irc_> <@w​illeml:m​atrix.org> All register stuff happens in the file in the last two links (external_flash.rs)
<re_irc_> <@w​illeml:m​atrix.org> Except for MPU init which happens at the end of main.rs https://github.com/willemml/rustworks/blob/77a6b1b10f8d4cf648a6f312a1f1118cfc7bcad7/src/main.rs#L303
<re_irc_> <@w​illeml:m​atrix.org> Also, main.rs is not meant to be a link, someone is just parking the domain
<re_irc_> <@j​osfemova:m​atrix.org> Is there any sort of daq-hal for data acquisition systems like National Instruments equipment? or at least wrappers around the C api NI provides?
<re_irc_> <@f​irefrommoonlight:m​atrix.org> willeml: sweet - I'll take a look later this week
fabic has joined #rust-embedded
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
tokomak has joined #rust-embedded
tokomak has quit [Ping timeout: 268 seconds]
tokomak has joined #rust-embedded
<re_irc_> <@w​illeml:m​atrix.org> firefrommoonlight: Awesome!
tokomak has quit [Ping timeout: 272 seconds]
fabic has quit [Ping timeout: 265 seconds]
tokomak has joined #rust-embedded
SomeWeirdAnon has quit [Ping timeout: 268 seconds]
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Related: Would you use internal Flash on applicable MCUs over external unless you're out of space? Should be faster and simplify hardware
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Although external is cheap
<re_irc_> <@9​names:m​atrix.org> probably not. have used flash for static webpages before, because it's simple and cheap.
<re_irc_> <@9​names:m​atrix.org> have also used external sdram for this when it was available.
<re_irc_> <@9​names:m​atrix.org> but if you go external flash you have the option of flashless mcu's, which can also be a good fit for some applications
<re_irc_> <@f​irefrommoonlight:m​atrix.org> Thanks!
<re_irc_> <@f​irefrommoonlight:m​atrix.org> It seems like the STM variants with more flash tend to be significantly more expensive
<re_irc_> <@i​ldar:m​atrix.org> Q: on rtt-target. So I got a binary that makes use of RTT. Now how do I use it with legacy tools, e.g. openocd?
<re_irc_> <@i​ldar:m​atrix.org> Per http://openocd.org/doc/html/General-Commands.html#Real-Time-Transfer-_0028RTT_0029 I need an address (optional) and ID
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 240 seconds]
fabic has joined #rust-embedded
<re_irc_> <@j​amesmunns:m​atrix.org> We go over the process for that here: https://ferrous-systems.com/blog/gdb-and-defmt/
<re_irc_> <@j​amesmunns:m​atrix.org> If you're just using rtt and not defmt, you can skip the steps on piping it to that, since you don't need to decode the data.
<re_irc_> <@j​amesmunns:m​atrix.org> Just the `nc localhost 8765` step should print the contents of rtt
xnor has joined #rust-embedded
<re_irc_> <@k​orken89:m​atrix.org> Does anyone know of an chip that is SPI to UART? So an MCU can talk to multiple of these over SPI to get many UARTs?
<re_irc_> <@g​rantm11235:m​atrix.org> If you just want to multiplex your uart, you could use something like a 74hc4052
<re_irc_> <@k​orken89:m​atrix.org> Thanks, though I need multiple physical UARTs
<re_irc_> <@k​orken89:m​atrix.org> Preferably with a few kB of FIFO AND MAYBE UP TO 10 Mbaud
<re_irc_> <@k​orken89:m​atrix.org> I'll continue hunting :)
<re_irc_> <@d​irbaio:m​atrix.org> so data can come in on any of them at any time and you don't want to lose it? sounds fun...
<re_irc_> <@k​orken89:m​atrix.org> Yeah
<re_irc_> <@k​orken89:m​atrix.org> I have a multi port 5MBaud RS485 system today, but can't get hold of the ST MCU they powers it
<re_irc_> <@d​irbaio:m​atrix.org> maybe a cheapo tiny MCU?
<re_irc_> <@d​irbaio:m​atrix.org> ah haha it's to workaround mcu shortage :D
<re_irc_> <@d​irbaio:m​atrix.org> oh no
<re_irc_> <@k​orken89:m​atrix.org> So I was going to go with nrf+bridge IC
<re_irc_> <@k​orken89:m​atrix.org> Can't find the bridge though xD
<re_irc_> <@k​orken89:m​atrix.org> So maybe it's time for plan D
<re_irc_> <@k​orken89:m​atrix.org> Thanks for the feedback :)
<re_irc_> <@d​irbaio:m​atrix.org> cheapo non-ST mcu? 🤣
<re_irc_> <@k​orken89:m​atrix.org> Haha the problem is the 5 MBaud
<re_irc_> <@k​orken89:m​atrix.org> Almost none good above 2M I've realized
<re_irc_> <@k​orken89:m​atrix.org> I found a few NXP
<re_irc_> <@k​orken89:m​atrix.org> But they are also out
<re_irc_> <@k​orken89:m​atrix.org> So I probably need to dig deeper :)
<re_irc_> <@k​orken89:m​atrix.org> Oh well, now it's time to throw some trash from the yard. Let's talk more later :D
<re_irc_> <@d​irbaio:m​atrix.org> oh and nrf's can do max 1Mbaud... welp
<re_irc_> <@k​orken89:m​atrix.org> Yeah xD
<re_irc_> <@d​irbaio:m​atrix.org> RP2040 (rpi pico) maybe?
<re_irc_> <@k​orken89:m​atrix.org> Hmm maybe actually
<re_irc_> <@k​orken89:m​atrix.org> I'll give it a look :)
<re_irc_> <@d​irbaio:m​atrix.org> it has 2 hardware uarts, they can do 10Mbaud
<re_irc_> <@d​irbaio:m​atrix.org> but with PIO you can do crazy stuff
<re_irc_> <@d​irbaio:m​atrix.org> all the 32 pins could be uarts :D
<re_irc_> <@r​yan-summers:m​atrix.org> You could also go with a USB -> UART solution? I know that FTDI makes some USB -> 4/8/16 UART chips
<re_irc_> <@r​yan-summers:m​atrix.org> Although that might require a usb host controller on chip, which would be no-fun
<re_irc_> <@d​irbaio:m​atrix.org> nrf can't do usb host :(
<re_irc_> <@j​amesmunns:m​atrix.org> I've used the black pill to go up to 10-12Mbps
<re_irc_> <@j​amesmunns:m​atrix.org> (I was using that for a high speed RS485)
<re_irc_> <@j​amesmunns:m​atrix.org> I think at least two of the UARTs can go that fast? Maybe 3?
<re_irc_> <@d​irbaio:m​atrix.org> the issue is stm32s are unobtainium :P
<re_irc_> <@j​amesmunns:m​atrix.org> I mean, if he needs five, I can send him them
<re_irc_> <@j​amesmunns:m​atrix.org> but if he needs a prod design, yeahhhhh
<re_irc_> <@d​irbaio:m​atrix.org> 🤣
<re_irc_> <@j​amesmunns:m​atrix.org> Honestly it does sound like a job for PIOs or a ice40 or something
<re_irc_> <@t​halesfragoso:m​atrix.org> How about the gigadevice chips ?
<re_irc_> <@l​achlansneff:m​atrix.org> Could `std::io::{Read, Write}` make their way into libcore? Looks like they don't have anything that relies on libstd.
<re_irc_> <@t​halesfragoso:m​atrix.org> I think io::Error was the problem
<re_irc_> <@l​achlansneff:m​atrix.org> I see that now. Hmm
<re_irc_> <@d​irbaio:m​atrix.org> io::Error has `Box<dyn Stuff>` 💩
<re_irc_> <@l​achlansneff:m​atrix.org> Could the core traits have an error associated type?
<re_irc_> <@l​achlansneff:m​atrix.org> and the std traits would be trait aliases
<re_irc_> <@d​irbaio:m​atrix.org> it'd have to be a parallel trait no matter what :(
<re_irc_> <@d​irbaio:m​atrix.org> trait aliases are not a thing :D
<re_irc_> <@l​achlansneff:m​atrix.org> Indeed they are!
<re_irc_> <@l​achlansneff:m​atrix.org> https://github.com/rust-lang/rust/issues/41517
<re_irc_> <@d​irbaio:m​atrix.org> oh wtf TIL
<re_irc_> <@d​irbaio:m​atrix.org> that's cool :D
<re_irc_> <@l​achlansneff:m​atrix.org> A few things would still need work
<re_irc_> <@l​achlansneff:m​atrix.org> The `read_to_string` method
<re_irc_> <@l​achlansneff:m​atrix.org> and `read_to_end`
<re_irc_> <@d​irbaio:m​atrix.org> either way you could get the same by having 2 traits, then doing blanket impls like `impl<T: core::io::Write> std::io::Write for T`
<re_irc_> <@d​irbaio:m​atrix.org> but still
<re_irc_> <@d​irbaio:m​atrix.org> ANNOYING
<re_irc_> <@l​achlansneff:m​atrix.org> Right, but having two traits would be annoying
<re_irc_> <@d​irbaio:m​atrix.org> and would stuff from std impl core::io::Write? 🤔
<re_irc_> <@l​achlansneff:m​atrix.org> I think a trait alias would work *except* for `read_to_string` and `read_to_end`.
<re_irc_> <@l​achlansneff:m​atrix.org> No, they'd be the same trait
<re_irc_> <@l​achlansneff:m​atrix.org> They could impl std::io::Read
<re_irc_> <@l​achlansneff:m​atrix.org> It'd be a trait alias with the error type set to io::Error
<re_irc_> <@d​irbaio:m​atrix.org> ah yeah with the trait alias sure
<re_irc_> <@l​achlansneff:m​atrix.org> I dunno, maybe it be possible if trait extensions were possible
<re_irc_> <@l​achlansneff:m​atrix.org> Like if a trait alias could include additional methods
<re_irc_> <@l​achlansneff:m​atrix.org> Or, if `Vec` and `String` were moved to `core`, the trait could have `Error` and `Allocator` be associated types
fabic has quit [Ping timeout: 240 seconds]
<re_irc_> <@s​ympatron:m​atrix.org> Vec and String need alloc though
<re_irc_> <@l​achlansneff:m​atrix.org> They'll be able to take a custom allocator type parameter
<re_irc_> <@l​achlansneff:m​atrix.org> Vec already can on nightly
<re_irc_> <@d​irbaio:m​atrix.org> having `Allocator` associated type would force users to have *some* allocator to use the traits
<re_irc_> <@l​achlansneff:m​atrix.org> Yep
<re_irc_> <@l​achlansneff:m​atrix.org> I don't really see too much of an issue with that
<re_irc_> <@l​achlansneff:m​atrix.org> We could default it to a no-op one
<re_irc_> <@d​irbaio:m​atrix.org> but what if an impl actually tries to return a `String`? it explodes?
<re_irc_> <@l​achlansneff:m​atrix.org> I mean, I wouldn't suggest defaulting to a no-op.
<re_irc_> <@l​achlansneff:m​atrix.org> But, the user could if they wanted
<re_irc_> <@d​irbaio:m​atrix.org> doesn't seem a very solid solution :S
<re_irc_> <@d​irbaio:m​atrix.org> imo core::io shouldn't require alloc at all
<re_irc_> <@l​achlansneff:m​atrix.org> core already has an alloc module
<re_irc_> <@l​achlansneff:m​atrix.org> Which contains the `Allocator` trait.
<crabbedhaloablut> Why don't we use the transparent bridge from libera<->matrix?
<re_irc_> <@l​achlansneff:m​atrix.org> (on nightly)
<re_irc_> <@d​irbaio:m​atrix.org> Yeah but I don't want to have to supply an allocator to do IO
<re_irc_> <@l​achlansneff:m​atrix.org> You could just set to no-op.
<re_irc_> <@d​irbaio:m​atrix.org> if `core::io::Write` requires an allocator, I'm going to continue using my custom `Write` trait that doesn't
<re_irc_> <@l​achlansneff:m​atrix.org> I agree, it's not ideal
<re_irc_> <@d​irbaio:m​atrix.org> setting it to no-op would crash if impls try to use it
<agg> crabbedhaloablut: a few reasons: a) the libera channel still isn't registered because it's in the #rust namespace and the core team haven't replied to my email asking if we can get this room delegated (they need to claim the namespace first)
<re_irc_> <@d​irbaio:m​atrix.org> impls have no idea if the allocator is noop or not
<re_irc_> <@d​irbaio:m​atrix.org> if the API allows returning a string, they should be able to return one without fear of crashing
<agg> b) the matrix room has >100 users so we need matrix.org admins to enable the bridge for us manually, and they're also not responding to my messages about it >_>
<agg> c) when we had the transparent bridge, it regularly kicked lots of idle matrix users, which annoyed everyone
<re_irc_> <@l​achlansneff:m​atrix.org> Yeah, I guess
<re_irc_> <@l​achlansneff:m​atrix.org> It just seems like there must be an elegant solution to this
<re_irc_> <@l​achlansneff:m​atrix.org> Might require language changes
<re_irc_> <@l​achlansneff:m​atrix.org> The read_to_string and read_to_vec methods really should've been in an extension trait
<re_irc_> <@a​damgreig:m​atrix.org> @room it's meeting time again! we'll start in 5 minutes, agenda is here: https://hackmd.io/skUOXiM0RK2fM828HiYeAg please add anything you'd like to announce or discuss!
<re_irc_> <@c​uno555:m​atrix.org> I hope that we are not drifting towards a design where no_std implies alloc, whether dummy allocator or not. (And I also hope that we won't be forced to use async.) I see a complexity risk in relying on ever more arcane and subtle features, and language extensions, that make the Rust / embedded Rust learning...
<re_irc_> ... curve even steeper and longer.
<re_irc_> <@l​achlansneff:m​atrix.org> I certainly agree.
<re_irc_> <@d​irbaio:m​atrix.org> > And I also hope that we won't be forced to use async
<re_irc_> <@d​irbaio:m​atrix.org> YEEES asyncify everything!
<re_irc_> <@d​irbaio:m​atrix.org> make integer addition async
<re_irc_> <@d​irbaio:m​atrix.org> `(1 + 2).await`
<re_irc_> <@l​achlansneff:m​atrix.org> I don't think no_std will ever imply alloc. Just that core, alloc, and std will eventually merge together.
<re_irc_> <@j​amesmunns:m​atrix.org> `(1 + yield + 2).await`
<re_irc_> <@a​damgreig:m​atrix.org> having core+alloc+std all together and you can just only use allocing-things when you have an allocator would be pretty neat
<re_irc_> <@a​damgreig:m​atrix.org> though might make it really hard to know if you can use a given lib without an OS or alloc....
<re_irc_> <@t​hejpster:m​atrix.org> I don't know why people are so down on alloc
<re_irc_> <@a​damgreig:m​atrix.org> nice that if something is no_std then you can probably use it embedded
<re_irc_> <@a​damgreig:m​atrix.org> thejpster: boooo dynamic allocation :P
<re_irc_> <@d​irbaio:m​atrix.org> alloc 👎️
<re_irc_> <@t​hejpster:m​atrix.org> A pools allocator is a perfectly reasonable way of assigning blocks of memory
<re_irc_> <@j​amesmunns:m​atrix.org> (this was one of my ideas for std-aware cargo)
<re_irc_> <@a​damgreig:m​atrix.org> I think just a lot of embedded people traditionally like only static allocation
<re_irc_> <@d​irbaio:m​atrix.org> being able to verify everything fits in RAM at compile time is priceless
<re_irc_> <@t​hejpster:m​atrix.org> I mean, otherwise you just keep a bunch of blocks in each module
<re_irc_> <@j​amesmunns:m​atrix.org> Basically: make `std` just a crate with optional features: `alloc` and `libstd`
<re_irc_> <@t​hejpster:m​atrix.org> Mostly unused
<re_irc_> <@t​hejpster:m​atrix.org> Just have one set of blocks and share them
<re_irc_> <@a​damgreig:m​atrix.org> yea, but then you know you have enough all the time
<re_irc_> <@j​amesmunns:m​atrix.org> so `std` + `no-default-features` == `core
<re_irc_> <@a​damgreig:m​atrix.org> if you share them you might need more than you have, which can be a real problem on some embedded systems
<re_irc_> <@t​hejpster:m​atrix.org> If you keep leaking them, note which file and line allocated it
<re_irc_> <@l​achlansneff:m​atrix.org> And `#![no_std]` would alias to that somehow?
<re_irc_> <@a​damgreig:m​atrix.org> if you know you always have enough ram because it's all allocated at the start, you can never have this problem
<re_irc_> <@t​hejpster:m​atrix.org> If you keep double freeing, note who freed it last
<re_irc_> <@j​amesmunns:m​atrix.org> Lachlan Sneff: it was a rejected RFC, so we never even got that far :)
<re_irc_> <@a​damgreig:m​atrix.org> it's not about leaking or double freeing so much as different runtime execution paths that might in some circumstances require more allocation than memory
<re_irc_> <@t​hejpster:m​atrix.org> adamgreig: You can always need more than you have, shared or not
<re_irc_> <@l​achlansneff:m​atrix.org> Anyhow, core implies no global allocation at the moment.
<re_irc_> <@l​achlansneff:m​atrix.org> a no_std crate can require that you pass in an allocator
<re_irc_> <@a​damgreig:m​atrix.org> that's often not true in embedded, you can know exactly how much you need statically and never need to exceed it
<re_irc_> <@j​amesmunns:m​atrix.org> https://github.com/rust-lang/rfcs/pull/2663
<re_irc_> <@t​hejpster:m​atrix.org> adamgreig: Great. Make your pools that big.
<re_irc_> <@l​achlansneff:m​atrix.org> I guess we should talk about async again?
<re_irc_> <@t​hejpster:m​atrix.org> Anyway, I'm distracting you. Go do meeting thing.
cr1901 has quit [Read error: Connection reset by peer]
<re_irc_> <@a​damgreig:m​atrix.org> yep, let's start the meeting!
<re_irc_> <@d​irbaio:m​atrix.org> weekly embedded-hal bikeshedding
<re_irc_> <@a​damgreig:m​atrix.org> quick announcement from this week is that probe-rs 0.11 is out now, there's a blog post about it here: https://probe.rs/blog/release-0-11-0/
<re_irc_> <@a​damgreig:m​atrix.org> fair to say there's just a whole bunch of good fixes and improvements I think
<re_irc_> <@a​damgreig:m​atrix.org> and some very cool looking things in the pipeline!
<re_irc_> <@a​damgreig:m​atrix.org> if anyone has any other announcements, now's the time
<re_irc_> <@d​irbaio:m​atrix.org> multicore 😍
<re_irc_> <@a​damgreig:m​atrix.org> multicore + sequences => rp2040 support in mainline
<re_irc_> <@a​damgreig:m​atrix.org> I feel like there should probably be something besides embedded-hal, but what is it...
<re_irc_> <@l​achlansneff:m​atrix.org> I wonder if embedded-nal should be discussed in these meetings too
<re_irc_> <@t​herealprof:m​atrix.org> How's the blog coming along? 😛
<re_irc_> <@a​damgreig:m​atrix.org> I guess technically it's an r-e-c project and i wouldn't wanna butt in on their stuff but happy to discuss specific things if you want to :)
<re_irc_> <@a​damgreig:m​atrix.org> therealprof: 🙈 well, we added the probe-rs release announcement...
<re_irc_> <@l​achlansneff:m​atrix.org> Is there a process for lifting projects from r.e.c to e.c. ?
<re_irc_> <@l​achlansneff:m​atrix.org> Not sure if they'd want to do that, just curious
<re_irc_> <@a​damgreig:m​atrix.org> I think last time it was discussed we worked out it would be the same as any other project, i.e. an rfc adding the repo to the relevant team's list and that team voting to approve
<re_irc_> <@l​achlansneff:m​atrix.org> Gotcha, thanks
<re_irc_> <@a​damgreig:m​atrix.org> ok, well, let's get back to some of the open embedded-hal things I guess
<re_irc_> <@a​damgreig:m​atrix.org> there's the async traits, and also the new prs on separate-buffers spi and changing the return type of blocking::spi
<re_irc_> <@a​damgreig:m​atrix.org> honestly I guess last I looked most of them were progressing ok in the pr itself, are there any details that we should try and clear up a bit further now?
<re_irc_> <@l​achlansneff:m​atrix.org> I think the key bit is whether the spi traits can do partial read/writes.
<re_irc_> <@d​irbaio:m​atrix.org> they can't
<re_irc_> <@d​irbaio:m​atrix.org> rereturning the slice is completely redundant
<re_irc_> <@l​achlansneff:m​atrix.org> or the length
<re_irc_> <@l​achlansneff:m​atrix.org> I agree about returning a slice now
cr1901 has joined #rust-embedded
<re_irc_> <@l​achlansneff:m​atrix.org> The issue I can think of with enforcing complete reads is that you can't really read an unknown amount of data without doing it byte-wise.
<re_irc_> <@d​irbaio:m​atrix.org> you read N bytes, the peripehral clocks the bus for N*8 cycles and gives you N bytes, period
<re_irc_> <@l​achlansneff:m​atrix.org> So, we'd need a separate trait for non-dma, partial reads?
<re_irc_> <@d​irbaio:m​atrix.org> you're supposed to know how much data you want to read upfront
<re_irc_> <@d​irbaio:m​atrix.org> if you don't know, then read to a 1-byte slice in a loop
<re_irc_> <@d​irbaio:m​atrix.org> no need for separate trait
<re_irc_> <@l​achlansneff:m​atrix.org> 👍️
<re_irc_> <@d​irbaio:m​atrix.org> not knowing the size upfront for SPI is very rare
<re_irc_> <@d​irbaio:m​atrix.org> thankfully UART crap like "read until newline" is not common on SPI 🤣
<re_irc_> <@l​achlansneff:m​atrix.org> Good point
<re_irc_> <@d​irbaio:m​atrix.org> (AT commands 🤮)
<re_irc_> <@l​achlansneff:m​atrix.org> yuck
<re_irc_> <@l​achlansneff:m​atrix.org> Been dealing with those a lot recently
<re_irc_> <@d​irbaio:m​atrix.org> related: what happened to these? I thought they were ready to go in, but they seem to have stuck
<re_irc_> <@d​irbaio:m​atrix.org> https://github.com/rust-embedded/embedded-hal/pull/280
<re_irc_> <@d​irbaio:m​atrix.org> https://github.com/rust-embedded/embedded-hal/pull/282
<re_irc_> <@l​achlansneff:m​atrix.org> Is the naming decided then?
<re_irc_> <@d​irbaio:m​atrix.org> yea, it was decided to allow "collisions" between different flavors of the same trait (blocking, nb, futures)
<re_irc_> <@a​damgreig:m​atrix.org> I think those just need someone to merge them, maybe therealprof could have a quick look?
<re_irc_> <@d​irbaio:m​atrix.org> and this one got merged https://github.com/rust-embedded/embedded-hal/pull/281
<re_irc_> <@l​achlansneff:m​atrix.org> What about the naming of the spi traits.
<re_irc_> <@l​achlansneff:m​atrix.org> It seems like it's `Transfer` and `TransferInPlace` now?
<re_irc_> <@d​irbaio:m​atrix.org> ah you're talking about #287 now
<re_irc_> <@l​achlansneff:m​atrix.org> Oh yes, sorry/
<re_irc_> <@j​amesmunns:m​atrix.org> oh, might be off topic
<re_irc_> <@d​irbaio:m​atrix.org> yeah I changed it from ReadWrite to Transfer, it seems to have more consensus and is in line with the old naming which is nice
<re_irc_> <@j​amesmunns:m​atrix.org> but I think we probably want a trait for "double buffered dma" actions
<re_irc_> <@t​herealprof:m​atrix.org> adamgreig: Sorry wasn't paying attention, 280 and/or 282?
<re_irc_> <@j​amesmunns:m​atrix.org> e.g. you are actively transferring to one buffer, and the hw will auto-swap to the next at some point
<re_irc_> <@a​damgreig:m​atrix.org> therealprof: yep
<re_irc_> <@j​amesmunns:m​atrix.org> I have this implemented for nrf's SPIM and SAADC peripherals, we call it `TransferPending`, but yeah.
<re_irc_> <@j​amesmunns:m​atrix.org> I can share the code for that if anyone wants to see the pattern. Feel free to ignore if too off-topic now.
<re_irc_> <@a​damgreig:m​atrix.org> as a generic trait in e-h? what would the trait interface look like?
<re_irc_> <@d​irbaio:m​atrix.org> jamesmunns: I think that's a bit out of scope of embedded-hal, as it's very specialized. HALs can offer a hardware-specific API doing that, it doesn't have to be a trait
<re_irc_> <@j​amesmunns:m​atrix.org> Yup, that's fair
<re_irc_> <@j​amesmunns:m​atrix.org> I just figured if we were talking about locking in DMA-friendly naming conventions
<re_irc_> <@j​amesmunns:m​atrix.org> back-to-back transfers are probably not TOO uncommon
<re_irc_> <@a​damgreig:m​atrix.org> wonder if double-buffered or circular buffered would be more helpful.. i guess sort of much of a muchness
<re_irc_> <@d​irbaio:m​atrix.org> circular buffer is super hard with rust borrow guarantees 🤣
<re_irc_> <@a​damgreig:m​atrix.org> for things that need to stream continuously like an ADC it could be quite useful
<re_irc_> <@a​damgreig:m​atrix.org> (double buffering I mean)
<re_irc_> <@a​damgreig:m​atrix.org> perhaps for device-initiated things like spi and uart traits it's less important
<re_irc_> <@t​herealprof:m​atrix.org> adamgreig: We really should have the CHANGELOG.md check in there. Both of them are missing CHANGELOG.md and I almost missed it. Luckily(?) bors didn't react...
<re_irc_> <@a​damgreig:m​atrix.org> but adc, spi peripherals, maybe uart reception, it can be essential to always have one buffer on-the-go
<re_irc_> <@j​amesmunns:m​atrix.org> I can't remember how I did that for sprocket-boot's reception, but probably just always blocking
<re_irc_> <@t​halesfragoso:m​atrix.org> adamgreig: heh, I've done double buffering drivers, but only with three buffers >_>
<re_irc_> <@a​damgreig:m​atrix.org> triple buffering, the extra buffer is for extra safety :P
<re_irc_> <@a​damgreig:m​atrix.org> must sacrifice one buffer to the borrowck gods
<re_irc_> <@t​halesfragoso:m​atrix.org> haha, but your idea was also nice, to write an invalid value to cause a DMA error
<re_irc_> <@t​halesfragoso:m​atrix.org> people are using on the H7, so you can make `next_transfer_with` safe, but still you can't do much, if you take too long you will miss the bus...
<re_irc_> <@a​damgreig:m​atrix.org> i like that it still gives you memory safety while letting the hal return a buffer to the user, i guess, though i was interested to see a report recently that someone found they got much better performance doing things a bit differently
<re_irc_> <@t​halesfragoso:m​atrix.org> hmm, really ?
<re_irc_> <@a​damgreig:m​atrix.org> https://github.com/stm32-rs/stm32h7xx-hal/pull/226
<re_irc_> <@a​damgreig:m​atrix.org> apparently 5x speedup which seems wild
<re_irc_> <@a​damgreig:m​atrix.org> but i guess depends a lot on how big your buffers are and how often you have to swap them around
<re_irc_> <@t​halesfragoso:m​atrix.org> that doesn't seem very safe...
<re_irc_> <@j​amesmunns:m​atrix.org> For the code that is using that SPIM driver, I'm just using a heapless-pool to allocate 4k pages
<re_irc_> <@t​halesfragoso:m​atrix.org> I mean, safe yeah
<re_irc_> <@t​halesfragoso:m​atrix.org> correct without fences, shaky
<re_irc_> <@j​amesmunns:m​atrix.org> so it just runs around trying to get back up to two-pending-buffers at all times
<re_irc_> <@a​damgreig:m​atrix.org> "oh we're not hard real-time" "...but if we take more than 100µs to process this buffer, our dma engine will overwrite memory we were using"
<re_irc_> <@a​damgreig:m​atrix.org> ooops, all real-time
<re_irc_> <@t​halesfragoso:m​atrix.org> yeah, it's nicer to do with a pool, I've seen that on the L0 driver
<re_irc_> <@a​damgreig:m​atrix.org> classic thing with double buffering in c, so i guess it's nice that the safe rust interfaces do prevent that
<re_irc_> <@t​halesfragoso:m​atrix.org> also on the embassy ethernet driver, we also use a pool
<re_irc_> <@t​halesfragoso:m​atrix.org> but then it's a bit hard to control because the "allocation" can fail
<re_irc_> <@a​damgreig:m​atrix.org> thalesfragoso: yea, it's not a safe method, the comments say "/// NOTE(unsafe): Memory safety is not guaranteed." 💀
<re_irc_> <@t​halesfragoso:m​atrix.org> adamgreig: I mean, but I think it's still need some DMBs
<re_irc_> <@a​damgreig:m​atrix.org> it has a note about that too
<re_irc_> <@t​halesfragoso:m​atrix.org> not sure if DMB itself, but at least compiler_fences
<re_irc_> <@t​halesfragoso:m​atrix.org> which should degrade the speed
<re_irc_> <@a​damgreig:m​atrix.org> not sure why it says to put compiler_fence into the user code instead of just putting it into the closure
<re_irc_> <@t​halesfragoso:m​atrix.org> if it does something is wrong...
<re_irc_> <@t​halesfragoso:m​atrix.org> I think the dmb is needed though, the write buffer can delay a write to the buffer before writing the enable in the DMA
<re_irc_> <@t​halesfragoso:m​atrix.org> anyways, probably got a bit side tracked
<re_irc_> <@d​irbaio:m​atrix.org> therealprof: added changelog
<re_irc_> <@l​achlansneff:m​atrix.org> I'll change the names of the async spi traits to match #287
<re_irc_> <@g​rantm11235:m​atrix.org> Speaking of e-h, I notice that it is impossible to impl the blocking spi traits generically over word size
<re_irc_> <@g​rantm11235:m​atrix.org> struct GenericSpiDevice<W>(core::marker::PhantomData<W>);
<re_irc_> <@g​rantm11235:m​atrix.org> ```rust
<re_irc_> <@g​rantm11235:m​atrix.org> impl<W> embedded_hal::blocking::spi::Write<W> for GenericSpiDevice<W> {
<re_irc_> <@g​rantm11235:m​atrix.org> type Error = ();
<re_irc_> <@g​rantm11235:m​atrix.org> error[E0119]: conflicting implementations of trait `embedded_hal::prelude::_embedded_hal_blocking_spi_Write<_>` for type `GenericSpiDevice<_>`:
<re_irc_> <@g​rantm11235:m​atrix.org> --> src/lib.rs:3:1
<re_irc_> <@g​rantm11235:m​atrix.org> |
<re_irc_> <@g​rantm11235:m​atrix.org> 3 | impl<W> embedded_hal::blocking::spi::Write<W> for GenericSpiDevice<W> {
<re_irc_> <@g​rantm11235:m​atrix.org> I don't have time to do a full writeup of the issue, so I thought I could at least mention it in the meeting
<re_irc_> <@l​achlansneff:m​atrix.org> Should I get rid of the `MaybeUninit` usage in the async spi traits?
<re_irc_> <@d​irbaio:m​atrix.org> Lachlan Sneff: probably, it can be added later to all traits (blocking + async) if there's consensus on how to do it
<re_irc_> <@t​halesfragoso:m​atrix.org> yeah, and casting u8 to MaybeUninit<u8> might be unsound in some cases .-.
<re_irc_> <@l​achlansneff:m​atrix.org> Really?
<re_irc_> <@l​achlansneff:m​atrix.org> That's disappointing
<re_irc_> <@t​herealprof:m​atrix.org> e-h PRs are merged.
<re_irc_> <@t​halesfragoso:m​atrix.org> I think if the other side calls MaybeUninit::uninit() on it then you can go back
<re_irc_> <@t​halesfragoso:m​atrix.org> the problem is probably going back
<re_irc_> <@d​irbaio:m​atrix.org> GrantM11235: wow that's extremely disappointing
<re_irc_> <@d​irbaio:m​atrix.org> I don't get why though
<re_irc_> <@t​halesfragoso:m​atrix.org> I heard something about it but now I can't remember exactly, but maybe if the API guarantees that after finishing all items will be init, then it might be okay
<re_irc_> <@d​irbaio:m​atrix.org> shouldn't the downstream crate be the one getting the "conflicting impl" error if it tries to impl that?
<re_irc_> <@l​achlansneff:m​atrix.org> Yea, that's a weird error.
<re_irc_> <@g​rantm11235:m​atrix.org> It's because of the weird opt-in blocking::spi::Default trait
<re_irc_> <@l​achlansneff:m​atrix.org> Those were pretty annoying when I was trying to write the async versions, so I just didn't add those
<re_irc_> <@t​halesfragoso:m​atrix.org> maybe because if W is a downstream type then they can implement it
<re_irc_> <@d​irbaio:m​atrix.org> maybe the Default thing should be removed?
<re_irc_> <@d​irbaio:m​atrix.org> it encourages writing the `nb` impl as the One True Impl and deriving the blocking one from it
<re_irc_> <@l​achlansneff:m​atrix.org> Yes
<re_irc_> <@g​rantm11235:m​atrix.org> dirbaio: Yeah, it doesn't even save that much boilerplate anyway
<re_irc_> <@l​achlansneff:m​atrix.org> I vote for removing it
<re_irc_> <@d​irbaio:m​atrix.org> while I'd rather have the ecosystem move away from `nb` :D
<re_irc_> <@d​irbaio:m​atrix.org> also once `futures` traits is in there might be another Default deriving `blocking` from the `futures` ones
<re_irc_> <@l​achlansneff:m​atrix.org> I'd suggest not doing that, but would definitely be possible.
<re_irc_> <@d​irbaio:m​atrix.org> and there's hardware where you can't use the `Default` anyway
<re_irc_> <@d​irbaio:m​atrix.org> nrf's can only do DMA
starblue has quit [Ping timeout: 252 seconds]
<re_irc_> <@a​damgreig:m​atrix.org> I have to run, thanks everyone for attending!
starblue has joined #rust-embedded
<re_irc_> <@t​halesfragoso:m​atrix.org> thanks adam
<re_irc_> <@l​achlansneff:m​atrix.org> Thank you for helping organize this chaos
<re_irc_> <@t​halesfragoso:m​atrix.org> dirbaio: addition no, but maybe division... (looks at the rp2040)
<re_irc_> <@a​damgreig:m​atrix.org> 😅 it's nice to see a lot of movement on embedded-hal!
<re_irc_> <@d​irbaio:m​atrix.org> yea the rp2040 is just WTF
<re_irc_> <@t​halesfragoso:m​atrix.org> why go for thumbv7 if you can plug a peripheral for doing divisions, right ?
<re_irc_> <@g​rantm11235:m​atrix.org> Does anyone else want to make a PR to remove the default traits? If not, I can probably do it Eventually ™️
<re_irc_> <@l​achlansneff:m​atrix.org> I don't really know anything about the rp2040, what's wrong with it?
<re_irc_> <@d​irbaio:m​atrix.org> GrantM11235: go for it, you have my emotional support
<re_irc_> <@d​irbaio:m​atrix.org> I predict it'll be controversial though
<re_irc_> <@l​achlansneff:m​atrix.org> I can go ahead and make the PR if you don't get to it first
<re_irc_> <@d​irbaio:m​atrix.org> the weird rp2040 stuff is probably because they weren't able to get a good deal on cortex m4 or higher licensing..?
<re_irc_> <@t​halesfragoso:m​atrix.org> even a M3 would make sense
<re_irc_> <@t​halesfragoso:m​atrix.org> Lachlan Sneff: thumbv6 doesn't have an instruction for division, so they made a hardware peripheral for that
<re_irc_> <@g​rantm11235:m​atrix.org> Maybe they were just having fun designing peripherals
<re_irc_> <@l​achlansneff:m​atrix.org> thalesfragoso: wat
<re_irc_> <@t​halesfragoso:m​atrix.org> GrantM11235: I can relate to that, hehe
<re_irc_> <@l​achlansneff:m​atrix.org> why not switch to a newer isa?
<re_irc_> <@d​irbaio:m​atrix.org> ah true the M3 is included in that ARM "super easy to get started licensing stuff" right?
<re_irc_> <@d​irbaio:m​atrix.org> no idea why did they go with the m0 then
<re_irc_> <@d​irbaio:m​atrix.org> silicon area..?
<re_irc_> <@t​halesfragoso:m​atrix.org> M0 is marketed as low power too
<re_irc_> <@d​irbaio:m​atrix.org> but the rp2040 isn't even lowpower
<re_irc_> <@t​halesfragoso:m​atrix.org> but doesn't make much sense to have a fast dual core with it...
<re_irc_> <@t​halesfragoso:m​atrix.org> dirbaio: but you can still say it uses a low power core, haha
<re_irc_> <@d​irbaio:m​atrix.org> they market it as "low power", but in comparison to the full fat linux raspis 🤣
<re_irc_> <@t​halesfragoso:m​atrix.org> although I think doing fast, sleep more is way better
<re_irc_> <@g​rantm11235:m​atrix.org> Is the rp2040 the fastest m0 on the market?
<re_irc_> <@t​halesfragoso:m​atrix.org> probably, yes
<re_irc_> <@d​irbaio:m​atrix.org> you can definitely tell they had lots of fun designing it
<re_irc_> <@d​irbaio:m​atrix.org> the PIO and stuff
<re_irc_> <@t​halesfragoso:m​atrix.org> assembly is back in the game baby, haha
<re_irc_> <@d​irbaio:m​atrix.org> the "basic" peripherals (uart, spi, i2c) are a bit meh, you can tell they just slapped the crappiest IP they could grab on there
<re_irc_> <@d​irbaio:m​atrix.org> SPI can't transfer bytes back-to-back 🤣
<re_irc_> <@d​irbaio:m​atrix.org> which is like WTF
<re_irc_> <@g​rantm11235:m​atrix.org> I was surprised that they used any basic peripherals, I was hoping that they would do everything with PIOs
<re_irc_> <@d​irbaio:m​atrix.org> it makes some sense, PIOs must be much bigger in silicon area
<re_irc_> <@d​irbaio:m​atrix.org> so you can use the hardware uart for basic stuff and still have the PIOs free for fun stuff
<re_irc_> <@l​achlansneff:m​atrix.org> The default stuff really should be done with specialization
<re_irc_> <@d​irbaio:m​atrix.org> not likely to be stable anytime soon...
<re_irc_> <@l​achlansneff:m​atrix.org> Indeed
<re_irc_> <@g​rantm11235:m​atrix.org> dirbaio: did you see the links I posted the other day about run-to-completion futures?
<re_irc_> <@d​irbaio:m​atrix.org> yeah
<re_irc_> <@d​irbaio:m​atrix.org> I have the same q as thalesfragoso : how does that protect from mem::forget
<re_irc_> <@d​irbaio:m​atrix.org> ah you did answer it
<re_irc_> <@l​achlansneff:m​atrix.org> Can you link again?
<re_irc_> <@d​irbaio:m​atrix.org> you're simply violating the `poll` safety contract
<re_irc_> <@d​irbaio:m​atrix.org> hmm
<re_irc_> <@g​rantm11235:m​atrix.org> Lachlan Sneff: This blog post https://carllerche.com/2021/06/17/six-ways-to-make-async-rust-easier/ and this pre-rfc https://github.com/Matthias247/rfcs/pull/1
<re_irc_> <@t​halesfragoso:m​atrix.org> my following question was, how do you prevent a user from calling mem::forget in a future inside an "complete async fn"
<re_irc_> <@d​irbaio:m​atrix.org> the concern I see is that the "RunToCompletionFuture" infects everything: if you want to poll a RunToCompletionFuture deep within an `async fn` stack, you have to make them all RunToCompletionFutures
<re_irc_> <@t​halesfragoso:m​atrix.org> the complete async fn wouldn't leak but any futures inside it could be leaked
<re_irc_> <@d​irbaio:m​atrix.org> similarly for libs, they'd have to take `where F: RunToCompletionFuture` instead of `where F: Future`
<re_irc_> <@d​irbaio:m​atrix.org> and for executors, they'd have to take `RunToCompletionFutures` if they want to hope to run everything
<re_irc_> <@d​irbaio:m​atrix.org> and in cases where the end user wants to handle futures (join, select, timeouts) it's very likely that end user code will need explicit `unsafe` blocks
<re_irc_> <@t​halesfragoso:m​atrix.org> nothing prevents the user from calling mem::forget in a future inside an async fn, and the user doesn't call the unsafe poll, the executor does
<re_irc_> <@d​irbaio:m​atrix.org> thalesfragoso: the idea is if user calls `mem::forget`, they're violating the safety contract so it's "fine"
<re_irc_> <@g​rantm11235:m​atrix.org> I think the dma would need to be started at the first poll, not when the future is created
<re_irc_> <@t​halesfragoso:m​atrix.org> dirbaio: which safety contract ? they didn't call any unsafe functions to get there
<re_irc_> <@d​irbaio:m​atrix.org> they have to either `.await` the RunToCompletionFuture, in which case Rust would enforce the current `async fn` is `#[completion]`
<re_irc_> <@d​irbaio:m​atrix.org> OR
<re_irc_> <@d​irbaio:m​atrix.org> call `.poll` manually, in which case they have an `unsafe{}` block
<re_irc_> <@t​halesfragoso:m​atrix.org> hmmm
<re_irc_> <@d​irbaio:m​atrix.org> OR call something that indirectly calls `.poll`, in which case that something should be an `unsafe fn` or return an RunToCompletionFuture
<re_irc_> <@d​irbaio:m​atrix.org> so yeah, it's all technically correct
<re_irc_> <@t​halesfragoso:m​atrix.org> now makes more sense
<re_irc_> <@d​irbaio:m​atrix.org> the problem is RunToCompletionFuture infects EVERYTHING with unsafe
<re_irc_> <@d​irbaio:m​atrix.org> also
<re_irc_> <@g​rantm11235:m​atrix.org> Is there any way that it could be enforced at compile time instead of being unsafe?
<re_irc_> <@d​irbaio:m​atrix.org> canceling DMA operations is fine, as long as you call Drop
<re_irc_> <@g​rantm11235:m​atrix.org> Or is that just re-inventing an auto leak trait
<re_irc_> <@d​irbaio:m​atrix.org> what we want is "you MUST call Drop"
<re_irc_> <@t​halesfragoso:m​atrix.org> GrantM11235: Leak auto trait
<re_irc_> <@d​irbaio:m​atrix.org> what RunToCompletionFuture gives is "you MUST call poll until completion"
<re_irc_> <@t​halesfragoso:m​atrix.org> hmm, yeah, it's a bit different
<re_irc_> <@d​irbaio:m​atrix.org> DMA can be stopped on drop just fine, blocking for a little bit if needed
<re_irc_> <@t​halesfragoso:m​atrix.org> it also gets rid of async drop it seems
<re_irc_> <@g​rantm11235:m​atrix.org> That pre-rfc and blog post both mention cancelable run-to-completion futures
<re_irc_> <@d​irbaio:m​atrix.org> yeah, I'm very not convinced about that part :S
<re_irc_> <@d​irbaio:m​atrix.org> "cancelable RunToCompletionFuture" is "like async Drop, but only for Futures"
<re_irc_> <@g​rantm11235:m​atrix.org> Basically, you signal the future that it should cancel, then await the future until it cooperatively cancels
<re_irc_> <@d​irbaio:m​atrix.org> want to async close a `std::fs::File` on drop? you can't
tokomak has quit [Ping timeout: 256 seconds]
<re_irc_> <@g​rantm11235:m​atrix.org> Futures yield cooperatively, so it makes sense to me that they would be cancelled cooperatively too
<re_irc_> <@d​irbaio:m​atrix.org> my point is if we had "async drop", it'd be useful for futures and other things
<re_irc_> <@d​irbaio:m​atrix.org> so "cancelable RunToCompletionFutures" would no longer be needed, they'd use "async drop" like everything else
<re_irc_> <@g​rantm11235:m​atrix.org> Hmm, the difference between a cancellable future and a droppable future is that a cancellable future returns something after it is cancelled. I'm not sure if this is an important difference.
<re_irc_> <@d​irbaio:m​atrix.org> ah right
<re_irc_> <@d​irbaio:m​atrix.org> yeah, subtle distinctions :S
<re_irc_> <@d​irbaio:m​atrix.org> in embassy a while ago we had that
<re_irc_> <@d​irbaio:m​atrix.org> an "uart read slice" future that you could `.stop()` to make it return how many bytes have been read (it'd wait until the full slice had been read otherwise)
<re_irc_> <@g​rantm11235:m​atrix.org> But if it just returned a "cancelled" error, then there isn't much practical difference
<re_irc_> <@d​irbaio:m​atrix.org> but that's "orthogonal" to RunToCompletionFutures right?
<re_irc_> <@d​irbaio:m​atrix.org> like, that could be used for normal Futures
<re_irc_> <@g​rantm11235:m​atrix.org> Yeah
<re_irc_> <@d​irbaio:m​atrix.org> dunno
<re_irc_> <@d​irbaio:m​atrix.org> my main criticism is that infecting everything with unsafe is not very rusty
<re_irc_> <@d​irbaio:m​atrix.org> not for something as foundational as futures
<re_irc_> <@d​irbaio:m​atrix.org> everything else is kinda bikeshedding
<re_irc_> <@g​rantm11235:m​atrix.org> Does it infect "everything" or just executors and some combinators?
<re_irc_> <@d​irbaio:m​atrix.org> all executors, all combinators, all async fns in user code
<re_irc_> <@d​irbaio:m​atrix.org> I think that qualifies as "everything" :D
<re_irc_> <@d​irbaio:m​atrix.org> like
<re_irc_> <@d​irbaio:m​atrix.org> libs will want to work with both Future and RunToCompletionFuture
<re_irc_> <@d​irbaio:m​atrix.org> so they'll take and return RunToCompletionFuture
<re_irc_> <@d​irbaio:m​atrix.org> (or alternatively have a Future and a RunToCompletionFuture version of everything, which is not nice either)
<re_irc_> <@d​irbaio:m​atrix.org> so as a user, as soon as you call one of these libs, you now have to make all your `async fns` to be `#[completion]`
<re_irc_> <@d​irbaio:m​atrix.org> and at the very top level switch to an executor that takes RunToCompletionFuture instead of Future
<re_irc_> <@d​irbaio:m​atrix.org> or for example, the embedded-hal traits
<re_irc_> <@g​rantm11235:m​atrix.org> dirbaio: But that doesn't require any `unsafe`, does it?
<re_irc_> <@d​irbaio:m​atrix.org> they'll return RunToCompletionFuture instead of Future
<re_irc_> <@d​irbaio:m​atrix.org> to acommodate DMA impls
<re_irc_> <@d​irbaio:m​atrix.org> so you're stuck with RunToCompletionFutures even if your particular impl doesn't use DMA
<re_irc_> <@d​irbaio:m​atrix.org> how would you do `select` with RunToCompletionFutures?
<re_irc_> <@d​irbaio:m​atrix.org> it HAS to have unsafe in user code
<re_irc_> <@d​irbaio:m​atrix.org> because you can give it a RunToCompletionFuture, have it poll a bit, then return it back to you before finishing, then drop it
<re_irc_> <@d​irbaio:m​atrix.org> if you store a RunToCompletionFuture in a struct of yours, now you have to make methods that poll the future `unsafe`
<re_irc_> <@d​irbaio:m​atrix.org> those two things are rather common
<re_irc_> <@d​irbaio:m​atrix.org> sometimes you manipulate futures in ways that are not just `.await`ing them, many of these become unsafe with RunToCompletionFuture
<re_irc_> <@g​rantm11235:m​atrix.org> That blog post suggests changing `select` to only allow abort-safe futures, and turning run-to-completion futures into abort-safe futures by spawning and joining a new task
<re_irc_> <@g​rantm11235:m​atrix.org> Does spawning new tasks require alloc?
<re_irc_> <@d​irbaio:m​atrix.org> I guess yeah
<re_irc_> <@d​irbaio:m​atrix.org> it's made abort-safe because if the current future gets aborted that child future keeps running right?
<re_irc_> <@d​irbaio:m​atrix.org> the memory for that child future needs to come from the heap then...
<re_irc_> <@d​irbaio:m​atrix.org> you could make like embassy executor does for toplevel tasks: define a static to store the future there
<re_irc_> <@d​irbaio:m​atrix.org> but then it can fail if that static is already being used for another future
<re_irc_> <@g​rantm11235:m​atrix.org> I think I am coming back around to the auto leak trait idea lol
<re_irc_> <@d​irbaio:m​atrix.org> 🤣
<re_irc_> <@d​irbaio:m​atrix.org> it's for different usecases though...
<re_irc_> <@d​irbaio:m​atrix.org> `Leak` would allow safe+ergonomic dma impls
<re_irc_> <@d​irbaio:m​atrix.org> but the "block on Drop" problem remains
<re_irc_> <@d​irbaio:m​atrix.org> I think that problem is bigger for big-server std workloads than for embedded though
<re_irc_> <@d​irbaio:m​atrix.org> and could be solved by async drop or by cancelation tokens or whatever
<re_irc_> <@d​irbaio:m​atrix.org> I don't really care about async drop personally though 🤣
<re_irc_> <@g​rantm11235:m​atrix.org> I still think that cooperative cancellation is nicer than the current norm where you just stop polling, but I guess it is too late for that to change
<re_irc_> <@d​irbaio:m​atrix.org> yeah...
<re_irc_> <@d​irbaio:m​atrix.org> it makes sense though, if you want Futures to be regular Rust objects
<re_irc_> <@d​irbaio:m​atrix.org> all Rust objects can be dropped...
<re_irc_> <@d​irbaio:m​atrix.org> futures in most other languages have some "black magic" that runs them out of your control
<re_irc_> <@d​irbaio:m​atrix.org> the js event loop, the Go runtime...
<re_irc_> <@d​irbaio:m​atrix.org> in rust they're plain old objects, no magic "runtime" neede
<re_irc_> <@d​irbaio:m​atrix.org> that's what makes rust async awesome for embedded :D
<re_irc_> <@d​irbaio:m​atrix.org> people want Rust async to be like Go or JS
<re_irc_> <@d​irbaio:m​atrix.org> it's just not
<re_irc_> <@g​rantm11235:m​atrix.org> IDK, `RawWakerVTable` still looks a bit like magic to me 🤣
<re_irc_> <@b​obmcwhirter:m​atrix.org> it's really just function pointers, at the end of the day
<re_irc_> <@g​rantm11235:m​atrix.org> When I see too many asterisks, my eyes start to glaze over
<re_irc_> <@d​irbaio:m​atrix.org> the waker black magic stuff is just
<re_irc_> <@d​irbaio:m​atrix.org> a manually-written vtable, like the one you get with `dyn`
<re_irc_> <@d​irbaio:m​atrix.org> most executors write the vtable so wakers behave like `Arc<dyn Waker>`
<re_irc_> <@d​irbaio:m​atrix.org> embassy makes it behave like `&'static dyn Task`
<re_irc_> <@d​irbaio:m​atrix.org> they could've made Waker be just `Arc<dyn Wake>` but this way it's possible to write executors that don't need alloc which is awesome
<re_irc_> <@l​achlansneff:m​atrix.org> Sometimes I wish that the it was a trait instead and `poll` had a type parameter for it so there could be no vtable overhead in certain cases.
<re_irc_> <@l​achlansneff:m​atrix.org> But that boat has sailed
<re_irc_> <@d​irbaio:m​atrix.org> that wouldn't really work
<re_irc_> <@l​achlansneff:m​atrix.org> Perhaps not
<re_irc_> <@d​irbaio:m​atrix.org> executors often create different waker vtables for each task
<re_irc_> <@l​achlansneff:m​atrix.org> In the case of a static executor, it might work but
<re_irc_> <@d​irbaio:m​atrix.org> so if it wasn't vtable-based, polling the same fut from 2 different tasks would duplicate the entire code for the fut
<re_irc_> <@l​achlansneff:m​atrix.org> Indeed, that's true
<re_irc_> <@d​irbaio:m​atrix.org> also how would you store wakers?
<re_irc_> <@l​achlansneff:m​atrix.org> Good point
<re_irc_> <@d​irbaio:m​atrix.org> that's why it's type-erased to the max :S
<re_irc_> <@d​irbaio:m​atrix.org> also you wouldn't be able to do `dyn Future`
<re_irc_> <@l​achlansneff:m​atrix.org> Also a good point
<re_irc_> <@l​achlansneff:m​atrix.org> Did any of you see that Pre-RFC or post or something that suggested changing the way Futures are structured internally so instead of an enum, it was an indirect call?
<re_irc_> <@d​irbaio:m​atrix.org> no?
<re_irc_> <@l​achlansneff:m​atrix.org> I think it was a year or two ago
<re_irc_> <@d​irbaio:m​atrix.org> does CYCCNT work inside QEMU? asking just in case so I don't waste time if it doesn't 🤣
<re_irc_> <@d​irbaio:m​atrix.org> and is it accurate? or should I test on real hardware?
<re_irc_> <@j​amesmunns:m​atrix.org> I don't think it does
<re_irc_> <@j​amesmunns:m​atrix.org> rtic's docs talk about that?
<re_irc_> <@s​irhcel:m​atrix.org> I'm thinking about adding support for rs-485/half-duplex with transmitter control to `stm32f3xx-hal`s `Serial`. I wanted to take a look on how other hals implement this. But my search on github did not show up anything related to rs-485 in `stm32-rs` and `nrf-rs` and I'm a bit puzzled now. Did I miss the...
<re_irc_> ... obvious? Or could it be that there is no support for rs-485 in these hals?
<re_irc_> <@d​irbaio:m​atrix.org> isn't rs485 the same framing as normal uart but with different voltages?
<re_irc_> <@s​irhcel:m​atrix.org> Practically, yes and typically an external rs-485 driver ic gets used to convert between single-ended (uart side) and differential (bus side). And all the typical mcu uarts i've seen so far support the additional hardware control signal for switching between send and receive on that external transmitter.
<re_irc_> <@d​irbaio:m​atrix.org> oh hm
<re_irc_> <@d​irbaio:m​atrix.org> I haven't seen such signal in the nrfs
<re_irc_> <@d​irbaio:m​atrix.org> this sounds like something you could build on the embedded-hal uart and digital traits, so it works on any mcu
<re_irc_> <@s​irhcel:m​atrix.org> For me, using the hardware transmitter control is the interesting part. But in case of the `stm32f3xx-hal` this would require adding a third pin as type parameter and I wanted to see how other have done this.
<re_irc_> <@s​irhcel:m​atrix.org> dirbaio: That's absolutely possible and i've seen such an implementation on the esp32 whose uart does not support the control signal in hardware.
<re_irc_> <@s​irhcel:m​atrix.org> I like your idea because is sufficiently heretic to my tunnel vision focussed on just using the hardware transmitter control. :)