ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
<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]
cr1901 has joined #rust-embedded
inara has quit [Server closed connection]
inara has joined #rust-embedded
diondokter[m] has joined #rust-embedded
<diondokter[m]> Hi James Munns, I'm trying to use grounded.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/XMuBUewQiqBuWOijdUJlrJzw>)
JamesMunns[m] has joined #rust-embedded
<JamesMunns[m]> hmm, let me check the c-m-rt linker script. I don't usually use .uninit, I usually define my own section...
<diondokter[m]> Already had it open :P
<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
<diondokter[m]> It loads everything in 16-bit chunks. And part of r1 is loaded before the critical section starts?
<diondokter[m]> Same thing with reading it. The lower part of r1 is loaded before the critical section.
<diondokter[m]> It's not really *wrong*, but I feel something is being weird
<JamesMunns[m]> it's moving the address mixed with the critical section, which is weird but fine imo
<JamesMunns[m]> it's setting the value within the critical section
<diondokter[m]> Yeah
<diondokter[m]> Ok, good
dirbaio[m] has joined #rust-embedded
<dirbaio[m]> That's fine, it's only reg operations so it's not visible from the "outside". The compiler is allowed to reorder stuff like that
<diondokter[m]> Well in that case the assembly looks fine IMO
<JamesMunns[m]> What about the read side?
<diondokter[m]> The read in there always reads 0 if I set it with the previous function
<diondokter[m]> volatile operations don't help
<dirbaio[m]> Is this stm32h7?
<diondokter[m]> Yeah
<dirbaio[m]> Hahahaha
<diondokter[m]> To jump to the built-in bootloader
<diondokter[m]> Oh no
<diondokter[m]> dirbaio[m]: I don't like this
<diondokter[m]> :P
<dirbaio[m]> I think I know what it is
<dirbaio[m]> stm32h7 does ram ecc by 64bit words
<dirbaio[m]> so when you write a 32bit word it "buffers" it just in case you write the 2nd 32bit word so it can calc the ecc at once
<dirbaio[m]> or something like that
<diondokter[m]> Oh man
<JamesMunns[m]> oh no lol
<dirbaio[m]> or if you write to some other random 32bit word then it "flushes" that buffer
<dirbaio[m]> BUT
<dirbaio[m]> it won't flush it before sys_reset
<diondokter[m]> It seems to work if I make it u64 🙈
<dirbaio[m]> so the last word you write before reset might be lost
<JamesMunns[m]> diondokter[m]: Time to write some spooky comments :D
<diondokter[m]> That's awful
<diondokter[m]> Even for volatile!
<dirbaio[m]> yeah it's the hardware that loses your write
<dirbaio[m]> very fun
<JamesMunns[m]> is there a way to manually "flush"? Or just do a dummy write elsewhere to force it?
<diondokter[m]> This is probably even different for each of the different RAMs
<dirbaio[m]> dummy write elsewhere should always flush it yep
<dirbaio[m]> I ran into this with teleprobe
<dirbaio[m]> very annoying
<dirbaio[m]> I'd write the binary to RAM, then reset to run it. it'd lose the last written word :D
<JamesMunns[m]> I'm glad you chimed in dirbaio, there's 0% chance I would have been able to figure that out lol
<diondokter[m]> Haha yeah definitely. Thanks!
<dirbaio[m]> i'm not sure if u64 is guaranteed to flush always. maybe it does as long as it's aligned
<dirbaio[m]> dummy write elsewhere definitely does
<diondokter[m]> Ok, I'll try do that
<JamesMunns[m]> Is there anything for Matter on the nrf52, btw?
<JamesMunns[m]> I'm guessing it's new enough it's only in the nordic + zephyr code, not anything the softdevice can do?
<JamesMunns[m]> https://github.com/project-chip/rs-matter seems to be for the esp32 family
<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
wassasin[m] has joined #rust-embedded
<wassasin[m]> bjoernQ started https://github.com/bjoernQ/bare-matter/tree/main a while back
<dirbaio[m]> nrf's C driver is opensource and independent from Zephyr tho https://github.com/nrfconnect/sdk-nrfxlib/tree/main/nrf_802154
<diondokter[m]> <dirbaio[m]> "dummy write elsewhere definitely..." <- Seems not to be true sadly.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/LOMDVaQcEcFTAvtZfFXfSgLo>)
<JamesMunns[m]> Interesting, so that'd be something you could bind to, sort of like the nrf-modem stuff (but on one core?)
<dirbaio[m]> maybe
<dirbaio[m]> but that's just 1 layer of the stack, you still need 6lowpan and matter 🫠
<dirbaio[m]> diondokter[m]: > <@diondokter:matrix.org> Seems not to be true sadly.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/RJEOvxgqrZTmkjvGFybNLApW>)
<diondokter[m]> Smoltcp has some 6lowpan support. But I don't know how well it works
<diondokter[m]> dirbaio[m]: Yeah, I've only got the axiram
<JamesMunns[m]> yep, all fair. Client didn't specifically mention Rust, but I'm not generally taking non-primarily-Rust gigs these days
<dirbaio[m]> diondokter[m]: no idea then 🥲
<dirbaio[m]> JamesMunns[m]: Rust or bust! 🦀
<dirbaio[m]> lol so I just realized
<dirbaio[m]> drop(x) does nothing. it copies x then drops the copy
<diondokter[m]> Oh no lol
<dirbaio[m]> there's a warning telling you "drop on Copy things does nothing, do let _ = x instead"
<dirbaio[m]> but that also copies then drops the copy. wtf?
<dirbaio[m]> so that's why that code both xs live until the end. so that future is 2kb, not 1kb
<diondokter[m]> Probably only solved with a newtype that doesn't impl Copy then
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]> <JamesMunns[m]> "Is there anything for Matter..." <- did you had a look at [rs-matter-stack](https://github.com/ivmarkov/rs-matter-stack?tab=readme-ov-file#the-examples-are-std-only) while info hunting? It's core is no-std + no_alloc so could be handeld on a wider range, though testing and running currently only is done on esp's
<dirbaio[m]> only way to "force early drop" Copy stuff is {}
<diondokter[m]> Making large arrays Copy was a mistake probably
<dirbaio[m]> or newtype yeah
<dirbaio[m]> meh
<JamesMunns[m]> or a much larger "eager drop" of copy + non ptr-escaped items :p
<vollbrecht[m]> * did you had a look at [rs-matter-stack](https://github.com/ivmarkov/rs-matter-stack?tab=readme-ov-file#the-examples-are-std-only) while info hunting? It's core is no-std + no\_alloc so could be handeld on a wider range of devices, though testing and running currently only is done on esp's
<JamesMunns[m]> vollbrecht[m]: thanks! Haven't looked deeply at anything yet, honestly!
<dirbaio[m]> so with current rust, that async fn is 1kb
<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]> tried it on company's firmware
<dirbaio[m]> and
<dirbaio[m]> ...
<dirbaio[m]> it saves a whopping 100 bytes of ram "|
<dirbaio[m]> s/"|/:|/
<diondokter[m]> Haha
<diondokter[m]> How did you measure ram usage?
<dirbaio[m]> size of bss, futures are statically allocated
<diondokter[m]> Yeah ok
<diondokter[m]> I can try with my sequential-storage example to see if there's differences there
<dirbaio[m]> i'm not sure if it's because these "bad" patterns for the old algo are rare in pracrice
<dirbaio[m]> like
<dirbaio[m]> "two variables, that don't overlap, and that are held across more than 1 await points" can be rare yeah..
<dirbaio[m]> or it's this "Copy things live for too long" stuff
<dirbaio[m]> it's annoying because compilation goes like "build MIR, then do the coroutine transform on it, then optimize"
<dirbaio[m]> there's like zero optimization before doing the coroutine transform
<dirbaio[m]> and once the coroutine transform is done, the fields in the future struct are "set in stone", they can't be optimized anymore
<dirbaio[m]> for example these big arrays in the snippets above are completely unused
<dirbaio[m]> they could be completely optimized out
<dirbaio[m]> but they aren't "|
<dirbaio[m]> * but they aren't :|
<diondokter[m]> <dirbaio[m]> "it saves a whopping 100 bytes of..." <- I'm seeing way more! And saves some text too
<dirbaio[m]> most of the savings are from https://github.com/rust-lang/rust/pull/127522, not from my changes
<dirbaio[m]> (i'm building on top of that pr)
<diondokter[m]> Ah check
<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
<AlexandervanSaas> I think the answer is hiding somewhere in this arduino library: https://github.com/greiman/SdFat
<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 :)