ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
IlPalazzo-ojiisa has quit [Quit: Leaving.]
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
<haobogu[m]> <rustyboy[m]> "I am really curious if you could..." <- I added some docs about this topic. Checkout here: pin me pls if you have any problems with it
AtleoS has joined #rust-embedded
AtleoS has quit [Remote host closed the connection]
AtleoS has joined #rust-embedded
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
shashankx86[m] has joined #rust-embedded
ef has joined #rust-embedded
AtleoS has quit [Ping timeout: 255 seconds]
sourcebox[m] has joined #rust-embedded
<sourcebox[m]> Are you really sure that calibration works on the S3? I had to disable it completely because it lead to a large deadzone at the lower range. The bias value seemed either to be wrong or not respected at all.
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
Guest7282 has left #rust-embedded [Error from remote client]
ef has quit [Quit: ef]
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #rust-embedded
<diondokter[m]> Ugh, freaking binary size...
<diondokter[m]> Had two function/future instances of 800 bytes due to generics. So I replace it with `dyn` and now I have one instance of that function but it grew to 1200 bytes!
<diondokter[m]> Hard to see *why* it changes because the assembly of futures is nonsensical
Guest7282 has joined #rust-embedded
<diondokter[m]> Hmmm ah, seems like the outliner stopped outlining so all those got pulled in
<diondokter[m]> Heh, funny. `&&dyn Foo` takes up 60 bytes less than `&dyn Foo` :P
<diondokter[m]> I guess this is because it's fewer instructions to deal with a word vs two words everywhere?
<diondokter[m]> * bytes less flash than `&dyn
dirbaio[m] has joined #rust-embedded
<dirbaio[m]> dyn is pretty bad for code size
<dirbaio[m]> it prevents the compiler from inlining stuff
<dirbaio[m]> best is always to try to structure the code so it doesn't require dyn/generics in the first place .. 🥲
<diondokter[m]> It's a really small trait and all functions are present, so no deadcode to worry about at least
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]> I've found using processors with more memory than I'll ever need also solves the problem ;)
<diondokter[m]> Ha true
<diondokter[m]> XIP on Pi Pico can apparently handle 16MB :P
<dirbaio[m]> but it's sssssslow 🐌
<dirbaio[m]> it's not just dead code. inlining A into B often unlocks more optimizations that wouldn't be possible by optimizing A alone
<dirbaio[m]> becasue the compiler is optimizing A+B together, so it can "see" many more things
<diondokter[m]> Yes, that's true. But it prevents having multiple 800 byte instances of the function
<dirbaio[m]> yea
<dirbaio[m]> I mean it's expected that you get a single function, but bigger
<diondokter[m]> Ha, I could make it a crate feature :P
<diondokter[m]> You choose!
<JamesMunns[m]> what does your generic function look like? there's the "lil generic adapter that calls a non generic inner function"
<diondokter[m]> JamesMunns[m]: This is for sequential-storage. I take the user type that needs to be serialized to disk.
<diondokter[m]> Now, the difficult part is that I need to serialize it in the one user-provided buffer I have for that purpose and that happens in the middle of many other things.
<diondokter[m]> I'm not sure if I can do the serialization ahead of time... Maybe?
<diondokter[m]> diondokter[m]: > <> This is for sequential-storage. I take the user type that needs to be serialized to disk.... (full message at <>)
<dirbaio[m]> ahhh yeah that's the wost case ever for generics
<dirbaio[m]> take user-provided generic, pass it down layers of complex logic, then call the generic methods at the bottom? :P
<dirbaio[m]> causes all the complex logic to get duplicated
<diondokter[m]> Yep :P
<dirbaio[m]> why not work with `&[u8]` and leave de/ser to the user
<dirbaio[m]> * the user?
<diondokter[m]> dirbaio[m]: I've pondered that
<diondokter[m]> Idk
<diondokter[m]> I mean, I do for the queue already
<dirbaio[m]> I mean, the user is required to impl StorageItem themselves already, so you're already making de/ser their responsibility
<diondokter[m]> I'll try and let the binary size do the talking compared to the dyn trait I guess
<ryan-summers[m]> I mean, for sequential-storage, we're already required to impl the ser/de process into the trait
<ryan-summers[m]> yeah what dario said then
<diondokter[m]> True
<dirbaio[m]> haha yeah
<dirbaio[m]> unless there's some advantage in doing the serialization "deeper" in the stack? like, you can stream it to/from flash?
<dirbaio[m]> the trait doesn't seem to support that tho
<dirbaio[m]> I thought abut that for EKV, but decided not to because even if streaming would be nice you're not supposed to have big key/values
<dirbaio[m]> it's a key/value store, not a filesystem :P
<diondokter[m]> dirbaio[m]: If you do that however, the user needs to provide two data buffers though. One with the serialized data and one for me for doing potential data migrations with
<diondokter[m]> Right now I can do all this with one buffer
hyphened[m] has joined #rust-embedded
<hyphened[m]> Hi, sorry to bother.I'm trying to build the STM32F7 examples of embassy for the STM32F746 Nucleo board and it's crashing with a Hardfault right before jumping to the cortex_m_rt::main function. I've managed to get some debug info from GDB. The faulting code is here: and the GDB log is here:
<hyphened[m]> The pre-init function runs correctly, reaches the <main> symbol and moves the stack correctly. After that it tries to jump to the main function and goes to Hardfault handler
<hyphened[m]> And at that point I lose the stack frame, I can only find the HardfaulTrampoline and Hardfault functions
<hyphened[m]> If anybody can help I would appreciate it. I can provide all code and run things locally if needed
<hyphened[m]> Thanks in advance
<ryan-summers[m]> hyphened[m]: My best guess would be a linker-related issue if you're hard faulting. Sounds like code may not be getting put in the right location
<ryan-summers[m]> Are you selecting the correct device and memory map for it?
<hyphened[m]> I'm using the memory map of the embassy-stm32 crate, using the "stm32f746zg", "memory-x" feature flags
<hyphened[m]> Is this not enough? Are there more steps to do this correctly?
<ryan-summers[m]> Not sure, I don't use embassy. Maybe try the #embassy-rs channel
<haobogu[m]> Adding all listed features in embassy’s example folder worked for me. Maybe you can have a try:)
<diondokter[m]> Oh! I found a way to do the serialization up front! And it saves... 110 bytes...
<diondokter[m]> Well... That's not amazing. And looking at it, every part that is still generic takes up 140-ish bytes, so adding a third type would negate all wins...
<dirbaio[m]> disable the memory-x feature, and provide your own memory.x file
starblue has quit [Ping timeout: 256 seconds]
<hyphened[m]> <ryan-summers[m]> "Not sure, I don't use embassy..." <- Tried yesterday, no answer, so I thought to try here, I would post again but I don't want to spam the channels
<hyphened[m]> dirbaio[m]: Will try now, I'll report if it fixes it
<hyphened[m]> Thank you
starblue has joined #rust-embedded
<hyphened[m]> <dirbaio[m]> "disable the memory-x feature..." <- Reporting back: copied the `memory_1024_320.x` file from the `stm32f7xx-hal` repo and removed the DTCM and SRAM2 regions and it worked
<dirbaio[m]> thx for reporting back
<hyphened[m]> I see that the STM32F756ZG MCU which uses the same memory layout is already reported, should I report also this variant?? Or leave it be to not clutter the issue?
<ryan-summers[m]> Glad you got it working :)
<dirbaio[m]> please report yeah
<dirbaio[m]> the stm32 memory sizes need a lot of fixing 🫠
<dirbaio[m]> it sucks
<dirbaio[m]> I haven't found a reliable data source
<hyphened[m]> Thousand thanks BTW dirbaio ryan-summers
<dirbaio[m]> stm32 XMLs have "yep this MCU has 320kb of RAM"
<ryan-summers[m]> Yeah the SVDs are crap
<dirbaio[m]> it's not even the SVDs, stm32-data gets the data from the internal XMLs of stm32cubemx
<dirbaio[m]> but not even in those
<ryan-summers[m]> Oof. Does stm32cubemx keep their own internal patch registry too? lol
<dirbaio[m]> it says nowhere that those 320kb are actually 256kb of SRAM at address X and 64kb of TCM at address Y 😭
<dirbaio[m]> registers are from the SVDs, the stm32cubemx XMLs are for GPIO AF maps, DMA channel maps, interrupts...
<dirbaio[m]> and memory layout in theory 😭
<diondokter[m]> dirbaio[m]: Really weird how that company can function in practice
<dirbaio[m]> you can't even data-mine it from the C headers
<ryan-summers[m]> I was using MPLABx recently and the debugger threw an exception about a java thread executing some python auto-generated code to communicate with the DAP interface on the probe
<hyphened[m]> dirbaio[m]: Trial and error is the way with STM32
<dirbaio[m]> because the FLASH_SIZE/RAM_SIZE constants are actually macros that read the size from some OTP area
<ryan-summers[m]> So IDK what any of these companies are doing from a tech stack side. That just seems insane to me
ryan-summers[m] has quit [*.net *.split]
sajattack[m]1 has quit [*.net *.split]
GrantM11235[m] has quit [*.net *.split]
david[m] has quit [*.net *.split]
wyager[m] has quit [*.net *.split]
<vollbrecht[m]> <ryan-summers[m]> "So IDK what any of these..." <- simple answer, there business is hardware not software. so the software part is just attached somehow to every new platform.
<vollbrecht[m]> Fabless manufactures like nordic, espressiff directly shows that contrast here, where you not see so much insanity.
david[m] has joined #rust-embedded
ryan-summers[m] has joined #rust-embedded
wyager[m] has joined #rust-embedded
GrantM11235[m] has joined #rust-embedded
sajattack[m]1 has joined #rust-embedded
<dirbaio[m]> Nordic has their fair share of insanity
<dirbaio[m]> see the nrf70 driver 🤣
<diondokter[m]> dirbaio[m]: 😡
<dirbaio[m]> hehehe
<diondokter[m]> Got the c wrapper far enough where everything that needs to be done should be done and the interrupt should go off, but it never happens...
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded