<Lumpio[m]>
Yep, found the commands after being nudged towards picotool. Not having to mount the thing and having better progress/error messages is more handy anyways.
<RobWells[m]>
<Lumpio[m]> Yep, found the commands after being nudged towards picotool. Not having to mount the thing and having better progress/error messages is more handy anyways.
<RobWells[m]>
Oh, does the --force option work OK? I wasn't sure what the picotool firmware meant by "running compatible code" (and didn't test it).
<RobWells[m]>
* Oh, does the --force option work OK? I wasn't sure what the picotool help message meant by "running compatible code" (and didn't test it).
M9names[m] has joined #rust-embedded
<M9names[m]>
pico-sdk's default setup provides stdout via usb-uart, and also has an endpoint you can use to trigger entry to the ROM bootloader so that the device will be programmable via the UF2 interface.
<Lumpio[m]>
I didn't try --force, no, but thanks for letting me know about it, I'll probably add the vendor specific interface into my firmware for easier development (I'm using a tiny board with no SWD header for this)
glitchy has quit [Remote host closed the connection]
glitchy has joined #rust-embedded
cbjamo[m] has quit [Quit: Idle timeout reached: 172800s]
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
MustafaKK[m] has joined #rust-embedded
<MustafaKK[m]>
hi, is there anyone among you who uses Rust on ESP32?
<MustafaKK[m]>
Is there a way to adapt libraries that use std when using esp32 rust?
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
for esp32 specific question we have a seperate room over https://matrix.to/#/#esp-rs:matrix.org . When you are compiling against the xtensa/riscv-esp-idf targets than as long as the resource constraints/system specific's of the mcu are met you can use other std librarys, if they themself are not written for a specific target.
<vollbrecht[m]>
For running ontop of the baremetal esp-hal. e.g compiling against the xtensa/riscv-none targets you have to use no_std librarys or modify a existing one to provide a no_std feature variant if that is possible.
starblue has quit [Quit: WeeChat 4.6.3]
dirbaio[m] has quit [Quit: Idle timeout reached: 172800s]
khionu[m] has quit [Quit: Idle timeout reached: 172800s]
Ralph[m] has joined #rust-embedded
<Ralph[m]>
<Lumpio[m]> Yep, found the commands after being nudged towards picotool. Not having to mount the thing and having better progress/error messages is more handy anyways.
<Ralph[m]>
you mention "not having to mount the thing"... does that mean that now that i'm using `picotool` i don't need to mount my pico anymore? that'd make life easier!
<Lumpio[m]>
<Ralph[m]> you mention "not having to mount the thing"... does that mean that now that i'm using `picotool` i don't need to mount my pico anymore? that'd make life easier!
<Lumpio[m]>
Yes, the bootloader supports two protocols, one being the mass storage device emulation and the other being "picoboot" which has much more features. picotool can use the latter to flash the device (and do other stuff too)
<Lumpio[m]>
I added the custom reset interface to my thing and it manages to reset it but doesn't seem to find it after the reset, will have to keep looking
<Lumpio[m]>
And of course this requires that your FW implements the picoboot reset request interface. But this makes it possible to run one command and update the FW without pushing any BOOTSEL buttons manually.
<Ralph[m]>
FWIW i'm using James Munns' approach of triggering the reboot through postcard-rpc, as per his example:
<Ralph[m]>
if you're anyway using prpc then this is IMHO one of the easiest approaches (just provide a bin on host side to trigger the endpoint)
<Lumpio[m]>
Are you making the literally same thing as I am lol
<Lumpio[m]>
>waveshape-rp2040-keyboard-3
<JamesMunns[m]>
I have it as a reference demo project for Poststation lol
<Lumpio[m]>
ooh
<Lumpio[m]>
Well anyways I'm happy with adding a few lines to my RMK firmware to implement the "standard" RP2040 method - I don't really need RPC for anything else
<JamesMunns[m]>
Yeah, in that case the standard rpi boot method makes more sense!
sroemer has quit [Quit: WeeChat 4.5.2]
glitchy has quit [Remote host closed the connection]
glitchy has joined #rust-embedded
everdrone[m] has quit [Quit: Idle timeout reached: 172800s]
dngrs[m] has quit [Quit: Idle timeout reached: 172800s]