ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
d34db33f has joined #rust-embedded
exark has quit [Quit: quit]
exark has joined #rust-embedded
kaoD has quit [Quit: Bye]
kaoD has joined #rust-embedded
d34db33f has quit [Remote host closed the connection]
<JamesMunns[m]> I audibly laughed at it not liking what defmt does.
<JamesMunns[m]> I would love to see the bug report for that and what they think of those shenanigans
i509vcb[m] has joined #rust-embedded
<i509vcb[m]> theres a part of me wondering if the linker script is generally turing complete
<i509vcb[m]> Like generating an entire program in just the linker
<i509vcb[m]> Do we need to RiiR the linker lol
<M9names[m]> you mean like this? https://github.com/davidlattimore/wild
sroemer has quit [Quit: WeeChat 4.4.3]
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
<thejpster[m]> I recall pietro is writing a linker too
rainingmessages has quit [Quit: bye]
rainingmessages has joined #rust-embedded
<diondokter[m]> This is indeed terrible, but I like it!
<thejpster[m]> To get two binaries to share one RTT buffer just needs a fork of defmt-rtt with a multi-core spinlock and the ability to pass in the RTT buffer address rather than statically allocating it. But that’s ok - I need to fork it anyway so I can specify that the buffer lives in non-cached memory (according to the MPU).
<thejpster[m]> Or I guess a defmt-ipc that throws data from R to M over a completely separate queue, which M then copies to the RTT buffer. At least then M can still do logging even if R crashes. And actually it should log if R crashes. That’s kind of the point of the M core.
<thejpster[m]> Anyway, now I need to see if I can run code on the M core and if RTT works.
sroemer has quit [Quit: WeeChat 4.4.3]
pcs38 has joined #rust-embedded
<JamesMunns[m]> > defmt-ipc that throws data from R to M over a completely separate queue
<JamesMunns[m]> If you want, I can hack you up an IPC safe version of bbqueue, as long as atomics are properly coherent between the R and M cores
<JamesMunns[m]> The one thing that I'd need you to impl is a "notification" trait impl, so that the R core can signal the M core "hey you have pending data", probably using some kind of mailbox peripheral or swi?
<JamesMunns[m]> (mnemos has a version of bbqueue that is/was intended to be ABI safe, and has manual "construct a Sender/Receiver from a base ptr address" methods, https://github.com/tosc-rs/mnemos/tree/main/source/abi/src/bbqueue_ipc, I've meant to forward port this to bbq2, but haven't needed it yet, just waiting for an excuse 😃 )
<JamesMunns[m]> @thejpster are both cores 32 bit, or is the R 64-bit?
sroemer has joined #rust-embedded
RobinMueller[m] has joined #rust-embedded
<RobinMueller[m]> What is the easiest way to test my defmt::Format impl on a host PC? for example, write the defmt formatted structure to a string again for example printouts?
sroemer has quit [Quit: WeeChat 4.4.3]
<thejpster[m]> It’s a four R5s and one M4 and I don’t know if they are atomically coherent
<thejpster[m]> <RobinMueller[m]> "What is the easiest way to..." <- The repo has tests. I’d do what that does.
<thejpster[m]> The AM243x-Launchpad is worth buying at $90, if you can live with openocd.
<JamesMunns[m]> I just ordered a stack of other hardware, having async on the cortex-m would actually be interesting, because you could `select` on four async bbqs to feed the m's rtt buffer
<JamesMunns[m]> I just ordered a stack of other hardware, so I'm probably going to pass on the launchpad.
<JamesMunns[m]> Having async on the cortex-m would actually be interesting, because you could `select` on four async bbqs to feed the m's rtt buffer, if you have to service four other cores
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
wangeng[m] has quit [Quit: Idle timeout reached: 172800s]
Foxyloxy has joined #rust-embedded
Foxyloxy has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Foxyloxy has joined #rust-embedded
Foxyloxy has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Foxyloxy has joined #rust-embedded
Noah[m] has quit [Quit: Idle timeout reached: 172800s]
Foxyloxy has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
Foxyloxy has joined #rust-embedded
sroemer has quit [Quit: WeeChat 4.4.3]
Foxyloxy has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
sroemer has quit [Quit: WeeChat 4.4.3]
Foxyloxy has joined #rust-embedded
pcs38 has quit [Remote host closed the connection]
<thejpster[m]> You could do that without async too? Just WFI then check each queue.
cinemaSundays has joined #rust-embedded
cinemaSundays has left #rust-embedded [#rust-embedded]
<JamesMunns[m]> You could certainly do anything async or not! It's useful if your m core has other things to do too.
Foxyloxy has quit [Quit: My Mac has gone to sleep. ZZZzzz…]