<vrakaslabs[m]>
<vrakaslabs[m]> "lifetime annotations are..." <- Out of curiosity, is the rule that
<vrakaslabs[m]>
> "the token borrows the device"
<vrakaslabs[m]>
enforced in the smoltcp api somehow, or is it just an expectation that implementations of phy::Device should specify that rule if needed?
<vrakaslabs[m]>
s///
<vrakaslabs[m]>
s///, s///
<vrakaslabs[m]>
s///
<vrakaslabs[m]>
* Out of curiosity, is the rule that
<vrakaslabs[m]>
enforced in the smoltcp api somehow, or is it just an expectation that implementations of phy::Device should specify that rule if needed?
<ryan-summers[m]>
<vrakaslabs[m]> "Out of curiosity, is the rule..." <- No, the tokens don't have to borrow the device, but that's what the lifetime specification allows you to do. Borrowing the device in the token makes it much simpler to i.e. perform a TX operation without a bunch of RefCells or data channels
sjm42[m] has quit [Quit: Idle timeout reached: 172800s]
duderonomy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<thejpster[m]>
what's the difference between embeddd-fatfs and embedded-sdmmc?
eldruin[m] has quit [Quit: Idle timeout reached: 172800s]
<mabez[m]>
thejpster[m]: embedded-fatfs is just fatfs + some helpers in the device module for block access and partitioning. It doesn't know anything about the sd/mmc protocols
<thejpster[m]>
is it async or blocking?
<mabez[m]>
and its async by default
<thejpster[m]>
oh, ok
<mabez[m]>
If someone wants a blocking API, they can PR it, but my only use is async at the moment
<thejpster[m]>
I can't think of a good way to make embedded-sdmmc async and non-async, so it isn't
<thejpster[m]>
But maybe there's an opportunity to have a crate defining all the FAT12, FAT16 and FAT32 structures and constants and so on.
<thejpster[m]>
Like, LFNs are the same no matter how you acquired the 512 byte directory block
<mabez[m]>
imo the "best" way to solve supporting async and blocking at the same time, is to write it for async first and then wrap the async interface with a blocking API that just uses block_on to run the futures
<mabez[m]>
Going the other way is pain 🥲
<diondokter[m]>
mabez[m]: Is there a good minimal block_on executor for embedded devices?
<mabez[m]>
Unless the lang team cook up some really nice keyword generic sauce, I don't see it improving
<thejpster[m]>
I'm not sure the value of sharing code between async and non-async binaries is worth of the pain of introducing async into an otherwise simple async binary
<diondokter[m]>
If you have a fully contained blocking wrapper, then it's probably only really the extra compile time and a little bit of executor overhead that you have to deal with
<thejpster[m]>
Like, async is very good for some use cases, but it's not free, and plenty of people were perfectly happy writing blocking Arduino C code on an Atmega
<thejpster[m]>
but an async FAT32 implementation needs an async block device trait.
<thejpster[m]>
So it all leaks out.
<diondokter[m]>
Yeah, that's true
<thejpster[m]>
(Can you even have async traits yet?)
<diondokter[m]>
Fair
<mabez[m]>
thejpster[m]: You're right, its not free. But paying that small cost means you don't have to write the whole thing twice :D
<diondokter[m]>
thejpster[m]: There's a PR since two days ago to stabilize it!
<thejpster[m]>
well apparently we wrote it twice anyway
<thejpster[m]>
so the only benefit to the pain is being able to throw one of them away
<thejpster[m]>
and I quite like mine because I wrote it
<thejpster[m]>
so maybe there's some middle ground where we try and pull out all the parsing things that don't involve reading or writing blocks.
<thejpster[m]>
or at least agree to some tests cases so we can try and ensure we're at least compatible with each other.
<mabez[m]>
There is a fork of embedded-sdmmc which adds async support, which I considered using: https://github.com/embassy-rs/embedded-sdmmc-rs, but based on the README (and it might have been out of date) it didn't look like it supported all of the FAT features I needed?
<mabez[m]>
I had already been using rust-fatfs in production for a number of years so I was confident in the fat implementation
<ryan-summers[m]>
diondokter: What was the flash-based storage database crate you wrote? I'm looking into using something like that for storing settings on Booster :) (broker hostname for MQTT, only have 64 bytes of EEPROM, so moving from IPs makes this no longer work)
<diondokter[m]>
Can be a bit slow depending on your flash speed
<diondokter[m]>
I should really add an option for caching
<diondokter[m]>
s/caching/indexing/
<ryan-summers[m]>
Awesome, thanks :) I think our idea is to take the second half of flash in these devices and just keep it for settings etc. since we're way below flash requirements. We don't need it to be fast, these settings only rarely get updated by the user
<ryan-summers[m]>
Ideally set the broker hostname like, only a few times for the life of the device tbh
<diondokter[m]>
Yeah sounds like a nice place to use the map datastructure!
<ryan-summers[m]>
So if you update a map entry, the old value still sits in flash, but gets passed over? Is that the general idea?
<diondokter[m]>
ryan-summers[m]: Yes the 'sequential' part of the name hints to the implementation. So yeah, old values still remain in flash
<diondokter[m]>
Only the most recent entry is returned
<ryan-summers[m]>
Heh, docs like this make me nervous " In principle you will never lose any data." Oh well, this looks very nice for our use case, cool idea
<diondokter[m]>
Well...
<diondokter[m]>
:P
<diondokter[m]>
That statement is factual :P
<ryan-summers[m]>
Factual if not lacking in confidence
<diondokter[m]>
I don't want to make a stronger claim because I've never run a fuzzer on it
<ryan-summers[m]>
Fair. In any case, it's pretty low impact on us if there's a bug so I'm not too worried
<diondokter[m]>
If you do find a problem, please let me know! We're using it in production code too :)
<ryan-summers[m]>
Yeah I figured as much. Will definitely open an issue if I see anything odd. Thanks for publishing this!
<diondokter[m]>
Also, there's an open issue on the project with some suggestions somebody made on how the crate could be further improved. Could be good to look through to see what might not be implemented right now
duderonomy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
yandrik[m] has joined #rust-embedded
<yandrik[m]>
Has anyone here any experience with nrf52 system_off mode and Rust? I think I've set up everything correctly, but it's just not working, and I have literally no idea why -.-
<yandrik[m]>
Am I missing something here? Or just doing something wrong? The system does actually shut off as far as I can tell, but doesn't react to the (hopefully) generated GPIOTE falling edge event
<yandrik[m]>
Except for while RTT is connected. While it logs, it sometimes reboots. But I don't know why or how that happens.
brazuca has quit [Quit: Client closed]
<yandrik[m]>
I've measured, the pullup at the button is still there, and the button does short it to ground, so it's electrically sound
<diondokter[m]>
I'm not familiar with softdevice...
<yandrik[m]>
It's the exact same system_off mode as without it
<yandrik[m]>
The softdevice call is just to allow graceful shutdown of bluetooth and such, but you can just nuke it by setting the register
<diondokter[m]>
Right, you could try to see if that works first
<diondokter[m]>
Just to make sure softdevice is not messing with your system
<yandrik[m]>
diondokter[m]: I saw it, it was very helpful, but unfortunately same problem
<yandrik[m]>
diondokter[m]: On it
<diondokter[m]>
Ok, strange, because it looks like you're setting the sense register fine and that's pretty much all you need
<dirbaio[m]>
the softdevice forbids access to POWER when enabled, you have to go through sd_power_system_off
<yandrik[m]>
interesting
<yandrik[m]>
because actually the opposite seems to be the case for my device for some reason
<yandrik[m]>
It works now. I've switched from sd_power_system_off to just writing the register bit
<yandrik[m]>
And that fixed it, somehow?
<dirbaio[m]>
the SD "enforces" you don't touch its reserved peripherals with the MWU
<diondokter[m]>
Is SD not yet initialized maybe?
<dirbaio[m]>
it doesn't actually prevent the peripheral access, it just fires an exception that the softdevice handles and throws an "assertion failed, you touched a peripheral you're not supposed to" at you
<yandrik[m]>
I see. Makes sense, and is the case. I get a Softdevice Assertion Failed exception. Somehow it still works tho
<yandrik[m]>
I have no idea why
<dirbaio[m]>
so it's possible that it still works if the register write causes entering system off before the MWU actually fires the irq
<dirbaio[m]>
but you're not supposed to do that
<JamesMunns[m]>
lol
<JamesMunns[m]>
HEY WAIT DON'T DO zzzzzzzz
<yandrik[m]>
That makes sense. I'd love to do it the right way, but somehow that just doesn't actually work here? It's wierd
<dirbaio[m]>
what happens with sd_power_system_off?
<dirbaio[m]>
it does go to sleep but never wakes up?
<yandrik[m]>
Exactly
<yandrik[m]>
Except for it sometimes does, when it's connected to RTT. But only then, for some reason
<JamesMunns[m]>
also note that RTIC prios and NVIC prios are inverse, IIRC
brazuca has joined #rust-embedded
<yandrik[m]>
JamesMunns[m]: exactly
dngrsspookyvisio has joined #rust-embedded
<dngrsspookyvisio>
aaargh
<yandrik[m]>
dngrsspookyvisio: Truly
<dirbaio[m]>
what prio are you calling sd_power_system_off from?
<yandrik[m]>
RTIC 5
<dirbaio[m]>
dirbaio[m]: > <@dirbaio:matrix.org> also note you can only do softdevice calls in priority levels 5-7 and thread mode
<dirbaio[m]>
> (becuase the SD handles them at priority 4)
<dirbaio[m]>
then you're violating this
<yandrik[m]>
oh. That makes a lot of sense then
<dirbaio[m]>
can call from rtic 3..0 only
<yandrik[m]>
My other code is partially incorrect then too. That's really good to know. But that somehow worked until now. Interesting.
<yandrik[m]>
actually scratch that, that's prio 3
<yandrik[m]>
But then the behavior makes sense. It somehow manages to kill part of the device (RTC), but then gets stuck in the infinite loop before the softdevice manages to shut the device down
GenTooMan has quit [Ping timeout: 240 seconds]
<yandrik[m]>
It works! Thank you so much for the help!
<yandrik[m]>
I've been ramming my head against that particular wall for a couple hours now, so having this working is really, reeeeally nice
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 245 seconds]
duderonomy has joined #rust-embedded
GenTooMan has joined #rust-embedded
d3zd3z[m] has quit [Quit: Idle timeout reached: 172800s]
<dngrsspookyvisio>
<yandrik[m]> "I've been ramming my head..." <- the joy of embedded 😬
<yandrik[m]>
But when it works, it's very cool indeed