02:30 <onkoe[m]> hey there! does anyone know if there's an on-going effort to get `avr-hal` working with `embedded-hal@1.0.0-r3`? i have a small library crate that i just ported to the new `embedded-hal` (since it's releasing soon), but i'd really like to test with my Arduino before i even commit + push the branch.

02:30 <onkoe[m]> as-is, the stable version of `avr-hal` uses the old `spi` implementation. however, with the new `embedded-hal`, i need an `SpiDevice` implementation instead!

02:30 <onkoe[m]> i have `embedded-hal-mock@0.10.0-rc.4` working just fine. however, i'd like to make sure it's all still good by testing it with real hardware :)

21:29 <barnabyw[m]> any opinions about exposing the chip feature list in embassy-stm32 as a collapsed <details> list in the docs? it’s slightly more work as (afaik) it’s not automatically generated and would be the longest such list, but prevents people from having to dig into a library Cargo.toml to find out if their chip is supported

22:02 <Noah[m]1> is anyone here using qemu on M1? I cannot even get it to boot a simple image :/

22:11 <thejpster[m]> M1 as in Apple Silicon?

22:12 <thejpster[m]> I use RISC-V QEMU and x86-64 QEMU on MacBook Pro quite a bit.

22:13 <diondokter[m]> Hey all, I need some opinions. I want to make `sequential-storage` support async.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/XTwxLdkWKMRnepuuYbhxRzsS>)

22:57 <JamesMunns[m]> you could do drop-panic bombs, at least for things that are not recoverable, however: a cancellation is no different than a cold-power off, right? Other than attempting to do more things later.

22:57 <JamesMunns[m]> Another option to force a recovery/consistency fix instead of panicking, basically blow an "aborted" flag, and don't clear it until you know you are in a consistent state

22:58 <JamesMunns[m]> (and definitely document "you should never cancel these futures, e.g. using select/etc")

22:59 <diondokter[m]> JamesMunns[m]: > <@jamesmunns:beeper.com> you could do drop-panic bombs, at least for things that are not recoverable, however: a cancellation is no different than a cold-power off, right? Other than attempting to do more things later.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/DEQxjPWFHTTLByqEZMcQqviC>)

23:00 <JamesMunns[m]> I mean a panic is just a very strong hint, that you hope people will find in dev :D

23:00 <diondokter[m]> Haha yeah

23:00 <diondokter[m]> Will be annoying though to wrap all futures in a panic-on-drop-future

23:01 <JamesMunns[m]> an alternative would be to design the format in a way that it was always deterministic to recover from a power loss, and blow the "unknown state" fuse on a cancellation

23:02 <JamesMunns[m]> yep

23:02 <JamesMunns[m]> diondokter[m]: yep

23:03 <JamesMunns[m]> JamesMunns[m]: I assume you would need to partially skip OR erase some segment, if you notice on cold-boot or after-cancellation that the state is inconsistent

23:03 <dirbaio[m]> A write cancel is kinda the same as an unclean poweroff during a write 

23:04 <dirbaio[m]> So you might be already handling that fine? 

23:04 <JamesMunns[m]> yeah, the issue is you EXPECT potential incomplete actions at boot, and (currently) do not expect it at "steady state"

23:04 <dirbaio[m]> Yeah! In ekv I solved this with a "dirty" flag 

23:04 <JamesMunns[m]> so if you maintain any state between writes/erases/whatever, it may be inconsistent depending on how you do async/carry state

23:04 <diondokter[m]> Currently it tries its best, but at some point it will tell you that it's corrupted

23:05 <dirbaio[m]> When starting an op, set dirty=true. When finish, set dirty=false. If when doing an op you see dorty=true, do the same "cleanup/recover" you'd do on boot 

23:05 <PeterHansen[m]> diondokter: I have fairly sophisticated flash "logging" filesystem code which is robust in the face of cancellations, crashes, or power failures. It mainly works by always writing a sector/page/record header with at least one "magic" bit still set, then other data, then goes back and clears the magic bit(s) to finalize the sector/page/record. Not sure if you're already doing something similar, but it's possible to make it

23:05 <PeterHansen[m]> completely bomb-proof if you take an approach like that.

23:06 <JamesMunns[m]> diondokter[m]: you should never lose EVERYTHING on a power loss, right? unless you just erased everything? like you might lose the current segment, but does it not recover from that?

23:06 <JamesMunns[m]> PeterHansen[m]: I'm interested to know how reliable you've found multiple writes to the same bytes across flash hardware

23:06 <dirbaio[m]> Yeah I'd expect an unclean poweroff to maybe write or maybe not, but not trash the whole thing 

23:07 <JamesMunns[m]> In theory it seems possible, I've always been to chicken to do it in fear of not being portable

23:07 <JamesMunns[m]> s/to/too/

23:08 <diondokter[m]> If an item header is fully written, things should be generally ok

23:08 <diondokter[m]> Hmmm, I'd have to test all invariants though. And those quickly multiply when any write or erase can be partial

23:10 <PeterHansen[m]> I've never found any of these sorts of flash (either the fancy external serial flash like QSPI stuff, or the flash inside embedded chips) to have a problem with writing repeatedly to one byte, provided of course you're only ever clearing bits. I never assume that any write will be atomic, however, just that bits will only ever go from 1 to 0 except during an erase. I do also implicitly assume that during an erase I will not

23:10 <PeterHansen[m]> likely ever encounter a partial erase state where only random bits are turned back into 1 while others are left as 0. I could imagine that happening, but since erase is on a sector by sector basis at a minimum, I just pretend I never thought of that... and don't ever expect to see it.

23:10 <PeterHansen[m]> I know some of the parts explicitly document you can write repeatedly, provided you don't expect to turn 0s into 1s.

23:11 <diondokter[m]> Thanks to lulf the project now has fuzzing, so I could add a random partial-write chance to the mock flash. The fuzzer should be able to find faults...

23:11 <JamesMunns[m]> PeterHansen[m]: most manuals I've seen (for external flash) don't mention it, and nrf's internal flash specifically says something like "N writes per page per erase" or something fear inducing like that

23:11 <diondokter[m]> STML4 has a check in hardware where on the second write, all bits have to be 0

23:12 <PeterHansen[m]> For appending records within a sector, for example, my header will include a record type value and a record length, and an "open" bit that is left 1. Then the data can be written separately, and then when it's fully written I go back to clear the "open" bit, so a 0 means "closed" or "final". On reboot, I have to scan all open sectors to find possibly unclosed records (skipping past all closed records), then possibly recover,

23:12 <PeterHansen[m]> or invalidate (e.g. write type field to 0), or possibly leave it invalid but go back to "close" the sector so no more appending is possible, then open a new one.

23:13 <JamesMunns[m]> diondokter[m]: fwiw: you could probably make this exhaustive for all tests: make one pass that counts how many steps there are, add a "fuel bar" to your simulator, and iterate from 1..N and see if you can recover at that point.

23:13 <PeterHansen[m]> James Munns: I know they may have a limit, but generally I'm only ever writing twice per byte.

23:14 <JamesMunns[m]> likely a single functional test is doing less than a few hundred writes per test, so you could just clone + check the whole flash from a cold boot to see what it says

23:14 <diondokter[m]> PeterHansen[m]: I do have CRC protection of the length and the data, so it may work pretty well already

23:15 <diondokter[m]> JamesMunns[m]: In my crate, every call is as if it cold-boots

23:15 <JamesMunns[m]> Also diondokter something that was handy for me recently was using `insta` with my mocked flash code, and writing a little "flash to hexdump" that skips all never-touched bytes

23:16 <JamesMunns[m]> tho if you have more detailed tests, insta/snapshot testing may be less valuable and more noisy

23:16 <diondokter[m]> JamesMunns[m]: Cool, I'll check it out!

23:16 <JamesMunns[m]> it's useful for telling if you accidentally made some format/determinism change tho :D

23:17 <JamesMunns[m]> (originally I WASN'T skipping untouched parts, and realized very quickly I was committing multi-megabyte text files because my mocked flash was 1M... whoops)

23:18 <PeterHansen[m]> So yeah, that explicitly allows doing what I'm doing, provided you are never trying to append less than basically one word at a time.

23:18 <PeterHansen[m]> Except I don't use internal flash as data, so far, for nRF...

23:19 <JamesMunns[m]> PeterHansen[m]: yeah, on most chips, internal flash is so painful to use at runtime, it's not worth it

23:19 <JamesMunns[m]> for like rare calibration/config data where you're fine with rebooting afterwards and/or basically stalling the whole system, it's okay.

23:20 <JamesMunns[m]> tho nordic does have the funny "stall for N milliseconds at a time" flash peripheral helper lol

23:21 <JamesMunns[m]> so you can choose how long you want your system to be unresponsive for when erasing/writing on-chip flash data

23:24 <PeterHansen[m]> Yeah, the most we've done is allowed the old C SDK to use 3 sectors for writing BLE encryption keys, but that's all Nordic's code so I just let it do whatever it did. With Rust we're doing that in external flash with the rest of the data. Also used UICR for factory settings but we'll move away from that now with the new APPROTECT junk getting in the way of doing that.

23:27 <PeterHansen[m]> James Munns: I would take Nordic's "two writes max per word between erases" to be explicit permission to do that rather than something meant to instill fear of doing even 2. I don't know what technical reason would make them not allow more, but I would guess they know that this sort of "dirty" bit thing is such a strong use case that they knew they had to support more than 1.

23:28 <JamesMunns[m]> Yeah, that's fair, the snippet you posted was more concise/clear than I remembered. I do appreciate them specifying it, the fear is more "oh god are all the other datasheets just incomplete on this topic?"

23:28 <PeterHansen[m]> true

23:28 <diondokter[m]> PeterHansen[m]: We've been doing 2 writes on the nrf91 and it's never gone wrong so far

23:28 <diondokter[m]> STM also explicitly allows it as long as the second write is all 0

23:29 <PeterHansen[m]> I can only say I haven't had a problem with this across tens of thousands of consumer devices doing this all day long for small bits of data (appending 4-100 bytes at a time, many times a day).

23:29 <PeterHansen[m]> but not in the nRF flash... definitely external

23:29 <PeterHansen[m]> diondokter: Ew, yuck... that would be so annoying.

23:29 <JamesMunns[m]> it's like when a food has a label that's like "contains no X!", and you're like, "wait, is that marketing, or does all other food like that contain X?"

23:30 <diondokter[m]> PeterHansen[m]: Yeah, it reports it as an error if it's not. But at least it's hardware-checked

23:30 <PeterHansen[m]> I guess it would just force me to reserve an entire word as the "dirty" flag. :(

23:31 <diondokter[m]> JamesMunns[m]: In Dutch supermarkets, the vegan label now gets put on everything. Like ok, thanks for letting me know this bag of vegetables is vegan...

23:31 <PeterHansen[m]> Which I guess is always an option too, of course... as long as you can spare the wasted space, I guess that's guaranteed safe.

23:33 <JamesMunns[m]> diondokter[m]: I was gunna make the same comment about "gluten free", because sometimes I see that on silly stuff that definitely never contains gluten.

23:33 <JamesMunns[m]> But hey, mcdonalds fries used beef tallow for a long time, which made some religious + vegetarian/vegan people fairly mad when they found out

23:34 <JamesMunns[m]> so, yes its a silly label, but also I wouldn't put it past a company to put whatever filler on things. Maybe a bag of broccoli is simple enough for that :D

23:34 <M9names[m]> diondokter[m]: You do want advance warning when your veg gets a taste for meat 😋

23:34 <PeterHansen[m]> As someone with a celiac daughter, I appreciate anything that explicitly says "no wheat". After all, it turns out even some spices and herbs toss in some wheat, apparently to absorb moisture.

23:35 <JamesMunns[m]> yeah, exactly. I have friends/family with allergies, and it's no joke. like "cooked on the same pan that was used to cook with shellfish" was enough to send my mom to the hospital, so I totally do appreciate those notices.

23:58 <kpcyrd[m]> In case somebody is going to be at 37c3, I'm going to be looking for somebody to implement embedded_hal::blocking::i2c::{Read, Write, WriteRead} with for an attiny85 :) I'm going to bring digisparks to develop with. I think one of the c3's was when I first ran into Rust for embedded, but only picked it up a few years later.