holo[m] has quit [Quit: Idle timeout reached: 172800s]
notgull has quit [Ping timeout: 252 seconds]
notgull has joined #rust-embedded
starblue has quit [Ping timeout: 255 seconds]
starblue has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
crabbedhaloablut has joined #rust-embedded
notgull has quit [Ping timeout: 245 seconds]
notgull has joined #rust-embedded
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
IlPalazzo-ojiisa has joined #rust-embedded
korken89[m] has joined #rust-embedded
<korken89[m]>
Does anyone know of a "guide"/"tutorial" on how to write an softdevice in Rust? With that I mean a binary blob with like a defined table of functions that can be called. Feels like someone before me must have done :) I want to share code between multiple firmwares loaded into different DFU partitions but not have that code multiplied by N DFU partitions.
IlPalazzo-ojiisa has quit [Read error: Connection reset by peer]
IlPalazzo-ojiis1 has joined #rust-embedded
<JamesMunns[m]>
It's likely not a tutorial, but IIRC thejpster's approach with Neotron's userspace API is the most reasonable approach to this problem:
<JamesMunns[m]>
Have a struct of fn pointers created either at compile time, or from "kernelspace", pass that struct by ref/val into the "userspace".
<JamesMunns[m]>
All types will need to be extern C, and not extern Rust
<JamesMunns[m]>
(unless you promise to always use the same compiler version, etc. etc.)
<korken89[m]>
Sounds very promising! Do you happen to know where this is defined in Neotron?
<JamesMunns[m]>
but yeah, conceptually: You need to write a staticlib, with a C ABI, that you are statically linking to a specific place. You also need to make an array of pointers for the location of all publicly visible symbols.
<korken89[m]>
ð
<korken89[m]>
I wonder if you can "objcopy" a static lib to a bin
<dirbaio[m]>
no, you have to link it
<dirbaio[m]>
with a custom linker script so the "struct of function pointers" is placed at a known offset
<M9names[m]>
*or a discoverable offset
<korken89[m]>
Hmm, alright. I might make a "fake bin" where the functions I want is the "vector table" of a normal app, conceptually. So I can make this thing fully selfcontained. Just a bin flashed to a known address
<korken89[m]>
* known address in the end.
<dirbaio[m]>
yea
<korken89[m]>
Thanks for the pointers!
<dirbaio[m]>
also make sure to link both binaries so RAM doesn't overlap, or you might have both placing different statics at the same addres
<korken89[m]>
Smart!
<dirbaio[m]>
or make the shared binary's RAM zero-length to enforce it doesn't use statics at all
<dirbaio[m]>
this stuff is cursed
<korken89[m]>
That sounds good. All I want in this place is the p256 asm code + SHA1.
<dirbaio[m]>
whatever RAM length you pick for the shared bin, you'll be stuck forever
<korken89[m]>
ðŠĶ
<dirbaio[m]>
the nrf softdevice has this funny "dynamically tell me how much RAM you need" because it also depends on runtime settings ðŧ
<korken89[m]>
Haha
<dirbaio[m]>
if it's just for crypto hopefully you can get away with using only stack, so no statics
<korken89[m]>
I hope so, I'll try without staticks and see if anything breaks :D
<korken89[m]>
s/staticks/statics/
<thejpster[m]>
Neotron OS gets the first 4K of SRAM. The BIOS passes the struct point to the entry function, which the OS stashes in a global. One of the functions tells the OS how bug the SRAM is when it uses to set up a sort of heap. Allocations get taken off the top, and if you start an application it gets given the whatever is left, starting at 0x20001000 (4K into SRAM). Again the application gets a struct pointer handed to the entry point,
<thejpster[m]>
and one of the API functions tells the app how much RAM there is.
<thejpster[m]>
You might also look at Flash Algos because the debugger injects those into ram at an arbitrary address and uses then to do Things (write and erase flash)
<thejpster[m]>
Oh and compiling a binary to an ELF and loading it at run time turns out to be easy. Relocating the code for an unexpected load address is harder though.
dngrsspookyvisio has joined #rust-embedded
<dngrsspookyvisio>
<korken89[m]> "Thanks for the pointers!..." <- That's also a fitting crate name
starblue has quit [Ping timeout: 246 seconds]
<JamesMunns[m]>
adamgreig (or someone on the cortex-m team?) if you could move it to `announcements` instead of `general` I'd appreciate that.
<AdamHott[m]>
embedded-hal-async = { version = "=1.0.0-rc.3" }
<AdamHott[m]>
Hey all, I know that you're in the middle of the release, I just started a project on the raspberry pi pico w - and am wondering what the last stable version is for these crates?
<AdamHott[m]>
embedded-hal-nb = { version = "=1.0.0-rc.3" }
<dirbaio[m]>
no stable version has existed, first one will be 1.0.0 when released
<AdamHott[m]>
ah right!
<AdamHott[m]>
do I need those crates for pico w or does embassy have that functionality already?
<AdamHott[m]>
The !!! are just telling me that no versions are found for those
<dirbaio[m]>
you're trying to set up a project for the pico w?
<M9names[m]>
<AdamHott[m]> "The !!! are just telling me that..." <- i'm assuming you're talking about the vscode plugin? ignore the warnings, it will build.