00:29 <RockBoynton[m]> with sequential-storage, is it expected that a store would hang if the flash memory has not previously been erased?

05:30 <Jubilee[m]> rmsyn: Heya.

14:03 <berkus[m]> adamgreig: i did some housekeeping on the awesome-embedded list, hope resources team dont mind

14:17 <thejpster[m]> can I get a hi-five on https://github.com/rust-embedded-community/tinyrlibc/pull/32 please? Adds rand and srand to tinyrlibc

14:18 <diondokter[m]> I would if I had rights....

14:19 <diondokter[m]> <RockBoynton[m]> "with sequential-storage, is it..." <- Hmmmm... the assumption is made that the flash is either erased of only written by the crate before.

14:19 <diondokter[m]> Using it on random data is not advised. Though hanging sounds quite bad and should probably be fixed...

14:29 <sarath08071994[m> Hi I compiled rust code for the armv7-unknown-linux-gnueabihf target. When I put the binary in the target board (LG innotek - lgit Lam -j300-4j) and run. I am getting the following error... (full message at <https://catircservices.org/_irc/v1/media/download/AXtEtrt9M7Efgy10iTGdhE8Ua8k1nsY73PsPVVOv_5WZieQ3sRXp0scr6wI6gv0Z2gk4xrVY7xf3wxGEqY6DdnS_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9nWHZHSWxxanhrd2JuWkR4cXpwRFZRelA>)

14:29 <sarath08071994[m> s/one/anyone/

14:30 <sarath08071994[m> * Hi I compiled rust code for the armv7-unknown-linux-gnueabihf target. When I put the binary in the target board (LG innotek - lgit Lam -j300-4j) and run. I am getting the following error... (full message at <https://catircservices.org/_irc/v1/media/download/AVpH_CT-Pvwu4G2BTxwmOy2_XIWxQwGo9XJPlqzkPus2m1uM12oRn0brmY36tZjyUUvnFnTdIJzp_oPLEtKSwXe_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9BU29udkpud0FhakV5bWRoblBJRk1XUUY>)

14:31 <davidmpye[m]> I'm using a Pico as an i2c matrix keypad driver because I have no space constraints and by the time I have both

14:49 <alex[m]1> your command and the error do not match their paths; this is confusing. if the board is a Linux (or similar system), this might be something like the binary not being the right kind (you can use the file command to verify, if available), or missing the executable bit

14:52 <thejpster[m]> diondokter: I have invited you to the org

14:53 <diondokter[m]> thejpster[m]: Ah cool! it can be merged now!

15:09 <thejpster[m]> Welcome to the gang

16:21 <RockBoynton[m]> <diondokter[m]> "Hmmmm... the assumption is..." <- > <@diondokter:matrix.org> Hmmmm... the assumption is made that the flash is either erased of only written by the crate before.

16:21 <RockBoynton[m]> > Using it on random data is not advised. Though hanging sounds quite bad and should probably be fixed...

16:21 <RockBoynton[m]> It seems to take slightly longer to fetch or store after a fresh erase, than after it is first fetched or stored to. It was just hanging because I expected there to be no delay in the code (I fixed that bug in my code)

17:02 <ivmarkov[m]> danielb: [Love it!](https://github.com/esp-rs/esp-hal/pull/2532). (Still need to test it)

17:03 <danielb[m]> now I feel exposed, thanks 🙈

19:23 <spikespaz[m]> Is there any reason to not impl core::error::Error for my embedded crate's Error?

19:34 <dirbaio[m]> backwards compatibility

19:34 <dirbaio[m]> no reason, no :)

20:49 <spikespaz[m]> Ty

20:49 <spikespaz[m]> But what was the deleted message XD

20:49 <dirbaio[m]> I thought you were asking something else

20:50 <spikespaz[m]> I remember there used to be edge cases where people had feature gated it under core_error or alloc

20:50 <dirbaio[m]> not sure why? it's never required alloc. maybe it's from when it was still unstable?

20:55 <spikespaz[m]> Perhaps, but also isn't actual usage difficult if the methods require alloc to be used correctly?

20:55 <dirbaio[m]> core::error::Error doesn't require alloc

20:57 <dirbaio[m]> maybe you're confusing it with std::io::Error which does

21:41 <spikespaz[m]> <dirbaio[m]> "maybe you're confusing it with..." <- That sounds accurate

21:59 <TeXitoi[m]> Error in core is very recent https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html#whats-in-1810-stable