<re_irc>
< (@adamgreig:matrix.org)> rursprung: you can enable an IDLE interrupt on the UART that will trigger when it sees a break in incoming data, and then process the DMA buffer at that point
<re_irc>
< (@adamgreig:matrix.org)> (still need to process the DMA full in case it fills up with no break, and you might want to be careful to avoid missing incoming data by using double buffers or circular DMA)
<re_irc>
< (@adamgreig:matrix.org)> Just processing each byte as it arrives may be simpler though - stick it on a buffer and if it looks like you've got a full message, tell rtic to schedule a task to deal with it or something
IlPalazzo-ojiisa has quit [Ping timeout: 260 seconds]
genpaku has quit [Remote host closed the connection]
<re_irc>
< (@adamgreig:matrix.org)> Or have the UART interrupt stick the new byte into a buffer and have another task just constantly/regularly check the buffer for messages
IlPalazzo-ojiisa has joined #rust-embedded
genpaku has joined #rust-embedded
<re_irc>
<rursprung> thanks for your feedback, ! i've now tried to add the idle interrupt and that's working. however, as i pass the "Rx" into the "dma::Transfer" i'm not sure how i can afterwards access it again to clear the interrupt flag? i've now just copied the ("unsafe") code directly from "Rx::clear_idle_interrupt", but would of course prefer to call it. do you happen to know if there's a clean way to get the "Rx" from the...
<re_irc>
... "Transfer" so that i can trigger the "clear_idle_interrupt"?
<re_irc>
<rursprung> (as i already had the DMA code in place i thought it'd be nicer to not throw that all away and rewrite it to single-byte-receiver based on an interrupt)
<re_irc>
< (@adamgreig:matrix.org)> Not sure about f4xx-hal I'm afraid
neceve_ has joined #rust-embedded
neceve has quit [Ping timeout: 260 seconds]
neceve_ is now known as neceve
IlPalazzo-ojiisa has quit [Ping timeout: 260 seconds]
IlPalazzo-ojiisa has joined #rust-embedded
genpaku has quit [Ping timeout: 260 seconds]
genpaku has joined #rust-embedded
neceve has quit [Ping timeout: 260 seconds]
neceve has joined #rust-embedded
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
dc740 has joined #rust-embedded
bjc has joined #rust-embedded
IlPalazzo-ojiisa has quit [Ping timeout: 260 seconds]
IlPalazzo-ojiisa has joined #rust-embedded
neceve_ has joined #rust-embedded
neceve has quit [Ping timeout: 260 seconds]
<re_irc>
<rursprung> just FYI: i've now copied the "unsafe" block over for the moment. i'll dig into this later - for now i can move on. thanks again for your help!
<re_irc>
<rursprung> and now for a totally different question: i have defined "build.target" in my ".cargo/config":
<re_irc>
[build]
<re_irc>
target = "thumbv7em-none-eabihf"
<re_irc>
i have a module which is independent of the hardware but i'm not ready to refactor it into its own crate. but with the above config i now can't use "#[test]" in this module. is there a possibility to define that "cargo test" uses a different target (i.e. my local target)? i didn't see anything in the docs :(
<re_irc>
< (@jamesmunns:beeper.com)> I think the cli can override that?
<re_irc>
e.g. "cargo test --target x86_64-unknown-linux-gnu" or so
creich_ has joined #rust-embedded
<re_irc>
<rursprung> that doesn't work, sadly:
<re_irc>
error: duplicate lang item in crate `std` (which `test` depends on): `panic_impl`.
<re_irc>
[..]
<re_irc>
= note: the lang item is first defined in crate `panic_halt` (which `[..]` depends on)
<re_irc>
|
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, for testing, you'd probably want to move as much as possible into a "#![no_std]" library crate, and a small-as-possible binary crate. That way you can test the lib, without the app
<re_irc>
< (@jamesmunns:beeper.com)> there are ways to work around the issues you posted, like making it a conditional dep (that is default on, but not while testing), and probably also conditionally toggling the no_std attr, e.g.
<re_irc>
"#![cfg_attr(not(test), no_std]"
<re_irc>
< (@jamesmunns:beeper.com)> * no_std)]"
creich has quit [Quit: Leaving]
creich_ has quit [Quit: Leaving]
creich has joined #rust-embedded
IlPalazzo-ojiisa has quit [Remote host closed the connection]
IlPalazzo-ojiisa has joined #rust-embedded
causal has joined #rust-embedded
causal has quit [Ping timeout: 248 seconds]
<re_irc>
< (@CyReVolt:matrix.org)> : damn i'm looking forward to doing something like that in oreboot - we have too much asm in there that always looked so awry
<re_irc>
< (@CyReVolt:matrix.org)> I never really got behind annotations or whatever like 1extern "C" {}` - this looks super clear now!
<re_irc>
< (@CyReVolt:matrix.org)> oh then we can get rid of naked function (which I never understood why we had it anyway), and get closer to using a stable toolchain
<re_irc>
< (@dirbaio:matrix.org)> the "pure rust" reset handler got rolled back in cortex-m-rt due to concerns it's UB though
<re_irc>
< (@CyReVolt:matrix.org)> oh noes 😭
<re_irc>
< (@CyReVolt:matrix.org)> What makes it ub?
<re_irc>
< (@dirbaio:matrix.org)> iirc there was a pretty extensive discussion about it in this chat a while ago
<re_irc>
< (@dirbaio:matrix.org)> but I failed to find it, searching the log for "r0" has a terrible SNR :S
<re_irc>
< (@9names:matrix.org)> It was November 2020, I checked the freenode logs. (Also very cool that ripgrep let's you search through gz'd logs)
<re_irc>
< (@9names:matrix.org)> The conversation kinda kept kicking up for a couple of months after that while we collectively tried to wrap our heads around pointer provenance
<re_irc>
< (@CyReVolt:matrix.org)> oh whew, if even the great minds couldn't collectively clarify that stuff fully... I'm somewhat afraid I want to even touch it. x)
<re_irc>
< (@CyReVolt:matrix.org)> -I want
explore has joined #rust-embedded
<re_irc>
< (@9names:matrix.org)> If you're interested, the most succinct description of the problem is in gankra's post "rust's unsafe pointer types need an overhaul". I wish it existed back then.