duderonomy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
duderonomy has joined #rust-embedded
IlPalazzo-ojiisa has quit [Remote host closed the connection]
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
duderonomy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
duderonomy has joined #rust-embedded
duderonomy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dngrsspookyvisio has joined #rust-embedded
<dngrsspookyvisio>
<JamesMunns[m]> "(the hardware loads the nintendo..." <- Has anyone tried to come up with a checksum collision image? 🙃
duderonomy has joined #rust-embedded
bpye has quit [Ping timeout: 245 seconds]
bpye has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
graso[m] has joined #rust-embedded
<graso[m]>
Could anyone help me? I have 100 files numbered: 0001.rs - 0100.rs in /src/bin/ those are functions which calculate some values, I would like to test whether they return correct values and how much time do they need (the time may differ, so it should be calculated for each one line by line). I probably could use #[cfg(test)] mod tests {...} but not sure if this is correct way to achieve so
duderonomy has quit [Read error: Connection reset by peer]
<graso[m]>
It's rather related to Rust, not embedded
duderonomy has joined #rust-embedded
Guest7221 has joined #rust-embedded
chrysn[m] has joined #rust-embedded
<chrysn[m]>
Looking at defmt's global logger docs, I'm a bit confused: It outlines the issues (concurrency, possible preemption), and states that it forbids interleaving frames, but doesn't tell what to do instead. Looking at the defmt-serial implementation, a double acquisition just panics. Is this how it is supposed to be, and does all of the defmt internal mechanism ensure (in a bugs-are-OK-but-they-panic way) that things are serialized
<chrysn[m]>
already before they come to the back-end?
duderonomy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mali[m] has joined #rust-embedded
<mali[m]>
Anyone at Euro Rust in Brussels?
<dngrsspookyvisio>
<chrysn[m]> "Looking at defmt's global logger..." <- That's an interesting question; I suppose it's designed with single core applications in mind. You could try asking in the rust embedded room (sec, am on mobile thus have to copy the link separately)
<chrysn[m]>
I think this is the Rust Embedded room..
<chrysn[m]>
s/.././
<dngrsspookyvisio>
Oh sorry this IS the embedded room lol
<dngrsspookyvisio>
Note to self: wake up, THEN open chat
<chrysn[m]>
The docs already point out that concurrency is not merely a matter of being multicore -- reentrance can also occur when the formatter itself happens to use debug output.
<chrysn[m]>
s/use/produce/
IlPalazzo-ojiisa has joined #rust-embedded
<JamesMunns[m]>
<chrysn[m]> "Looking at defmt's global logger..." <- IIRC defmt "requires" you to get a critical section
<JamesMunns[m]>
if you are using the rzcobs framing, if you do corrupt a message, you'll lose some messages, but the stream will recover
<JamesMunns[m]>
<chrysn[m]> "The docs already point out..." <- Yeah, I think generally the docs say "don't do that", iirc
<JamesMunns[m]>
like don't have a Format impl that does a defmt log lol
brazuca has joined #rust-embedded
<jannic[m]>
<mali[m]> "Anyone at Euro Rust in Brussels?" <- Yes, sure!
tiwalun[m] has joined #rust-embedded
<tiwalun[m]>
<mali[m]> "Anyone at Euro Rust in Brussels?" <- Yes! 🦀
ruabmbua[m] has quit [Quit: Idle timeout reached: 172800s]
kenny has quit [Ping timeout: 255 seconds]
<FlixtheNewbie[m]>
Does anyone have an example of a serial communication using usb-device?
<tiwalun[m]>
mali ⚡️, jannic Want to meet during the snack break? I‘ll be around the entrance, with a green shirt and a small Ferris plushie on my backpack.
<FlixtheNewbie[m]>
FlixtheNewbie[m]: And is there a gotcha when using USB both for HID and serial?
<jannic[m]>
FlixtheNewbie[m]: I didn't try that, but as far as I know the one thing to remember is that poll needs to be called with the same arguments in the same order every time. Otherwise, I'm not aware of any gotcha.
<chrysn[m]>
<JamesMunns[m]> "if you are using the rzcobs..." <- Yeah, that's something I probably have to look into separately: I'm spooling data in a ring buffer for later delivery through CoAP, and that ring buffer has means for acknowledgedly losing data (like, "yes there were 204 more bytes between here and there but the network wasn't fast enough"). So I could go with the rzcobs framing and effectively not use this (or use it but it'd just
<chrysn[m]>
avoid accidental recombination across loss-of-bytes points), or do some own framing of which the ring buffer is aware.
<FlixtheNewbie[m]>
jannic[m]: Thanks! I do the polling in the same RTIC interrupt, so it should be alright
<JamesMunns[m]>
<chrysn[m]> "Yeah, that's something I..." <- Makes sense! The two main failure cases (IIRC) are:
<JamesMunns[m]>
* Out of space, which can happen
<JamesMunns[m]>
* Pre-emption, which technically SHOULDN'T ever happen, as `Logger::acquire` is supposed to act as a critical section, or you need one buffer/thread/prio level
<JamesMunns[m]>
Honestly, I think you COULD probably decode across pre-emption on a host that can heap allocate (basically do "stacked" decoding), if you start the message with the null byte (instead of appending to the end), but I'm not sure how well it would recover across data loss
<dngrsspookyvisio>
hmm, that makes me wonder ... the overruns I've experienced might actually be caused by a slow terminal on the host side
<dngrsspookyvisio>
- or maybe a slow probe? how much throughput can one expect over st-link v2 clones?
<dngrsspookyvisio>
anyway, in the former case probe-rs run might benefit from a named pipe mode where you'd display log output in a separate terminal…
<dngrsspookyvisio>
* hmm, that makes me wonder ... the overruns I've experienced might actually be caused by a slow terminal on the host side
<dngrsspookyvisio>
- or maybe a slow probe? how much throughput can one expect over st-link v2 clones?
<dngrsspookyvisio>
anyway, in the former case probe-rs run might benefit from a named pipe mode where you'd display log output in a separate terminal…
<dngrsspookyvisio>
* hmm, that makes me wonder ... the overruns I've experienced might actually be caused by a slow terminal on the host side
<dngrsspookyvisio>
... or maybe a slow probe? how much throughput can one expect over st-link v2 clones?
<dngrsspookyvisio>
anyway, in the former case probe-rs run might benefit from a named pipe mode where you'd display log output in a separate terminal…
<dngrsspookyvisio>
coming to think of it it must be the terminal, or at least: can't be the probe, since flashing is fast enough
<chrysn[m]>
If every formatter could tell in advance how much data it'd put in, I could even handle the preemption locally (barring overruns, of course), but getting that information is not trivial in the general case.
<chrysn[m]>
On slow terminals: For my case, defmt's output would be buffered and sent over the network. Think ssh if you like :-)
<dngrsspookyvisio>
chrysn[m]: do you need preemption though? as I understand it the only case where it'd happen on a single core is calling `defmt::{info,...}` *inside an impl of `defmt::Format`*
<chrysn[m]>
Well I'd like to be able to produce debug logs from interrupt handlers -- graceful failure is fine (basically, in a collision between a print from a low level and from a high level interrupt, either may get lost, but it mustn't make things crash).
<JamesMunns[m]>
firefrommoonligh: > <@firefrommoonlight:matrix.org> adamgreig: I was looking at the f32 precision loss issues on wrapping timers we were discussing. Now that I think about it, I\_think\_ it wouldn't be an issue in this case (Wrapping a hardware timer for uptime count) because:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/abuYlkajchfkyncCYaBZQojm>)
kenny has joined #rust-embedded
<dngrsspookyvisio>
chrysn[m]: that should be fine since defmt does a critical section
<firefrommoonligh>
JamesMunns[m]: AH, got it. So, the issue is representing large numbers in floating point
<JamesMunns[m]>
dngrsspookyvisio: yeah, your options are
<JamesMunns[m]>
* one buffer per thread/interrupt prio level
<JamesMunns[m]>
* critical section (no preemption)
<chrysn[m]>
Full story is: I'm running in RIOT OS (written in C), which is multithreaded, and so far I've placed its puts/printf outputs in a ring buffer. I'd like to be able to use defmt too now, without loss of features.
<JamesMunns[m]>
firefrommoonligh: In your case, yes. There's two issues, but precision only applies if you do repeated adds, instead of "add u32, convert to f32 every time".
<JamesMunns[m]>
chrysn[m]: I think you can maybe? Not sure how you'd know whether you are in the "discard" case
<JamesMunns[m]>
but maybe have it be a counting atomic, and if count != 1, then discard
<JamesMunns[m]>
JamesMunns[m]: that being said, f32 brings no value here imo
<JamesMunns[m]>
JamesMunns[m]: `2^23` seconds (as floats) is 97 days, `2^32` seconds (as u32) is 136 years
<JamesMunns[m]>
so, if you don't need to support a runtime of >136 years, you are probably just fine with seconds-as-32.
<JamesMunns[m]>
s/32/u32/
<dngrsspookyvisio>
wouldn't a critical section also prevent a thread switch? What am I missing?
<firefrommoonligh>
JamesMunns[m]: It does - it's easy to work with and intuitive, and avoids another class of errors
<JamesMunns[m]>
dngrsspookyvisio: yeah
<dngrsspookyvisio>
or are you actually multicore
<JamesMunns[m]>
dngrsspookyvisio: his critical section would also have to prevent an OS context switch
<firefrommoonligh>
*not a huge win over working with u32 ns directly, but given a choice...
<JamesMunns[m]>
(which disabling interrupts would probably do)
<chrysn[m]>
The critical section would prevent a thread switch (we're not multicore yet), but there are already way more critical sections around than I'm happy with.
<JamesMunns[m]>
yep, makes sense!
<JamesMunns[m]>
Lots of options and tradeoffs here :)
<dngrsspookyvisio>
ah I see
<JamesMunns[m]>
chrysn[m]: fwiw in mnemos, we have two buffers, one interrupt and one non-interrupt
<dngrsspookyvisio>
my POV is that a defmt call itself should be very fast anyway so I wouldn't try to make it preemptable, but it's purely a gut feeling
<JamesMunns[m]>
it means that nested interrupts can't log if you start logging in one interrupt and it preempts, but you can usually get interrupt logs.
<dngrsspookyvisio>
benchmark ittttt
<JamesMunns[m]>
dngrsspookyvisio: it's less about perf and more that RIOT is an actual RTOS, who might care about timing deadlines
<JamesMunns[m]>
and defmt is pretty cheap, but I can see not wanting to have to do the timing analysis.
<chrysn[m]>
dngrsspookyvisio: It's hard to benchmark general OS design questions. The criteria will come from the application, and that may have arbitrarily tight real-time constraints.
<dngrsspookyvisio>
ah fair
<chrysn[m]>
jinx :-D
<JamesMunns[m]>
easier to say "the default mode won't block but logs in interrupts are 'best effort'".
<dngrsspookyvisio>
massive armchair again but given defmt "AOT"s the actual log buffer contents in the typical case I would have assumed the buffer filling part should actually be easy to analyze
<Lumpio->
How "ahead of time" is it though? I thought all it does is collect messages, assign them IDs, and the rest is runtime
<dngrsspookyvisio>
yeah, I meant in all the cases where you don't have anything dynamically sized like a slice or Debug2Format
<dngrsspookyvisio>
at least in my projects that's the majority
<dngrsspookyvisio>
but of course majority != everything, I'm not contesting the tradeoff or saying that chrysn's idea is bad in general
<chrysn[m]>
If it's possible to just shed dynamically sized content in contentious situations, I'd love that. Like, at call time it says "I need this and that many bytes, do your atomic magic to make it happen, here's my data, and then I may have more to fill but if it's gone it's gone".
<JamesMunns[m]>
IMO the challenge is that there's no introspection to know whether you have dynamically sized fields until you hit them
<dngrsspookyvisio>
ah true, nested structs is where it bites you
<JamesMunns[m]>
I can give you lots of "pick two" options
<JamesMunns[m]>
where "efficient" is mostly in RAM space, for example not requiring a 128-byte "slab" for messages that might only be 2 bytes
<dngrsspookyvisio>
Yeah
<chrysn[m]>
Hm, defmt may be in the unique position (compared to classic fmt) that it does have a bit more information at hand at derive time -- gotta look deeper into how it actually works.
<JamesMunns[m]>
Possible! But again custom Format impls and variable size types (slices mostly) throw a pretty big wrench here
<dngrsspookyvisio>
Yeah but as soon as you have a slice you lose
duderonomy has joined #rust-embedded
kenny has quit [Ping timeout: 240 seconds]
kenny has joined #rust-embedded
kenny has quit [Quit: WeeChat 4.0.5]
duderonomy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<chrysn[m]>
OK, understanding is setting in slowly ... I think the piece I was missing is that the defmt logger implementation can trust being called in the acquire-write-release sequence without the (logically created but never expressed) held lock ever moving between execution contexts.
<chrysn[m]>
Two more questions on defmt:
<chrysn[m]>
* (Where) can I add extra data to the records? For example, it may make sense to record whether interrupts are just disabled, or which interrupt we're logging from.
<chrysn[m]>
* If my logger is using its own transport (which may not be stream based but already has a record layer), do I really need to go through the encoder?
lulf[m] has quit [Quit: Idle timeout reached: 172800s]
<chrysn[m]>
(I could add that data on the outer layer, but then it'd be even harder to integrate with a printer)
ilpalazzo-ojiis4 has quit [Quit: Idle timeout reached: 172800s]
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #rust-embedded
stephe has quit [Read error: Connection reset by peer]
edm has quit [Read error: Connection reset by peer]
stephe has joined #rust-embedded
nohit has quit [Ping timeout: 252 seconds]
Ekho has quit [Remote host closed the connection]
edm has joined #rust-embedded
nohit has joined #rust-embedded
newam[m] has quit [Quit: Idle timeout reached: 172800s]
duderonomy has joined #rust-embedded
Ekho has joined #rust-embedded
<dirbaio[m]>
> If my logger is using its own transport (which may not be stream based but already has a record layer), do I really need to go through the encoder?
<dirbaio[m]>
no, you can skip it. you won't get the rzcobs compression though.
<dirbaio[m]>
> (Where) can I add extra data to the records? For example, it may make sense to record whether interrupts are just disabled, or which interrupt we're logging from.
<dirbaio[m]>
I don't think this is supported currently. there's support for customizing the timestamp, which gets added to every message, but I don't think you can add more data to it
<dirbaio[m]>
not if 2 interrupts call the same code
<chrysn[m]>
No -- code from the same module can be run from an interrupt or from the regular context.
<andresovela[m]>
Ah true true
<andresovela[m]>
You can just add that in the arguments where you need that info though
<andresovela[m]>
No need for defmt to add support especially for that
<chrysn[m]>
I can pass it explicitly, but I'd love to have it as part of the system's provided data for each line. (But then, maybe I can fidget it into the time stamp?).
<andresovela[m]>
Out of curiosity, what are you doing that you need that data in every log?
<andresovela[m]>
I’d personally find it noisy if that was present in every log
<chrysn[m]>
Currently just exploring.
<chrysn[m]>
Debug output of RIOT OS can be really verbosely high, and with its message passing it may be practical to filter by thread when reading logs, but I don't really have a precise plan there yet.
<andresovela[m]>
I plan on working on a better filtering story for defmt soon
<andresovela[m]>
I think filtering is pretty unusable at the moment
<andresovela[m]>
At least I’m used to having better filtering facilities
<TomB[m]>
as I understand it, there's a lock free mpmc setup using both a ring and atomic list
<TomB[m]>
thought I watched a linux plumbers conference video talking about the clever and high performing setup linux has to deal with N cpus printing to M consoles