<KevinPFleming[m]>
Wow... one of the M55s has 1.25MB of SRAM.
adamgreig_ has quit [Server closed connection]
adamgreig_ has joined #rust-embedded
mathu has quit [Server closed connection]
mathu has joined #rust-embedded
ska has quit [Ping timeout: 260 seconds]
sroemer has joined #rust-embedded
i509vcb[m] has quit [Quit: Idle timeout reached: 172800s]
Socke has quit [Ping timeout: 240 seconds]
Socke has joined #rust-embedded
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
does anybody have examples of drivers that "give back" things on error? like having functions `-> Result<(), (Thing, P::Error)`
<dirbaio[m]>
s/`/>`/
<dirbaio[m]>
I feel this is a somewhat common pattern, having examples of it would be helpful
MartinSivk[m] has joined #rust-embedded
<MartinSivk[m]>
I have seen it, but I wonder where that was
<dirbaio[m]>
context is [this discussion](https://github.com/rust-lang/rust/issues/120141). If `P::Error` is `Infallible` the `Err()` variant could be completely optimized out, making that `Result` zero-sized. But in that discussion some peopel are arguing in favor of *not having this optimization*, ie making that `Result` have at least the size of `Thing` even if it's literally never going to be used.
<dirbaio[m]>
so we have to provide examples to show it's not jut a theoretical concern
<dirbaio[m]>
s/jut/just/
<chrysn[m]>
I rely on the error optimization a lot (and it sounds super weird to disable it), but sadly don't have examples of additional-data-on-error :-/
<MartinSivk[m]>
Well practically it is a case of an initialization consuming call (self) returning an error and not returning a device back in embedded HALs. That prohibits any future access to the device.
<dirbaio[m]>
yeah
<dirbaio[m]>
any examples I can link? :D
<MartinSivk[m]>
Hmm.. let me think where that might have been.
<JamesMunns[m]>
heapless' push is like that
<JamesMunns[m]>
if push fails, you get the T back
<MartinSivk[m]>
I think it could have been an SPI device driver with additional interrupt GPIO, but it has been few months since I worked with that
<dirbaio[m]>
JamesMunns[m]: yeah I thought about that too, but the error is not "might be infallible, might not be" in that case
<dirbaio[m]>
the lost optimization is: when an enum variant has multiple fields, and one of the fields is uninhabited, the size for all other fields is optimized out
<dirbaio[m]>
"one of the fields is uninhabited" most likely happens because it comes from an embedded-hal associated error type
<dirbaio[m]>
you wouldn't write Infallible directly, you might as well remove the enum variant directly
<dirbaio[m]>
so it most likely happens in the case of "return error, plus additional data"
<danielb[m]>
<dirbaio[m]> so it most likely happens in the case of "return error, plus additional data"
<danielb[m]>
I have a use case pending for this but im trying to avoid it. Context is esp-hal, single api supporting N devices with different capabilities
<danielb[m]>
A usage pattern may end up causing a deadlock on exactly one device
<danielb[m]>
So I need to detect and error, likely
<MartinSivk[m]>
Hmm, I might have an idea where I saw that.. I was initializing a driver that needed a "gpio" that could have been backed by both direct gpio or a spi expander one... the direct one was Infallible (just registers), the SPI one could fail (not present or bus error etc.). Let me check the project to see if it was actually implemented like that at the end.
<chrysn[m]>
We're planning to use general infallible-variants patterns a lot in embedded-cal, esp. when trimming down a concrete back-end such that its types become smaller. I *think* all the current examples in the explorative code are more about enums where one, all-but-one, all or no variants become uninhabited ([crude test code](https://github.com/lake-rs/experiments-on-interfaces/blob/main/fallthrough-impls/src/lib.rs)), would that also be
<chrysn[m]>
affected?
seds has joined #rust-embedded
<MartinSivk[m]>
Hmm so even though the code I remember could have been written in such way (return stuff back on error) it was not at the end and has the traditional "release" method. So sadly, I don't have an example apart from a theoretical one. Even embedded-io 1.0 write traits do not need this, because they use references nowadays.
seds has quit []
seds has joined #rust-embedded
stgl has quit [Server closed connection]
stgl has joined #rust-embedded
glitchy has quit [Remote host closed the connection]
AdamHorden has quit [Server closed connection]
AdamHorden has joined #rust-embedded
JamesMunns[m] has quit [Server closed connection]
JamesMunns[m] has joined #rust-embedded
<chrysn[m]>
I'm having a hard time following that ZST-uninhabited [discussion](https://github.com/rust-lang/rust/issues/120141). Does the latest state mean that `enum<T1, T2> {A(T1), B((something, T2))}` can still be as small (or as ZST) as T1 if `T2=!` ?
<dirbaio[m]>
in today's implementation that enum has size tag + max(T1, something) even if T2 = !
<dirbaio[m]>
* if you have `enum { A(T1), B(T2, !) }`
<dirbaio[m]>
in today's implementation it has size `tag + max(T1, T2)`
<dirbaio[m]>
even if you can never instantiate B. So the memory for T2 is wasted.
<dirbaio[m]>
there's a possible optimization that would remove uninhabited variants entirely.
<dirbaio[m]>
so it would make the size of that enum just T1. (the B variant is removed entirely, then since there's only 1 variant left there'd be no need for a tag)
<dirbaio[m]>
the problem is what happens when you try to use offset_of! to get the offset of the T2
<dirbaio[m]>
if the variant is completely gone, there's no space for the T2 at all
<dirbaio[m]>
so `offset_of!` wouldn't be able to support enums, we'd have a `try_offset_of!()` instead that returns `Option<usize>`
mkj[m] has joined #rust-embedded
<mkj[m]>
it seems like that could be a useful optimisation also if a compiler could realise certain variants are never constructed?
<dirbaio[m]>
some people in the issue are arguing this is bad because reasons and therefore Rust should commit to never doing this optimization
explodingwaffle1 has quit [Quit: Idle timeout reached: 172800s]
RockBoynton[m] has joined #rust-embedded
<RockBoynton[m]>
<t-moe[m]> embedded-test 0.7.0 is about to be released, and it comes with support for (inline) unit tests (previously limited to integration tests)....
<RockBoynton[m]>
thank you for your work on this, it is huge!
sroemer has quit [Quit: WeeChat 4.5.2]
zeenix[m] has quit [Quit: Idle timeout reached: 172800s]
timokrgr[m] has joined #rust-embedded
<timokrgr[m]>
<dirbaio[m]> does anybody have examples of drivers that "give back" things on error? like having functions `-> Result<(), (Thing, P::Error)`
<timokrgr[m]>
embedded-can traits were designed like that
<dirbaio[m]>
interesting. where is it, an old version?
<thejpster[m]>
See cortex-ar - all the testing is done in QEMU
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
<t-moe[m]> embedded-test 0.7.0 is about to be released, and it comes with support for (inline) unit tests (previously limited to integration tests)....
<i509vcb[m]>
Hmm I guess I have something to look at when I get to testing my Cortex-M7 JIT compiler lol
dinkelhacker has joined #rust-embedded
HumanG331 has joined #rust-embedded
Darius has joined #rust-embedded
nohit has joined #rust-embedded
n3t has joined #rust-embedded
tk has joined #rust-embedded
kline has joined #rust-embedded
vancz has joined #rust-embedded
NishanthMenon has joined #rust-embedded
lethalbit has joined #rust-embedded
HumanG331 has quit [Max SendQ exceeded]
HumanG331 has joined #rust-embedded
sgued[m] has quit [Quit: Idle timeout reached: 172800s]
khionu[m] has quit [Quit: Idle timeout reached: 172800s]
Dlaw[m] has quit [Quit: Idle timeout reached: 172800s]
ouilemur has joined #rust-embedded
<dngrs[m]>
<jason-kairos[m]> Has anyone ever run their embedded firmware in qemu?...