06:36 <Kaspar[m]> <JamesMunns[m]> "What are you linking with?" <- I think it is using lld, a failing link is calling `"rust-lld" "-flavor" "gn

06:36 <Kaspar[m]> u" ...`

06:37 <Kaspar[m]> > <@jamesmunns:beeper.com> What are you linking with?

06:37 <Kaspar[m]> * I think it is using lld, a failing link is calling `"rust-lld" "-flavor" "gnu" ...`

06:39 <Kaspar[m]> Kaspar[m]: Or maybe not. When I use lld through clang with `-Clinker=clang -Clink-arg=-fuse-ld=lld -Clink-arg=--target=${RUSTC_TARGET}`, the OS/ABI is set to the correct (well, working) value.

09:03 <JamesMunns[m]> <Kaspar[m]> "Or maybe not. When I use lld..." <- Yeah, it smelled like a wrong linker and/or linker config (including flags and stuff)

11:20 <JamesMunns[m]> Hey diondokter, if I wanted to time sync a network of devices, specifically a bunch of USB devices hooked to a PC, that also have a common line they can use for low latency comms (sync pulse, or could be UART broadcast, basically a common open drain line that happens to be wired up to UART TX + RX), do you have any opinions on the best way to do that?

11:21 <JamesMunns[m]> is there something in ptp or ntp that I could pull out to assist with this? or am I better off rolling something on my own?

11:23 <JamesMunns[m]> it doesn't necessarily have to be "wall clock" time, but ideally something that is accurate enough that if the PC says "I want all of you to do this at time X", where time X is reasonably in the future, that it'll happen at a precise enough time?

11:26 <JamesMunns[m]> (open to suggestions from folks other than Dion here as well, if anyone has a thing or research paper for this :D)

11:29 <JamesMunns[m]> My current best idea is to dedicate one of the chips as the "time keeper", and send out a 32/64 bit time over UART, with a specifically timed "break" pulse, say at 1kHz, and have that drive the "tick count" for the rest of the system, and have the devices keep their own sub-millisecond timers (and live with the minor potential drift), then do... something? to have the PC and time keeper sync, or just live with the PC

11:29 <JamesMunns[m]> lagging/jittering a little bit behind the "official" time

11:33 <Darius> I imagine it depends how close they need to be

11:36 <JamesMunns[m]> yep, no specific requirements yet.

11:39 <JamesMunns[m]> this is on an RP2040, so I probably could get clever with the PIO or something, but I do probably need to better define what kind of things I want to be able to do.

11:41 <vollbrecht[m]> any naive sync approach is limited by two things, the smallest (round-trip time / 2), and at minimum what your oscillator drift distribution is ( for simplicity with both chips at the exact same external factors, like temperature, power source etc)

11:41 <vollbrecht[m]> s/(//, s/)//

11:43 <vollbrecht[m]> what is simply to compensate, is how long for example it takes to set a count value into your local timer, and how long it takes out to read from it. If you have two identically chips and run the "same" routines here you can cancel alot here. But it can be else quite a factor

11:55 <vollbrecht[m]> but yeah having a physical connection makes things *alot* easier, e.g you have a lot more options that can work.

11:55 <vollbrecht[m]> I implemented something for time sync over wifi, that uses wifi's FTM high time resolution. You can go into ns there wich otherwise is not simply possible with wireless of the shelf technology in user space.

11:56 <vollbrecht[m]> One nice paper you can read about that is [here](https://www.usenix.org/system/files/atc21-chen.pdf)

12:02 <birdistheword99[> <JamesMunns[m]> "My current best idea is to..." <- This a a decent approach, and its how cameras, audio, and tracking system are synchronised in Broadcast and Film. You have a master clock which maintains time, and an audio signal called 'Timecode' which regularly sends out the time. This is what you would typically see on clapper boards, and all recorded footage is linked to this time. You then have a second signal called

12:02 <birdistheword99[> It might be over-kill for your application, but there are Timecode drivers for PC if you were interested in that approach. You don't need SAI or an audio peripheral to decide it, its just pulse counting basically.

12:02 <birdistheword99[> 'Genlock' which is essentially a pulse, and it triggers the capture of a frame (in cameras), and is used by all equipment to count up time in between timecode transmissions.

13:01 <birdistheword99[> s/decide/decode/

15:29 <therustybits[m]> Quick question to anyone here that has been working with embedded Rust for awhile: what is your preferred approach to string formatting? Using the core::write macro with heapless::String? ufmt also seems like a good option...

15:33 <JamesMunns[m]> Yeah, when I need real formatting, it's usually into a heapless string, or an ad-hoc Write impl on a slice

16:24 <cbjamo[m]> <JamesMunns[m]> "this is on an RP2040, so I..." <- If you're happy committing to rp2040 specific functions, you might consider the gpin/out clock pins.

16:30 <JamesMunns[m]> yeah, I don't think I can clock sync the whole system, the whole area is maybe 50cm wide, maybe more like 60-70cm once you go through all the ribbons and stuff

16:30 <JamesMunns[m]> on a smaller board, running all the boards in locked clock time would be a fun way to make them all synchronous tho :D

21:01 <fay_carsons[m]> Does anyone here have experience w/ DMA on the RP2040? I'm trying to set up two transfers, one which reads a buffer into a PIO FIFO, and another which resets the first's read address back to the start of the buffer when it... (full message at

21:01 <fay_carsons[m]> <https://catircservices.org/_irc/v1/media/download/AeG2LFW4WA4yx_SYtuBHkflTTulVlb0jGpBixhlRnSe6V6YbAWBFX2l1VTf-SYVMEDcfLcurmbf8peakDbNLPLVCeSEXPMBwAGNhdGlyY3NlcnZpY2VzLm9yZy91d0dxeUdQemhWS3R6VVBwTWNQUkNjT3M>)

21:02 <ithinuel[m]> fay_carsons[m]: you can ask on #rp-rs:matrix.org to get experts’ reply 🙂 There’s even the author of the DMA support in rp2040-hal in there 🙂

21:06 <fay_carsons[m]> ithinuel[m]: Thank u!! No idea how matrix works, super helpful

21:33 <thejpster[m]> <fay_carsons[m]> "Thank u!! No idea how matrix..." <- Click the channel name in that message to join the channel

21:33 <thejpster[m]> thejpster[m]: I have a working ping pong video PIO DMA thing that works

21:42 <dinkelhacker> Hey all, this isn't strictly an embedded question but I assume this is still a good place to ask. I keep getting into situations where I end up having cyclic dependencies between crates. Basically the root cause often is something like this: I have a arch-independent type in one crate, e.g., a type that represents a Task. That type contains a arch-dependent type,e.g., a type representing the

21:42 <dinkelhacker> CpuContext that lives in the arch crate. If I want to pass a pointer of the containing Task struct to a method of the CpuContext struct both crates depend on each other. I can get rid of that by just having all in one crate and just use #cfg to decide which arch module to use. However that leads to a mono crate. Any suggestions how to deal with that?

21:45 <dirbaio[m]> make a single crate and use cfg's yes

21:45 <dirbaio[m]> there's nothing wrong with a monocrate

21:45 <dirbaio[m]> you can still organize code within a crate nicely with modules etc

21:46 <dinkelhacker> well what about compilation speed? Like I don't want to recompile all the architectur code becaus something in the common part changed?

21:48 <dinkelhacker> I'm working on a hobbyist os and if I'd do that this means the whole thing is one compilation unit... that feels wrong

21:49 <dirbaio[m]> rust can do incremental compiling within a crate, it splits it in chunks and only recompiles chunks that changed.

21:51 <dirbaio[m]> it's not as good as two crates, it still has to do some compute to tell what changed or not, but it's pretty good

21:51 <dirbaio[m]> unless your crate becomes HUGE I wouldn't worry about it

21:54 <dinkelhacker> maybe you're right... like the time i've spent untangling these things, factoring out more and more things into smaller and smaller crates is actually getting anyoing