<JamesMunns[m]>
Not sure about that crate, but cbor is a self describing format, so it'll give you a lot more flexibility to change schemas over time than postcard
<JamesMunns[m]>
in trade, postcard will likely be faster, use less ram + code space.
<JamesMunns[m]>
I'm working on quite a few "schema cross-check" tools right now (using the same techniques as postcard-rpc), but that'll just give better protection from accidental misuse, and still requires both sides to agree on a schema, or use a fully dynamic serde_json::Value type API to decode.
<JamesMunns[m]>
If you're designing something with persistent comms (especially USB), I might have a tool you can try out. I'm working on a "fully working device manager" tool.
<JamesMunns[m]>
(oh and postcard will likely be smaller on the wire, not a ton, but some)
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #rust-embedded
<JamesMunns[m]>
additionally cbor has better tooling outside of Rust, if that's important. Though the device manager will transcode messages to JSON for you, if you use it as a proxy for the connected devices.
<JamesMunns[m]>
* device manager i'm building for postcard will transcode
<RockBoynton[m]>
This would be comms between a microcontroller and an embedded linux system; we typically write our apps with haskell when we have an OS, and CBOR is well supported there, but using JSON as a proxy could work. Flexibility to change over time (backwards and forwards compat) would also be really nice though
<JamesMunns[m]>
postcard-rpc takes the position "types and endpoints never change", but you *can* add new ones over time.
<JamesMunns[m]>
The idea is that the PC can speak multiple versions, or know of v1/v2 endpoints or v1/v2 types, and switch accordingly
<JamesMunns[m]>
This is a rough diagram of what I am building :)
<dngrs[m]>
rpc = Rust PC
<JamesMunns[m]>
could work with one device, it's maybe overkill for that. The idea is to manage multiple devices, including historical data in a database
<RockBoynton[m]>
Now that I think about it, the source of both systems are controlled in a monorepo and with nix, so we should be able to have atomic updates and we shouldn't need to have back/forward compat. I don't think we can run into a situation where one's version is changed and not the other
<JamesMunns[m]>
I'm targeting the rp2040 as the first reference design, so i'll have embassy based examples for that. It should work similarly well on stm32/nrf/rp.
<JamesMunns[m]>
I'll have a Rust crate API for clients, and a cli (for scripting) and tui (for poking around) interface.
<JamesMunns[m]>
oh, and some kind of either REST or JSON-over-socket API for other langs.
<marmrt[m]>
I was debugging a watchdog timer a while back, and noticed that the datasheet said there's an interrupt flag for the watchdog. So I figured I could log some useful info in an ISR before reset. But the interrupt got raised at the same time as the watchdog reset the MCU, so there was no time to execute the ISR.
<JamesMunns[m]>
Usually your MCU will have a "reset reason" register, that will tell you it was because of a watchdog reset
<diondokter[m]>
Some watchdogs can generate an interrupt just before they do the reset. You might be able to log something (like the PC if the function that was interrupted) so you can read it back later
<vollbrecht[m]>
In what context does your WDT get feed? In esp-idf we have two WDT's to make it implicitly more simple to detect where it happens by having one low prio ISR that constantlly feed the IWDT and one WDT that is feed by a low prio task. That way you directly know if the problem is some busy looping in a task, or a locking problem in a critical section etc for example.
<diondokter[m]>
* Some watchdogs can generate an interrupt just before they do the reset. You might be able to log something (like the PC of the function that was interrupted or a partial stack trace) so you can read it back later
<t-moe[m]>
vollbrecht[m]: oh, thats a great idea. I guess I should read through the esp-idf source-code more often. (especially, since I'm using an esp32 chip as well)
<t-moe[m]>
alright. thanks for those ideas guys. I'll see whether I can add the pc/stack dumping and maybe another watchdog.
Foxyloxy_ has joined #rust-embedded
Foxyloxy has quit [Ping timeout: 264 seconds]
frostie314159[m] has quit [Quit: Idle timeout reached: 172800s]
AtleoS has quit [Ping timeout: 252 seconds]
AtleoS has joined #rust-embedded
AtleoS has quit [Ping timeout: 244 seconds]
AtleoS has joined #rust-embedded
rfuentess has quit [Remote host closed the connection]
<thejpster[m]>
Thanks, your internet is faster than mine
<dirbaio[m]>
:D
<dirbaio[m]>
gigabit goes brrr
<dirbaio[m]>
I bisected with --relese tho
<thejpster[m]>
I'm interested to see if they say "whoops" or "nope, you were holding it wrong"
<dirbaio[m]>
s/relese/release/
<dirbaio[m]>
is it only failing for you in debug mode?
<thejpster[m]>
I was offered 7000 Mbps from a new fibre provider.
<thejpster[m]>
I have 40 Mbps ADSL currently
<thejpster[m]>
I only ever try debug with this repo
<dirbaio[m]>
okay, bisect yields the same if I try without --release
<dirbaio[m]>
honestly I'm not surprised that it breaks
<dirbaio[m]>
PROVIDE is cursed
<dirbaio[m]>
i'm using a newer nightly (both at work and in embassy) and it didn't break for me, tho. I wonder why
<dirbaio[m]>
lol #[used] doesn't work, it says "attribute must be applied to a static variable"
<dirbaio[m]>
haha what, with RUSTFLAGS=-Csave-temps it compiles
<dirbaio[m]>
save-temps is supposed to only help debugging, not affect behavior :|
AtleoS has quit [Ping timeout: 276 seconds]
<dirbaio[m]>
how the hell do you debug this then
<thejpster[m]>
Does pub help?
<dirbaio[m]>
nope
<thejpster[m]>
I thought export-symbol was like no-mangle with a hat on - like “other people you don’t know about might touch this”. But maybe it’s just now “give it this name”
<thejpster[m]>
Does critical section still work?
<dirbaio[m]>
haven't seen anyone report issues with c-s. that one doesn't use PROVIDE though
<thejpster[m]>
It has magically named symbols, right?
<thejpster[m]>
So maybe the issue is that the spooky action at a distance happens through a linker alias
<dirbaio[m]>
if you don't link a c-s impl it just fails, there's no fallback
<dirbaio[m]>
I think it has to do with the fact that rustc doesn't "see" the symbol is used
<dirbaio[m]>
because it's defined with one name and used with another
<thejpster[m]>
But that can happen to any no-mangle symbol?!
<dirbaio[m]>
only with PROVIDE
<thejpster[m]>
rustc can only see one translation unit at a time
<thejpster[m]>
Only the linker sees all
<dirbaio[m]>
not exactly, there's the crazy symbols.o thing
<thejpster[m]>
Wait. Does debug have LTO on?
<thejpster[m]>
(I’m on my phone)
<thejpster[m]>
Ah the thing that broke LEON 3
<thejpster[m]>
Because SPARC Linux guy made it go “ah, V8 Plus for everyone”
<thejpster[m]>
Two targets, same target_arch, different architecture.
<thejpster[m]>
Well defmt is broken on beta
<thejpster[m]>
How bad is everything going to be if it’s not fixed?
<dirbaio[m]>
it seems to affect only some projects tho
<thejpster[m]>
ORLY?
<dirbaio[m]>
yea
<dirbaio[m]>
work is on nightly-2024-09-06 and it works
<dirbaio[m]>
all these symbols are unused so the linker doesn't include them, but for whatever reason it goes "whoops actually I need __defmt_default_panic"
<dirbaio[m]>
* all these symbols are unused so the linker doesn't include them, but for whatever reason it goes "whoops actually I did need \_\_defmt\_default\_panic"
<dirbaio[m]>
while if you do use it, it gets included and all is fine
<dirbaio[m]>
either EXTERN(_defmt_panic) or EXTERN(__defmt_default_panic) fix it, but that means the panic handler will get included even if unused
<dirbaio[m]>
cortex-m-rt uses PROVIDE for DefaultHandler, it hasn't broken because it also uses EXTERN
<jannic[m]>
It compiles with "-C", "linker=/home/jan/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/rust-lld" (but still fails with "-C", "linker=/home/jan/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/rust-lld")
<dirbaio[m]>
ooh, that's smart, changing just the linker
<dirbaio[m]>
:D
<dirbaio[m]>
in other news
<dirbaio[m]>
they're renaming "object-safe" to "dyn-compatible"
<dirbaio[m]>
"object-safe" was terrible terminology
<diondokter[m]>
Oh cool, yeah that's a better name. Might be my non-native English, but I don't like 'compatible'. 'capable' would be better IMO
<diondokter[m]>
But it's good people are thinking about this. I saw some movement about the name 'target' as used by cargo in e.g. --all-targets.
<diondokter[m]>
I think they wanted to go with the word 'artifact'
ana_briated[m] has joined #rust-embedded
<ana_briated[m]>
<dirbaio[m]> "they're renaming "object-safe..." <- it took me reading "dyn-compatible" to actualize what object-safe actually meant as a concept in rust