<M9names[m]>
oh, i guess that's a different impl right?
<M9names[m]>
it wouldn't work on cortex-m0, at least (no VTOR)
<M9names[m]>
but if you bootload a firmware that has cortex-m-rt and that feature is enabled you'd get the same effect, no?
<JamesMunns[m]>
yep, but I spent some time confused why my app was crashing, it was because I forgot to call the "set vtor" function before bootload, and didn't have that feature enabled in my app
<JamesMunns[m]>
<M9names[m]> "it wouldn't work on cortex-m0..." <- I *think* m0+ can have a vtor (as a treat)
<M9names[m]>
yeah m0+ is fine, it's only m0 that's weird like that
<JamesMunns[m]>
IMO on platforms with a vtor, we should be setting it. At least mention it on the function like "hey if you don't set the vtor, or your app doesn't use `set-vtor`, it'll misbehave"
<M9names[m]>
and presuming that other bootloaders might not set vtor, it was decided the best option was to set it in the application (if it makes sense to).
<M9names[m]>
at least documenting this footgun makes sense to me
<JamesMunns[m]>
yeah, (just to be clear) I'm not advocating for set-vtor to be enabled by default, but rather the bootload function to specifically use the provided vector table address as the value to set the vtor to.
<JamesMunns[m]>
I don't think you'd ever bootload to the softdevice, for example
<JamesMunns[m]>
I feel like I run into this every time I write a bootloader
bpye has joined #rust-embedded
wassasin[m] has joined #rust-embedded
<wassasin[m]>
Is anyone using unmanaged QSPI NAND flash for a project here? Rolling their own bad block management and such
<wassasin[m]>
Apparently the NRF chipset QSPI is tailored for NOR flash and NAND is explicitly not supported. In devzone tickets Nordic devs are like "no NAND is a terrible idea", but I honestly do not understand what the fuss is about if you properly implement the bad block mangement. At least the NRF52 QSPI apparently has a baked in 0x05 command that is sent at activation that you can not bypass, and your NAND might not support it
<wassasin[m]>
This might be a reason for me to switch MCU last-minute to something that has better support or if any of you has any good experiences
<wassasin[m]>
Maybe go even with an STM with proper SDMMC support, saves me a bit of software implementation
jistr has quit [Quit: quit]
jistr has joined #rust-embedded
mobergmann[m] has joined #rust-embedded
<mobergmann[m]>
Is there an easy way to figure out the parameter type when passing a "complicated" struct, utilizing the embedded_hal? E.g. I am trying to pass the VL53L0x struct from https://docs.rs/vl53l0x/latest/vl53l0x/struct.VL53L0x.html to a function, but I cant figure out the trait specification for the parameter.
<davidmpye[m]>
i'm just using the crates off crates.io rather than embassy directly from github
cinemaSundays has joined #rust-embedded
<davidmpye[m]>
Given that the various postcard init functions take and consume the USB driver, am I correct in thinking there's no way to create any other USB endpoints for other functions on the device when using postcard as-is?
<davidmpye[m]>
*postcard-rpc
<JamesMunns[m]>
There's not a helper function for it, but you definitely can. You can check out the setup function and modify it to create multiple endpoints
<JamesMunns[m]>
If there's something that's not public that prevents you from doing that, lemme know and Ill correct that
<dirbaio[m]>
you could take `&mut Builder` to create the postcard-rpc stuff on it, but still leave access to the user to create other classes
<dirbaio[m]>
same as the class impls on embassy-usb itself do
<davidmpye[m]>
Because init() takes and consumes the UsbDevice, and does the build functionality internally, there's no way to work round it without modifying postcard itself (to create additional endpoints inside init() ) as far as I can see?
<davidmpye[m]>
if it took a &mut builder, then it could do the building but still leave the builder available to the caller? That said, I did wonder if it might e possible to use init_without_build as that does return the builder to the caller
<JamesMunns[m]>
Ah yeah, that got added recently
jgmerritt has joined #rust-embedded
jgmerritt has left #rust-embedded [WeeChat 4.5.1]
cinemaSundays has quit [Quit: Connection closed for inactivity]
EricHolk[m] has joined #rust-embedded
<EricHolk[m]>
Does anyone here have experience using Rust on the Raspberry Pi Pico 2? I'm trying to get a simple blink program working, and I've got it compiling, then I used elf2uf2 to make a UF2 file, but when I copy this onto the Pico2 nothing happens. It sounds like this means there's usually something that the Pico2 doesn't like about the UF2 header, but I'm not sure how to tell what's missing. (I'm new to embedded Rust, most of my
<EricHolk[m]>
embedded experience is using Arduino a few years ago)
<JamesMunns[m]>
Might be worth asking in #rp-rs:matrix.org (if you're using rp-hal) or #embassy-rs:matrix.org (if you're using embassy-rp), I know some folks are using it already!
<EricHolk[m]>
awesome, thanks! (I'm also pretty new to Matrix :) )
thejpster[m] has joined #rust-embedded
<thejpster[m]>
people often use rp-rs regardless of which HAL they use.
<thejpster[m]>
Eric Holk which one are you using and which blinky are you using? If you wrote it from scratch, you'll be missing the Image Definition Block that tells the Boot ROM vital details about your binary (like whether you want to run it in Arm mode or RISC-V mode).
<EricHolk[m]>
It's one I've cobbled together from two or three different repos, so everything is wrong I'm sure :)
<thejpster[m]>
if you don't have picotool, it's worth getting it. It talks to the Boot ROM over USB and can ask it things like "do you have a partition table" and "what is installed on you right now". Much nicer than dropping UF2 files and hoping they work.
<thejpster[m]>
Note the ImageDef block which goes into a special linker input section to make sure it appears somewhere in the first 4K of the binary where the Boot ROM looks for it.
dngrs[m] has joined #rust-embedded
<dngrs[m]>
Wow their Mac build script straight up nukes stuff in /use/local/bin, rude
<thejpster[m]>
a classic embedded firmware failure mode is to fail to pass the linker script to cargo (using .cargo/config.toml, or RUSTFLAGS). You can inspect the binary with rust-objdump (cargo install cargo-binutils) and check the symbol is where you expect it to be.
<EricHolk[m]>
Okay, I got the rp-rs blinky built and working!
<davidmpye[m]>
James Munns: Don't suppose you have come across an error from the rust compiler complaining about the assert! and unreachable! macros that themselves come from define_dispatch! being ambiguous?
<davidmpye[m]>
= note: ambiguous because of a conflict between a name from a glob import and an outer scope during import or macro resolution
<davidmpye[m]>
= note: `assert` could refer to a macro from prelude
xnor has quit [Ping timeout: 260 seconds]
xnor has joined #rust-embedded
<JamesMunns[m]>
I didn't think I've seen that before, if you can post the full error in an issue I can look tomorrow
ego_undefined has joined #rust-embedded
ego_undefined has quit [Remote host closed the connection]