<re_irc>
<yruama_lairba> dirbaio: what is the stat of embassy ? Is there somme publication planned on crates.io ?
<re_irc>
<dirbaio> Soon™! The IO stuff was one of the blockers, it had some IO traits with some design issues previously
<re_irc>
<dirbaio> (and it makes sense to have them as a separate crate too)
<re_irc>
<yruama_lairba> i'm looking DMA-hal implementation of stm32f4xx-hal. There is no support for circular buffer DMA
<re_irc>
<yruama_lairba> i'd like to have decent DMA abstraction for a tricky thing I already implemented directly with pac, but with unsoundness.
<re_irc>
<yruama_lairba> i made works 2 circular DMA on same buffers for audio application with i2S
<re_irc>
<yruama_lairba> one DMA transfer filling buffer with adc DATA, the other transfer reading buffer to output audio on DAC, and in the middle, a piece of software processing the audio data
fabic has joined #rust-embedded
<re_irc>
<firefrommoonlight> The API I use:
<re_irc>
/// This struct is used to pass common (non-peripheral and non-use-specific) data when configuring
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
fabic has quit [Ping timeout: 260 seconds]
<re_irc>
<dngrs (spookyvision@github)> sigh, stm32+defmt+rtic, what could be going on? The only thing unusual I can see about this project is that I've put defmt's template "lib.rs" in a separate package so I can reuse it
<re_irc>
Error: An error with the usage of the probe occured
<re_irc>
Caused by:
<re_irc>
Operation timed out
<re_irc>
<dngrs (spookyvision@github)> (hardware is fine, I checked)
<re_irc>
<dngrs (spookyvision@github)> sigh, stm32f411+defmt+rtic, what could be going on? The only thing unusual I can see about this project is that I've put defmt's template "lib.rs" in a separate package so I can reuse it
<re_irc>
Error: An error with the usage of the probe occured
<re_irc>
Caused by:
<re_irc>
Operation timed out
<re_irc>
<newam> low power maybe? Messing around with low power is usually when I get that message.
<re_irc>
<dngrs (spookyvision@github)> different source code runs fine with this exact setup
<re_irc>
<dngrs (spookyvision@github)> I'll give it more oomph just to be extra sure
<re_irc>
<newam> I have also seen that with power supply issues
<re_irc>
<dngrs (spookyvision@github)> didn't help unfortunately
<re_irc>
<dngrs (spookyvision@github)> yeah it works when I move the defmt support back into the packagve
<re_irc>
<dngrs (spookyvision@github)> oh well, guess I can use symlinks if I don't want the duplication.
<re_irc>
<dirbaio> are you "use"ing the lib crate?
<re_irc>
<dirbaio> if not, it doesn't get linked so the defmt stuff won't be there
<re_irc>
<dirbaio> are you "use"ing the lib crate from the bin crate?
bjc has quit [Remote host closed the connection]
<re_irc>
<newam> does anyone have wear leveling code for flash storage? Not looking for a full FS, just need a non-volatile u64 and I want to extend the flash lifetime as much as possible.
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
<re_irc>
<thejpster> So what I would do is have a structure, containing a Tag (to ID the value you are storing), a Length (in case you don't understand the Tag), a Counter (goes up by one every time you write a given Tag), and a Value (of Length bytes). Keep writing these structs end to end. When you have completed a full Erase Page, defrag the block into a second erase page by keeping only the block with the highest counter for each tag....
<re_irc>
... Now append to that second page until full, when you defrag into the first.
<re_irc>
<thejpster> Spread across as many erase pages as you can afford. To find a value, it's a linear scan through all the data finding the highest count for each tag. You might want to cache that in RAM.
<re_irc>
<thejpster> Or, if you only have one value, and it's always a u64, and if your u64 is never 0xFFFF_FFFF_FFFF_FFFF, you can just keep writing it to consecutive addresses across as many erase pages as you have. To read back, it's the last non-FF value you read. You only need to erase a page just before you write to the first value in it.
<re_irc>
<thejpster> Writes are basically free (as you can only write to each byte in an erase page once), and it's just erases you are trying to avoid. The naive read-erase-write approach on the same erase page every time is not ideal - although a NOR flash might handle 100k erase cycles, so I mean, how often are you writing this value?
<re_irc>
<newam> every 15 minutes for the lifetime of the device, each page is only rated for 10k cycles though :/
<re_irc>
<newam> Actually 10k cycles with a 2048B page for a u64 is still 256k writes per page, doing that every 15 minutes is 73 years before the flash dies, and the flash is only rated for 30 years of service for code retention anyway
<re_irc>
<dngrs (spookyvision@github)> I'm running into more questionable problems here, beginning to suspect that the nightly I'm using might be a bit too nightly... will analyze more if I can find the energy
<re_irc>
<newam> dngrs (spookyvision@github): If it makes you feel better I just spent a day debugging a TCXO because I was resetting it after wakeup from standby :D
<re_irc>
<dngrs (spookyvision@github)> ouch
<re_irc>
<dngrs (spookyvision@github)> here I've been observing spurious panics when using erased pins, and right now it seems to me that I can't even change the the output state between low and high in an rtic task if I don't once do it in init (????)
<re_irc>
<newam> how does a pin panic? O_o
<re_irc>
<dngrs (spookyvision@github)> I know right
<re_irc>
<dngrs (spookyvision@github)> let's see if I can recreate the problem; it's all rather heisenbuggy