04:37 <re_irc> <Julia> I need defragmentation for my embedded device, any good solutions that anyone knows of?

05:06 <re_irc> < (@9names:matrix.org)> What is getting fragmented?

05:16 <re_irc> <Julia> It's kind of hard to explain because im doing something weird. The problem essentially boils down to me needing to almost always use all 32kb of ram, but some large vectors need to be allocated some times which is not possible without defragging. I can think of a workaround but that will just be a poor man's defrag haha.

05:17 <re_irc> < (@grantm11235:matrix.org)> Are you using an allocator?

05:17 <re_irc> <Julia> Yes i am using alloc-cortex-m i think.

05:18 <re_irc> < (@grantm11235:matrix.org)> I recall hearing that that allocator is prone to fragmentation

05:19 <re_irc> < (@grantm11235:matrix.org)> There is some discussion about it here https://github.com/rust-embedded/embedded-alloc/issues/36

05:29 <re_irc> <Julia> does a linked list allocator help in this case? im not too familiar with allocators so i might be misunderstanding how they work

07:14 <re_irc> < (@tmgross:matrix.org)> In the embedded_storage crate, what is the purpose of the "RmwMultiwriteNorFlashStorage" struct? It has no docs really https://docs.rs/embedded-storage/latest/embedded_storage/nor_flash/struct.RmwMultiwriteNorFlashStorage.html

07:30 <re_irc> < (@nihal.pasham:matrix.org)> https://twitter.com/npashi/status/1618149205037522946?s=12&t=4QQgIz9gTxGtj5xeos4LwQ

07:31 <re_irc> < (@nihal.pasham:matrix.org)> * Insightful - https://insights.sei.cmu.edu/blog/rust-vulnerability-analysis-and-maturity-challenges/

12:50 <re_irc> < (@utku:grusbv.com)> Hello, me and my colleague , are trying to apply a High Pass Filter to a data array but can't seem to find any crates that has implemented this feature. Is there any available crate that implements a HPF?

12:52 <re_irc> <henrik_alser> : What are your filter requirements?

12:53 <Darius> https://docs.rs/digital-filter/latest/digital_filter/ ?

12:54 <re_irc> <henrik_alser> For a basic iir biquad there's https://crates.io/crates/biquad

13:07 <re_irc> < (@mehmet:grusbv.com)> We were thinking of a basic Butterworth filter essentially aiming to kill very low freqs, a couple of Hz

13:08 <re_irc> <henrik_alser> Then the biquad should be fine

13:09 <Darius> Butterworth suggests you want a maximally flat passband

13:11 <re_irc> < (@ryan-summers:matrix.org)> : If you need it to be really fast, check out https://github.com/quartiq/idsp

13:12 <re_irc> <thejpster> : The nano-arena crate they quote when talking about CVEs in Rust has only 1,200 downloads. Ever.

13:34 <re_irc> < (@chrysn:matrix.org)> The no-std::no-alloc category is now available on crates.io. If your libraries are not only no-std but also don't require alloc, please consider adding it.

13:34 <re_irc> This will make it easier for other embedded developers to tell embedded friendly crates from libraries that (rightfully) observed that they don't need std, but still depend on having a heap.

13:42 <re_irc> < (@mehmet:grusbv.com)> : Wow this is news to me. I always assumes no-std was no-alloc

13:42 <re_irc> < (@mehmet:grusbv.com)> * assumed

13:44 <re_irc> < (@chrysn:matrix.org)> That's what it used to be, up to the point when "extern crate alloc" became possible on no-std. That's a good thing on its own (allowing the creation of no-std-but-needs-alloc crates), because there's a class of crates where that's practical, but it lost us an important distinction (between allocating and non-allocting crates).

14:02 <re_irc> < (@dkhayes117:matrix.org)> The Coap-lite crate is that way. No-std but needs an allocator.

14:02 <re_irc> < (@dkhayes117:matrix.org)> +feature

14:13 <re_irc> < (@chrysn:matrix.org)> As are, unfortunately, dcaf, coset and large parts of ciborium. (They contributed to inspiring the addition of the no-alloc category).

14:15 <re_irc> < (@chrysn:matrix.org)> I find it a bit odd for a CoAP crate to require allocation; the whole protocol was designed to not make any necessary. embedded-nal-coapserver manages well without (but granted, is a bit limited so far due to my stubborn insistence to always go through trait interfaces, having the CoAP application server portable across CoAP libraries, including coap-lite).

14:36 <re_irc> < (@nihal.pasham:matrix.org)> thejpster: True. But the article also refers to vulnerabilities (https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust) affecting a wide range of community-maintained libraries.

14:36 <re_irc> But what I found insightful was their analysis on why and how security tools must mature alongside Rust.

14:36 <re_irc> < (@nihal.pasham:matrix.org)> * True though the article also refers to vulnerabilities

14:43 <re_irc> < (@nihal.pasham:matrix.org)> +(https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust)

14:57 <re_irc> < (@jamesmunns:beeper.com)> 397 CVEs in 8 years (50/year), covering the language, the compiler, the stdlib, and all versions of all third party crates doesn't seem THAT unreasonable?

15:01 <re_irc> < (@jamesmunns:beeper.com)> Anyway, we should hold Rust to a high standard. Just make sure that if someone is pointing at deficiencies when comparing to other langs/ecosystems (C, C++), we use an even bar for comparison :)

15:01 <re_irc> < (@dirbaio:matrix.org)> UB found in a rust lib: fix is released, CVE is filed, affected versions are yanked, tools warn users that they have it in the tree and should update.

15:01 <re_irc> UB found in a C++ lib: "you're holding it wrong lols, just don't do that 🤪"

15:02 <re_irc> < (@jamesmunns:beeper.com)> : I mean, this is the even bar I mean :). I'm sure there's a name for "it's easier to judge rust because we admit certain things are bad, when other projects wouldn't", or stuff like "the bad number went up when we actually started rigorously counting all of the bad events, what happened?!?!"

15:04 <re_irc> < (@nihal.pasham:matrix.org)> : Yes

15:04 <re_irc> < (@jamesmunns:beeper.com)> Even if we hold that 70% of CVEs are memory safety as a truth, that's still 30% of logic error CVEs to deal with (I see a lot of DOS and panic related items on that list), or CVEs due to FFI to mem unsafe langs (I see a lot of those), or just general use of unsafe (I see some of those)

15:10 <re_irc> <riskable> Anyone working with audio? I want to learn how to play back sounds on a speaker that could be stored in flash or an SD card or wherever.

15:29 <re_irc> < (@altsegcat:matrix.org)> What's your hardware platform, and audio format

15:29 <re_irc> <ukrwin> Hello. How can I search for SDV files?

15:30 <re_irc> <ken> I don't suppose anyone here has managed to get the Nordic pre-built openthread-ftd library to link? I can't get it to find the symbols ("undefined symbol: otInstanceInitSingle"), but I'm not sure if that's an issue with some options in the library, or something I'm doing wrong so I thought I'd ask before spending too much time investigating.

15:46 <re_irc> < (@jamesmunns:beeper.com)> ken might be worth asking in #nrf-rs:matrix.org (https://matrix.to/#/#nrf-rs:matrix.org) as well. Not sure I've seen anyone using that library specifically.

15:49 <re_irc> <ken> Thanks . I'll poke a bit more at linker flags and then try there

15:50 <re_irc> < (@jamesmunns:beeper.com)> ukrwin: Are you looking for "SVD" files? If so, each vendor releases them in different places, do you know what chip you are looking for?

15:52 <re_irc> <ukrwin> SVD sorrey, yeah, it is STM8S103F3

15:52 <re_irc> <ukrwin> But there is not SVD files on the product page

15:52 <re_irc> <ukrwin> https://www.st.com/en/microcontrollers-microprocessors/stm8s103f3.html#documentation

15:53 <re_irc> < (@jamesmunns:beeper.com)> The STM8 family aren't Cortex-M chips, and I don't think Rust supports the STM8 family at all.

15:53 <re_irc> <ukrwin> SVD sorry, yeah, it is STM8S103F3

15:53 <re_irc> < (@jamesmunns:beeper.com)> (SVD is specifically a Cortex-M thing, though other architectures like RISC-V and Cortex-A have "adopted" it, at least for tools like svd2rust)

15:54 <re_irc> < (@jamesmunns:beeper.com)> Specifically, the LLVM project (part of the Rust compiler) doesn't support the STM8 CPU architecture. Which means it isn't generally possible to use Rust with those chips yet.

15:54 <re_irc> < (@jamesmunns:beeper.com)> * of/used by

15:54 <re_irc> <ukrwin> oh... ok. Thank you for your help. I will know that.

15:55 <re_irc> < (@jamesmunns:beeper.com)> Any of the other 32-bit parts, like STM32F, STM32G, STM32L, STM32C, etc., will generally work in Rust, because they are Cortex-M CPUs.

16:08 <re_irc> <riskable> : Anything. Though lately I've been doing a lot with RP2040

16:10 <re_irc> <riskable> I suppose I'd prefer to work with the opus audio format (because I like it) but it doesn't really matter at this point. I'm just looking to learn how to play back audio *in general* via embedded rust

16:10 <re_irc> < (@jamesmunns:beeper.com)> Generally, there's a couple parts:

16:10 <re_irc> 2. How do you decode the files (if you are using something like MP3 or OGG instead of WAV with raw PCM audio)

16:10 <re_irc> 1. How do you store/load the files (SD card, flash, etc.)

16:10 <re_irc> 3. How do you play that out to a speaker

16:10 <re_irc> < (@jamesmunns:beeper.com)> 1 is probably covered by the embedded-sdmmc and/or fat-fs crates if you're using an SD card, but you could also use embedded-storage on an external flash chip

16:10 <re_irc> <riskable> : Yeah exactly: I want to learn how others are doing it. I'll learn _all the ways_! 😁

16:11 <re_irc> < (@jamesmunns:beeper.com)> There are some fancy chips, like the VS1053, which will do steps 2 + 3 for you, you just stream it the compressed file

16:11 <re_irc> <riskable> : By "stream it" what do you mean?

16:11 <re_irc> < (@jamesmunns:beeper.com)> otherwise, you need to do the decoding, maybe with a library like https://docs.rs/symphonia.

16:13 <re_irc> < (@jamesmunns:beeper.com)> riskable: The VS1053b specifically has like a 512 byte (or something?) input buffer, so to start playing, you send it the first 512 or whatever bytes of let's say a 3MiB file. Then you keep it "topped up" with data over SPI, when it says that it has room for more data

16:13 <re_irc> < (@jamesmunns:beeper.com)> If you are doing step 2 in software, you'll need to talk to a DAC, either internal or external. Decoding will get you a stream of PCM samples (like, 16-bit signed numbers, 44000/second), which you feed to something, like your internal DAC, or over some protocol like I2S to an external DAC

16:15 <re_irc> < (@jamesmunns:beeper.com)> If you use "uncompressed"/"unencoded" formats like WAV, you can skip step 2, and only do step 1 and 3. If you use an "all in one codec" like the VS1053b, you can do step one and then sort of combine steps 2 and 3

16:15 <re_irc> <riskable> : Reading an audio file and decoding it sounds relatively straightforward to me. It's the, "what do I do with the decoded stream?" part that I have no clue about

16:16 <re_irc> < (@jamesmunns:beeper.com)> yup, the most common answer to that is usually "feed the decoded stream to a DAC over I2S"

16:16 <re_irc> <riskable> Never done that before. Do various HALs have a common way to write to a DAC? Maybe that's the part I'm missing

16:16 <re_irc> < (@jamesmunns:beeper.com)> usually you'll configure the DAC over I2C or SPI or something, like "get ready for a stereo 16-bit signed PCM channel", then you start streaming the samples over I2S.

16:17 <re_irc> < (@jamesmunns:beeper.com)> I've seen some people doing I2S things I think? But I don't see anything specific on the Awesome Embedded Rust list.

16:17 <re_irc> < (@jamesmunns:beeper.com)> I think the #neotron:matrix.org (https://matrix.to/#/#neotron:matrix.org) folks have some kind of I2S DAC? Not sure tho

16:18 <re_irc> < (@jamesmunns:beeper.com)> Seems so, or at least they have plans to support it: https://neotron-compute.github.io/Neotron-Book/neotron_pico.html

16:18 <re_irc> < (@jamesmunns:beeper.com)> > Audio [...] TLV320AIC23BPW audio codec

16:21 <re_irc> < (@jamesmunns:beeper.com)> https://en.wikipedia.org/wiki/I%C2%B2S explains some basics, but the long and short of it is that you basically just stream (at audio sample rate) the samples, with left and right samples typically interleaved

16:23 <re_irc> < (@jamesmunns:beeper.com)> For example, for stereo 16-bit, 44.1kHz decoded audio, you would essentially be streaming at 1.35Mbit over I2S. you'd usually use DMA to send blocks at a time.

16:23 <re_irc> < (@jamesmunns:beeper.com)> * 1.35Mbit/s

16:24 <re_irc> < (@jamesmunns:beeper.com)> So you'd decode, say, 64KiB, start a DMA transfer, then decode the next 64KiB, and start that DMA transfer right when the first one ends (and over and over and over)

16:28 <re_irc> < (@jamesmunns:beeper.com)> hope that helps. I don't have a lot of examples for you unfortunately, just a vague understand of how it's supposed to work :)

16:28 <re_irc> I used the VS1053b in mnemos on the nrf52 and allwinner d1, but it's not really _good_ code that I'd recommend looking at :D

18:59 <re_irc> < (@firefrommoonlight:matrix.org)> Maybe the word you're looking for is codec. They're parts that can do various audio I/O. You can send or receive data on the forms of PCM streams like I2S etc

19:00 <re_irc> < (@firefrommoonlight:matrix.org)> You'd use a dedicated audio periph on the MCU to interface with them

19:00 <re_irc> < (@firefrommoonlight:matrix.org)> James hit the big parts

19:01 <re_irc> < (@firefrommoonlight:matrix.org)> Config the codec over I2C, SPI etc

19:01 <re_irc> < (@firefrommoonlight:matrix.org)> The data is streamed from a buffer using DMA. Possibly a double circular buffer

19:02 <re_irc> < (@firefrommoonlight:matrix.org)> Where you modify one half while streaming the other etc

19:03 <re_irc> < (@firefrommoonlight:matrix.org)> Config is a bit tricky as there are lots of ways to configure the audio protocol. The MCUs and codecs I've used have been flexible, so the important part is making sure they're configured the same way

19:03 <re_irc> < (@firefrommoonlight:matrix.org)> My experience is mostly with Stm32 SAI peripheral

19:03 <re_irc> < (@firefrommoonlight:matrix.org)> Most MCUs have something equivalent

19:04 <re_irc> < (@firefrommoonlight:matrix.org)> Clock config must be set up appropriately between MCU and codec. You can usually pick which side generates the clock

19:17 <cr1901> jamesmunns: Is it possible to "incbin" a postcard-serialized data structure as a static into an embedded app?

19:18 <cr1901> Context: "I want to use MSP430's INFO mem to store version info. It makes sense to generate the data structure in build.rs.

19:21 <re_irc> < (@jamesmunns:beeper.com)> cr1901: Not totally sure what you mean, but you could totally serialize a value in a build rs, then either "include_bytes!()" a file or just generate the static directly from the build rs.

19:21 <cr1901> Yes this is what I want

19:23 <cr1901> The idea being "if someone finds a bug in my firmware, and they have a way to run a debugger, they can dump the memory, and I can pretty-print it"

19:24 <re_irc> < (@jamesmunns:beeper.com)> but yeah, you'd do one of:

19:24 <re_irc> static INFO: &[u8] = include_bytes!("generated.bin");

19:24 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/1jzEhLjd73bjUTGcECJR18elZurKpfNK (10 lines)

19:24 <re_irc> or in the build rs (this is println, but you should write to a file...)

19:24 <re_irc> #[link-section = "..."]

19:24 <cr1901> would INFO: [u8; _] work?

19:24 <cr1901> Anyways thanks

19:24 <re_irc> < (@jamesmunns:beeper.com)> I don't think you can elide the actual length in a static

19:24 <cr1901> Compiler's too lazy to calculate it, huh?

19:24 <cr1901> :P

19:25 <re_irc> < (@jamesmunns:beeper.com)> include_bytes returns a slice, but you could have the specific length computed by the build rs codegen

19:26 <re_irc> < (@jamesmunns:beeper.com)> but yeah, I guess you would save yourself one "usize" of static mem by using a sized array instead of a slice :)

19:27 <cr1901> arrays are internally usize, then contents, correct?

19:28 <re_irc> < (@grantm11235:matrix.org)> I think they are "(pointer, lenght)"

19:28 <cr1901> Yea, not sure if array vs slice matters then

19:28 <cr1901> (unless I'm missing something obvious)

19:29 <re_irc> < (@grantm11235:matrix.org)> Oh sorry, I misread. I thought you were asking about slices

19:29 <re_irc> < (@grantm11235:matrix.org)> Arrays just have their contents

19:31 <cr1901> ahhh so you save two usizes then :P. In any case, if a user gives me a dump of INFO mem, then I don't know ahead of time how large the array is.

19:32 <cr1901> Even tho the pointer part is useless, the length part is useful

19:49 <re_irc> < (@Ericson2314:matrix.org)> I was doing "cargo:rustc-link-arg=--defsym=" in a build script, but now I need to do something for a library when testing

19:49 <re_irc> < (@Ericson2314:matrix.org)> and "build.rs" seems to week for "cfg(test)" only stuff

19:50 <re_irc> < (@Ericson2314:matrix.org)> any know any other tricks to "cfg(test)" define a symbol?

20:02 <re_irc> <thejpster> https://hachyderm.io/Mara/109750138856951150

20:11 <re_irc> < (@Ericson2314:matrix.org)> https://sourceware.org/binutils/docs/as/Set.html#Set got it :D

20:11 <re_irc> < (@Ericson2314:matrix.org)> thejpster: I responded to that one

20:12 <re_irc> < (@Ericson2314:matrix.org)> I have for years heard rumors of trying to combine std and core, but I think that is the wrong direction

20:21 <re_irc> < (@chrysn:matrix.org)> Aren't these orthogonal? There are already things moving from std to core (whether through re-exports or new types) all the time; combining std and core would alter the mechanics, but is there anything that can be done after the combining that can't be done now?

21:35 <re_irc> <FredrikLL> Has anyone had good experience with using C in an embedded rust project? I want to use the vendor's BLE library, which is precompiled with a bunch of header files. Is is really as easy as it seems in the embedded rust book, or are there some caveats?

21:37 <re_irc> <henrik_alser> FredrikLL: Nordic softdevice?

21:38 <re_irc> <FredrikLL> Nope, I am using a silabs chip.

21:46 <re_irc> < (@dkhayes117:matrix.org)> FredrikLL: the nrfxlib-sys (https://github.com/nrf-rs/nrfxlib-sys) crate is probably something similar. It is used for the nRF9160 cellular modem library.

21:48 <re_irc> <FredrikLL> Thanks, I'll have a look at that!