GenTooMan has quit [Ping timeout: 272 seconds]
fabic_ has joined #rust-embedded
radens has joined #rust-embedded
GenTooMan has joined #rust-embedded
starblue2 has joined #rust-embedded
starblue1 has quit [Ping timeout: 258 seconds]
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
fabic_ has quit [Ping timeout: 265 seconds]
fabic_ has joined #rust-embedded
tokomak has joined #rust-embedded
bpye has joined #rust-embedded
fabic_ has quit [Ping timeout: 265 seconds]
rjframe has joined #rust-embedded
fabic_ has joined #rust-embedded
rjframe has quit [Ping timeout: 265 seconds]
<re_irc> <@d​irbaio:m​> TIL github actions already comes with rustup... so no `- uses: actions-rs/toolchain@v1` needed! You can choose the rust version with `rust-toolchain.toml`.
<re_irc> <@a​damgreig:m​> huh
<re_irc> <@a​damgreig:m​> which gha, ubuntu-20.04?
<re_irc> <@d​irbaio:m​> not sure.. `runs-on: ubuntu-latest`
<re_irc> <@a​damgreig:m​> ubuntu-latest currently maps to ubuntu-20.04
<re_irc> <@a​damgreig:m​> idk why they even provide it... it seems like it would be a surprise nightmare for all your CI to suddenly change OS, lol
<re_irc> <@d​irbaio:m​> Rustup 1.24.3
<re_irc> <@d​irbaio:m​> right.. no idea 🤣
<re_irc> <@a​damgreig:m​> i just use "ubuntu-20.04" now but didn't realise it already had rustc 1.53 and rustup
<re_irc> <@a​damgreig:m​> will rustup go ahead and install a missing toolchain if rust-toolchain specifies it?
<re_irc> <@a​damgreig:m​> I guess it's still kinda a pain if you want to test on a few specific versions like stable, nightly, msrv for the same crate?
<re_irc> <@d​irbaio:m​> adamgreig: yep
<re_irc> <@d​irbaio:m​> adamgreig: 🤷‍♂️ I guess you can set overrides with `rustup` from shell commands
<re_irc> <@a​damgreig:m​> hmm, I think you can just use actions-rs/toolchain anyway
<re_irc> <@a​damgreig:m​> just looked and in a recent GHA run, I asked for stable, and it noticed rustup and 1.53 were both already installed and no-op
<re_irc> <@a​damgreig:m​> if you ask for some other target it can just install that, and you can put override:true on the toolchain action to make it use it for the rest of the run
<re_irc> <@a​damgreig:m​> so maybe still the easiest way?
<re_irc> <@d​irbaio:m​> yeah.. dunno
<re_irc> <@d​irbaio:m​> maybe using rustup directly is nicer, it's the same commands that you'd run locally
<re_irc> <@d​irbaio:m​> instead of black magic that only works in GHA
<re_irc> <@a​damgreig:m​> eh, that action just calls rustup for you, just depends which syntax you prefer I guess
<re_irc> <@d​irbaio:m​> I just got bit by actions-rs not supporting `rust-toolchain.toml` (just `rust-toolchain`) 🤣
<re_irc> <@d​irbaio:m​> it was using latest nightly instead of the pinned one... and nightly broke, oops :D
<re_irc> <@a​damgreig:m​> huhh
<re_irc> <@a​damgreig:m​> why does actions-rs use it at all? shouldn't rustup itself just use it?
<re_irc> <@d​irbaio:m​> it uses it to know what to install
<re_irc> <@d​irbaio:m​> otherwise it'll install what you tell it in the yaml, but then when you actually run cargo it'll install again the one in rust-toolchain.toml
dcz_ has joined #rust-embedded
<re_irc> <@n​ewam:m​> Does anyone know of a compile time cfg macro to ensure features are exclusive?
<re_irc> <@n​ewam:m​> I am looking for a way to make `--all-features` fail to compile as fast as possible for this:
<re_irc> <@n​ewam:m​> ```rs
<re_irc> <@n​ewam:m​> cfg_if::cfg_if! {
<re_irc> <@f​irefrommoonlight:m​> Is this to catch errors where someone specifies multiple (exclusive) MCU-selection features?
<re_irc> <@n​ewam:m​> Yeah, it will fail to compile if that happens, but only after some time and with a less-than-helpful message.
<re_irc> <@f​irefrommoonlight:m​> What's consuming the time? How about something at the top of that makes sure you don't have more than one exclusive features set
<re_irc> <@n​ewam:m​> > What's consuming the time?
<re_irc> <@n​ewam:m​> Just actually compiling until it hits a duplicated symbol (there are other places in the crate that expose different APIs for different hardware).
<re_irc> <@n​ewam:m​> Checking for an exclusive feature is what I want to do, just seeing if anyone else has made a convenience macro since it seems like it would be a common problem in the embedded space.
<re_irc> <@f​irefrommoonlight:m​> I just assume users will only use one! But I agree this would be useful
<re_irc> <@f​irefrommoonlight:m​> I'll use it once you've finished
<re_irc> <@f​irefrommoonlight:m​> I think some messy `cfg_if!` logic at the top of `` would do the trick
<re_irc> <@a​damgreig:m​> newam I've mostly done this in e.g.
<re_irc> <@d​irbaio:m​> you can do something like this
<re_irc> <@d​irbaio:m​> shame it grows like O(n^2)
fabic_ has quit [Ping timeout: 240 seconds]
<re_irc> <@j​ohn_socha:m​> I'm very new to embedded Rust. In my, I'm getting a warning "Can't find crate for test." This is in VSCode. Is there a way to suppress this message? I seem to remember seeing something somewhere, but haven't been able to find it with the searches I've tried.
<re_irc> <@y​atekii:m​> does anyone know a way to make a proc_macro scope aware
<re_irc> <@d​khayes117:m​> john_socha: Maybe put `test=false` in the cargo.toml?
<re_irc> <@j​ohn_socha:m​> Nope. This seems to be an error from the Rust language server rather than the compiler. I don't see any warnings when I build--just in VSCode.
<re_irc> <@a​damgreig:m​> are you using rust-analyzer?
<re_irc> <@j​ohn_socha:m​> I'm using the Rust 0.7.8 extension. Should I be using Rust-Analyzer instead?
<re_irc> <@a​damgreig:m​> I think it's widely considered the best option for vscode users,
<re_irc> <@j​ohn_socha:m​> adamgreig: That's good to know. I chose based on download numbers as I didn't see anything in t he rust-analyzer help pages that explained how it might be better.
<re_irc> <@a​damgreig:m​> though I think your issue is probably common to both of them, there's a few issues about it like and
<re_irc> <@j​ohn_socha:m​> adamgreig: Perfect! That fixed it. And I learned that there is a better language server!
<re_irc> <@d​khayes117:m​> Oh yeah, I had that trouble in IntelliJ. I had to set build all targets to false in the settings.
tokomak has quit [Read error: Connection reset by peer]
<re_irc> <@a​lmindor:m​> Rust analyzer is pretty good overall. Also for non embedded builds check out it improves linking speed considerably on x86
<re_irc> <@y​atekii:m​> ^ nice!
<re_irc> <@f​irefrommoonlight:m​> Btw, if y'all haven't tried IntelliJ Rust plugin - it's phenomenal for code introspection, refactoring, highlighting errors etc
<re_irc> <@f​irefrommoonlight:m​> With a cost of a somewhat sluggish IDE
<re_irc> <@t​hejpster:m​> Does anyone fancy some super simple code reviews for an open source (GPL) Embedded Rust project?
<re_irc> <@t​hejpster:m​> I'm managing to muck things up without a second pair of eyes.
dcz_ has quit [Ping timeout: 256 seconds]
rjframe has joined #rust-embedded
rjframe has quit [Remote host closed the connection]
<re_irc> <@y​ruama_lairba:m​> Hi, can somone give several examples of lib to talk to a write only chip throught i2c or SPI ? i'd like to see if there is some convention when writing such lib
<re_irc> <@y​ruama_lairba:m​> i wander those thing because i found a hal for wm8731 and i find it not so much convenient. The main reason is because a "Register" need to be manually transformed (bit shift and bit masking) before being sended into a serial bus
Yruama has joined #rust-embedded
<Yruama> some people here ?
<re_irc> <@y​ruama_lairba:m​> does the irc bridge work properly ?
<agg> seems to be?
<re_irc> <@y​ruama_lairba:m​> "seems to be" to what ?
<Shell> yes :p
<agg> sorry, i mean, it seems to be working properly
<re_irc> <@y​ruama_lairba:m​> yes it work, but it doesn't work like the former freenode bridge
<agg> yes, for various boring reasons it's not currently possible to use the same bridge as before
<re_irc> <@y​ruama_lairba:m​> can i have help into some reflexion ? i just want to confirm something
<re_irc> <@y​ruama_lairba:m​> if i understand correctly, inside a PAC, writing (not modifying) to a register is done throught a closure, because it's possible to read the register inside a closure ?
<re_irc> <@a​damgreig:m​> with svd2rust pacs, the closure for writing is just an API design, it's not essential
<re_irc> <@n​ewam:m​> > if i understand correctly, inside a PAC, writing (not modifying) to a register is done throught a closure, because it's possible to read the register inside a closure ?
<re_irc> <@n​ewam:m​> The closure is a stylistic choice.
<re_irc> <@n​ewam:m​> There are other ways of doing this, another popular one is `tock_registers`:
<re_irc> <@n​ewam:m​> Though, svd2rust is the most ubiquitous because tock (and most others) require nightly.
<re_irc> <@y​ruama_lairba:m​> lol, i was expecting simpler answer
<re_irc> <@y​ruama_lairba:m​> i should explain more my mind, in fact i'm looking into a hal to control a codec, and the guy who did this seems to have stupidly immitaded svd2rust pacs
<re_irc> <@n​ewam:m​> yruama_lairba: There can be valid reasons for doing this; one thing svd2rust is not great at is handling register arrays.
<re_irc> <@t​halesfragoso:m​> newam: Not sure what svd4rust does different, but you can (manually) apply some transformation and it behaves really well when creating arrays
<re_irc> <@t​halesfragoso:m​> I would think they are quite similar
<re_irc> <@y​ruama_lairba:m​> i'm not talking about tock
<re_irc> <@t​halesfragoso:m​> But maybe Im talking non-sense, dirbaio should know better
<re_irc> <@y​ruama_lairba:m​> to be short, for the wm8731 chip, I think a much more simple and stupid but more conveninent API can be written
<re_irc> <@y​ruama_lairba:m​> maybe the guy use sv2rust for this chip ? i don't know if there is svd file for codecs
<re_irc> <@a​damgreig:m​> svd2rust only generates stuff for memory mapped IO, so probably not
<re_irc> <@y​ruama_lairba:m​> this codec have registers with addresses
<re_irc> <@a​damgreig:m​> yes, but you don't access it to writing to those addresses in your own chip's RAM, right?
<re_irc> <@a​damgreig:m​> it goes over SPI or I2C etc?
<re_irc> <@y​ruama_lairba:m​> yes goes SPI or I2C (this chip can do both)
<re_irc> <@a​damgreig:m​> svd2rust doesn't generate code that can use spi to access registers, only memory mapped IO (MMIO) where you directly write to (your own) memory
<re_irc> <@a​damgreig:m​> so it is probably not made using svd2rust
<re_irc> <@y​ruama_lairba:m​> the crate don't manage SPI or I2C
<re_irc> <@y​ruama_lairba:m​> it just has function to generate address and data to write
<re_irc> <@y​atekii:m​> am I weird because I like building proc_macros?
<re_irc> <@y​ruama_lairba:m​> it's only weird if what you do with proc_macro can be achieve in a simpler way
<re_irc> <@y​atekii:m​> ofc not :P
<re_irc> <@y​ruama_lairba:m​> lol, i really don't understand why pacs use closure to write to a register