<timokrgr[m]>
<jannic[m]> "https://media.ccc.de/v/camp2023-..."; <- very nice talk, reminds me of the stuff oxidecomputer is doing with humility and probe-rs
vancz_ has joined #rust-embedded
vancz has quit [*.net *.split]
jsolano has quit [*.net *.split]
jsolano has joined #rust-embedded
<Noah[m]>
<CHMchmousset[m]> "you can always request funding..." <- > <@chmousset:matrix.org> you can always request funding from NLNet https://nlnet.nl/propose/
<Noah[m]>
the problem with grants is basically that you are constantly applying for grants with no guaranteed outcome :)
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
badrb[m] has joined #rust-embedded
<badrb[m]>
Hey, do you happen to know of any library that can turn a unique ID into a hash that humans can easily read?
<badrb[m]>
I need it for my project where I want to generate a user-friendly version of my 64-bit unique ID from my MCU. This will make it easier to provide support out in the field.
<Ablu[m]>
@badrb: if random letters are ok, maybe just use base32?
<badrb[m]>
Ablu[m]: I was thinking something shorter and easier to read. https://github.com/bryanmylee/zoo-ids like `FineAntiqueElk` or `pertinentPoshGoldfinch` would be ideal, but what sqids generates `Swd2Mt4u` or `Cj7uZaIi` might work too.
<Ablu[m]>
I stole the docker constainer name generation names once and hashed into those, but I do not know any off-the-shelve crates to do this.
<JamesMunns[m]>
but you could have a global asm __pre_init symbol and not use the macro
<dirbaio[m]>
yeah... the docs should show how to do that
<dirbaio[m]>
and perhaps entirely remove the macro because there's no way to use it soundly?
<dirbaio[m]>
perhaps using it with a naked fn is sound?
<dirbaio[m]>
or a regular fn if the ONLY thing inside it is an asm!? I don't think so because the compielr can insert accesses to statics in function prologue/epilogue, like canary stack checks
<JamesMunns[m]>
idk, imo "using rust at all before the environment is fully set up" is pretty questionable
<JamesMunns[m]>
like it might be more likely to work, but still not really sound
<dirbaio[m]>
yeah...
dygear[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
idk much about what you're doing diondokter, I've always used "extra ram areas" as uninit (for like buffers and buffer descriptors), there might be a way to do that at runtime, making something like static cell with an unsafe constructor instead (where you init and get back an `&'static mut` you can use for stuff
<JamesMunns[m]>
(if writing your own pre_init is less desired)
<JamesMunns[m]>
but yeah, cmrt really only covers the basics of section init as-is
IlPalazzo-ojiisa has joined #rust-embedded
<diondokter[m]>
Yeah well, we have a lot of large queues and other data that needs to go in axis ram and the project is already quite complex. I'd rather add a small boot thing than force everything to manually initialize
<JamesMunns[m]>
but treat that as "a different approach"/"a workaround" rather than "the right way"
<JamesMunns[m]>
gotcha!
<diondokter[m]>
Only question I have left is how to differ between the .data and .bss? Normally the compiler does this for you, but I guess I'm gonna need to let people specify it on the data itself?
<JamesMunns[m]>
yeah, I don't think there's a way to get automatic splitting
<diondokter[m]>
Right. That's ok I guess
<diondokter[m]>
But it does suck a bit that the ergonomics get so much worse
<JamesMunns[m]>
JamesMunns[m]: (could be wrong, I don't know all of the linker Dark Magic, but the compiler automatically places .data or .bss, but once you specify a region, it just takes that as-is afaik)
<JamesMunns[m]>
what sorta data are you initializing it with? you could ensure that all structures have a zero init, which would make it easier
<JamesMunns[m]>
but I imagine you have two regions for a reason :)
<diondokter[m]>
Rust has done a lot of good work on the compiler and language side. But it feels like there's space for a radically new linker. But there's no glory to be gotten there :P
<JamesMunns[m]>
tbf: that's a "compiler problem" not a linker problem
<JamesMunns[m]>
compiler picks the sections, linker fills them
<dirbaio[m]>
the linker is cuuuuuuursed
<diondokter[m]>
JamesMunns[m]: One of the problems is that you get no protection from Rust. You don't need to use unsafe and yet you could have a NonNullPtr be 0 if you place it in BSS
<JamesMunns[m]>
(basically: compiler picks/fills the section "buckets", linker empties the buckets and places them in the regions you specify)
<JamesMunns[m]>
diondokter[m]: totally fair! OR if you have the flash/the ram region is small, you could go the other way and make it all data
<diondokter[m]>
Ok, well more accurately, the section model could maybe be revolutionized
<JamesMunns[m]>
yeah, don't let me discourage you from thinking "things could be better", because I totally agree with that :)
<JamesMunns[m]>
maybe propose a new link_section_prefix attribute? :p
<JamesMunns[m]>
so you get .PREFIX.data
<diondokter[m]>
Haha well I've got a colleague who's way deeper into compilers and it's always fun to provoke him into a (often weirdly nuanced) rant about current compilers and linkers
<diondokter[m]>
ryan-summers[m]: Yeah I took a look what you guys did with the memory.x because I remembered you
<ryan-summers[m]>
So it's like our own pre-init, but basically there's just uninitialized memory after we call main()
<diondokter[m]>
* remembered you're on stm32h7 too
<diondokter[m]>
Is it that much faster?
<ryan-summers[m]>
Its not a great solution, but it works
<ryan-summers[m]>
ITCM is way faster
<diondokter[m]>
Could be fun to try at some point haha
<ryan-summers[m]>
I think we put our DSP routines in it and do RAM functions to make it super fast
<ryan-summers[m]>
We had issues where the startup was failing because the cache was cold, so we manually put all the funcs in ITCM so we didn't have to worry about cache
<JamesMunns[m]>
any issues with "oops called a rust intrinsic outside of RAM, cache miss"?
<ryan-summers[m]>
Not that I'm aware of. It's not the end of the world if we have a few inst outside of cache
<JamesMunns[m]>
(that's the other usual issue I've seen with ramfuncs, you can't really recursively guarantee ALL instrs live there, esp with intrinsics)
<JamesMunns[m]>
yeah, for "just" perf, probably measurably "good enough" :)
<ryan-summers[m]>
We did have to manually go through the call chain for the DSP stuff and mark it specifically though
<JamesMunns[m]>
bigger deal when you like, disable the flash for a bit and WANT to be running all RAM lol
<JamesMunns[m]>
usually it's like "oops that got optimized to memcpy, guess where that lives!"
<ryan-summers[m]>
Yeah, that's a bigger issue. Rust intrinsics would definitely bite you there
<JamesMunns[m]>
(only way I know to fix that is to make a "separate binary" you load into ram, sorta like a dylib/ROM table, but then FFI and sadness)
M9names[m] has joined #rust-embedded
<M9names[m]>
hmm, speaking of such things: i managed to get linker errors the other day trying to put some C code in ram, and call it from rust.
<M9names[m]>
precisely because it was trying to call intrinsics that were too far away from the caller.
<JamesMunns[m]>
oof, which target? it's been a while since I had to think about trampolines/veneers
<ryan-summers[m]>
Why would the C code call rust intrinsics?
<M9names[m]>
cortex-m0. ah, maybe intrinsics is the wrong word (i'm tired)
<M9names[m]>
it was tripping up on memcpy and friends
<M9names[m]>
so i guess just the libc stuff that compiler-builtins or cc bundles?
<diondokter[m]>
Oh, here's a fun one too. If you do #[link_section = ".name.with.typo"], then the compiler nor the linker will complain
<diondokter[m]>
It works!
<diondokter[m]>
Thanks James Munns and dirbaio :D
<diondokter[m]>
Now let's see what the team thinks of this and if it survives the PR review haha
<JamesMunns[m]>
yeah, there's multiple "intrinsics", another overloaded word :)
<JamesMunns[m]>
but yeah there's two ways to call in arm, one with shorter range, looks like the compiler picked the shorter one (because that's all it could see/covers all of flash) when you really needed the longer one (to jump between flash/ram)
<JamesMunns[m]>
so: I don't know how to fix that, but the problem makes sense :p
M9names[m]1 has joined #rust-embedded
<M9names[m]1>
I've solved in the past by tell the compiler to use a different code model, don't think I've ever done it for cortex-m though...
<M9names[m]1>
It would probably hurt code perf enough to not make it worthwhile anyway
<JamesMunns[m]>
but yeah, if you CAN'T recompile/force your staticlib to use long range jumps, the only other answer is a thunk/trampoline/veneer, which I thought the compiler should generate (short jump to something that long jumps), but dunno how to force it to do that
<dirbaio[m]>
I think it's the linker that has to generate them?
<JamesMunns[m]>
yeah
<JamesMunns[m]>
you're right, I said compiler but the linker is supposed to insert thunks
<dirbaio[m]>
which is cuuuuursed :D
<dirbaio[m]>
linker doing compiler things
<JamesMunns[m]>
9names any chance you are compiling one of them with GCC's LD and the other with LLVM's LLD?
<JamesMunns[m]>
like, the staticlib with gcc, then compiling rust and linking with lld? maybe one linker isn't picking up what the other put down, and maybe you could try using the same compiler/linker for both?
<JamesMunns[m]>
(well, same linker I guess, clang+rustc + lld, or gcc+rustc + ld)
<M9names[m]1>
C compiled with GCC via cc-rs. Same issue when linking with ld or lld.
<M9names[m]1>
Didn't get to testing with clang yet...
crabbedhaloablut has quit [Ping timeout: 258 seconds]
crabbedhaloablut has joined #rust-embedded
danielb[m] has quit [Quit: Idle timeout reached: 172800s]
Darius has quit [Ping timeout: 244 seconds]
Darius has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Killed (NickServ (GHOST command used by cr1901_!~cr1901@2601:8d:8600:226:6712:3a8e:7f64:543a))]
cr1901_ is now known as cr1901
<badrb[m]>
<Ablu[m]> "I searched "rust human hash..." <- Argh, because of `getrandom` dep of uuid with v4 feature enabled, this doesn't compile for `thumbv7em-none-eabihf`
<jessebraham[m]>
Looks like a release never got created for 1.0.0-rc.1 on the embedded-hal repo, by the way
crabbedhaloablut has quit []
nex8192 has left #rust-embedded [Error from remote client]
nex8192 has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 246 seconds]
cr1901__ has joined #rust-embedded
cr1901__ has quit [Read error: Connection reset by peer]
cr1901__ has joined #rust-embedded
cr1901_ has quit [Ping timeout: 246 seconds]
cr1901__ is now known as cr1901
Dr_Who has quit [Read error: Connection reset by peer]
cr1901_ has joined #rust-embedded
cr1901_ has quit [Read error: Connection reset by peer]
cr1901 has quit [Ping timeout: 245 seconds]
cr1901 has joined #rust-embedded
cr1901 has quit [Quit: Leaving]
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<firefrommoonligh>
* More rust flight controller; changed up the control scheme so it holds attitude... but still flies like rate controls bc the RC input changes the target attitude. Should make feeding into the autopilot smooth.
<firefrommoonligh>
More rust flight controller; changed up the control scheme so it holds attitude... but still flies like rate controls bc the RC input changes the target attitude. Should make feeding into the autopilot smooth.