<re_irc_>
<@korken89:matrix.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_>
<@korken89:matrix.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_>
<@jordens:matrix.org> I.e. your `Release` needs to DMB.
<re_irc_>
<@uep:matrix.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_>
<@ryan-summers:matrix.org> Specifically, the ordering /atomic docs talk about what types of fences are placed under which ordering semantics
<re_irc_>
<@ryan-summers:matrix.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_>
<@korken89:matrix.org> Hmm I see
<re_irc_>
<@korken89:matrix.org> I'm looking into when the `dmb` is needed, and in the case of non-multicore MCUs it's never needed
<re_irc_>
<@korken89:matrix.org> But when it comes to multicore Cortex-Ms they usually have their own "synchroniztion" hardware
<re_irc_>
<@korken89:matrix.org> It's difficult to get the info though...
<re_irc_>
<@korken89:matrix.org> Maybe one needs to lay the choice on the user, but I'd rather not.
<re_irc_>
<@jordens:matrix.org> Are you sure that DMB is not needed? E.g. you might not be racing another CPU but a DMA core.
<re_irc_>
<@korken89:matrix.org> (if possible)
<re_irc_>
<@korken89:matrix.org> This can only happen if the datastructure supports DMA, which in my case it does not
<re_irc_>
<@korken89:matrix.org> (I'm looking into readding the `SingleCore` support in the `heapless::Queue`)
<re_irc_>
<@jordens:matrix.org> Ok. But "non-multicore MCUs" isn't a sufficient condition to discard barriers.
<re_irc_>
<@korken89:matrix.org> It should be, as the core is a single execution context and uses a single memory bus
<re_irc_>
<@jordens:matrix.org> But your statement that "`dmb` is never needed in the case of non-multicode MCUs" isn't correct.
<re_irc_>
<@korken89:matrix.org> Or did you have something different in mind?
<re_irc_>
<@jordens:matrix.org> That being said: very nice idea to optimize `heapless:Queue` for single-core!
<re_irc_>
<@korken89:matrix.org> The reference manual for instructions is not very helpful though :P
<re_irc_>
<@jordens:matrix.org> And for `Queue`s of `Box` (`Pool` ) (for e.g. DMA) you still want barriers for the inner mutability, right?
<re_irc_>
<@jordens:matrix.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_>
<@korken89:matrix.org> Should not matter for the Queue
<re_irc_>
<@korken89:matrix.org> It only cares for the correct indexes, however the DMA impl needs to understand the MCU
<re_irc_>
<@jordens:matrix.org> Not for the `Queue` but for the application using the items in the queue.
<re_irc_>
<@korken89:matrix.org> Like with an M7 where the cache can do weird things
<re_irc_>
<@korken89:matrix.org> jordens: This is up to the data structure you put in the queue/pool to upkeep
<re_irc_>
<@korken89:matrix.org> The pool / queue does not understand DMA for example
<re_irc_>
<@jordens:matrix.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_>
<@korken89:matrix.org> But if you put a `DMAFrame` in the data structure which handles the "DMA understanding" all is fine
<re_irc>
<@barafael:matrix.org> Can anybody recommend a good GPS module with good rust embedded-hal driver support?
<re_irc>
<@barafael:matrix.org> I'm looking for anything recent, reliable, accurate...
<re_irc>
<@barafael:matrix.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>
<@adamgreig:matrix.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>
<@firefrommoonlight:matrix.org> sirhcel I don't have a RM on me now, but IIRC the only hardware thing stm32 provides is hardware DE
<re_irc>
<@firefrommoonlight:matrix.org> For rs
<re_irc>
<@firefrommoonlight:matrix.org> So, it'll manage the DE pin on your RS IC so you don't need to do it manually
<re_irc>
<@barafael:matrix.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>
<@adamgreig:matrix.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>
<@hifi:vi.fi> (we're talking on IRC with agg not being able to send messages through the bridge)
<re_irc>
<@sirhcel:matrix.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>
<@sirhcel:matrix.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>
<@sirhcel:matrix.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>
<@lachlansneff:matrix.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>
<@ryan-summers:matrix.org> I think it would help the merging case if there were some demonstrated gating impl? Just a personal thought
<re_irc>
<@dirbaio:matrix.org> embassy will switch over when they're merged
<re_irc>
<@dirbaio:matrix.org> design is almost the same as embassy-traits
<re_irc>
<@dirbaio:matrix.org> impls for nrf52 and soon stm32
<re_irc>
<@dirbaio:matrix.org> it seems people are OK with merging it before GATs are stable as long as it's behind `unstable-futures` flag
<re_irc>
<@dirbaio:matrix.org> alternatively maybe we could do a separate crate? and merge them into embedded-hal when GATs are stable
<re_irc>
<@dirbaio:matrix.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>
<@lachlansneff:matrix.org> I just had a brilliantly simple idea to get Read and Write into core.
<re_irc>
<@lachlansneff:matrix.org> A breaking change.
<re_irc>
<@lachlansneff:matrix.org> Move all the methods that use Vec and String into extension traits that are exported from the prelude
<re_irc>
<@lachlansneff:matrix.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>
<@lachlansneff:matrix.org> Technically a breaking change, but there might not even be any crates that are broken by it.
<re_irc>
<@lachlansneff:matrix.org> It would need to be in an edition
fooker has quit [Ping timeout: 268 seconds]
<re_irc>
<@lachlansneff:matrix.org> Or, does std need to work for all editions?
<re_irc>
<@dirbaio:matrix.org> rust needs to support compiling current and old edition crates and link them together
<re_irc>
<@dirbaio:matrix.org> i'm not sure you can make std different for different editions like that
<re_irc>
<@dirbaio:matrix.org> i'm not awaare of any change in rust 2018 that does that
<re_irc>
<@lachlansneff:matrix.org> Alas
<re_irc>
<@lachlansneff:matrix.org> Well, trait_aliases mention that they could (but currently don't) support aliasing multiple traits together
<re_irc>
<@lachlansneff:matrix.org> I suppose std read could be aliased to core read + alloc readext
<re_irc>
<@lachlansneff:matrix.org> And that wouldn't be a breaking change
<re_irc>
<@dirbaio:matrix.org> can you impl a trait alias like that?
<re_irc>
<@dirbaio:matrix.org> like
<re_irc>
<@dirbaio:matrix.org> what does `impl std::io::Read for Foo` do if `std::io::Read` is a trait alias like that
<re_irc>
<@lachlansneff:matrix.org> I don't know
<re_irc>
<@lachlansneff:matrix.org> It might not be sorted out yet
<re_irc>
<@dirbaio:matrix.org> I don't think you can, it's not even a real trait at that point
<re_irc>
<@dirbaio:matrix.org> and even if you could
<re_irc>
<@dirbaio:matrix.org> you wouldn't be able to override all the default impls, which you can today
fooker has joined #rust-embedded
<re_irc>
<@lachlansneff:matrix.org> You're right, it seems like they can't be used for impls
<re_irc>
<@lachlansneff:matrix.org> Oh well
<re_irc>
<@lachlansneff:matrix.org> Separate core traits it is
<re_irc>
<@dirbaio:matrix.org> yeah
<re_irc>
<@dirbaio:matrix.org> it's so stupid :S
<re_irc>
<@lachlansneff:matrix.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>
<@lachlansneff:matrix.org> If io::Read and io::Write might end up in core somehow, should AsyncRead and AsyncWrite get there too?
<re_irc>
<@dirbaio:matrix.org> well, there's no AsyncRead and AsyncWrite in std either sooo..
<re_irc>
<@dirbaio:matrix.org> there are talks about redesigning these
<re_irc>
<@dirbaio:matrix.org> might be a looooong time
<re_irc>
<@lachlansneff:matrix.org> dirbaio: How so?
<re_irc>
<@lachlansneff:matrix.org> I would actually vote for some of the net types getting into core as well