<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?
<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]>
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
<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
<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...