emerent_ has joined #rust-embedded
emerent is now known as Guest621
emerent_ is now known as emerent
Guest621 has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
fabic has joined #rust-embedded
starblue1 has joined #rust-embedded
starblue has quit [Ping timeout: 240 seconds]
tokomak has joined #rust-embedded
<re_irc_> <@s​tarthalmo:m​atrix.org> sirhcel: I think `stm32l4xx-hal` implements it. https://github.com/stm32-rs/stm32l4xx-hal/blob/9cba0fbe98cff27418459a7589f45b6153d52987/src/serial.rs#L1043
<re_irc_> <@s​irhcel:m​atrix.org> Awesome! Thank you! :)
creich has joined #rust-embedded
fabic has quit [Ping timeout: 240 seconds]
<re_irc_> <@k​orken89:m​atrix.org> I've been looking at the codegen for atomic operations for the Cortex-M, and I'm not sure why the following generate different instructions. Does anyone know?
<re_irc_> <@k​orken89:m​atrix.org> The first adds a `dmb`, while the second does not. To my understanding they should be equivalent, but I think my understanding is lacking somewhere :)
<re_irc_> <@k​orken89:m​atrix.org> ```rust
<re_irc_> <@k​orken89:m​atrix.org> a.store(val, Ordering::Release);
<re_irc_> <@k​orken89:m​atrix.org> The documentation says that the `compiler_fence` should not generate instructions - but both are related to atomics
fabic has joined #rust-embedded
<re_irc_> <@j​ordens:m​atrix.org> My understanding always was that the atomic ops also block [hardware reordering](https://doc.rust-lang.org/nomicon/atomics.html#hardware-reordering) (hence DMB) while compiler_fence doesn't.
<re_irc_> <@j​ordens:m​atrix.org> I.e. your `Release` needs to DMB.
<re_irc_> <@u​ep:m​atrix.org> fundamentally, compiler fences prevent reordering within the compiler (e.g. optimisations) and the hardware barrier prevents reordering within hardware (which it needs to be told about)
<re_irc_> <@r​yan-summers:m​atrix.org> Yeah, the docs related to ordering talk about this a bit as well. https://doc.rust-lang.org/nomicon/atomics.html
<re_irc_> <@r​yan-summers:m​atrix.org> Specifically, the ordering /atomic docs talk about what types of fences are placed under which ordering semantics
<re_irc_> <@r​yan-summers:m​atrix.org> Also, just realized that jordens link is a subsection of what I just linked.... But yeah, it's my understanding as well that it's hardware related
<re_irc_> <@k​orken89:m​atrix.org> Hmm I see
<re_irc_> <@k​orken89:m​atrix.org> I'm looking into when the `dmb` is needed, and in the case of non-multicore MCUs it's never needed
<re_irc_> <@k​orken89:m​atrix.org> But when it comes to multicore Cortex-Ms they usually have their own "synchroniztion" hardware
<re_irc_> <@k​orken89:m​atrix.org> It's difficult to get the info though...
<re_irc_> <@k​orken89:m​atrix.org> Maybe one needs to lay the choice on the user, but I'd rather not.
<re_irc_> <@j​ordens:m​atrix.org> Are you sure that DMB is not needed? E.g. you might not be racing another CPU but a DMA core.
<re_irc_> <@k​orken89:m​atrix.org> (if possible)
<re_irc_> <@k​orken89:m​atrix.org> This can only happen if the datastructure supports DMA, which in my case it does not
<re_irc_> <@k​orken89:m​atrix.org> (I'm looking into readding the `SingleCore` support in the `heapless::Queue`)
<re_irc_> <@j​ordens:m​atrix.org> Ok. But "non-multicore MCUs" isn't a sufficient condition to discard barriers.
<re_irc_> <@k​orken89:m​atrix.org> It should be, as the core is a single execution context and uses a single memory bus
<re_irc_> <@j​ordens:m​atrix.org> But your statement that "`dmb` is never needed in the case of non-multicode MCUs" isn't correct.
<re_irc_> <@k​orken89:m​atrix.org> Or did you have something different in mind?
<re_irc_> <@j​ordens:m​atrix.org> That being said: very nice idea to optimize `heapless:Queue` for single-core!
<re_irc_> <@k​orken89:m​atrix.org> The reference manual for instructions is not very helpful though :P
<re_irc_> <@j​ordens:m​atrix.org> And for `Queue`s of `Box` (`Pool` ) (for e.g. DMA) you still want barriers for the inner mutability, right?
<re_irc_> <@j​ordens:m​atrix.org> The lack of clear detailed documentation on the insns is really disappointing. It seems to be best to resort to reading LLVM code to deduce the needed info.
<re_irc_> <@k​orken89:m​atrix.org> Should not matter for the Queue
<re_irc_> <@k​orken89:m​atrix.org> It only cares for the correct indexes, however the DMA impl needs to understand the MCU
<re_irc_> <@j​ordens:m​atrix.org> Not for the `Queue` but for the application using the items in the queue.
<re_irc_> <@k​orken89:m​atrix.org> Like with an M7 where the cache can do weird things
<re_irc_> <@k​orken89:m​atrix.org> jordens: This is up to the data structure you put in the queue/pool to upkeep
<re_irc_> <@k​orken89:m​atrix.org> The pool / queue does not understand DMA for example
<re_irc_> <@j​ordens:m​atrix.org> Also, for example lack of cycle counts for instructions on M7. I get that it's not fixed in some cases but in many cases it is.
<re_irc_> <@k​orken89:m​atrix.org> But if you put a `DMAFrame` in the data structure which handles the "DMA understanding" all is fine
<re_irc_> <@k​orken89:m​atrix.org> jordens: Yeah, quite frustrating
fabic has quit [Ping timeout: 265 seconds]
<re_irc_> <@r​yan-summers:m​atrix.org> In general, DMB is necessary to syncrhonize all of the AMBA bus masters
<re_irc_> <@r​yan-summers:m​atrix.org> That may be a CPU core, DMA engine, peripheral, flash bank, etc. There's a lot of potential bus masters
<re_irc_> <@r​yan-summers:m​atrix.org> Replace AMBA with AXI
<re_irc_> <@k​orken89:m​atrix.org> Indeed
<re_irc_> <@k​orken89:m​atrix.org> I like this document, best I found so far on this topic https://developer.arm.com/documentation/dai0321/a/
fabic has joined #rust-embedded
re_irc_ has quit [Ping timeout: 268 seconds]
re_irc has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
SomeWeirdAnon has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc> <@b​arafael:m​atrix.org> Can anybody recommend a good GPS module with good rust embedded-hal driver support?
<re_irc> <@b​arafael:m​atrix.org> I'm looking for anything recent, reliable, accurate...
<re_irc> <@b​arafael:m​atrix.org> on awesome-embedded-rust, there is no mention of GPS, but i saw a number of crates
<agg> there's a bunch of NMEA parsers on crates.io that might work with standard GPA modules that output NMEA strings
<agg> and there's also a ublox crate that uses the UBX protocol for ublox modules, and the ublox-core crate that seems to be a ublox driver (though I've not tried any of those)
<re_irc> <@a​damgreig:m​atrix.org> barafael: I've not used any, but there's the `nmea` crate that should parse most GPS modules that emit NMEA strings, and also there's a `ublox` crate that advertises no_std support for ublox modules and ublox-core crate that uses embedded-hal for ublox-m8 modules
<re_irc> <@f​irefrommoonlight:m​atrix.org> sirhcel I don't have a RM on me now, but IIRC the only hardware thing stm32 provides is hardware DE
<re_irc> <@f​irefrommoonlight:m​atrix.org> For rs
<re_irc> <@f​irefrommoonlight:m​atrix.org> So, it'll manage the DE pin on your RS IC so you don't need to do it manually
<re_irc> <@b​arafael:m​atrix.org> I'm aware of these :) I even made some small changes to ublox. Was looking for some practical experience with some modules
<re_irc> <@a​damgreig:m​atrix.org> I'd probably go with the ublox modules, then, like the max-m8q
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
<agg> (test, ignore)
<agg> hifi: hm, none of these messages are going through, even though there's still an agg user in the matrix room, and running 'raw names #rust-embedded' shows agg on the irc userlist
<agg> (have just restarted heisenbridge with the latest git version, to see if that helped, too)
<agg> could still be something up with dendrite though :/
<hifi> my money is on dendrite since this is the only channel/room combination with this issue as far as I know
<agg> hah, your message is getting bridged fine, just not mine :(
<agg> will see if I can figure out anything else dendrite is messing up
<hifi> if your user shows up in the joined_members list but it fails to send a message for some reason (does heisenbridge log anything?)
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
<agg> testing
<agg> it seems to be trying to PUT a transaction to the homeserver for each of my messages
<agg> and gets a 200 back
<agg> so, yea, dendrite...
<agg> (testing)
<agg> meh, restarting dendrite hasn't helped
<agg> seems to be basically a problem for my user, will look into it more later
<hifi> I think this is a serious bug in dendrite if this is in fact the case
<hifi> though I'm not sure how many bridges are actually used with dendrite right now, it may not be thoroughly tested
<re_irc> <@h​ifi:v​i.fi> (we're talking on IRC with agg not being able to send messages through the bridge)
<re_irc> <@s​irhcel:m​atrix.org> firefrommoonlight: Thank you! :) That's the thing i'm looking for. The stm32f303 usarts which support de even go a step further and provide hardware support for the modbus rtu timeouts. I have not played around with this feature but this could safe a timer.
<re_irc> <@s​irhcel:m​atrix.org> starthalmo: This implementation looks really great. I did not know that one can implement traits for tuples. I had something like this in my mind when looking for examples. Interestingly, the github search showed nothing wen searching for _485_ despite the referenced line contains _RS485_.
<re_irc> <@s​irhcel:m​atrix.org> Thank you all dirbaio , @starthalmo, and firefrommoonlight very much for your input! Now i've got the luxury problem which one to tackle at first.
<re_irc> <@l​achlansneff:m​atrix.org> I'm curious what people are thinking wrt to the async SPI PR. Is that something that is going to get merged before GATs are stabilized or not?
<re_irc> <@r​yan-summers:m​atrix.org> I think it would help the merging case if there were some demonstrated gating impl? Just a personal thought
<re_irc> <@d​irbaio:m​atrix.org> embassy will switch over when they're merged
<re_irc> <@d​irbaio:m​atrix.org> design is almost the same as embassy-traits
<re_irc> <@d​irbaio:m​atrix.org> impls for nrf52 and soon stm32
<re_irc> <@d​irbaio:m​atrix.org> it seems people are OK with merging it before GATs are stable as long as it's behind `unstable-futures` flag
<re_irc> <@d​irbaio:m​atrix.org> alternatively maybe we could do a separate crate? and merge them into embedded-hal when GATs are stable
<re_irc> <@d​irbaio:m​atrix.org> embedded-hal-futures
<re_irc> <@d​irbaio:m​atrix.org> so we can fearlessly major-bump it
tokomak has quit [Ping timeout: 240 seconds]
fabic has quit [Remote host closed the connection]
<re_irc> <@l​achlansneff:m​atrix.org> I just had a brilliantly simple idea to get Read and Write into core.
<re_irc> <@l​achlansneff:m​atrix.org> A breaking change.
<re_irc> <@l​achlansneff:m​atrix.org> Move all the methods that use Vec and String into extension traits that are exported from the prelude
<re_irc> <@l​achlansneff:m​atrix.org> And make Error an associated type, and then reexport them from std::io using trait aliases with the Errror type set to io::Error.
<re_irc> <@l​achlansneff:m​atrix.org> Technically a breaking change, but there might not even be any crates that are broken by it.
<re_irc> <@l​achlansneff:m​atrix.org> It would need to be in an edition
fooker has quit [Ping timeout: 268 seconds]
<re_irc> <@l​achlansneff:m​atrix.org> Or, does std need to work for all editions?
<re_irc> <@d​irbaio:m​atrix.org> rust needs to support compiling current and old edition crates and link them together
<re_irc> <@d​irbaio:m​atrix.org> i'm not sure you can make std different for different editions like that
<re_irc> <@d​irbaio:m​atrix.org> i'm not awaare of any change in rust 2018 that does that
<re_irc> <@l​achlansneff:m​atrix.org> Alas
<re_irc> <@l​achlansneff:m​atrix.org> Well, trait_aliases mention that they could (but currently don't) support aliasing multiple traits together
<re_irc> <@l​achlansneff:m​atrix.org> I suppose std read could be aliased to core read + alloc readext
<re_irc> <@l​achlansneff:m​atrix.org> And that wouldn't be a breaking change
<re_irc> <@d​irbaio:m​atrix.org> can you impl a trait alias like that?
<re_irc> <@d​irbaio:m​atrix.org> like
<re_irc> <@d​irbaio:m​atrix.org> what does `impl std::io::Read for Foo` do if `std::io::Read` is a trait alias like that
<re_irc> <@l​achlansneff:m​atrix.org> I don't know
<re_irc> <@l​achlansneff:m​atrix.org> It might not be sorted out yet
<re_irc> <@d​irbaio:m​atrix.org> I don't think you can, it's not even a real trait at that point
<re_irc> <@d​irbaio:m​atrix.org> and even if you could
<re_irc> <@d​irbaio:m​atrix.org> you wouldn't be able to override all the default impls, which you can today
fooker has joined #rust-embedded
<re_irc> <@l​achlansneff:m​atrix.org> You're right, it seems like they can't be used for impls
<re_irc> <@l​achlansneff:m​atrix.org> Oh well
<re_irc> <@l​achlansneff:m​atrix.org> Separate core traits it is
<re_irc> <@d​irbaio:m​atrix.org> yeah
<re_irc> <@d​irbaio:m​atrix.org> it's so stupid :S
<re_irc> <@l​achlansneff:m​atrix.org> Rust feels like so well designed, but it's just these things, where a bit of hindsight would've gone a long way
<re_irc> <@l​achlansneff:m​atrix.org> If io::Read and io::Write might end up in core somehow, should AsyncRead and AsyncWrite get there too?
<re_irc> <@d​irbaio:m​atrix.org> well, there's no AsyncRead and AsyncWrite in std either sooo..
<re_irc> <@d​irbaio:m​atrix.org> there are talks about redesigning these
<re_irc> <@d​irbaio:m​atrix.org> might be a looooong time
<re_irc> <@l​achlansneff:m​atrix.org> dirbaio: How so?
<re_irc> <@l​achlansneff:m​atrix.org> I would actually vote for some of the net types getting into core as well
<re_irc> <@l​achlansneff:m​atrix.org> IntoSocketAddrs, IpAddr, SocketAddr, etc
<re_irc> <@d​irbaio:m​atrix.org> uuh
<re_irc> <@d​irbaio:m​atrix.org> controversial :D
<re_irc> <@l​achlansneff:m​atrix.org> Haha yes
<re_irc> <@l​achlansneff:m​atrix.org> I'm coming at it from the embedded networking angle.
<re_irc> <@l​achlansneff:m​atrix.org> There really needs to be standardization there
<re_irc> <@l​achlansneff:m​atrix.org> I guess it doesn't need to be in core, but something blessed by the rust team
<re_irc> <@d​irbaio:m​atrix.org> uh
<re_irc> <@d​irbaio:m​atrix.org> something like embedded-nal?
<re_irc> <@l​achlansneff:m​atrix.org> Well, sort of
<re_irc> <@d​irbaio:m​atrix.org> imo for many networky things you can get away with AsyncRead+AsyncWrite
<re_irc> <@l​achlansneff:m​atrix.org> Those and ToSocketAddrs would be enough I think
<re_irc> <@d​irbaio:m​atrix.org> like, abstracting the entire network stack makes sense if you want a library to use it
<re_irc> <@d​irbaio:m​atrix.org> but many (most?) libs don't want a whole network stack
<re_irc> <@d​irbaio:m​atrix.org> for example a TLS lib needs just AsyncRead+AsyncWrite
<re_irc> <@l​achlansneff:m​atrix.org> Exactly
<re_irc> <@d​irbaio:m​atrix.org> you setup the socket with your stack-specific api, then give it to the TLS lib
<re_irc> <@l​achlansneff:m​atrix.org> Yeah, embedded-nal is too much for most things
<re_irc> <@d​irbaio:m​atrix.org> maybe a trait for "send/receive packets"
<re_irc> <@d​irbaio:m​atrix.org> like AsyncRead+AsyncWrite but for packet streams, instead of byte streams
<re_irc> <@d​irbaio:m​atrix.org> dunno
<re_irc> <@l​achlansneff:m​atrix.org> Interesting idea
<re_irc> <@d​irbaio:m​atrix.org> for UDP
<re_irc> <@d​irbaio:m​atrix.org> but for TCP AsyncRead+AsyncWrite is definitely enough
<re_irc> <@l​achlansneff:m​atrix.org> Most udp stacks don't seem to expose that kind of api, do they?
<re_irc> <@t​halesfragoso:m​atrix.org> is there async rng out there ? otherwise I still think TLS shouldn't take async necessarily
<re_irc> <@d​irbaio:m​atrix.org> there will be one! in a few minutes when I'm done reviewing https://github.com/embassy-rs/embassy/pull/262
<re_irc> <@d​irbaio:m​atrix.org> ahaha
<re_irc> <@d​irbaio:m​atrix.org> and we can make the stm32 one async with the same method
<re_irc> <@t​halesfragoso:m​atrix.org> still, I think it could just take a bunch of bytes and have the processing async, I like rustls design
<re_irc> <@d​irbaio:m​atrix.org> nrf's rng also lacks dma, it's stupid :D
<re_irc> <@t​halesfragoso:m​atrix.org> like openssl with memory bio, but better
SomeWeirdAnon has quit []