<Averyshethey[m]>
<vollbrecht[m]> "its nice to be able to cast..." <- It almost sounds like you want a static cell, but more built into rust
IlPalazzo-ojiisa has quit [Quit: Leaving.]
almindor[m] has joined #rust-embedded
<almindor[m]>
it is sad that they didn't fix this in all those years. but hey we got broken async so that's a win ;P
<dirbaio[m]>
How is async broken? Lol
<NickStevens[m]>
<almindor[m]> "it is sad that they didn't fix..." <- How is this sad? This is such a technical problem to even "exploit". If your argument is security then I hate to tell you but any crate you use and don't view the source code could delete your home directory or many other far worse things. There are problems that are such low actual risk but such a high technical burden that they're not worth fixing on their own. Instead you
<NickStevens[m]>
just try to remember them when doing larger design changes.
<NickStevens[m]>
I think this same measured approach, tackling problems incrementally while maintaining backwards compatibility, is probably why you think async is broken? There's lots that can (and will) be improved with async. Would you prefer that you had nothing right now? I've written programs with straight Mio as the event loop, I don't think anyone prefers that. 😆
cr1901_ has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
<thejpster[m]>
I found one ticket referring to it ... from 2017
<laura[m]>
Ah, rats!
<laura[m]>
That would have been really nice
<laura[m]>
but thanks for looking :D
MathiasKoch[m] has quit [Quit: Idle timeout reached: 172800s]
<burrbull[m]>
<laura[m]> "Hey all! Does anyone know if svd..." <- No. It even does not parse them
<laura[m]>
Understood, thanks!
<burrbull[m]>
Feel free to open PR
andodeki2[m] has joined #rust-embedded
<andodeki2[m]>
Which affordable sensor can I use to measure fluid level in a tank like generator fuel tank or elevated water tank?
<JamesMunns[m]>
> generator fuel tank or elevated water tank
<JamesMunns[m]>
those are very different use cases
<JamesMunns[m]>
the former is probably an ATEX rated sensor, the latter is probably just water resistant
<diondokter[m]>
andodeki2[m]: What's affordable?
diondokter[m] has joined #rust-embedded
<diondokter[m]>
I've seen people use a radar chip on plastic containers to see the livestock feed level.
<diondokter[m]>
For metal trash bins I've seen a time of flight sensor be used successfully
<diondokter[m]>
(A plus for the radar is that it can be attached on the outside)
<JamesMunns[m]>
Usually you'd use float sensors, to measure how high things are. This likely requires modification to the tank
<JamesMunns[m]>
Sometimes you can use radar or sonar chips on the roof, this is a very bad idea for a gas tank unless you buy a very expensive atex zone zero rated device
<JamesMunns[m]>
agreed with dion, tho I've seen a lot more "demos" than production systems, at least for deployed/unmaintained setups (like "trash cans across the city"), because someone has to keep the lenses clean for it to work
<JamesMunns[m]>
(in a factory line or similar where you can clean them regularly it makes more sense)
<JamesMunns[m]>
Another common setup is to use strain gauges or other weight sensors to measure changes in weight, like with hanging propane tanks
<JamesMunns[m]>
(again, probably requires some modification, may not work reasonably for like a giant house water tank)
<JamesMunns[m]>
yeah, that's a really bad idea. Less bad with diesel than gas, still a bad idea IMO
<JamesMunns[m]>
I believe you someone has done it, I don't think that makes it not a bad idea.
<JamesMunns[m]>
like, ATEX rating is from the fact that just having 3.3v or 5.0v across a pair of electrical pads can sometimes cause enough of an energy buildup to ignite fumes under the right conditions
<diondokter[m]>
JamesMunns[m]: Surely that's only relevant when the electronics is inside the tank, right?
<whitequark[cis]>
<JamesMunns[m]> "like, ATEX rating is from the..." <- that's incredible. I had no idea
<JamesMunns[m]>
Yeah the charge analysis you have to do is pretty astounding. stuff like measuring the voltage and distance between exposed pads
<JamesMunns[m]>
(I worked at a company that built gas sensors)
<JamesMunns[m]>
which, is hilarious because a lot of explosive gas sensors are built by putting a thermometer under a heating element. If there are explosive gasses in the air, the temperature sensor heats up
<JamesMunns[m]>
(there are other ways to measure for certain gasses lol)
<whitequark[cis]>
<JamesMunns[m]> "which, is hilarious because a..." <- what.
<JamesMunns[m]>
yeah, it's usually a heating element and/or a catalyst over a wheatstone bridge
<JamesMunns[m]>
I think the spicier atex ones might use a different approach, but general handheld units often work like that
<spinfast[m]>
hmm Is it common to see fmt::Display taking up a ton of .text
<spinfast[m]>
nearly 25% of my elf atm for a simple sample app, which is... surprising I guess
<JamesMunns[m]>
Yeah, this is why we are all so vocal about using defmt
<spinfast[m]>
* cargo bloat gives me... 19.4% 1.7KiB std \<&T as core::fmt::Display>::fmt and its unclear to me what this means, is this all monomorphized fmt impls showing up under one item?
<JamesMunns[m]>
Not sure specifically. cargo bloat attempts to guess, and formatting uses dynamic dispatch, which makes it hard to follow
<spinfast[m]>
This is using defmt
<spinfast[m]>
but the hal provides debug/display for some peripheral state/status types
<thejpster[m]>
defmt doesn't use core::fmt::Display AFAIK
<JamesMunns[m]>
it only does if you use a debug2format adapter
<JamesMunns[m]>
but panics might still invoke fmt
<thejpster[m]>
so the display impls should only appear if you actually do "{}" with them.
<JamesMunns[m]>
which panic impl are you using spinfast?
<spinfast[m]>
what about panic_probe
<spinfast[m]>
0.3% 2.7% 236B panic_probe <&T as core::fmt::Display>::fmt
<thejpster[m]>
mmm, yeah, if you Debug2Format your panic info you can eat flash space
<JamesMunns[m]>
panic_probe shouldn't use std fmt, but it's possible the optimizer isn't dead-code eliminating as much as it can
<thejpster[m]>
Do you have print-defmt set?
<JamesMunns[m]>
(also note that even cargo-bloat notes that the "source crate" field is a guess - with inlining and stuff it is very difficult to diagnose)
<thejpster[m]>
it's a feature on panic-probe which uses core::fmt for the panic info.
<spinfast[m]>
So panic info can't use defmt natively I take it
<spinfast[m]>
and that's probably where this is coming from then?
<JamesMunns[m]>
nope
<thejpster[m]>
So panic info can't use defmt natively I take it - correct, defmt is a third-party library.
<thejpster[m]>
and that's probably where this is coming from then? - yes
<thejpster[m]>
if you want to save space, turn the feature off and rely on the backtrace
<thejpster[m]>
you'll get file and line number, and most panic messages aren't that fancy so seeing the rendered version doesn't help
<thejpster[m]>
and most production systems reboot on panic so you never ever see the message
<spinfast[m]>
I wonder if I could toggle the feature only for debug builds
<spinfast[m]>
and disabling the print-defmt results in... 50% elf savings
<spinfast[m]>
so it was actually much greater than 25%
<spinfast[m]>
insane
<thejpster[m]>
you could talk to the binary size working group. They're aware of the problems.
<thejpster[m]>
but also, don't look at the size of the .elf file, run cargo size, because you want to ignore all the defmt symbols.
<thejpster[m]>
i mean, unless you really care about the size of the .elf itself. You might.
<spinfast[m]>
oh thats nice, wrappers for binutils
<spinfast[m]>
I was using arm-none- tools by hand hah
<spinfast[m]>
nothing like beating the nxp sdk in size for a sai sine sample
<spinfast[m]>
though not a true apples to apples I guess
<spinfast[m]>
I do wish const fn were just a little more flexible, feel like I could generate a regmap configuration array with a const fn and completely erase all that code
<spinfast[m]>
actually I didn't see it show up in cargo bloat at all, so maybe it did it already...
<spinfast[m]>
like even after stripping the mcux sdk elf is 78k, 67k of that is .text
<spinfast[m]>
the rust sai sample I have is 4k .text
<spinfast[m]>
both play sine waves
<spinfast[m]>
I think the mcux sdk has a little shell though to do record/sine/playback... so again not totally fair, at all, but sheesh
mameluc[m] has joined #rust-embedded
<mameluc[m]>
does anybody embed the git tag and/or hash in the binary somehow? I want to send it on first connect. I guess some kind of build.rs magic?
<NickStevens[m]>
<spinfast[m]> "cargo bloat gives me... 19.4% 1...." <- I've had good luck with https://crates.io/crates/cargo-llvm-lines to see how much of a binary is monomorphized impls, or at least how many monomorphizations are created
riskable[m] has quit [Quit: Idle timeout reached: 172800s]
<jannic[m]>
I love those adafruit docs. Why don't they tell in which way the i2c protocol is violated? I tried to search for it a bit, but all I found was https://github.com/micropython-IMU/micropython-bno055. That page mentions that the BNO055 does clock stretching up to 500µs. You may need to increase some timeout on the esp32 to allow for that?
<Ralph[m]>
thanks! i'm not using `esp-idf-sys`, i'm running on bare metal. i tried [`I2C::new_with_timeout`](https://docs.rs/esp32c6-hal/0.8.0/esp32c6_hal/i2c/struct.I2C.html#method.new_with_timeout) which does not document what `timeout` is (seems to be the actual value to be written to the underlying register which in turn seems to be a 5-bit field...?). i've set it to `0b11111` (as it's 5bits) but that didn't do the trick. i'm still getting
<Ralph[m]>
a `I2c(AckCheckFailed)`
sirhcel[m] has joined #rust-embedded
<sirhcel[m]>
I'm working on using embedded-hal-compat for transitioning a side-project form e-h 0.2 to 1.0. It uses the i2c mux driver [xca9548a](https://crates.io/crates/xca9548a) which implements blocking `Write`, `Read`, `WriteRead` but no iterator or transaction traits. The current i2c forwarding is implemented only for an implementation of all i2c... (full message at
<dirbaio[m]>
Especially for i2c, the basic read/write/write_read api hasn't changed between 0.2 and 1.0 so there's chances you can change the trait bounds to 1.0 and have it working quickly
<sirhcel[m]>
Let me try to rephrase it: embedded-hal-compat forwarding is currently only implemented for an impl which implements *all* e-h 0.2 i2c traits. Impls which only implement some of them (like just `Write` and `Read`) seem currently not covered by embedded-hal-compat. And just adding support for them with marker seems to require all impls implementing more than `Read` and `Write` to get verbose and explicitly select a variant like
<sirhcel[m]>
* Let me try to rephrase it: embedded-hal-compat forwarding is currently only implemented for an impl which implements _all_ e-h 0.2 i2c traits. Impls which only implement *some* of them (like just `Write` and `Read`) seem currently not covered by embedded-hal-compat. And just adding support for them with marker seems to require all impls implementing more than `Read` and `Write` to get verbose and explicitly select a variant like
<dirbaio[m]>
That will do each read/write in a separate transaction (i2c start+stop) while it has to be in a single one (i2c repeated start)
<sirhcel[m]>
Due to the repeated start condition in such a transaction?
<dirbaio[m]>
If 0.2 transactional is not impld you can't emulate it, best you can do is returning a "not supported" error in 1.0
<dirbaio[m]>
Same for write_read, it's not the same as a write then a read
<sirhcel[m]>
Good points. So not supported is the error to be expected in such a situation and this would need to be sorted out at runtime then.
<sirhcel[m]>
Thanks for the pointers! I know how to fix the forwarding impls now. But imposing the verbosity on all users of i2c forwarding still remains so far.
Guest7282 has left #rust-embedded [Disconnected: Replaced by new connection]
<mattnite[m]>
Hey everyone! James Munns told me about this matrix server, I’m working on building up the embedded space for Zig and looking forward to working together to improve embedded development :)
<jannic[m]>
mattnite[m]: What a coincidence, I just saw a posting about microzig on mastodon. "Unified abstraction layer and HAL for several microcontrollers" sounds interesting indeed.
<JamesMunns[m]>
That's how I found microzig too (tho on HN)
<mattnite[m]>
jannic[m]: We’ve got quite a ways to go, but I’ve been pretty pleased with progress over the last couple of years
<mattnite[m]>
The largest steps forward have been due to running small workshops at “Software You Can Love” conferences if you’re familiar
IlPalazzo-ojiisa has quit [Ping timeout: 272 seconds]