<re_irc>
<@dngrs:matrix.org> : I have a daisy too! never gotten around to doing much with it either unfortunately. I've encountered these probe errors occasionally on other STM32F4 and F1 boards. What I usually do to fix them is hold the board reset button while flashing and let go before the code starts (this usually takes a few attempts :D ) - never found out what exactly is causing it.
<re_irc>
<@dngrs:matrix.org> wait, I think it was "let go of reset right before flashing starts", not "ends". Not 100% sure.
<re_irc>
<@metajack:matrix.org> Which is basically the defmt example app customized for the daisy
<re_irc>
<@metajack:matrix.org> That gives me the same error as above.
<re_irc>
<@dngrs:matrix.org> do you have the correct "memory.x" ?
<re_irc>
<@dngrs:matrix.org> (I'll be going to bed soon, maybe #stm32-rs:matrix.org (https://matrix.to/#/#stm32-rs:matrix.org) can help you more)
<re_irc>
<@metajack:matrix.org> I updated the gist with the memory.x file. It's basically from the hal crate.
<re_irc>
<@dngrs:matrix.org> feel free to "@mention" me on Saturday if your problem hasn't been solved till then and I can try to get something going on my daisy board
<re_irc>
<@metajack:matrix.org> I tried switching to rtt-target and panic-halt with the same result. Switching from probe-run to cargo embed gets me:
<re_irc>
Error Failed to attach to RTT
<re_irc>
Caused by:
<re_irc>
RTT control block not found in target memory.
<re_irc>
- Make sure RTT is initialized on the target, AND that there are NO target breakpoints before RTT initalization.
<re_irc>
- For VSCode and probe-rs-debugger users, using `halt_after_reset:true` in your `launch.json` file will prevent RTT
<re_irc>
initialization from happening on time.
<re_irc>
- Depending on the target, sleep modes can interfere with RTT.
<re_irc>
<@metajack:matrix.org> rtt_init_print!() is the first line of my entry function after which I do a single rprintln!("hello world"); and then loop {}
starblue3 has quit [Ping timeout: 240 seconds]
starblue3 has joined #rust-embedded
jasperw has quit [Ping timeout: 258 seconds]
Ekho has quit [Quit: CORE ERROR, SYSTEM HALTED.]
kenny has quit [Ping timeout: 260 seconds]
kenny has joined #rust-embedded
Ekho has joined #rust-embedded
jasperw has joined #rust-embedded
jr-oss has joined #rust-embedded
GenTooMan has quit [Ping timeout: 246 seconds]
GenTooMan has joined #rust-embedded
_whitelogger has joined #rust-embedded
Dr_Who has quit [Read error: Connection reset by peer]
crabbedhaloablut has quit [Ping timeout: 260 seconds]
crabbedhaloablut has joined #rust-embedded
Michael[m]12 has quit [Remote host closed the connection]
<re_irc>
<@joelsa:fehler-in-der-matrix.de> Hi I am using postcard to send serialized data to an stm32 via uart and i am loving it, but depending on the data i get 1501 or 1502 bytes for my vec of 500 u16 values, is there a nice way to keep it constant or know what to expect exactly?
<re_irc>
<@jamesmunns:beeper.com> If you're not using COBS, there's an experimental Schema macro that will give you the max size of a message
<re_irc>
<@jamesmunns:beeper.com> if you ARE using cobs, it's a handy way to figure out where one message ends and another starts
<re_irc>
<@jamesmunns:beeper.com> if you AREN using cobs, it's a handy way to figure out where one message ends and another starts
<re_irc>
<@jamesmunns:beeper.com> if you AREN'T using cobs, it's a handy way to figure out where one message ends and another starts
<re_irc>
<@joelsa:fehler-in-der-matrix.de> Thank you very much, the fixint encoders are exactly the right choice for me i think
<re_irc>
<@jamesmunns:beeper.com> Do note that a lot of things are varints, and there's no "everything fixed size" flag or option
<re_irc>
<@jamesmunns:beeper.com> (all integers, lengths of arrays, enum discriminants, etc.)
<re_irc>
<@jamesmunns:beeper.com> I wouldn't _generally_ recommend trying to accumulate a fixed number of bytes, not sure if you're trying to do that, or just figuring out how big the buffer should be.
<re_irc>
<@jamesmunns:beeper.com> I generally use COBS, it gives you two nice things:
<re_irc>
- You can have variable length messages
<re_irc>
- If you ever lose a byte, e.g. the wire is corrupted or the hardware drops a byte, you can recover, only losing one message, instead of corrupting messages forever.
<re_irc>
<@juliand:fehler-in-der-matrix.de> : We're trying to generate data on a PC and transfer it to the controller to verify our implementation. The problem now was that after changing something in the u16 array generation on the host, the serialized data was no longer 1501 bytes but 1502 bytes. Which then caused issues on the controller expecting 1501 bytes.
<re_irc>
Also it's pretty inefficient to transfer 1500 bytes in order to deserialize it into 500 u16s. So having a fixed size would be even more efficient in this case (I presume).
<re_irc>
It's not time-critical, so sending more data is not an issue.
<re_irc>
<@juliand:fehler-in-der-matrix.de> : This sounds like a good thing to have for transferring the results out from the controller in the field later. We will look into it, thank you! :)
<re_irc>
<@jamesmunns:beeper.com> are the numbers generally very large? e.g. "0xFF00" or so?
<re_irc>
<@jamesmunns:beeper.com> If so: yeah, the varints will be 3 bytes instead of 2
<re_irc>
<@jamesmunns:beeper.com> normally you "average out" with well distributed numbers to be smaller than 2, but if you have a LOT of large numbers, you'll definitely go a little pathological
<re_irc>
<@juliand:fehler-in-der-matrix.de> : They should be 2^14 on average iirc
<re_irc>
<@jamesmunns:beeper.com> the cobs accumulator would help so that your embedded system "doesn't care" if the messages are 500, 1500, or 1600, and could change over time
<re_irc>
<@jamesmunns:beeper.com> but yeah, if they are >= 2^14, they will be three bytes each :)
<re_irc>
<@jamesmunns:beeper.com> (you get 7 data bits per byte on the wire for varints)
<re_irc>
<@juliand:fehler-in-der-matrix.de> 2^15 I mean, like half the U16's max value
<re_irc>
<@juliand:fehler-in-der-matrix.de> Makes sense
<re_irc>
<@jamesmunns:beeper.com> yup, then you'll almost always be at the pessimal case, which is a bummer.
<re_irc>
<@jamesmunns:beeper.com> you could swap the numbers to be "0xFFFF - x" on the wire, so everything is usually small, then they'd all be one byte :D
<re_irc>
<@jamesmunns:beeper.com> but that is probably more tricky than just using fixed size values :)
<re_irc>
<@juliand:fehler-in-der-matrix.de> Yeah, the fixed size ones are exactly what we were missing.
<re_irc>
Thanks for all the input, and for making postcard available, of course. It's been very useful for us already.
Dr_Who has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
<re_irc>
<@riskable:matrix.org> It's been a while since I examined the state of Embedded Rust... Is there an exemplar project demonstrating how to support multiple boards/hardware while having a shared "base" of code they all use? Something like a keyboard firmware.
<re_irc>
<@avery71:matrix.org> There is the embedded-hal
<re_irc>
<@riskable:matrix.org> Avery (she/they): Yeah that's too low-level. I'm talking about a high-level project that supports a wide variety of hardware. What about projects that have lots of hardware-specific compile-time configuration options? Have we figured out good ways to do things like set constants at compile time based on user parameters yet?
<re_irc>
<@avery71:matrix.org> The embedded-hal is how you support a wide variety of chips with a shared base
<re_irc>
<@avery71:matrix.org> There are also a handful of Component abstraction crates to help write generic code
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
<re_irc>
<@fuse117:matrix.org> I am using "nrf-modem" on a custom board. I have been hitting the following error "An ARM specific error occurred. Error using access port. Failed to write register CSW at address 0x00000000. An error occurred in the communication with an access port or debug port. Target device did not respond to request." No panic, just a crash. Can anyone give me insight into this error and possibly provide general steps for debugging?
<re_irc>
<@diondokter:matrix.org> fuse117: This is not your microcontroller crashing. Probe-rs lost contact with the microcontroller.
<re_irc>
Best to update probe-run (I think you're using that)
<re_irc>
<@diondokter:matrix.org> Also, if you need help with nrf-modem, then feel free to ping me here or in the nrf matrix room. I wrote the library 🙂
<re_irc>
<@fuse117:matrix.org> : Cool. The hang occurs on "LteLink::wait_for_link()". My test code runs on a "nrf9160-dk" as expected. It crashes on my custom board.
<re_irc>
<@dkhayes117:matrix.org> @fuse117 if you haven't, try running your code with the defmt env-var set to "trace" with the "defmt" feature enabled on nrf-modem
<re_irc>
<@fuse117:matrix.org> will give that a shot
<re_irc>
<@dkhayes117:matrix.org> you can add it to your .cargo/config.toml file
<re_irc>
[env]
<re_irc>
# `cargo clean -p defmt` after you change this
<re_irc>
DEFMT_LOG = "trace"
<re_irc>
<@dkhayes117:matrix.org> you can add it to your .cargo/config.toml file
<re_irc>
# `cargo clean -p defmt` after you change this
<re_irc>
[env]
<re_irc>
DEFMT_LOG = "trace"
Dr_Who has quit [Read error: Connection reset by peer]
dc740 has quit [Remote host closed the connection]
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<re_irc>
<@mabez:matrix.org> Is there a way to get cargo fix to apply all help suggestions? i.e I have errors like
<re_irc>
error[E0277]: the `?` operator can only be applied to values that implement `Try`
<re_irc>
--> src/file.rs:225:9
<re_irc>
225 | disk.flush()?;
<re_irc>
|
<re_irc>
| ^^^^^^^^^^^^^ the `?` operator cannot be applied to type `impl Future<Output = Result<(), <IO as ErrorType>::Error>>`
<re_irc>
|
<re_irc>
= help: the trait `Try` is not implemented for `impl Future<Output = Result<(), <IO as ErrorType>::Error>>`
<re_irc>
help: consider `await`ing on the `Future`
<re_irc>
|
<re_irc>
225 | disk.flush().await?;
<re_irc>
| ++++++
<re_irc>
Can I get cargo just to auto apply the help suggestions?
<re_irc>
<@dirbaio:matrix.org> ahhhaha to mass-asyncify code?
<re_irc>
<@mabez:matrix.org> Haha yes
<re_irc>
<@dirbaio:matrix.org> I searched for it too
<re_irc>
<@dirbaio:matrix.org> there isn't 😭
<re_irc>
<@mabez:matrix.org> Like it knows exactly what to do, just do it!!
<re_irc>
<@mabez:matrix.org> Welp
<re_irc>
<@dirbaio:matrix.org> yeah, right???
<re_irc>
<@mabez:matrix.org> I'm 90% of the way there with some regex search and replaces, but I guess I'll have to work through the rest manually
<re_irc>
<@adamgreig:matrix.org> does anyone use and need "linker=arm-none-eabi-gcc"? my vague memory is it's useful to get a libc pulled in for building with precompiled C libs but I don't remember the details