00:05 <re_irc> <thebutlah> what is the difference between "probe-run" and "cargo flash"?

00:07 <re_irc> <therealprof> thebutlah: cargo-flash only flashes the binary and doesn't deal with the system after that at all. probe-run flashes the binary and attaches to the system, watching and displaying any output coming via rtt and printing panics.

00:14 <re_irc> <thebutlah> in that case, what is the difference between "probe-run" and "cargo embed"?

00:15 <re_irc> <therealprof> "probe-run" is a fire and forget type of affair: flash the binary, attach to the target. "cargo embed" provides more tooling and integration with IDEs/debuggers.

00:16 <re_irc> <therealprof> I don't use debuggers unless I can't avoid it and I don't like setup so I can't really tell you that much about "cargo embed".

00:40 <re_irc> <adamgreig> "cargo embed" is used a bit differently, in that you can configure it with a "Embed.toml" or your "Cargo.toml" and it runs as a cargo subcommand (you can do "cargo embed --release --features bla" etc)

00:41 <re_irc> <adamgreig> "probe run" is a runner you set in your .cargo/config.toml, then you use "cargo run" to execute it

00:41 <re_irc> <adamgreig> both do RTT and defmt if you want, "cargo embed" has a slightly different user interface (more compact display, logs to a file as well as the screen, uses curses to do a scrolling interface with multiple tabs for each RTT channel)

00:42 <re_irc> <adamgreig> probe-run is maintained by knurling, separately from the probe-rs team, so it sometimes/often has an older version of the probe-rs library, not sure if that's currently the case

00:42 <re_irc> <adamgreig> (but both cargo-embed and probe-run use the probe-rs library to talk to debug probes and microcontrollers etc)

02:01 <re_irc> <boondocker> 4000323c <main>:

02:01 <re_irc> 4000323c: 81010113 addi sp,sp,-2032

02:01 <re_irc> 40003240: 7e112623 sw ra,2028(sp)

02:01 <re_irc> 40003244: 04000537 lui a0,0x4000

02:01 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/a1ce4b12de3df40d06794a80760cc7a66d21812fd9028e4da49c69546d0a481c (7 lines)

05:19 <re_irc> <boondocker> heh, I had a "Box::new([0; NUM])" which was trying to allocate a huge amount of stack space lol

08:59 <re_irc> <laizy> Hi, I want to compile rust code to a single-core, no threads, no interrupts RISCV32 target. But the code has some dependencies which use atomics. I follow this doc https://docs.rust-embedded.org/embedonomicon/custom-target.html#fill-the-target-file to set "singlethread" and target file is:

08:59 <re_irc> {

08:59 <re_irc> "arch": "riscv32",

08:59 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/9cff76a3fa4eeb14d96905e4dd8a78009a06f03cb4e343c7510c784eeae88e3c (20 lines)

08:59 <re_irc> "cpu": "generic-rv32",

09:02 <re_irc> <mabez> laizy: I don't think single thread helps if CAS is involved. By the way, maybe you want to use this: https://github.com/esp-rs/riscv-atomic-emulation-trap

09:02 <re_irc> <boondocker> The default riscv32i target should work for you. The config you’re showing enables +m and +a which would enable the multiplier and atomic extensions

09:06 <re_irc> <laizy> boondocker: but some dependencies use atomics, if i do not enable +a, it can not compile.

09:07 <re_irc> <laizy> rust-lld: error: undefined symbol: __atomic_fetch_add_4

09:07 <re_irc> >>> referenced by ahash.d15ab06a-cgu.4

09:07 <re_irc> >>> ahash-de973e2c289d941b.ahash.d15ab06a-cgu.4.rcgu.o:(_$LT$ahash..random_state..DefaultRandomSource$u20$as$u20$ahash..random_state..RandomSource$GT$::gen_hasher_seed::h8a1b0e6055e624d5)

09:11 <re_irc> <boondocker> laizy: Then you’ll have to emulate them. See the trap handler emulation above

09:24 <re_irc> <laizy> mabez: boondocker Thank you for the link! I have tried to emulate them by myself, but do not known how to implement LR/SC. I find the link code just use 1 slot to reserve address, is this implementation meet the requirements of the specification?

09:24 <re_irc> 0b00010 => {

09:24 <re_irc> /* LR */

09:24 <re_irc> S_LR_ADDR = frame[rs1];

09:24 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/81a496bf784b315c411c5a4b70d063edc085d1c27b5f62aeb8aa7e173d54a20c (18 lines)

09:38 <re_irc> <laizy> The spec defines a "reservation set", which seems can reserve multiple address at the same time.

10:15 <re_irc> <9names (@9names:matrix.org)> or https://github.com/embassy-rs/atomic-polyfill

10:15 <re_irc> <9names (@9names:matrix.org)> > Then you’ll have to emulate them. See the trap handler emulation above

10:15 <re_irc> or use https://github.com/embassy-rs/atomic-polyfill

14:05 <re_irc> <James Munns> We got 8 submissions for the Final Friday showcase, the first one is up, the next seven are going up at :30 past the hour for the rest of the day :)

14:05 <re_irc> https://twitter.com/rustembedded/status/1563156111829913600

14:06 <re_irc> <James Munns> If anyone is now having FOMO and wants to share their project, I can add it to the queue if you get it to me (or DM the rustembedded twitter) in the next few hours :D

14:15 <re_irc> <Mehmet Ali> Hi all, does defmt default to the terminal?

14:15 <re_irc> <Mehmet Ali> If I omit defmt-rtt, would it work like println?

14:19 <re_irc> <James Munns> So, defmt logs to a global source. You need to provide one. Typically, people use RTT, which uses the debugger to read from that global source and print to your desktop

14:19 <re_irc> <James Munns> you can provide a DIFFERENT global option, but it wouldn't "fall back" to anything if you just removed defmt-rtt.

14:21 <re_irc> <James Munns> You could use https://github.com/gauteh/defmt-serial, or https://github.com/jamesmunns/defmt-bbq/, but the output would still be in the "compressed" defmt protocol, so you'd need something to decode it. e.g. you couldn't just print it to a UART and read it directly (without piping it through a decoder program/library)

14:27 <re_irc> <Mehmet Ali> Ahh, I see.

14:27 <re_irc> <Mehmet Ali> Thanks, Jame

14:27 <re_irc> <Mehmet Ali> * James

14:28 <re_irc> <Mehmet Ali> I am actually following the testing embedded apps project structure

14:29 <re_irc> <Mehmet Ali> That being, https://ferrous-systems.com/blog/test-embedded-app/

14:29 <re_irc> <Mehmet Ali> So, I have a cross compiled crate in the workspace which I flash

14:30 <re_irc> <Mehmet Ali> There are also other crates that the cross compiled imports

14:30 <re_irc> <Mehmet Ali> * depends.

14:30 <re_irc> <Mehmet Ali> +in my workspace

14:31 <re_irc> <Mehmet Ali> That makes those other crates testable on the dev machine.

14:31 <re_irc> <Mehmet Ali> Like "messages" crate in that blog post.

14:33 <re_irc> <Mehmet Ali> I was wondering whether if I use defmt in those crates I can still be able to "read" the messages, say in tests.

14:34 <re_irc> <Mehmet Ali> Or whether those packages can emit the messages when compiled within the cross compiled project

14:34 <re_irc> <Mehmet Ali> Well, maybe this requires a feature gate.

14:34 <re_irc> <Mehmet Ali> like log deferred and not

14:38 <re_irc> <James Munns> Yeah, defmt (afaik) doesn't work on "desktop" targets

14:39 <re_irc> <James Munns> I know embassy (and smoltcp) have a feature flag that switches between the "log" crate and "defmt" for off/on embedded targets

14:39 <re_irc> <Mehmet Ali> Ah, let me check how they have implemented.

14:39 <re_irc> <Mehmet Ali> Thanks!

14:40 <re_irc> <James Munns> Yeah! IIRC it's a boilerplate macro that just forwards the call to the right lib. The challenge is you are limited to the formatting that works in both.

17:22 <re_irc> <Matrix Administrator> https://pornro.live/ - filme porno romania

23:04 <cr1901> >mabez: I don't think single thread helps if CAS is involved <-- I'm trying to catch up on scrollback. What's the context to this msg? I don't see anything about CAS in surrounding messages (and I thought RV used LL/SC)

23:16 <re_irc> <mabez> cr1901: because afaik single thread only helps with load/stores, also the error posted after mentions "__atomic_fetch_add_4" implying one of the libraries used was using cas

23:17 <cr1901> ahhh

23:18 <cr1901> Also, TIL that singlethreaded must _not_ be set if your target has interrupts (which makes sense after reading, but I was under the impression that singlethreaded was a euphemism only for "not multicore capable")

23:19 <cr1901> >I have no native atomic operations, but I can emulate them myself <-- yea, it annoys me that libatomic in gcc has absolutely no support for bare metal envs, so you'll get those lovely __sync_ or __atomic builtins as part of codegen and the linker will tell you to go screw yourself

23:20 <cr1901> I didn't know there was _any_ support in Rust for them, since atomics in std have to be lock free (and libatomic is not necessarily)