03:47 <rafael[m]> <M9names[m]> "Maybe the default value for..." <- Thx! Will try that as soon as I find the time this week.

10:44 <dngrs[m]> * the #rp-rs:matrix.org room might have

11:21 <chrysn[m]> <krensito> "Does cargo-embed somehow support..." <- > <@krensito:matrix.org> Does cargo-embed somehow support colorful output for the log levels?

11:21 <chrysn[m]> > INFO in blue and so on

11:21 <chrysn[m]> There's an issue about it at https://github.com/probe-rs/probe-rs/issues/1377 -- I've started to look into how to best resolve the reasons for why the codes are filterd out, but am not sure it can be done easily without just moving to something like a scroll view widget (which then still needs workaround because at least the one I've looked at expects a fixed size rather than indefinitely growing).

13:32 <ckrenslehner[m]> Thanks for this information. I need to take a look at the code at some point to get a better understanding on how things work

14:56 <SiddharthChandra> Hi, I have a few nice!nano v2 clones (NRF52840) which have the adafruit bootloader pre-flashed. Has anyone used these for rust development? I don’t have a j-link with me so I would like to use the bootloader to flash (like the esp32) controller but don’t want use the u2f file based flashing. The bootloader documentation says it supports serial DFU but I cannot locate a serial device when the device is plugged in

14:57 <SiddharthChandra> * based flashing as the workflow is slower. The

14:58 <dirbaio[m]> My advice is get a debug probe

14:58 <dirbaio[m]> And use SWD to flash and debug

14:58 <dirbaio[m]> Nrf is not designed for developing via USB bootloader

14:59 <dirbaio[m]> You can get it working and then you can add usb logging to your firmware, but you won't get log messages from panics

14:59 <dirbaio[m]> Which is terrible for debugging

14:59 <SiddharthChandra> I did consider that. And then considered using a Pi zero to bitbang swd. But those solutions sounds clumsy compared to a bootloder which allows me to flash with serial interface (as I don’t care about debugging)

15:00 <SiddharthChandra> * care about hardware debugging)

15:00 <dirbaio[m]> You care about panic messages tho?

15:00 <SiddharthChandra> And it does not help at all that j-link is expensive.

15:01 <dirbaio[m]> If you access an array out of bounds you'll just see the firmware freeze

15:01 <dirbaio[m]> With no idea where's the problem

15:01 <dirbaio[m]> SiddharthChandra: Get a raspberry pi debug probe. Cheap and works very well with all arm chips including the nrf

15:01 <SiddharthChandra> dirbaio[m]: That I do. But isn’t there a way to get that working in some other method?

15:01 <dirbaio[m]> No

15:02 <dirbaio[m]> If the firmware crashes usb stops working so the panic message can't go through

15:03 <diondokter[m]> Using a debug probe is the way these chips are designed to be flashed and debugged. Doing other things can work, but never as good as a real debugger

15:07 <SiddharthChandra> Okay, will get the Pi debug probe

15:11 <thejpster[m]> Oh no. A client on a training says "my dictionary doesn't print".... (full message at <https://catircservices.org/_irc/v1/media/download/AVziyYGvSuvsj0MaUoTpflBOP3HVmq6cq_D3zU416Fjikxt4aqwwnager027VZ7T1m4p0Qc7fKyhwlOH8_4aV-O_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9ObXZEZWZGT3VuSlBDdUVWa2lHY3djcnM>)

15:11 <thejpster[m]> Other people had no problems with exact same data type for dict

15:11 <thejpster[m]> or even the exact same line of code to print it out

15:12 <thejpster[m]> It's a heapless::LinearMap if that matters

15:12 <mabez[m]> host tooling issue?

15:12 <dirbaio[m]> If gets too big and overflows the buffer so the whole line gets dropped?

15:12 <diondokter[m]> One item being so large it doesn't fit in the RTT buffer?

15:12 <thejpster[m]> dirbaio wins a biscuit

15:13 <thejpster[m]> Debug formatting for LinearMap<u8, u8, N> is pretty verbose (and in decimal)

15:13 <dirbaio[m]> I've seen this before 😐

15:13 <thejpster[m]> at about 128 entries, you're over 1024 bytes of string.

15:13 <dirbaio[m]> Only with our factory tooling tho. Did it happen with probe-rs as well?

15:13 <dirbaio[m]> The issue is not switching RTT to blocking mode properly

15:14 <thejpster[m]> it's horrible. I'd much prefer a ... ellipsis indicating truncated output

15:14 <thejpster[m]> this was probe-rs 0.27

15:14 <dirbaio[m]> If RTT is in blocking mode it should stream the log frame just fine even if it's larger than the buffer

15:14 <dirbaio[m]> The cpu blocks if buffer is full, then the probe drains it, then the cpu resumes

15:15 <dirbaio[m]> If it's not doing that then it's a bug

15:16 <thejpster[m]> I guess I'll need to poll the "are we in blocking mode" bit.

15:20 <danielb[m]> <dirbaio[m]> "The cpu blocks if buffer is full..." <- the CPU can actually print stuff before the debugger gets to reconfiguring the channel to blocking, unfortunately

15:21 <JamesMunns[m]> this is why probe-run used to set a breakpoint to prevent that from happening 😛

15:21 <dirbaio[m]> Probe-run had this thing where it'd set a breakpoint on main, run until main , then switch RTT to blocking, then resume

15:21 <dirbaio[m]> Yeah

15:22 <dirbaio[m]> This was carried over to probe-rs tho

15:22 <danielb[m]> JamesMunns[m]: yeah but where to set it to...

15:22 <dirbaio[m]> So maybe there's some bug

15:22 <danielb[m]> probe-rs doesn't set a breakpoint on main at all

15:22 <JamesMunns[m]> dirbaio[m]: I'm pretty sure it wasn't

15:22 <dirbaio[m]> danielb[m]: It'd hardcode the symbol used by cortex-m-rt

15:22 <dirbaio[m]> Ouch

15:22 <danielb[m]> dirbaio[m]: I have my opinion on that

15:22 <dirbaio[m]> Well that explains it then

15:23 <danielb[m]> also, rtt_target doesn't do anything before main

15:23 <JamesMunns[m]> I could have sworn I had an issue on probe-rs tracking this, not sure where it went tho

15:23 <diondokter[m]> Afaik, it does still set it to blocking...

15:23 <dirbaio[m]> 😩

15:24 <danielb[m]> https://github.com/probe-rs/probe-rs/issues/2185

15:24 <danielb[m]> but: 1: nobody cares enough to do it and 2: it's not a good solution due to rtt_target

15:24 <JamesMunns[m]> Ah, Tiwalun opened it

15:25 <dirbaio[m]> Maybe we can extend RTT somehow so that probe-rs places a magic value on the RTT control block and then init sees it and switches to blocking mode right from the start? This way you don't need any breakpoint funny business

15:25 <danielb[m]> segger would be rather sad

15:26 <danielb[m]> firmware can detect if a debugger is attached, and configure themselves

15:26 <dirbaio[m]> Segger is already sad yhst everyone is using their patented RTT

15:26 <dirbaio[m]> s/yhst/that/

15:27 <thejpster[m]> SEGGER sponsored my Embedded World demo, and they think defmt over RTT is really cool.

15:27 <thejpster[m]> They just asked me to remind everyone it's called "SEGGER RTT" not "RTT".

15:27 <danielb[m]> lmao

15:28 <thejpster[m]> defmt-over-RTT also works in the Ozone debugger (if you use defmt-print to connect to their TCP socket).

15:29 <thejpster[m]> also, this failure mode occurs after ~2 seconds of runtime and about a thousand previous messages.

15:30 <JamesMunns[m]> what version of probe-rs?

15:30 <JamesMunns[m]> there was an off-by one error in rtt a couple versions ago

15:31 <thejpster[m]> 0.27 - the lateste

15:31 <thejpster[m]> * 0.27 - the latest

15:31 <danielb[m]> okay so is this one of the many rtt bugs we fixed since 0.27?

15:33 <thejpster[m]> https://github.com/probe-rs/probe-rs/commit/9ef35402283e1d1fb5cb6bd87f957dc6f39dcfba

15:33 <thejpster[m]> > Fixed defmt not being able to read messages larger than the RTT buffer.

15:33 <danielb[m]> man, why do you make me debug code I've already debugged?

15:34 <thejpster[m]> why do you make me use releases with known bugs in them?

15:34 <thejpster[m]> (I'm kidding. I know I'm entitled to a Full Refund of the $zero I paid)

15:35 <danielb[m]> thejpster[m]: I have an answer for that

15:36 <danielb[m]> probe-rs is really frustrating to work on, because the project has a 1-approval-needed policy and no maintainers

15:36 <danielb[m]> or, rather, out of the 12 people in the org only Noah occasionally merges stuff

15:36 <danielb[m]> or Scott if it's Espressif-relevant

15:37 <danielb[m]> so you are allowed to say that a relase is slow in coming, but I don't think the current state is release-ready and I can only take one step at a time

15:38 <thejpster[m]> "Why no release", "Because master is not ready to release" - can't argue with that.

15:38 <thejpster[m]> (also, I note the choice of branch name but I'm not getting into it)

15:38 <danielb[m]> thejpster[m]: you're already getting into it by saying that

17:32 <chrysn[m]> ad lost messages: I think every ring buffer where "don't put it in there it's too big" needs a dropped-message indicator or counter.

17:33 <chrysn[m]> I've also encounterd this kind of overflow, and spent more time than I should have wondering why my printf debugging didn't take the path it actuallyt ook.

18:58 <r[m]> tags

19:02 <JamesMunns[m]> danielb how can I help you call for more maintainers for probe-rs?

19:03 <danielb[m]> i can do no such thing, I don't think so :) probe-rs isn't my project

19:04 <JamesMunns[m]> Noah same question

19:05 <JamesMunns[m]> Let's treat it like a bug and figure out how to resolve it, and let's get probe-rs some more maintainers.

19:41 <Noah[m]> <danielb[m]> "i can do no such thing, I don'..." <- You are as entitled as anyone :)

19:41 <Noah[m]> * You are as entitled to call it your project as me :)

19:41 <danielb[m]> I usually have merge rights to my projects 🙈

19:42 <Noah[m]> <JamesMunns[m]> "Noah same question" <- eh, it's tricky. essentially same problem as before I started the project. nobody wants to touch this dreadful thing with debug probes, everyone wants to make the shineys with firmware ;)

19:42 <Noah[m]> danielb[m]: eh, I tried to improve recently, but I guess not enough :(

19:44 <Noah[m]> <JamesMunns[m]> "Let's treat it like a bug and..." <- yeah it's def. a bug. problem is: most of the maintainers that were once upon a time have huge projects/tasks in the oss community (adam, dario) or do this for a living already (dominik)

19:44 <Noah[m]> not sure what's up with jack tbh :)

19:45 <Noah[m]> fortunately there is some nice folks that answer questions best to their ability in the chat, but nobody actively writes code other than daniel

19:45 <Noah[m]> and I am just trying to chip away at my one thousand projects I have -.-

20:35 <rafael[m]> <M9names[m]> "Maybe the default value for..." <- You are a genius! That was my problem. I did w write where I should have done a modify, overwriting the register and that way basically cuttin power to the core because the EN field is kind of important to be at 1 and not 0 🙂

21:25 <reitermarkus[m]> Heapless 0.9.0 is out!

21:25 <reitermarkus[m]> https://github.com/rust-embedded/heapless/releases/tag/v0.9.0

21:26 <danielb[m]> wow that's a lot of "Added" entries 👀

21:26 <danielb[m]> congrats!

21:37 <PhilMarkgraf[m]> Went to check it out, but got: docs.rs failed to build heapless-0.9.0

21:56 <reitermarkus[m]> Yeah, just saw it too. Seems we missed adding the bytes feature to CI.

22:03 <reitermarkus[m]> Going to sleep now, anyone feel free to fix https://github.com/rust-embedded/heapless/issues/566 in the meantime. :)