explore has quit [Quit: Connection closed for inactivity]
Foxyloxy has quit [Ping timeout: 244 seconds]
Foxyloxy has joined #rust-embedded
causal has joined #rust-embedded
starblue has quit [Ping timeout: 265 seconds]
starblue has joined #rust-embedded
<re_irc>
<762spr> I'm having an issue with STM32_hal2's UART... I can write to PuTTY no problem, but for some reason, nothing ever gets sent back? I am using a nucleo32 dev board with TX on PA2 and RX on PA15 going to the onboard STLink. I am basing it off of the example file, but the interrupt never triggers...
<re_irc>
// config usart
<re_irc>
let _uart_tx = Pin::new(Port::A, 2, PinMode::Alt(7));
<re_irc>
let _uart_rx = Pin::new(Port::A, 15, PinMode::Alt(7));
<re_irc>
<762spr> I have noticed that "uart2.enable_interrupt(UsartInterrupt::ReadNotEmpty);" seems to just trigger the interrupt, not sure if that is the intended behavior or not. In other examples it looks like it is actually used to enable, not trigger but I could be wrong there. if I uncomment line 17 above and use enable interrupt, it will trigger the interrupt, which then gets cleared from within the interrupt, but it never gets...
<re_irc>
<762spr> upon further investigation, "uart2.enable_interrupt(UsartInterrupt::ReadNotEmpty);" seems to indeed enable the interrupt, but for whatever reason RXNE starts as true even with nothing actually in the RDR. Enabling it without clearing the RXNE will cause the interrupt to trigger.
<re_irc>
I just don't seem to be able to actually get anything to the RDR... is my PuTTY config wrong?
Guest2011 has quit [Killed (zinc.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 255 seconds]
<re_irc>
<omar_u8> I'm trying to share a heapless::spsc queue among multiple routines in interrupt based code (not using an RTIC). What is the best approach to do that? Do I treat the queue as a peripheral and wrap it in a RefCell (as explained in https://docs.rust-embedded.org/book/concurrency/)? Or would there be a better/different approach?
<re_irc>
<omar_u8> * the
crabbedhaloablut has quit [Remote host closed the connection]
<re_irc>
<xgroleau> I'm trying to cross compile a C library using the CC crate and bindgen, though I am getting "fatal error: 'string.h' file not found"
<re_irc>
, how can I include the headers shipped with the arm-none-eabi with the compiler? The stubs are already written, so I just need the headers not the library itself. Ideally, I don't want to hard code the path since I want the build to be reproducible. Or would the proper way to do it would be to simply copy the header file in the crate and include it?
<re_irc>
<xgroleau> I'm trying to cross compile a C library using the CC crate and bindgen, though I am getting "fatal error: 'string.h' file not found", how can I include the headers shipped with the arm-none-eabi with the compiler? The stubs are already written, so I just need the headers not the library itself. Ideally, I don't want to hard code the path since I want the build to be reproducible. Or would the proper way to do it would be...
<re_irc>
... to simply copy the header file in the crate and include it?
<re_irc>
<xgroleau> Nvm the issue was with bindgen and not CC
<re_irc>
<Trevor Gross> After some talk on the zulip, I think I'm planning on bringing back a version of https://github.com/rust-lang/rfcs/pull/2990, "ArrayVec" in core. My main reasons are that the concept is very useful in no_std, and it represents the C "somefunc(int buf[BUF_SIZE], int* len)" pattern very well so FFI would be eased. Also would allow a good interface for arbritary "&str" to "CStr" which is pretty clunky currently (most...
<re_irc>
... docs suggest going through "CString", but this of course isn't possible for embedded). Anybody here have any thoughts?
<re_irc>
<Trevor Gross> The "fixed-length buffer with capacity and current length" pattern is also just so common on embedded that I see it making sense to have some sort of good representation
<re_irc>
<thejpster> How does that differ from a heapless::Vec?
<re_irc>
<Trevor Gross> The "heapless", "arrayvec", "tinyvec", "smallvec" and "staticvec" crates all do the same thing slightly differently (with tiny & small having the option to move to the heap). So, some unificiation is another of the benefits
<re_irc>
<adamgreig> room meeting time again! agenda is https://hackmd.io/cWnfdC24RB6Uii5wnNNvYg, please add anything you'd like to announce or discuss and we'll start in just a couple mins :)
<re_irc>
<adamgreig> ok, let's start! I'll just repeat eldruin's memo from earlier this afternoon that GATs are now coming in 1.65 which should be exciting for embedded async stuff!
<re_irc>
<adamgreig> otherwise no announcements from me, anyone else got anything?
<re_irc>
<dirbaio> also lots of activity in Rust zulip lately on "async fn in trait", ie native async tratis :D
<re_irc>
<dirbaio> * traits
<re_irc>
<newam> dirbaio: Doesn't this still require TAITs?
<re_irc>
<adamgreig> GATs is the last big blocker to stabilising async in traits right?
<re_irc>
<dirbaio> "manually desugared" async traits require GAT to declare, GAT+TAIT to impl (unless you hand-implement futures, which sucks)
<re_irc>
<newam> Ahhh, so like alloc, able to declare on stable, but the error handler needs nightly features.
<re_irc>
<dirbaio> newam: async-fn-in-traits will desugar to GAT+TAIT, but it can be stable before TAIT is stable (using it as an implementation detail only, similar to how stable async uses unstable generators today)
<re_irc>
<newam> Makes sense, glad it is closer than I expected :)
<re_irc>
<dirbaio> fingers crossed 🤞
<re_irc>
<adamgreig> nice :)
<re_irc>
<adamgreig> just a couple of issues from last week then I think, the critical-section PR to handle poisoning in the std mutex is updated, https://github.com/rust-embedded/critical-section/pull/26, though I dunno if we want say anything else in the docs
<re_irc>
<adamgreig> last week the conclusion was we should clarify what "with" does on unwind and double check that the dropguard doesn't degrade codegen
<re_irc>
<dirbaio> docs LGTM
<re_irc>
<adamgreig> cool, yea I guess it says everything we really need to
<re_irc>
<dirbaio> checking whether it bloats my firmware..
<re_irc>
<dirbaio> I've addressed all the review comments from eldruin
<re_irc>
<dirbaio> except, regarding the "-bus" crate: I'm not sure how to structure it. For example, the "ExclusiveDevice" could impl both blocking+async "spi::Device" traits at the same time
<re_irc>
<dirbaio> depending on what the underlying Bus supports
<re_irc>
<dirbaio> we don't necessarily need separate structs "blocking::ExclusiveDevice" and"asynch::ExclusiveDevice"
<re_irc>
<dirbaio> others will be blocking-only (for example a cs-mutex-based one) or async-only (async mutex) since you can't really have a "blocking+async mutex"
<re_irc>
<dirbaio> so.. I'm not sure :D
<re_irc>
<adamgreig> so in other words we might not need to partition them into separate blocking/async modules?
<re_irc>
<adamgreig> I guess the crate would have to depend on both e-h and e-h-a in that case
<re_irc>
<dirbaio> yes...
<re_irc>
<dirbaio> (e-h-a stuff will have to be feature-gated while it's nightly only)
<re_irc>
<dirbaio> but perhaps having "blocking", "async" mods is still simpler?
<re_irc>
<adamgreig> perhaps a tiny bit annoying if you want e-h-bus just for e-h traits but probably not a huge deal
<re_irc>
<adamgreig> eh, given it probably has like five or six structs tops, having them all in the top level doesn't seem too bad?
<re_irc>
<dirbaio> yes but
<re_irc>
<dirbaio> I meant that some structs can work for _both_ blocking and async
<re_irc>
<dirbaio> the same struct
<re_irc>
<adamgreig> if anything that seems like a reason to not have separate modules?
<re_irc>
<eldruin> sorry, running late. I agree with having no separate mods for e-h-bus. nothing else from me
<re_irc>
<dirbaio> niiiiiice
<re_irc>
<dirbaio> so anything left for #394?
<re_irc>
<adamgreig> soon there won't be anything left to remove and then we can release e-h 1.0 :D
<re_irc>
<adamgreig> anyway, let's end the meeting there then, thanks :D
<re_irc>
<Ryan Hedgecock> Hey, I'm really new to this, so you'll have to forgive me if this isn't the right place.
<re_irc>
I'm working on an embedded rust project for the first time (also first time doing anything embedded), and I'm unsure how to proceed with SPI in the stm32f4xx-hal crate.
<re_irc>
I'm using "SPI1" in "TransferModeBidi" and I'm able to successfully write data out of the pin (verified with an oscillator). But I am supposed to get data back almost immediately after writing, and it doesn't seem like I should be using the "read" method on the spi struct as I am running into all kinds of issues when I try (like the write output being cut short for some reason). How do I go about reading from the pin after I write...
<re_irc>
<wannes_> Ryan Hedgecock: ran into the same issue, this could help as a workaround: https://github.com/stm32-rs/stm32f4xx-hal/issues/520 (see last comment). You might need to adjust the SPI config. The "transfer" method is what you're looking for to read after write.
causal has quit [Quit: WeeChat 3.6]
rardiol has quit [Ping timeout: 265 seconds]
rardiol has joined #rust-embedded
rardiol has quit [Client Quit]
<re_irc>
<jannic> What ordering guarantees does "critical_section" provide? Is there a full "atomic::fence(Ordering::SeqCst)" at the beginning and end of the critical section, or is the guarantee weaker?
<re_irc>
<dirbaio> seqcst, yup
<re_irc>
<dirbaio> like locking/unlocking a global mutex
<re_irc>
<dirbaio> oh hmm wait, locking an std mutex is just Acquire/Release ordering, isn't it?
<re_irc>
<jannic> I don't know, the docs of std::Mutex don't tell either.
<re_irc>
All I found was done statement about c++ Mutex providing acquire/release ordering.
<re_irc>
<jannic> * some
<re_irc>
<dirbaio> but anyway, since the CS is a _single_ program-wide mutex, does it make a difference?
<re_irc>
<jannic> So I guess rust should do it the same way, but it was nicer if it was properly documented.
<re_irc>
<dirbaio> like, can you write code that's sound if the CS is SeqCst, but unsound if it's just Acq/Rel?
<re_irc>
<dirbaio> the difference is relevant when you have _mutiple_ mutexes because they might interleave in a weird way
<re_irc>
<dirbaio> but with just a single one...?
<re_irc>
<dirbaio> i have no idea 🤷
<re_irc>
<jannic> In theory, if it doesn't guarantee any ordering (but just prevented concurrent execution) it could work like a relaxed atomic and wouldn't guarantee any ordering in relation to things happening outside the critical sections.
<re_irc>
<dirbaio> it does guarantee Acq/Rel at least _for sure_
<re_irc>
<dirbaio> I mean
<re_irc>
<dirbaio> currently it isn't documented
<re_irc>
<dirbaio> but if it was, it'd be at least Acq/Rel, and all impls now do provide Acq/Rel at least
<re_irc>
<dirbaio> std impl uses a mutex which is Acq/Rel (I guess)
<re_irc>
<dirbaio> cortex-m impl has SeqCst fences
<re_irc>
<dirbaio> (if the CS didn't provide at least Acq/Rel it'd be very very broken)
<re_irc>
<jannic> Rp2040 doesn't. Perhaps it should? I don't trust my intuition about memory ordering, so I prefer to have the requirements and guarantees clearly spelled out.
<re_irc>
<dirbaio> rp2040 doesn't?
<re_irc>
<jannic> It doesn't have SeqCst. Not so sure about Acq/Rel, there are some fences in the code but I don't remember the details.
<re_irc>
<jannic> And it does the inter-core-synchronisation using hardware spinlocks. For the compiler, those look just like volatile register access. Not sure what that means for ordering guarantees.
<re_irc>
<dirbaio> the fences tell the compiler to not reorder, that should be enough
<re_irc>
<jannic> Does the compiler fence together with the spinlock guarantee the same as a full fence would?
<re_irc>
(I wrote parts of that code, and I sure was convinced it was sufficient the way it is. But whenever I come back to that code months later, I'm worried about it, again)
<re_irc>
<jannic> It's probably fine because the m0 is strictly in-order and doesn't have core-local caches.
<re_irc>
<dirbaio> I think the m0 doesn't have funny things like caches or store buffers, so a compiler fence is the same as a full (hardware) fence
<re_irc>
<dirbaio> yep
<re_irc>
<dirbaio> so "disable irqs, acquire spinlock, compiler_fence(SeqCst)" should be enough
cr1901 has quit [Read error: Connection reset by peer]