00:09 <M9names[m]> <slabity[m]> "Is there something I'm missing?" <- please share your project. it's going to be very hard to anyone to diagnose an issue like this without being able to observe the problem firsthand

00:12 <slabity[m]> Yea, sure. It's pretty straight-forward: https://gist.github.com/Slabity/feba4721928b557d5b117beec684d284

00:13 <slabity[m]> The main.rs file just contains setup code to spawn the adc_task on CORE1 and then it just flashes the LED

00:15 <slabity[m]> The ADC code isn't really too fancy either. It's just doing some readings of an ADC over an I2C connection. The issue is that when I upload the code after plugging in my programmer/debugger it just reports this:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ghrJpCfoupzQOJEPcLuwtOdW>)

00:18 <slabity[m]> The code *does* successfully flash. If I power it off and on the new code runs without any issue. However, in order for the log statements to appear on the debugger I need to:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/gCZTtRPRWLgTaOtjzZQrPaUh>)

00:22 <M9names[m]> you're not resetting the spinlock used by the rp2040 critical-section on startup, that's going to be one potential cause of lack of logs (because it will deadlock a lot of the time)

00:23 <slabity[m]> Hmm... I'm not seeing that in the multicore.rs example in the embassy_rp crate.

00:24 <M9names[m]> it's not in any of the examples, but it is still required

00:24 <M9names[m]> embassy_rp::pac::SIO.spinlock(31).write_value(1);

00:25 <M9names[m]> put it as the first line in main

00:26 <trinhtuan[m]> Does anyone successfully use sleep() in a bare metal esp32 (no-std) program? I have tried and searched google but no success. A sample working code is really appriciated also. By the way what are the differences behind the scenes between sleep() and delay()? Thank you.

00:27 <M9names[m]> #esp-rs:matrix.org is a good place for that question, everyone who knows how it's implemented will be there

00:28 <slabity[m]> M9names[m]: ```rust... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/GScpqyWEMVgmUrkRdgBvFCfi>)

00:28 <slabity[m]> Oh, I think I am missing a feature

00:29 <M9names[m]> yeah, you need "unstable-pac"

00:30 <slabity[m]> Okay, so that compiled and uploaded. Still same issue though. Program is not executing

00:31 <slabity[m]> And if I disable the CORE1 program and reupload...

00:32 <slabity[m]> Restart the power, then re-enable CORE and upload...

00:32 <slabity[m]> And now it executes

00:34 <M9names[m]> could you share your cargo.toml as well? i can't get the code you posted to compile, not sure if it's crate versions or because the code is broken

00:34 <slabity[m]> Sure, give me one moment and I should be able to upload the entire Git repo

00:35 <M9names[m]> i would recommend doing it this way in the future. having to RE someone else's project config is tedious

00:36 <slabity[m]> Yea, I just haven't actually committed anything because I was just messing around and didn't have a particular goal in mind. Just have a bunch of files to clean up first

00:42 <slabity[m]> Alright, done: https://github.com/Slabity/actuator-controller

00:43 <slabity[m]> Can ignore the flake.* and .direnv files if you don't use Nix or direnv

00:43 <slabity[m]> * Can ignore the flake.* and .direnv/.envrc files if you don't use Nix or direnv

00:46 <slabity[m]> s//`/, s/.*/.*`/, s/.direnv/`.envrc`/

00:48 <slabity[m]> Oh, also I made some changes to use assign-resources because I was told it makes things a lot cleaner for passing clear delimination of resources

00:50 <slabity[m]> My suspicion is that core 1 isn't getting paused or reset when flashed, and so it could be just trying to pick up where it left off for some reason?

00:51 <M9names[m]> seems to reliably print logging info on my end, though obviously it is panicking when trying to do i2c reads.

00:51 <M9names[m]> yeah, maybe? you can manually reset core1 on startup to ensure it's in a good state.

00:52 <M9names[m]> spawn_core1 already does this, but maybe it needs to happen earlier

00:53 <slabity[m]> Well the strange thing is it doesn't even get to the "Starting program" state before the core1 process even spawns. It just doesn't print anything unless I remove the core 1 process, upload it, then reset the entire thing and upload the new program again

00:58 <slabity[m]> Hmm... I tried simplifying it by removing the ADC process entirely and making it just an LED flasher on Core 1:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ZUxeSsuiYutgLSIEzoIfZvRc>)

01:03 <M9names[m]> one other thing you're doing that's not recommended is relying on git master versions of embassy things.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/zTtKNYyqRZZpMgPqFuqNmZyc>)

01:05 <slabity[m]> Yea, that's definitely an issue. I was told a new update will remove some of the generics issues I was having so I just wanted to rollover to master until that was fixed.

01:05 <slabity[m]> Honestly the entire thing has been kind of me just kicking stuff around to see how embedded rust works.

01:06 <slabity[m]> So I have not been following best practices

01:07 <M9names[m]> are you running release builds?

01:07 <slabity[m]> Well I just updated to debugprobe-v2.0.1 and that doesn't seem to have helped. Wasn't sure if maybe there was some bug there causing it to not reset properly

01:08 <slabity[m]> No, I was hoping to keep debug symbols for the debugger to use

01:08 <slabity[m]> Oh wait, there was a solution for that somewhere

01:08 <slabity[m]> So that I could use DWARF symbols or something in release builds?

01:08 <M9names[m]> add... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/RYKmMCsgQNFJscbfXVpKInQa>)

01:10 <slabity[m]> Thanks, I'll use release builds in case the debug builds were causing any issues

01:10 <slabity[m]> Though after updating and everything it still seems to be the same exact issue for some reason.

01:10 <slabity[m]> Also that timer panic seems suspicious

01:15 <M9names[m]> yes, it does

01:15 <slabity[m]> Looks like people using OpenOCD have been having issues with multicore programs as well:

01:16 <slabity[m]> - https://forums.raspberrypi.com/viewtopic.php?t=349795

01:16 <slabity[m]> - https://forums.raspberrypi.com/viewtopic.php?t=336715

01:30 <slabity[m]> Well I think I'm just going to not use the second core until I can figure out what's going on with that. I'll just be happy embassy easily lets me move tasks around without needing to rewrite a ton of code

01:31 <M9names[m]> i'm not able to reproduce any issues replacing your adc task with a blinky on my end, so i'm afraid i won't be much more help

01:32 <slabity[m]> Yea, maybe it's literally my RP2040 having an issue.

01:33 <slabity[m]> I did have a faulty ADC, so maybe some other weird stuff is going on

01:37 <slabity[m]> I have to give credit where it's due though, the issues I've been running into with embassy have been way minor compared to needing to manually set up interrupts and entire state machines to get things working asynchronously in C++.

02:06 <M9names[m]> just had a bit of a struggle trying to install the latest git version of probe-rs (the cli tools).... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/LCOtRCzrQYaTtLcCgsjmKKyh>)

02:19 <M9names[m]> latest git probe-rs locks up exactly as you described @slabity - is that what version you are using?

02:19 <M9names[m]> release versions 23 and 22 work fine.

02:30 <slabity[m]> $ probe-rs --version

02:30 <slabity[m]> probe-rs 0.23.0

02:30 <slabity[m]> git commit: crates.io

02:47 <M9names[m]> oh no, it's not a probe-rs issue, it is the firmware. it just locks up after running for a while. cool cool, that's something debuggable.

03:08 <M9names[m]> reproduced. it's rtt buffer being full and blocking the second core. recovery requires that the spinlock is cleared before main.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/QiRuxJmloushJbGplsMFuqNQ>)

03:11 <M9names[m]> actually doesn't require 2nd core. just spinning in a loop on core0 defmt::printing is sufficient to encounter this issue.

03:32 <M9names[m]> ah no, this issue only happens on git probe-rs not 23, your issue must be different to this one.

05:48 <slabity[m]> <M9names[m]> "reproduced. it's rtt buffer..." <- > <@9names:matrix.org> reproduced. it's rtt buffer being full and blocking the second core. recovery requires that the spinlock is cleared before main.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/DHIaihKJMFKJagDZQFqjUHdo>)

05:50 <slabity[m]> I do get these warnings when I stop `probe-rs` now though... But they're completely benign for me.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/SNwiJyQJYbmmBFXSIAYoHCgA>)

05:50 <slabity[m]> <M9names[m]> "ah no, this issue only happens..." <- Oh, just read this... But it seems to have fixed it on my end, so possibly related?

06:36 <M9names[m]> different issue but same solution i think

09:45 <jannic[m]> <M9names[m]> "reproduced. it's rtt buffer..." <- > <@9names:matrix.org> reproduced. it's rtt buffer being full and blocking the second core. recovery requires that the spinlock is cleared before main.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/CFfGSquKmqRGIWfcYpDSfwWK>)

09:49 <JamesMunns[m]> jannic[m]: I'd imagine the second core might be running with access to resources and memory it shouldn't have, so pre-init ensure it happens before any memory init possibly happen

09:50 <JamesMunns[m]> JamesMunns[m]: agreed pre_init is Not Great, tho, but probably fine for a single volatile op.

09:50 <JamesMunns[m]> s/happen/happens/

09:59 <M9names[m]> > Shouldn't it be sufficient to do it at the first command within main... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/xcQsgsXsAlQmfMOptNcaqfnv>)

10:05 <JamesMunns[m]> Yeah, idk how much it's POSSIBLE to have miscompilations in `pre_init`, but it's definitely breaking the environmental contract with the rust abstract machine (e.g., some invariants hold true before Rust "starts", e.g. statics will be initialized either to zero or their initial value).... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/GYNKvNxzPhRJCkUgxdYtISya>)

10:06 <JamesMunns[m]> Using statics in pre-init would be a big red flag to me (even/especially read access of statics!), and any writes to statics that aren't uninit/in other sections would be another big red flag.

10:07 <JamesMunns[m]> that being said, "ub is ub and all bets are off and you can't reason logically about it over time", but I can't particularly imagine what the compiler would burn us with outside of static access.

10:09 <JamesMunns[m]> that being said that being said, the optimizer doesn't super mess with volatile ops, so this usage doesn't spook me, personally, for what that's worth.

10:55 <jannic[m]> Yes, I agree it's probably fine. And for a firmware with limited scope and no intention of long-term maintainability, that should be enough. So just to get things running, I'd probably do the same. I'm just a bit wary of any general advice short of "avoid rust code in pre_init".

11:07 <jannic[m]> <M9names[m]> "> Shouldn't it be sufficient..." <- > <@9names:matrix.org> > Shouldn't it be sufficient to do it at the first command within main... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/PXJJubrSeUGfmAoZWlTHcmIt>)

12:12 <dirbaio[m]> A custom entry macro composes badly. For example embassy-executor or rtic have their own entry macros too, you can't use both at the same time 

12:14 <dirbaio[m]> Perhaps the hal can put a pre_init for you. That'll mean the user won't be able to use pre_init themselves tho. 

12:16 <JamesMunns[m]> yeah, extern unmangled pre_init global asm, behind a default feature, on the rp-hal or embassy-rp crates would be pretty slick, IMO

12:16 <JamesMunns[m]> (pre_init usage is rare, and having a feature to disable it would cover any complaints, imo)

14:35 <Seth[m]> ppl

14:35 <Seth[m]> I could use some help

14:35 <Seth[m]> yo

14:36 <Seth[m]> I can't get Joshuto to work with Ueberzugpp

14:57 <xiretza[cis]> <Seth[m]> "I can't get Joshuto to work with..." <- how is that related to using Rust on embedded devices?

15:03 <Seth[m]> ...oh that's what this room is about 💀

15:03 <Seth[m]> well

15:03 <Seth[m]> Joshuto is written in Rust

15:03 <Seth[m]> and...

15:03 <Seth[m]> okay fine nvm

20:34 <whitequark[cis]> none of these words are in the bible

21:05 <sirhcel[m]> Has anyone a good example/best practices for how to diable some tests requiring actual hardware in ci? Feature, environment variable, ... I'm working on cleaning up tests for serialport-rs and encountered that some of them always suceed due to ignoring Results. Fixing this will cause our ci to fail due to not having any serial devices there and i want to disable tests actually using a serial device in ci.

21:06 <sirhcel[m]> * Has anyone a good example/best practices for how to diable some tests requiring actual hardware in ci? Feature, environment variable, ... I'm working on cleaning up tests for serialport-rs and encountered that some of them always suceed due to ignoring Results. 😅 Fixing this will cause our ci to fail due to not having any serial devices there and i want to disable tests actually using a serial device in ci.