<posborne[m]>
👋 Hey all, I'm back from my adventure out on the PCT. I'm going to remain on hibernation for the time being until I've got employment and life sorted out again but feel free to ping me if there's anything outstanding that could use my attention/input on the Linux side of things within rust-embedded.
M9names[m] has joined #rust-embedded
<M9names[m]>
<huayra1[m]> "when you write an ffi for a c..." <- that's how i do it, and it does seem to be a common convention if you're not building a standalone *-sys crate
mengkeyu[m] has left #rust-embedded [#rust-embedded]
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
<sourcebox[m]>
<explodingwaffle1> "ima_0d2e6cd.jpeg" <- That would mean we also need to have 0x0201 as option.
mkesper[m] has joined #rust-embedded
<mkesper[m]>
<JamesMunns[m]> "btw, the next-up feature is..." <- Sounds really nice, maybe this could be a step into Rust for people more used to e.g. MicroPython REPL?
<JamesMunns[m]>
mkesper[m]: That's an option! I also plan to make a python library from it, so you could get a very similar experience, where the REPL is on your PC, but instead of running the scripts on the MCU, you're running it locally and the hardware commands get "proxied" to the external device.
nickez[m] has quit [Quit: Idle timeout reached: 172800s]
chrysn[m] has quit [Quit: Idle timeout reached: 172800s]
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
okhsunrog[m] has quit [Quit: Idle timeout reached: 172800s]
dngrs[m] has joined #rust-embedded
<dngrs[m]>
Resident REPL fan tuning in
<dngrs[m]>
I am on and off working on Rust based REPL/interpreted stuff on-device
<dngrs[m]>
But it's a really big problem space
omani[m] has joined #rust-embedded
<omani[m]>
is there any crate that implements `TcpStream`? the equivalent of std::net::TcpStream or tokio, etc.
<omani[m]>
* is there any crate that provides a `TcpStream`? the equivalent of std::net::TcpStream or tokio, etc.
<omani[m]>
* is there any crate that provides a `TcpStream`? the equivalent of std::net::TcpStream or tokio, etc.
<JamesMunns[m]>
Are there any power jumpers on the board, and are they in a reasonable position?
<JamesMunns[m]>
Ralph ^ - this might happen if the probe is powered but the target chip is not powered.
<Ralph[m]>
the jumpers seem to be in a reasonable state (aligned with the manual) and the power LED (LD3) on the main part is lighting up => it should receive power
<JamesMunns[m]>
debugger jumpers at the top still there?
<JamesMunns[m]>
the two up top to the left of the USB port
<Ralph[m]>
yep, they're there
<Ralph[m]>
i also just put a multimeter to the GND & 5V ports and i get ~5V, so that's looking fine.
<Ralph[m]>
and the chip is not getting crazy hot (i had that two years ago where it fried one and it was the same as now: the probe would work but the chip wouldn't be reachable; but then the chip would feel very hot to the touch)
<Ralph[m]>
`cargo run` fails but `cargo run -- --connect-under-reset` works
<Ralph[m]>
why would i need to always do `connect-under-reset`? is there some weird flag set somewhere?
<JamesMunns[m]>
yeah that modifies how the debugger interacts with the chip, iirc some stm32s require it
<JamesMunns[m]>
folks in #probe-rs:matrix.org might be able to explain the root cause better :)
<JamesMunns[m]>
or you could have a firmware that is using wfi or something and the chip is asleep which means the debugger can't talk to it? I can't remember honestly.
<JamesMunns[m]>
(and by connecting under reset it is possible to talk to the debug core?)
<JamesMunns[m]>
but yeah, you'd just update your .cargo/config.toml runner flag to just add --connect-under-reset to the probe-rs invocation
<Ralph[m]>
<JamesMunns[m]> "(and by connecting under reset..." <- how would i verify this?
<Ralph[m]>
JamesMunns[m]: i'd prefer not to do this... it worked fine without this flag for the last two years of using this board/chip type :|
<JamesMunns[m]>
Oh, I'm just guessing at why it is necessary
<Ralph[m]>
> <@jamesmunns:beeper.com> but yeah, you'd just update your `.cargo/config.toml` `runner` flag to just add `--connect-under-reset` to the probe-rs invocation
<Ralph[m]>
* i'd prefer not to do this... it worked fine without this flag for the last two years of using this board/chip type :|
<Ralph[m]>
i'll check in the probe-rs channel, thanks for your hints!
<JamesMunns[m]>
Ralph[m]: run a basic firmware (not with rtic or embassy), or one where you override the "idle" behavior of using wfi (I think it's a config setting for embassy's init function)
FreeKill[m] has quit [Quit: Idle timeout reached: 172800s]
<Ralph[m]>
well, i don't know what happened, but now it's magically back to working just fine even without --connect-under-reset - regardless of whether i upload the blinky example from stm32f4xx-hal or my small RTIC (v1) program and regardless of which one is currently running 🤷
<thejpster[m]>
Please take a moment to test it against your favourite disk images. There's a 'shell' example you can use to poke around them. I just loaded up a Windows 95 disk image and it all seems OK.
<jannic[m]>
I only had a very quick look, but my first impression is good. Much more flexible. The caller can still collect the iterator into a heapless::Vec or an alloc::vec::Vec quite easily. Without being bound to a specific version of heapless.
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
sajattack[m]1 has quit [Quit: Idle timeout reached: 172800s]
omniscient_[m] has quit [Quit: Idle timeout reached: 172800s]
flippette[m] has quit [Quit: Idle timeout reached: 172800s]