00:33 <re_irc> <tigerdruid21> monacoprinsen: No problem, was just wondering if Rust Embedded had something more standard to address that issue than relying on an external crate.

00:38 <re_irc> <tigerdruid21> I’m to understand if this is something that will be addressed in future version of standard rust Embedded out of the box or we’ll have for ever to rely on that external crate (or any other external crate) knowing there is no warranty having this one update or keep in sync with embedded-hal for instance.

00:40 <re_irc> <adamgreig> tigerdruid21: the upcoming embedded-hal 1.0 is expected to have built in support for various ways of sharing a bus, https://github.com/rust-embedded/embedded-hal/pull/392 is the PR for I2C

00:43 <re_irc> <tigerdruid21> adamgreig: That an awesome news, so temporary at least for the I2C bus we can use the « shared-bus » crate.

00:43 <re_irc> What about the SPI bus or ADC bus, or any other buses?

00:49 <re_irc> <adamgreig> similar trait for SPI is already in 1.0 alpha release https://docs.rs/embedded-hal/1.0.0-alpha.8/embedded_hal/spi/blocking/index.html

00:49 <re_irc> <adamgreig> there's no ADC trait at the moment

01:00 <re_irc> <nihal.pasham> James Munns: Thanks

01:02 <re_irc> <tigerdruid21> adamgreig: Thanks

04:04 <re_irc> <tiasb> .

06:17 <re_irc> <omar_u8> I'm looking at the ADC DMA RTIC example for the stm32f4 here (https://github.com/stm32-rs/stm32f4xx-hal/blob/master/examples/adc_dma_rtic.rs) and I have three questions I'm hoping some one can help me answer. First is why is the buffer in lines 81 and 121 being wrapped with a "Some" ? Second is, why do the DMA buffers have to be singletons (lines 80 and 81)? Finally, why does the code need a polling task that seems to...

06:17 <re_irc> ... kick off an ADC conversion every 1 second (lines 95 - 104)? The ADC is already configured for Scan and Continuous in line 71.

06:17 <re_irc> <omar_u8> I'm looking at the ADC DMA RTIC example for the stm32f4 here (https://github.com/stm32-rs/stm32f4xx-hal/blob/master/examples/adc_dma_rtic.rs) and I have three questions I'm hoping some one can help me answer. First, why is the buffer in lines 81 and 121 being wrapped with a "Some"? Second, why do the DMA buffers have to be singletons (lines 80 and 81)? Finally, why does the code need a polling task that seems to kick off...

06:17 <re_irc> ... an ADC conversion every 1 second (lines 95 - 104)? The ADC is already configured for Scan and Continuous in line 71.

06:17 <re_irc> <omar_u8> * on

06:22 <re_irc> <omar_u8> Actually, theres one more thing :) why are two buffers being used? lines (80 and 81), wouldn't one be sufficient?

06:51 <re_irc> <hartan> Is there an obvious to tell whether certain crates depend on "std" without waiting for the compile to yell at me?

06:51 <re_irc> <hartan> +way

06:53 <re_irc> <diondokter> Sadly no. But there are two things you can check. First, go to the Cargo.toml. If you see a feature with the "std" name, then probably you can turn it off. Secondly, go to the lib.rs of the crate. If there's a "#![no_std]" somewhere at the top, you're set to go

07:28 <re_irc> <hartan> What is the idiomatic way to parse bits into custom types? I have a "u8" that codes both an internal state and an error with different bits each.

07:30 <re_irc> <K900> There's https://docs.rs/nom/latest/nom/bits/index.html

07:30 <re_irc> <K900> If it's something complex

09:09 <re_irc> <firefrommoonlight> Depends on the types you're parsing into

09:09 <re_irc> <firefrommoonlight> Likely a mix of clone or copy from slice, from_xe_bytes etc

09:10 <re_irc> <firefrommoonlight> There's a crate that can help for reverse constructing enums, with a try from primative decorator

09:11 <re_irc> <firefrommoonlight> There was chat here recently about possibly making serde or Postman work for this in the future

09:11 <re_irc> <firefrommoonlight> Nvm I misread; what I posted is byte level; you're looking for splitting bytes

09:12 <re_irc> <firefrommoonlight> The play here is bit arith as you'd do in any lang

09:20 <re_irc> <firefrommoonlight> It would be cool if there were a u4 type though that could be generated from a u8 method in Rust official though!

10:00 <re_irc> <hartan> firefrommoonlight: Or something that allows destructuring "uN" into individual bits you can match patterns against. I went for good old bitmasking/shifting magic now.

10:33 <re_irc> <Marius Kriegerowski> So, this is a question where I'm rather on thin ice as I have not too much embedded rust experience but let's see. My personal rust learning project is an intrusion detection system which does a very simple thing: Go through all your files, hash them, store the hash and start watching the filesystem. If some file gets changed, it will send out an email, or a message telegram. So, nothing too fancy....

10:33 <re_irc> ... https://github.com/HerrMuellerluedenscheid/snitch

10:33 <re_irc> I also did some embedded rust fumbling with LED displays and sensors and was wondering if I could provide a "no_std" version of that as well. I'm not too deep into the realm of embedded security and thus not sure if intrusion on embedded systems is actually a thing but as I said this is mostly for learning.

10:33 <re_irc> So the actual question is: What options do I have to have to do the same using embedded rust? Basically periodically accessing the memory registers which should not change, something like "read_memory(start_address, end_address)". It kind of defeats the idea of rust and its borrow checker so I guess I have to dive into unsafe code or so, but I'm really not certain.

10:33 <re_irc> I'm also happy to receive some hints to memory handling, accessing, memory management, etc. because I'm also not really sure what to look for and where to start. So basically ANY info is highly appreciated :)

10:38 <re_irc> <jannic> Some DMA engines can calculate checksums on the data they read/write. Depending on your hardware, you may be able to just set up a DMA transfer to calculate the checksum in the background. The rust program will never even notice that the memory was read by the DMA engine, so the borrow checker isn't involved at all.

10:42 <re_irc> <Marius Kriegerowski> jannic: Thanks for the hint! Do I understand (based on my favourite search engine result) correctly, that this would require dedicated hardware, the DMA? At the moment I'm using a rp2040, so I guess this will not be an option here. Am I guessing right?

11:03 <re_irc> <heksa> Does SVD have any facilities for heterogeneously multi-CPU architectures? Say, you have a physical peripheral that's available to two separate cores, but it's memory mapped in different places for those two cores. I'm sure svd2rust has run into this use case, could someone point me to an issue or a search keyword?

11:04 <re_irc> <heksa> We ended up making a kind of "metapac" (name copied from another HAL), that unifies the types of those shared peripherals. But that's quite manual, even if it's regular enough to be wrapped in macros.

11:07 <re_irc> <heksa> I kinda left out the problem from that message: say you have a serial driver that you want to run on both cores. Both cores have a different PAC so the type of the serial register interface is different, even if it's the same physical interface. Therefore those types need to be unified. A common trait is the primary solution I guess.

11:11 <re_irc> <heksa> I guess it's a similar issue to when you have the same peripheral that's available on multiple microcontroller models, except that the microcontrollers are actually on the same chip. I recall seeing something about that on some cortex-m device.

12:16 <re_irc> <jannic> Marius Kriegerowski: Well in fact it is! See section "2.5.5.2. CRC Calculation" of the datasheet, https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf. However, to my knowledge there is no rust crate supporting this feature, so you'd have to program the hardware registers manually.

12:47 <re_irc> <Marius Kriegerowski> jannic: Thanks so much. I guess that was a really valuable hint! I'll take a dive into the datasheet

12:50 <re_irc> <jannic> If it's really about security, one serious limitation is that the hardware only supports simple checksums like CRC which are not cryptographically secure. But as you wrote that it's mostly for learning, it might still be fine?

14:03 <re_irc> <Marius Kriegerowski> jannic: Yes, this is about learning. Mostly.