conplan has quit [Remote host closed the connection]
Andy_Flatline has quit [Quit: Leaving]
wose has quit [*.net *.split]
tafa has quit [*.net *.split]
re_irc has quit [*.net *.split]
re_irc has joined #rust-embedded
tafa has joined #rust-embedded
wose has joined #rust-embedded
ni has quit [*.net *.split]
oak- has quit [*.net *.split]
ni has joined #rust-embedded
oak- has joined #rust-embedded
causal has joined #rust-embedded
hwj has joined #rust-embedded
dc740 has joined #rust-embedded
hwj has quit [Ping timeout: 240 seconds]
hwj has joined #rust-embedded
hwj has quit [Ping timeout: 268 seconds]
hwj has joined #rust-embedded
hwj has quit [Ping timeout: 268 seconds]
hwj has joined #rust-embedded
explore has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
hwj has quit [Ping timeout: 240 seconds]
explore has quit [Quit: Connection closed for inactivity]
<re_irc>
<Limeth> Hello, I'd like to create a driver for an I2C-based chip. Can someone recommend an existing driver that I could use as a guide/inspiration?
<re_irc>
< (@jessebraham:matrix.org)> Oh sorry missed the cargo part, on mobile
<re_irc>
< (@k900:0upti.me)> conplan: You'd use the Cargo that gets built/installed along with the forked rustc
<re_irc>
< (@k900:0upti.me)> Looks like the espup tool can generate a script to add it to your current shell environment
<re_irc>
< (@orclev:matrix.org)> also FYI, rustup is the tool most people use for managing their rust toolchains. Unfortunately I don't believe it supports actual forks of rust like the esp rust compiler, so it wouldn't help there, but for things like swapping between nightly and stable it's the tool for the job.
<conplan>
Has ther been any effort to allow rustup to support forks of the rustc compiler
<re_irc>
< (@k900:0upti.me)> No
<re_irc>
< (@k900:0upti.me)> I am pretty sure the rustup people would not be very fond of the idea
<Shell>
`rustup toolchain help link` if you already have a custom-built toolchain.
<re_irc>
< (@k900:0upti.me)> rustup represents the Rust project, and forks very much do not
<re_irc>
< (@k900:0upti.me)> Which is to say, any artifacts rustup ships will be treated as "official" to some extent, and thus need to meet a certain standard of quality and upstream support
<re_irc>
< (@k900:0upti.me)> And the Xtensa fork currently doesn't have that for either rustc or LLVM
<Shell>
so you can use rustup to switch between forks that you build yourself, but it's not a rust compiler build tool so it's not gonna build stuff for you.
hwj has joined #rust-embedded
starblue has joined #rust-embedded
hwj has quit [Ping timeout: 268 seconds]
emerent has quit [Ping timeout: 246 seconds]
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
<re_irc>
< (@thebutlah:matrix.org)> I have a driver written in C++ arduino for the icm20948 that I can't find an "embedded-hal" driver for with the same features (chiefly, support for the DMP). I thought that I would replace the "Wire.h" and "SPI.h" functionality it invokes with my own functions that call into "embedded-hal".
<re_irc>
Does this sound viable? Does anyone have any tips for how to get this to work?
<re_irc>
< (@thebutlah:matrix.org)> +I am experienced with "safer-ffi" and "cxx" but those usually box everything, I'm not sure if that is a viable approach here - perhaps I should make my own C++ classes that then call into rust-as-c code?
<re_irc>
< (@firefrommoonlight:matrix.org)> Nice. Probably better than what I'm using to fuse
<re_irc>
< (@firefrommoonlight:matrix.org)> I've been using CMSIS-DSP lowpass filters, then an algo called AHRsFusion that Madgwick wrote
<re_irc>
< (@firefrommoonlight:matrix.org)> I don't think you'll be able to make an embedded-hal driver for this
<re_irc>
< (@firefrommoonlight:matrix.org)> (I'm a bit out of date though)
<re_irc>
< (@firefrommoonlight:matrix.org)> When I last checked, you couldn't really do the DMA of the 12+ registers you'd need to read in a row with it
<re_irc>
< (@thebutlah:matrix.org)> > I don't think you'll be able to make an embedded-hal driver for this
<re_irc>
> How so?
<re_irc>
< (@thebutlah:matrix.org)> ->
<re_irc>
< (@firefrommoonlight:matrix.org)> I don't think EH supports DMA
starblue has quit [Ping timeout: 256 seconds]
<re_irc>
< (@firefrommoonlight:matrix.org)> You'd have to block at each reg
<re_irc>
< (@firefrommoonlight:matrix.org)> Which is a no-go for an attitude platform
<re_irc>
< (@thebutlah:matrix.org)> I'm sorry I'm pretty new to embedded development. DMA is direct memory access, but IDK what that really means.
<re_irc>
Are you saying that if I mocked out the arduino stuff and tried to implement the arduino functionality with "embedded-hal", I wouldn't because the arduino stuff is doing DMA and I can't do that with embedded hal?
<re_irc>
< (@firefrommoonlight:matrix.org)> I'm saying if you have an attitude platform, you probably want to read all 12 Acc/gyro regs each, at a high data rate, while not blocking the CPU