10:00 <re_irc> <@thejpster:matrix.org> I cleaned up a bunch of outstanding rust-embedded-community/embedded-sdmmc PRs. Apologies to anyone whose PR we didn't get merged before I came back to the project and broke everything.

10:00 <re_irc> <@thejpster:matrix.org> Volunteers for stewarding the crates in rust-embedded-community are always welcome :)

11:08 <re_irc> <@devakiran:matrix.org> hi i am new to rust in esp32

11:08 <re_irc> <@devakiran:matrix.org> can i use eps-wroom32 for this

11:21 <re_irc> <@firefrommoonlight:matrix.org> I dunno I guess

11:21 <re_irc> <@firefrommoonlight:matrix.org> ESP32 has a v confusing product line

11:21 <re_irc> <@firefrommoonlight:matrix.org> But they're all p much the same!

11:21 <re_irc> <@firefrommoonlight:matrix.org> Sometimes they even use different-named footprints that are actually the same

11:21 <re_irc> <@firefrommoonlight:matrix.org> Learn to lurve it

11:21 <re_irc> <@firefrommoonlight:matrix.org> I am assuming ESP-WROOM32 is like all the others

11:48 <re_irc> <@fuse117:matrix.org> can someone provide an example of rust code for a device that is a SPI slave?

11:49 <re_irc> <@fuse117:matrix.org> i have never developed the slave side. im thinking of something like a server that waits for commands, executes those commands, and possibly responds to a master

12:07 <re_irc> <@henrik_alser:matrix.org> fuse117: https://github.com/embassy-rs/embassy/blob/main/examples/nrf52840/src/bin/spis.rs

12:13 <re_irc> <@henrik_alser:matrix.org> https://github.com/stm32-rs/stm32f4xx-hal/blob/master/examples/rtic-spi-slave-dma.rs

16:14 <re_irc> <@thejpster:matrix.org> https://github.com/neotron-Compute/neotron-bmc

16:14 <re_irc> <@thejpster:matrix.org> with a command / response protocol, runs on an STM32F0. Only goes up to about 4 MHz bus clock though - I should be using DMA really.

16:15 <re_irc> <@thejpster:matrix.org> The protocol is designed to have a fixed size first packet, so you can receive it with DMA, and then an optional variable sized second packet (where the first packet told you how big it's going to be).

16:16 <re_irc> <@thejpster:matrix.org> I also would generally avoid the old Mxxx and Sxxx terminology. Controller and Peripheral, or Initiator and Recipient work.

17:11 <cr1901> M/S was also removed from the latest I2C spec. So NXP seems to agree

17:11 <cr1901> https://twitter.com/cr1901/status/1576340915601297408

17:51 <re_irc> <@drebbe:matrix.org> Sad we are changing terminology when it doesn't even correlate to the thing that people take offense to.

18:08 <re_irc> <@juliand:fehler-in-der-matrix.de> drebbe: Well, if people are offended by this terminology I personally don't have a problem to change it. It would be helpful though, to replace it with some consistent terminology to avoid confusion. (Maybe at least across the rust ecosystem?) Are there any guidelines for this atm?

18:14 <re_irc> <@cajt:matrix.org> They missed the oportunity to actually improve ther terminology, on the protocol level there would be a better option: initiator and responder ... and suddenly everyone has an idea what going on.

18:17 <re_irc> <@drebbe:matrix.org> : Consistency would be amazing, change just to change isn't very intelligent IMO

18:18 <re_irc> <@drebbe:matrix.org> : I don't think anyone was ever confused about what master and slave mean in computer science. If they were they probably needed a new field of study, lol.

18:22 <re_irc> <@cajt:matrix.org> drebbe: no, probably not. But the modifications taken are often bad and confusing for various reasons. The SPI naming miso mosi for example fixed the context problem with rx/tx, as probably everyone long enough in embedded expierienced at one time. That was an improvement, many of the later choices, not so much

18:24 <re_irc> <@cajt:matrix.org> The stuff ARM picked was easies to remember, if one knew the context: keep M/S abbreviations consistend, so it kinda remains master and slave.

18:27 <re_irc> <@drebbe:matrix.org> : TX/RX has caused the industry probably billions in mistakes, lol. Let's change that first.

20:15 <re_irc> <@robgal519:matrix.org> Hi, I have an application running on stm32f103. I want to save some flags to the end of the flash build in to the SoC. How to do this ?

20:15 <re_irc> I tried using PAC to gain access to flash, and I was able to read the flash, and even write some bytes ( but I started getting some errors.) I generally do not like this approach, because the build system does not see my modifications, and if my application grows, I can accidentally overwrite the application.

20:15 <re_irc> so my question is How to shrink the FLASH region, and use the freed space for separate None Volatile Storage accessible from the application ?

20:20 <re_irc> <@dirbaio:matrix.org> reduce FLASH in memory.x

20:22 <re_irc> <@dirbaio:matrix.org> so the reserved space is guaranteed to not be used (linking will fail if you add too much code, instead of using the reserved space)

20:26 <re_irc> <@robgal519:matrix.org> ok, I can try this. BTW is there some standard way of storing persistent application settings for embedded devices written in Rust ? I just need to store some configuration values, that most likely will be done only few times in the lifetime of the device, so flash usage is not an issue (It will also be just a few Bytes). I'm wondering if I try to invent the wheel, or is there a better solution for storing such data...

20:26 <re_irc> ... without external EEPROM chip ?

20:28 <re_irc> <@dirbaio:matrix.org> simpler is better :)

20:28 <re_irc> If the dataset fits in RAM, you could read/write it all at once. Either making it repr(C) and transmuting, or serializing it with some compact serde flavor such as postcard

20:29 <re_irc> <@dirbaio:matrix.org> if it doesn't then there's

20:29 <re_irc> https://github.com/embassy-rs/ekv

20:29 <re_irc> https://github.com/tweedegolf/sequential-storage

20:30 <re_irc> <@dirbaio:matrix.org> sequential-storage is much lighter but does linear scans to find keys. i'd recommend using sequential-storage if your store is small (<1000 keys) and ekv if it's big (>1000 keys)

20:32 <re_irc> <@robgal519:matrix.org> Thank You, I will check them :D

20:34 <re_irc> <@diondokter:matrix.org> : I want to make an async version too, but I implemented it with (limited) recursion. So I can't easily translate...

20:35 <re_irc> <@dirbaio:matrix.org> oops

20:35 <re_irc> <@dirbaio:matrix.org> :D

21:24 <re_irc> <@dngrs:matrix.org> test

21:37 <re_irc> <@firefrommoonlight:matrix.org> : Onboard flash

21:38 <re_irc> <@firefrommoonlight:matrix.org> I usually use a config struct with "to_bytes()" and "from_bytes()" methods

21:39 <re_irc> // For the initial config (Eg on a new device), 0xff in flash indicates the config

21:39 <re_irc> // hasn't been saved yet.

21:39 <re_irc> <@firefrommoonlight:matrix.org> eg

21:39 <re_irc> let mut config = Config::load(&mut flash_onboard);

21:39 <re_irc> if config.common.node_id == 0xff {

21:39 <re_irc> config = Default::default();

21:39 <re_irc> config.save(&mut flash_onboard);

21:39 <re_irc> }

21:39 <re_irc> <@firefrommoonlight:matrix.org> I usually use a config struct with "save()" and "load()" methods

21:39 <re_irc> let mut config = Config::load(&mut flash_onboard);

21:39 <re_irc> <@firefrommoonlight:matrix.org> eg

21:39 <re_irc> // hasn't been saved yet.

21:39 <re_irc> if config.common.node_id == 0xff {

21:39 <re_irc> // For the initial config (Eg on a new device), 0xff in flash indicates the config

21:39 <re_irc> config = Default::default();

21:39 <re_irc> config.save(&mut flash_onboard);

21:39 <re_irc> }

21:39 <re_irc> <@firefrommoonlight:matrix.org> eg something like this on init

21:39 <re_irc> // For the initial config (Eg on a new device), 0xff in flash indicates the config

21:39 <re_irc> let mut config = Config::load(&mut flash_onboard);

21:39 <re_irc> // hasn't been saved yet.

21:39 <re_irc> if config.common.node_id == 0xff {

21:39 <re_irc> config = Default::default();

21:39 <re_irc> config.save(&mut flash_onboard);

21:39 <re_irc> }

21:40 <re_irc> <@firefrommoonlight:matrix.org> And "load" may look something like this:

21:40 <re_irc> let mut buf = [0; MsgType::ConfigGnss.payload_size() as usize];

21:40 <re_irc> flash.read(Bank::B1, crate::FLASH_PAGE_ONBOARD, 0, &mut buf);

21:40 <re_irc> Self::from_bytes(&buf)

21:40 <re_irc> pub fn load(flash: &mut Flash) -> Self {

21:40 <re_irc> }

21:41 <re_irc> <@firefrommoonlight:matrix.org> Make sure the page/sector etc is past what your program memory takes up.

21:41 <re_irc> <@firefrommoonlight:matrix.org> Or you will have surprises

21:46 <re_irc> <@firefrommoonlight:matrix.org> pub fn save(&self, flash: &mut Flash) {

21:46 <re_irc> .write_page(Bank::B1, crate::FLASH_PAGE_ONBOARD, &self.to_bytes())

21:46 <re_irc> flash

21:46 <re_irc> flash.erase_page(Bank::B1, crate::FLASH_PAGE_ONBOARD).ok();

21:46 <re_irc> .ok();

21:46 <re_irc> }

21:52 <re_irc> <@dirbaio:matrix.org> : you might want to add a checksum or something. If power fails while writing the config you might end up with "node_id != 0xFF" but unwritten 0xFF in other fields

21:53 <re_irc> <@dirbaio:matrix.org> or completely random garbage if power fails while erasing

21:55 <re_irc> <@dirbaio:matrix.org> so you can treat "checksum fail" as "no config"

21:56 <re_irc> <@dirbaio:matrix.org> and this can still behave weird because if a change from "config A" to "config B" fails you can end up with "no config"

21:57 <re_irc> <@dirbaio:matrix.org> so if you want to 100% guarantee config writes are atomic

21:58 <re_irc> <@dirbaio:matrix.org> you need two copies of the config in separate pages, a "sequence number" to know which one is newer, and ping-pong between them

21:58 <re_irc> <@dirbaio:matrix.org> using raw flash is trickier than it seems 🥲

22:01 <re_irc> <@firefrommoonlight:matrix.org> Concur re checksum or other sanity check

22:02 <re_irc> <@dirbaio:matrix.org> a crate that does just that would be useful

22:02 <re_irc> <@dirbaio:matrix.org> no fancy key-value things

22:02 <re_irc> <@firefrommoonlight:matrix.org> The dual copies also would add robustness

22:03 <re_irc> <@dirbaio:matrix.org> just "read bytes", "atomically write bytes"

22:03 <re_irc> <@firefrommoonlight:matrix.org> But I can also imagine nothing going wrong for thousands of cycles. Depends on if it's a safety-critical device etc

22:03 <re_irc> <@firefrommoonlight:matrix.org> But your approach is better code complexity not withstanding

22:05 <re_irc> <@dirbaio:matrix.org> yea... I guess, as always, the answer is It Depends™️

22:05 <re_irc> <@dirbaio:matrix.org> ++D

22:05 <re_irc> <@dirbaio:matrix.org> * =D

22:05 <re_irc> <@dirbaio:matrix.org> for some applications it might be fine to erase the config if a write gets interrupted... 🤷