<YuhanLin[m]>
The arm-app example has code size of 12.5 kB, but some of it is due to panic and formatting machinery and PartialEq impls. RAM usage is harder to gauge and depends entirely on what types are being generated, but the code generation is highly configurable. For example, you can customize the size of the generated int fields.
jakzale has quit [Server closed connection]
jakzale has joined #rust-embedded
_catircservices1 has quit [Server closed connection]
_catircservices1 has joined #rust-embedded
ello_ has quit [Server closed connection]
ello has joined #rust-embedded
hmw has quit [Server closed connection]
hmw has joined #rust-embedded
dav1d has quit [Server closed connection]
dav1d has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
<JamesMunns[m]>
yeah, I don't understand why it is ending up in BSS then, it pretty clearly should be in the uninit range
<JamesMunns[m]>
You aren't doing that inside of a function that is doing any sort of macro transform, right?
<diondokter[m]>
The only thing that's different is the extra unsafe cell in grounded
<diondokter[m]>
Nope, no macros
<diondokter[m]>
Wait, if I rename it and have it unused it does show in the uninit... what?
<JamesMunns[m]>
* you might need to mark it no_mangle, and maybe `pub`, for rustc/the linker to realize that the symbol needs to be visible outside the current binary
<JamesMunns[m]>
off the top of my head:
<JamesMunns[m]>
* The `.uninit` section in cortex-m-rt doesn't KEEP the symbols, which I've done for my manual code before
<diondokter[m]>
Yeah, it looks like some weird stuff is going on
<JamesMunns[m]>
It may be "optimizing" the use for you, I'd say try the pub + no mangle part, and see if that does the job
<diondokter[m]>
Nope
<diondokter[m]>
Doesn't work...
<diondokter[m]>
Ugh, ok just gotta keep trying combinations I guess
<JamesMunns[m]>
That's really bizarre, I don't know why the compiler would be disregarding your link section command
<diondokter[m]>
Yeah no idea either. Very annoying how this kinda thing is often so flaky
<JamesMunns[m]>
oh
<JamesMunns[m]>
it's not in bss, it's just nm being weird
<diondokter[m]>
Oh!
<JamesMunns[m]>
24008240 00000004 b cm7::BOOTLOADER_FLAG::hb56cde299cd38289
<JamesMunns[m]>
24008240 00000000 B __ebss
<JamesMunns[m]>
24008240 00000000 B __suninit
<diondokter[m]>
Ugh
<diondokter[m]>
Yeah
<JamesMunns[m]>
look at the addrs, they are all the same, just not sorted "right"
<diondokter[m]>
Man, it's done that before to me hahaha
<JamesMunns[m]>
:)
<diondokter[m]>
Ok, then I need to figure out why it's 0 at boot :P
<diondokter[m]>
Thanks for the help!@
<diondokter[m]>
s/!@/!/
<JamesMunns[m]>
when you say zero at boot: whatcha mean?
<JamesMunns[m]>
as in: you've set it, then rebooted, and the value got wiped?
<diondokter[m]>
Yep
<JamesMunns[m]>
It would be interesting to see the cargo-show-asm for that chunk of code, we should be able to see if it's being miscompiled
<diondokter[m]>
You mean where the flag is read?
<JamesMunns[m]>
and/or, you might need a compiler_fence prior to access to reading to poke the compiler into realizing that the value could have changed
<JamesMunns[m]>
diondokter[m]: yep
<JamesMunns[m]>
If the assembly is just like "lol load zero", then it's miscompiling. If it is reading that, then it's more interesting.
<diondokter[m]>
Sure, I'll try
<diondokter[m]>
Well both setting the flag and reading it look janky.
<diondokter[m]>
Like, they're not 100% incorrect, but it's weird. Lemme share
<dirbaio[m]>
matter runs on either wifi or 802.15.4/6lowpan
<diondokter[m]>
I thought there was matter for BLE too?
<JamesMunns[m]>
I think it's Thread for data, BLE for provisioning
<diondokter[m]>
Ah right
<dirbaio[m]>
not as "main" mode of operation. I tihnk for provisioning only yep
<JamesMunns[m]>
(where Thread is 802.15.4/6lowpan)
<diondokter[m]>
Just read that too
<dirbaio[m]>
and 802.15.4 is not something the softdevice does :P
<dirbaio[m]>
there's the 802.15.4 driver in nrf-hal but it's probably not complete enough for matter
<dirbaio[m]>
and there's 6lowpan support in smoltcp but again probably not complete enough
<dirbaio[m]>
and I dunno how easy it is to glue rs-matter to work on top of that :D
<JamesMunns[m]>
yeah. I had a client looking for stuff on nordic with Thread, trying to figure out if that's a reasonable thing to approach in Rust, or a huge science project
<dirbaio[m]>
because currently variables that are held across more than 1 await are never eligible for overlapping with other variables :D
<vollbrecht[m]>
vollbrecht[m]: ivmarkov is the absolute matter expert, so check out his work if you need to find anything with rust + matter
<diondokter[m]>
Whut
<dirbaio[m]>
yep 🤷
<dirbaio[m]>
but I have a new layout algo that does. it makes that future 1kb too 🦀
<diondokter[m]>
dirbaio[m]: As in something to PR to Rustc?
<dirbaio[m]>
yep :D
<diondokter[m]>
Ah cool!
<JamesMunns[m]>
btw diondokter, you can define a wrapper type if you need that aligns your flags to 8-byte alignment, then manually ensure the flags are a multiple of 8 if you write the whole thing
<diondokter[m]>
Please share the link once you post it. I'm curious :)
<dirbaio[m]>
also be careful if you try it. I still have a bug that overlaps things when it shouldn't 🥲
<dirbaio[m]>
dunno how to fix it without making it O(n^3) :(
<JamesMunns[m]>
is the n small, e.g. a single future body?
<dirbaio[m]>
amount of variables held across awaits
<dirbaio[m]>
* across awaits, in one async fn
jxsl has joined #rust-embedded
pflanze has quit [Server closed connection]
fooker has quit [Ping timeout: 256 seconds]
pflanze has joined #rust-embedded
whitequark[cis] has quit [Server closed connection]
whitequark[cis] has joined #rust-embedded
ello has quit [Read error: Connection reset by peer]
ello_ has joined #rust-embedded
bpye has quit [Server closed connection]
bpye has joined #rust-embedded
sauce has quit [Server closed connection]
sauce has joined #rust-embedded
jxsl has quit [Quit: Konversation terminated!]
jxsl has joined #rust-embedded
jxsl has quit [Client Quit]
jxsl has joined #rust-embedded
ruabmbua[m] has joined #rust-embedded
<ruabmbua[m]>
<dirbaio[m]> "amount of variables held..." <- A tool that shows an analysis of that would be great. Maybe I'll look into adding something to rust-analyzer
<ruabmbua[m]>
In General some kind of suspend point analysis
<dirbaio[m]>
you can see it with -Zprint-type-sizes
Ekho has quit [Server closed connection]
fooker has joined #rust-embedded
fooker has quit [Ping timeout: 246 seconds]
fooker has joined #rust-embedded
Ekho has joined #rust-embedded
limpkin has quit [Server closed connection]
limpkin has joined #rust-embedded
dne has quit [Server closed connection]
dne has joined #rust-embedded
agg has quit [Server closed connection]
agg has joined #rust-embedded
AlexandervanSaas has joined #rust-embedded
<AlexandervanSaas>
Does anyone here have experience with working with writing to a FAT32 formatted SD card in applications where power can be lost at any time? I know FAT is not power fail safe but I heard there are some tricks to avoid corrupting the file system. I'm struggling to find details on this though. I'm fine with some garbage data at the end of my file.
<dirbaio[m]>
yeah fat32 (and probably sdcards in general) are not the right tool for this
<dirbaio[m]>
I think these tricks are more "best-effort" than "guaranteed no corruption"
<AlexandervanSaas>
I have a arduino based serial logger that doesn't seem to encounter this problem
<AlexandervanSaas>
I'm struggling to understand what happens in the arduino library
tuxmix[m] has joined #rust-embedded
<tuxmix[m]>
It could some kind of bit flipping program in place to check for corrupted data and fix it from there
<AlexandervanSaas>
dirbaio[m]: How do commercial devices do this? I've lots of devices with SD cards that never corrupted.
<AlexandervanSaas>
* this? I've used lots of
<tuxmix[m]>
Probably some kind of error checking/fixing. Since data is just a bunch of binary information, you could send a batch of data and compare the results
<tuxmix[m]>
So if you send 8 bits that equal 10, but you check on the system and it equals 12, you know some error happened somewhere
<tuxmix[m]>
I haven’t done error validation myself though, and I’m going off some older knowledge. So I’m making some assumptions with this
<AlexandervanSaas>
Ensuring data integrity shouldn't be hard with a checksum but avoiding file system corruption is more difficult I think
<tuxmix[m]>
Yeah. Maybe some in memory cache? But that also could be tricky with embedded devices
<JamesMunns[m]>
Or: enough capacitance to flush any writes as soon as you notice the power is dying.
<AlexandervanSaas>
sounds risky
<JamesMunns[m]>
I'm all out of magic wands :)
<JamesMunns[m]>
(I have worked with a client that used a super cap for this, and to ensure a "disconnect" message was sent over the radio, it is viable, with the tight system design)
<JamesMunns[m]>
Super cap only gets you a couple of seconds, but that's a lot for sending packets and flushing to disk
<dirbaio[m]>
That you haven't seen corruption doesn't mean that lib is corruption-proof
<AlexandervanSaas>
That's true but when I used https://github.com/MabezDev/embedded-fatfs I got a corrupted file system every 2-3 power cycles so there must be some difference.
<dirbaio[m]>
Oof 😭
<dirbaio[m]>
Okay, maybe yes 🤣
danielb[m] has joined #rust-embedded
<danielb[m]>
i wonder if fixing this will result in spacebar heating ("i used fs corruption to check for blackouts")
<danielb[m]>
* spacebar heating reports ("i used
geky[m] has joined #rust-embedded
<geky[m]>
What an interesting puzzle
<geky[m]>
<AlexandervanSaas> "That's true but when I used..." <- Sorry if I'm intruding, but to second @dirbaio:matrix.org you can't make FAT power resilient without breaking compatibility. My guess is one of these is writing to metadata more often or keeps unflushed metadata pending longer and you're just being lucky (or unlucky)
<geky[m]>
If you think about how fast computers are vs how slow humans are, it's uncommon to actually experience corruption from pulling out an SD card, but it's always possible
<geky[m]>
Plus humans tend not to pull out SD cards when lights are blinking
Alistair[m] has joined #rust-embedded
<Alistair[m]>
I know you are looking for FAT, but if you just need to store data with power resilience you can use TicKV (https://crates.io/crates/tickv). It's power resilient, runs in embedded and stores data with a K/V store.
<Alistair[m]>
It won't help if you need to transfer the SD card to a PC though, but I thought I would give it a shout out :)