vulfe has quit [Remote host closed the connection]
vulfe has joined #rust-embedded
vulfe has quit [Client Quit]
vulfe has joined #rust-embedded
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
lehmrob has joined #rust-embedded
vulfe has quit [Quit: Leaving...]
lehmrob has quit [Ping timeout: 246 seconds]
vulfe has joined #rust-embedded
<re_irc>
<@jaxter184:matrix.org> is there a way to access a mutex without creating a critical section?
<re_irc>
<@jaxter184:matrix.org> and/or is there a way to make a structure available to only a specific interrupt?
<re_irc>
<@jaxter184:matrix.org> with just plain embedded-hal
<re_irc>
<@ryan-summers:matrix.org> Can always do it in an unsafe manner :)
<re_irc>
<@ryan-summers:matrix.org> i.e. make it a static mut
<re_irc>
<@jaxter184:matrix.org> not ideal, but i can probably make that work
<re_irc>
<@jaxter184:matrix.org> i guess if i trust my logic, then it should be fine
<re_irc>
<@ryan-summers:matrix.org> Other than that, the only other idea I have would be to move it into an option and "take" it within the ISR
<re_irc>
<@ryan-summers:matrix.org> that's the only other way to guarantee from a rust standpoint that only one context has access to it
<re_irc>
<@ryan-summers:matrix.org> I mean, all frameworks use "unsafe" code under the hood
<re_irc>
<@jaxter184:matrix.org> oh actually that would probably work
<re_irc>
<@jaxter184:matrix.org> thanks!
<re_irc>
<@ryan-summers:matrix.org> No problem :)
IlPalazzo-ojiisa has joined #rust-embedded
vulfe has quit [Quit: Leaving...]
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
<re_irc>
<@nothingtohide:matrix.org> With the new "SpiDevice" api where "transaction()" takes operations instead of a function is there any way to to do a write followed by a read with a very short delay without deasserting cs, flushing the bus, and unlocking the bus in between the write and the read?
<re_irc>
<@nothingtohide:matrix.org> From embedded-hal
jsolano has quit [Remote host closed the connection]
<re_irc>
<@diondokter:matrix.org> : Hmmm I don't think so. But if toggling the clock pin is fine, you could do a dummy read
<re_irc>
<@dirbaio:matrix.org> : what chip are you writing a driver for, that needs that?
<re_irc>
<@nothingtohide:matrix.org> ADS1255/56 needs a 7 micro second delay between the command to read a register and reading the corresponding data over SPI
<re_irc>
<@nothingtohide:matrix.org> > > <@nothingtohide:matrix.org> With the new "SpiDevice" api where "transaction()" takes operations instead of a function is there any way to to do a write followed by a read with a very short delay without deasserting cs, flushing the bus, and unlocking the bus in between the write and the read?
<re_irc>
> what chip are you writing a driver for, that needs that?
<re_irc>
<@nothingtohide:matrix.org> I am new to embedded development, didn't know it was uncommon lol
<re_irc>
<@peter9477:matrix.org> Can anyone explain why putting this in .cargo/config.toml results in the locally compiled core and alloc crates being included, but using "-Z build-std=alloc,core" on the command line apparently does not?
<re_irc>
[unstable]
<re_irc>
build-std = ["alloc", "core"]
<re_irc>
<@peter9477:matrix.org> This is e.g. using "cargo size -Z build-std=alloc,core" or similar things. I have channel="night-xxxx-xx-xx" in my rust-toolchains.toml but using "+nightly" and similar has no impact on this either.
<re_irc>
<@jamesmunns:beeper.com> I think you need to pass the z flags to rustc not cargo
<re_irc>
<@jamesmunns:beeper.com> The actual usage of z flags is weird iirc
<re_irc>
<@dirbaio:matrix.org> "custom" commands like "cargo size" don't always correctly forward "weird" flags like -Z to the underlying Cargo invocation
<re_irc>
<@peter9477:matrix.org> : I've been trying this with cargo size, cargo build, cargo objcopy, and others...
<re_irc>
<@dirbaio:matrix.org> with "cargo build" it should definitely work