<dngrs[m]>
hmmm I'd think 6kHz should totally work, try streaming it as a topic
<dngrs[m]>
not request-response
<JamesMunns[m]>
yeah, you can stream messages as a topic, basically blindfiring them. The current impl doesn't batch multiple frames into a single report tho, so you might want to batch them to say 16 at a time, then send that as a topic message
<JamesMunns[m]>
then you're likely to have the better part of a 64-byte message (16-48 bytes if the samples are varinted, or a straight 32 of data if you make them `[u8; N]` (you'll need a few bytes for a header)
<JamesMunns[m]>
then you're also only sending at 375hz, out of the potential 1000hz usb typically polls at
<JamesMunns[m]>
yeah, you can stream messages as a topic, basically blindfiring them. The current impl doesn't batch multiple postcard-rpc-frames into a single usb-frame tho, so you might want to batch them to say 16 at a time, then send that as a topic message
<JamesMunns[m]>
that being said, if you just want to do min/max/stddev, yeah, you're probably better off doing that on the device, unless you really want the raw stream for post-processing :)
<Ralph[m]>
thanks! yeah, i'll keep it on-device. i don't think i need those 24kb RAM
<Ralph[m]>
i hadn't used a stream before because i didn't want to continuously spam it with that (i only need it at specific times). but i guess i could have a start/stop endpoint for the stream if i'd go down that route?
<JamesMunns[m]>
yep, that's a pretty common thing I do
<JamesMunns[m]>
have one endpoint for "start stream" and one endpoint for "stop stream"
Hallo124 has quit [Remote host closed the connection]
Hallo124 has joined #rust-embedded
<dngrs[m]>
is there an offline version for people who don't want to use the cloud?
<dngrs[m]>
(on a more serious note: interesting, TIL!)
<jannic[m]>
Offline version? Like on paper? West, D. H. D. (1979). "Updating Mean and Variance Estimates: An Improved Method". Communications of the ACM. 22 (9): 532–535.
<jannic[m]>
Maybe available at some university library nearby?
<dngrs[m]>
I was just intentionally misunderstanding "online algorithm" as "something you need to be online for in order to use it"
<jannic[m]>
😆
Koen[m] has joined #rust-embedded
<Koen[m]>
Averaging as a Service, contact your AWS sales representative for subscription options! 😆
<jannic[m]>
Depending on your microcontroller it may be more efficient to calculate it on blocks of data the conventional way, and then combine the results using the "parallel algorithm" described further down on the Wikipedia page. Depending on the availability of an FPU. Float divisions done in software are quite expensive.
<Ralph[m]>
i was not aware of that online algorithm, thanks! (but i'll stick to wasting RAM for now - much easier to reason about the code that way)
<Ralph[m]>
(i wanted to say "... unless someone provides a crate which implements it; but i don't want to pull in another dependency ..." and then i remembered: i had to pull in `libm` for `sqrt` on floats because it hasn't been stabilised yet in core 😅)
<Ralph[m]>
<dngrs[m]> "if you're on cortex-m and..." <- interesting that it offers super simple things like `abs`, complex things like `fft` but not the in-between stuff like `sqrt` 😮
<firefrommoonligh>
<Ralph[m]> "interesting that it offers super..." <- Use num_traits for sqrt
<firefrommoonligh>
CMSIS-DSP is good for filters, FFT, and some other more complicated things. (As mentioned). If you want standard math and trig fns, it's num_traits
<firefrommoonligh>
(Or libm)
<firefrommoonligh>
So, for Ralph's example of streaming ADC values, he would use CMSIS-DSP's FIR or IIR filters.
<jason-kairos[m]>
Can zerocopy deal with structures that contain boolean values in an ergonomic way?
<jason-kairos[m]>
It seems like it really wants to work with bytes and not bits - not sure about the rules surrounding how they get represented/stored (1 byte per bool?)
<dngrs[m]>
bit fields are not a native Rust type so you will need to delegate that
<jbeaurivage[m]>
<burrbull[m]> "This is possible. Is this before..." <- It would be after that PR. I'll check it the issue persists with 0.36.0, which is before #930
<jannic[m]>
<sourcebox[m]> "If you're ok with 5% error, then..." <- Nice coincidence that the image is very related to the initial question :-)
Kaspar[m] has joined #rust-embedded
<Kaspar[m]>
Hey everyone! I'm looking for background info regarding stm32-rs vs. stm32-metapac. I do understand that the former are based on the SVD files and the latter on the Cube metadata, and that stm32-rs was there first. So why stm32-metapac? I'd assume that the SVD based ones where inconsistent and buggy, whereas the Cube data is just more accurate?
<M9names[m]>
> I'd assume that the SVD based ones where inconsistent and buggy
<M9names[m]>
all the data is inconsitent and buggy
<M9names[m]>
both rely on humans to fix up the data and make something that works across multiple chips, but stm32-metapac doesn't try the make that common format svd.
<firefrommoonligh>
On the topic of fast-math: Good article describing some of the traps lately. Some of it is applicable to SIMD instructions not relevant on embedded, and mostly academic, but good read: https://simonbyrne.github.io/notes/fastmath/
<firefrommoonligh>
So, the sin fn from cmsis-DSP is probably faster and less accurate than the one from num-traits, but I haven't compaerd or dug into the internals
<firefrommoonligh>
(And then you can get into the hardware trig fns available on some MCUs too like stm32 CORDIC)
sroemer has quit [Quit: WeeChat 4.5.2]
balbi[m] has quit [Quit: Idle timeout reached: 172800s]
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
<jason-kairos[m]>
This is a shot in the dark, but does anyone have insight into the various flavors of the STM32 WFI bug? (or know who to ask, or where to look)
<jason-kairos[m]>
it comes and goes, and none of the workaround give reliable results.
<jason-kairos[m]>
* This is a shot in the dark, but does anyone have insight into the various flavors of the STM32 WFI bug? (or know who to ask, or where to look)
<jason-kairos[m]>
it comes and goes, and none of the workarounds give reliable results.
<GuineaWheek[m]>
<firefrommoonligh> "So, the sin fn from cmsis-DSP is..." <- ime it has the best tradeoff of speed/size/accuracy; it’s like 0.0001 less accurate than libm while being 20x faster
<GuineaWheek[m]>
micromath tends to make spherical cow tier approximations
pcs38 has joined #rust-embedded
pcs38 has quit [Quit: leaving]
<thejpster[m]>
does anyone have a working USD Keyboard demo in Rust? I think I just wrote a keyboard decoder - but I need some actual HID frames from a keyboard.
<GuineaWheek[m]>
<sourcebox[m]> "If you're ok with 5% error, then..." <- most of us are using a cortex-m4f or m7f that has a vsqrtf function. unfortunately its only accessible thru core::intrinsics::sqrtf32 — its both faster than the micromath impl while not being ridiculously off
BradleyNelson[m] has joined #rust-embedded
<BradleyNelson[m]>
Hello everyone - I've written a blog post describing one of the demos at the Infineon table at RustWeek that showed a pure Rust, async embassy WiFi application with a web page served up from a FAT32 formatted SD card. The source for the demo is available as a zip file attached to the blog post.
<BradleyNelson[m]>
For anyone who's not on LinkedIn and didn't see it, I thought I'd cross post here since several of you were there and we handed out a few dev kits - this demo will run on that kit. Feel free to let me know thoughts and I'm here to answer questions as well!
<BradleyNelson[m]>
We also released Infineon PSOC 6 and PSOC Control C3 PACs to crates.io recently: https://crates.io/users/jnkr-ifx
<BradleyNelson[m]>
Jonathan and I are happy to help anyone get started.
<M9names[m]>
<GuineaWheek[m]> "most of us are using a cortex-..." <- I don't think "most of us" are, actually.
<M9names[m]>
I suspect no-one has hard data on the composition of the community but if I had to guess where most of the users were, it would be some flavour of espressif chip.