07:45 <bitts[m]> Huh, I'm trying to include some c-files into a rust (cortex-a53) project using cc. It compiles fine when I build locally on my (arm) Mac, but if I try to build in a Docker, I get a `rust-lld: error: /<snip>/target/aarch64-unknown-none/debug/build/int_test-3e1a21ae7e1a8a49/out/libweetest.a(db3b6bfb95261072-weetest.o) is incompatible with /tmp/rustcSdBeHS/symbols.o`. Anybody know what is going on?

07:46 <bitts[m]> * project using the cc, * cc crate. It

10:24 <thejpster[m]> Your Mac will have clang, which is a cross compiler. What C compilers does your docker container have?

10:27 <thejpster[m]> Here’s an example that works on Mac and Linux. The CI pipeline on Linux installs gnu-arm-none-eabi, which cc finds automatically.

10:27 <thejpster[m]> https://github.com/ferrous-systems/threadx-experiments/tree/main/qemu-cortex-r5-app

11:44 <bitts[m]> The docker has both aarch64-none-elf-gcc, tiarmclang, arm-none-eabi (and more). I guess cc needs some more hints on which compiler to choose..

12:32 <whitequark[cis]> folks, what would you use for structured-ish data exchange between Rust and Python code? deserialization perf Python-side matters a lot to me

12:33 <whitequark[cis]> (asking here since I think my preferences for this project are typical for an embedded one, although it all runs on a PC)

12:48 <ben[m]> <whitequark[cis]> "folks, what would you use for..." <- You could look into postcard-rpc. But as far as I know you need to write you own python side for it.

12:48 <ben[m]> James Munns might have some thoughts on this

12:48 <ben[m]> * You could look into postcard-rpc. But as far as I know you need to write you own python side for it.

12:48 <ben[m]> James Munns might have some thoughts on this

12:48 <ben[m]> * You could look into postcard-rpc. But as far as I know you need to write you own python side for it. Perhaps a better solution would be to let postcard-rpc do the deserialisation and call that from within python.

12:48 <ben[m]> James Munns might have some thoughts on this

13:07 <jason-kairos[m]> design question: in a multithreaded system it can be nice to append the name of the thread "battery management thread: starting charge cycle" to serial port println!()s (it's plain ascii, no fancy precomputed defmt etc... (full message at

13:07 <jason-kairos[m]> <https://catircservices.org/_irc/v1/media/download/Aeej_8LLRKvO151zciVUfVkNSc2e11nD-lxk7I4SIyBTH64K8m5ICi3StXQ-X6ZY6RwoRTbClo3yQ3TREmXopCe_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9nUlljYlBmcmdyUmhlU2xuYXFtd0dBa1U>)

13:12 <thejpster[m]> I’d call it “tprintln!”

13:19 <bitts[m]> <ben[m]> "You could look into postcard-rpc..." <- We used postcard + PyO3 a while back, but I would not call the experience smooth. There were quite a few gotchas and things that did not work quite as you would expect. Possible, but I am hesitant to recommend it..