<Lumpio->
Although that one's pretty cumbersome unless you're just storing a few small numbers
<Lumpio->
Do you want like a full filesystem?
<re_irc>
<K900> I don't want a full filesystem, but I do need to store a decent amount of data
<re_irc>
<K900> It's for a keyboard firmware
<re_irc>
<diondokter> K900: How often will it get updated? Like, usually STM claims 100K sector erases. Do you expect to hit that?
<re_irc>
<K900> Honestly I have no idea
<re_irc>
<K900> That's part of the problem
<re_irc>
<K900> I know I want to store some state when the computer is off, but I don't know how much it's going to be or how often it's actually going to change
<re_irc>
<diondokter> Well, what is the worst case update rate? Once a day?
<re_irc>
How long ought the keyboard work? 20 years?
<re_irc>
20x365=7300
<re_irc>
<K900> I mean I know it's probably fine, I was just wondering if there's an existing solution for it that's _good_ and not just _fine_
<re_irc>
<diondokter> Or in reverse, to get to 100K in 20 years you get 100000/20/365=13.7 sustained erases per day
<re_irc>
<K900> Also the keyboard has been running vendor firmware for now and I have no idea what it's writing or where or how much
<re_irc>
<K900> So I also just kinda want to be on the safe side
<re_irc>
<diondokter> I think you're fine. I don't know of any crates that do this. (Maybe a fun idea for you to do :P)
<re_irc>
An easy way to deal with this is to take multiple sectors and store an incremental number in your config.
<re_irc>
From that number you can see which sector has the most up-to-date version and it'll allow you to know what the next sector to write to is.
<re_irc>
<K900> Oh yeah I know how to do wear leveling
<re_irc>
<diondokter> I'd say there's probably no crate for it because it's pretty easy
dc740 has quit [Remote host closed the connection]
<re_irc>
<almindor> I'd rather not, at least until v1.0 is stable. Easier to just keep these in PRs and push pre-releases to crates.io. People who want to try them out can then just depend on the -alpha ones (like embedded-hal itself did)
<re_irc>
<almindor> the cfg code bloat would be quite ugly IMO
Guest14 has joined #rust-embedded
Guest14 is now known as brazuca
<re_irc>
<dirbaio> yeah but even when the final, stable 1.0 is out
<re_irc>
<dirbaio> * yeah, but even when the final, stable 1.0 is out, immediately dropping support for 0.2 is quite disrupive
<re_irc>
<dirbaio> * disruptive
<re_irc>
<dirbaio> because all drivers out there will still be on 0.2
<re_irc>
<dirbaio> * most
causal has joined #rust-embedded
<re_irc>
<almindor> oh no I'm all for feature gating then
<re_irc>
<almindor> just don't wanna keep it going over the alphas
<re_irc>
<almindor> easiest at that point would be to probably just take the new versions and put them into new subfolders/modules and just cfg the imports in the main lib
<re_irc>
<dirbaio> but yeah, another option is supporting 1.0 only, and telling users to use embedded-hal-compat to use drivers still on 0.2 ...
<re_irc>
<almindor> I'll see what disasm says at least for the riscv/riscv-rt. Once those are published I can publish the e310x*
<re_irc>
<disasm> almindor: Do we really need to publish releases for the whole chain of crates?
<re_irc>
<dirbaio> people who've used SPI slave mode: how is CS typically handled?
<re_irc>
<dirbaio> it seems to me you MUST make the HW handle it (ignore SCK pulses if CS is high)
<re_irc>
<dirbaio> because if you handle it in software, seems like it'd be too easy to do it too slow and lose data
<re_irc>
<disasm> Dunno, with SPI slave you can do SPI itself too slow and lose data, so you have to react on transaction start really quickly unless you have a weird fallback mechanism (like send zeros if MCU didn't provide data yet)
<re_irc>
<disasm> Usually you have time between CS low and the first SCK pulse
<re_irc>
<dirbaio> (assuming you do the data transfer with DMA)
<re_irc>
<dirbaio> like, if you initialize the SPI peripheral in slave mode with just SCK+MOSI+MISO pins then it'd always "react" to an SPI transaction even if it's not for us (on a shared bus, activity on SCK but CS is still high)
<re_irc>
<dirbaio> so with software-CS you'd have to manually have the CPU enable/disable the SPI on CS low/high, and you'd lose data if you do it too slow
<re_irc>
<dirbaio> so you pretty much always want hardware-CS with SPI slave mode (?)
<re_irc>
<disasm> Unless this SPI slave is the only device on the bus
<re_irc>
<disasm> But I agree, hardware-controlled CS makes a lot of sense in general
<re_irc>
<dirbaio> even if the bus is not shared, you still need CS to know when transactions start/end
<re_irc>
<almindor> disasm: this is more for the "let's check if things work while alpha" crowd I guess. We don't really need to publish the e310x but the riscv ones make it simpler to work on the hal crates
crabbedhaloablut has quit [Remote host closed the connection]
<re_irc>
<disasm> dirbaio: In theory, one can restart SPI after the rising CS edge, so no need to track the falling edge
crabbedhaloablut has joined #rust-embedded
<re_irc>
<almindor> dirbaio: I've only used hw for CS, seems finickey to do otherwise
<re_irc>
<disasm> almindor: TBH, I don't understand how alpha testing process is supposed to work. Because in general one can grab all the dependencies by git-references, but apparently releasing these versions is somehow more useful.
<re_irc>
<almindor> disasm: less dependencies in your workspace, otherwise as long as the code is somewhere sure, it's just a grab game
<re_irc>
<almindor> i'm ok with keeping it as just PRs, but [pre]releasing alphas on crates.io is cheap and saves a few headaches this way
crabbedhaloablut has quit [Write error: Connection reset by peer]
dc740 has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
smach has quit [Quit: Leaving]
smach has joined #rust-embedded
smach has quit [Remote host closed the connection]
<re_irc>
<dirbaio> hmm stm32f1xx-hal, stm32f4xx-hal, stm32l4xx-hal have SPI slave mode support, but no hardware CS
<re_irc>
<almindor> seems like a timing nightmare
<re_irc>
<dirbaio> (and they impl the embedded-hal spi master traits for the driver in slave mode!)
<re_irc>
<dirbaio> any examples of anyone using that successfully in the real world?
<re_irc>
<dirbaio> also, I guess as a user you'd want the API to give extra extra info about the transaction lengths? For example, if you start a transfer with 256-byte buffer but the master only sends 10 bytes (sets CS low, sends 10 bytes, sets CS high).
<re_irc>
<dirbaio> you'd want the transfer to return, saying "I got only 10 bytes", instead of hanging waiting for the other 246 bytes 🤔
<re_irc>
<dirbaio> (these HALs do right now hang like that)
<re_irc>
<dirbaio> fun
dc740 has quit [Remote host closed the connection]
crabbedhaloablut has quit [Remote host closed the connection]