ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
<re_irc> <Clark Kozak> That should do it! Hooray for micromath! I wonder if they use bitshifting...
<re_irc> <Clark Kozak> thank you :)
<re_irc> <firefrommoonlight> How CMSIS-DSP does it for "arm_sqrt_f32" etc:
<re_irc> > Computes the square root of a number. There are separate functions for Q15, Q31, and floating-point data types. The square root function is computed using the Newton-Raphson algorithm. This is an iterative algorithm of the form:
<re_irc> x1 = x0 - f(x0)/f'(x0)
<re_irc> where x1 is the current estimate, x0 is the previous estimate, and f'(x0) is the derivative of f() evaluated at x0. For the square root function, the algorithm reduces to:
<re_irc> <firefrommoonlight> I can't seem to find the source for the floating point version though
<re_irc> <jessebraham> Clark Kozak: For "sqrt" specifically I think FISR: it uses
<re_irc> <jessebraham> * it uses FISR:
<re_irc> <firefrommoonlight> Classic
<re_irc> <jessebraham> Truly haha
<re_irc> <Clark Kozak> welp. I'm trying to take this microbit and get it to tell me how fast it's going 😂 but that's a lot of cool information about how to take sqrts of stuff
<re_irc> <Clark Kozak> in otherwise, y'all rock
dreamcat4 has quit [Quit: Connection closed for inactivity]
<re_irc> <Clark Kozak> Totally didn't know about fast inverse square root. Here's a video cuz it's awesome:
bjc has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
lowq has quit [Ping timeout: 260 seconds]
emerent is now known as Guest6773
emerent_ has joined #rust-embedded
Guest6773 has quit [Killed ( (Nickname regained by services))]
<re_irc> <ian_rees> thanks for the link clarkkozak! HAKMEM is worth a read if you've not seen it before
<re_irc> <Ahmed Charles> I'm trying to use "riscv-rt" and override the extension points that are provided via the linker script, but it doesn't seem to be working. Has anyone been able to get those to work?
<Lumpio-> I wonder if any language has a mechanism for a compile time "only ever called once" guarantee of some sort
<Lumpio-> Would get rid of all the unwrapping for stuff like singleton!() and struct Peripherals
<Lumpio-> Some kind of call_once functions may only be called from other call_once functions safely thing
<Lumpio-> Has it ever been tried or is it infeasible to prove in a practical program 🤔
<Lumpio-> I mean, it'd have to do a program-wide analysis to make sure each call_once function is only ever called from one place too.
<re_irc> <Ahmed Charles> You can simulate that if you're willing to pass the values as a parameter to your main function by value.
explore has joined #rust-embedded
<re_irc> <Chris [pwnOrbitals]> Anyone has experience with building elf files for embedded targets with only data ? I’d just like to instantiate a struct with custom config data and flash it at a known address... is that even possible ?
<Darius> I've done it in C but it was quite tedious
<Darius> (with objcopy)
<re_irc> <Chris [pwnOrbitals]> * get it flashed
<Darius> well I guess it wasn't C per se
<re_irc> <ryan-summers> Do you have to use ELF for that? Seems like a hex file may be more appropriate
<re_irc> <ryan-summers> And those are pretty trivial to build yourself - there's even python packages to do it by hand if you need to
<re_irc> <Chris [pwnOrbitals]> good question, I’d be okay with a hex... but I have no clue how to generate a hex through cargo/rustc. I just need to flash data I instanciated in Rust, so no Python or C :/ currently working with repr(Rust) structs (I know it’s a bad idea, though)
<Darius> if you want to put it in flash you need it in a form the linker understands
<Darius> converting hex to elf helps with that
<re_irc> <Chris [pwnOrbitals]> can cargo generate hex files instead of elf ?
<re_irc> <Chris [pwnOrbitals]> * cargo/rustc
<re_irc> <therealprof> "cargo-binutils" can.
<Darius> it depends what you are trying to do, I would have thought converting to an elf .o then linking to your final executable would be easier as it would mean you can flash your code and the data in a single step
<Darius> chris: what are you trying to do with the result?
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
<re_irc> <Chris [pwnOrbitals]> I’d need to flash it independently of any executable
<re_irc> <Chris [pwnOrbitals]> Darius: imagine there are a number of executables that could run on my target and they all share some configuration at a given place in flash. I’d like to initialize this configuration (and maybe reflash it later)
<Darius> ah right, like pseudo EEPROM
<Darius> I was thinking you might be after a way to store (say) a bitmap or something
<re_irc> <Chris [pwnOrbitals]> right :)
<re_irc> <ian_rees> chris_pwnorbitals: have you looked at probe-rs? I haven't dug in to the API but would think it could do that sort of thing
<re_irc> <Chris [pwnOrbitals]> i hadn’t, but looking at it now : wouldn’t be easy as I’ll be sending out the file (hex or elf) for some other people to flash it through their tools
<re_irc> <ian_rees> ah, I see, so the question is how to turn the Rust struct in to bytes then?
<re_irc> <Chris [pwnOrbitals]> ian_rees: and pack it into a flashable format, that’s right
<Darius> you probably want a version number in it, and maybe a CRC
<re_irc> <ian_rees> as for how to make a flashable format, looks like a good candidate
<re_irc> <ian_rees> I only tinker with linker scripts often enough to know they exist, but would think that making a linker section at the appropriate address, then there's probably a way to tag a const static struct instance to be linked in that section.
<re_irc> <ian_rees> and compile+link, then use objcopy to package up just that. Sorry if that's incoherent - very long day here...
<re_irc> <ian_rees> * that section as elf or hex.
<re_irc> <ian_rees> I only tinker with linker scripts often enough to know they exist, but would start with making a linker section at the appropriate address, then there's probably a way to tag a const static struct instance to be linked in that section.
<Darius> in C, you can create a section and tell the compiler to put data etc in that section
<re_irc> <Chris [pwnOrbitals]> ian_rees: this looks like a great solution indeed !!! thank you very much, trying it right now
explore has quit [Quit: Connection closed for inactivity]
<bjc> you can specify the linker section in rust, too, with `#[link_section = "foo"]`
<Darius> much less hideous than in C :D
<re_irc> <Chris [pwnOrbitals]> and boom, it works ! :)))
<re_irc> <dalepsmith> Is there a way to get the size/length and starting address of a "#[link_section..]" from Rust code? Is there a way to order linker sections? (from Rust).
<re_irc> I'm guessing that has to be done in linker scripts.
<bjc> i don't think there's a way from rust. i've only ever done it in linker scripts
<re_irc> <Clark Kozak> ian_rees: This?
<re_irc> ?
explore has joined #rust-embedded
lowq has joined #rust-embedded
unknown__ has joined #rust-embedded
creich_ has quit [Ping timeout: 256 seconds]
<re_irc> <mutantbob> Does it bug anyone else that the "uWrite" interface forces you to convert a ProgMem<&str> to a &str, instead of letting you just copy the bytes one-by-one ?
explore has quit [Quit: Connection closed for inactivity]
<re_irc> <dirbaio> if you find the new rust-analyzer inlay hint colors ugly: put this in vscode settings.json:
<re_irc> "workbench.colorCustomizations": {
<re_irc> "editorInlayHint.background": "#ff000000",
<re_irc> "editorInlayHint.foreground": "#999999"
<re_irc> }
<re_irc> <dirbaio> before:
<re_irc> <dirbaio> after:
<re_irc> <Kiran Shila> Hey everyone! Is the idiomatic way to share an instance of an I2C bus between drivers to use the shared-bus crate?
<re_irc> <dirbaio> yep
<re_irc> <dirbaio> or you can roll your own with RefCell if you want something simpler
<re_irc> <Kiran Shila> Great! Cheers
<cr1901> Can the same RefCell trick be done with SPI?
<re_irc> <dirbaio> with spi it's a bit harder because currently drivers manage the CS pin on their own and can do multiple write/trasnfer calls
<re_irc> <dirbaio> with a RefCell impl you can't do anything to prevent multiple drivers interleaving their transactions
<re_irc> <dirbaio> embedded-hal 1.0 has a redesigned SPI that solves this
<re_irc> <dirbaio> the spi Device vs Bus thing
<re_irc> <dirbaio> (and we'll maybe do the same for i2c if it works out)
<cr1901> Hmmm, I'll have to come back to this. I can't visualize offhand, but I'm also heavily focused on getting an invasive PR out the door
<cr1901> I just saw the chat and wanted to ask :P