ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
aspe has joined #rust-embedded
aspe has quit [Client Quit]
aspe has joined #rust-embedded
fabic has joined #rust-embedded
aspe has quit [Quit: aspe]
starblue has quit [Ping timeout: 276 seconds]
starblue has joined #rust-embedded
<re_irc> <sajattack> hope y'all don't mind a bit of rust-psp shitposting https://chaos.social/web/sajattack/108280854816964557
_whitelogger has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
<re_irc> <gauteh> Hi, if anyone has any experience on how to robustly store data to SD-card while also keeping track of what data has been sent home over an unstable connection, I'd be very happy for suggestions: https://users.rust-lang.org/t/wave-buoy-storing-data-to-sd-card-robustly-and-transmitting-over-unstable-connection/75512
<re_irc> <gauteh> There's a detailed hackster tutorial coming for how to build the buoy in the making, but needs some more photos of the process
dc740 has joined #rust-embedded
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
emerent has quit [Remote host closed the connection]
emerent has joined #rust-embedded
<re_irc> <justacec> So, I have a situation where I have multiple sensors on a single I2C bus. Unfortunately, because of this I am currently unable to pass the ownership of the I2C peripheral to both devices at the same time. It is here that I kind of wish that the "embedded_hal" traits were setup to offer peripherals with a Sync+Send type deal such as an Arc<Mutex<...>> approach. One of the drivers for the devices does not take ownership,...
<re_irc> ... but I have to pass the I2C dev with each call. The other tried to take ownership. What is the best approach in these situations? (I was considering proposing a PR to the second driver to not take ownership and just require that the I2C was passed each time)
<re_irc> <Robert Jördens> "shared-bus" (https://crates.io/crates/shared-bus) for example
<re_irc> <justacec> lol
<re_irc> <justacec> and there you go
<re_irc> <justacec> Thanks for the pointer guys
<re_irc> <TimSmall> There's also e.g. https://crates.io/crates/shared-bus-rtic
<re_irc> <TimSmall> (for RTIC applications).
<re_irc> <ryan-summers> You shouldn't need that for I2C from what I remember
<re_irc> <justacec> Why is that?
<re_irc> <justacec> The main issue is that one of the devices takes ownership of the bus instance and therefore it is not available for the other device
dc740 has quit [Quit: Leaving]
<re_irc> <justacec> ryan-summers: Just noticed you were the package author. Thanks for the package. :)
<re_irc> <firefrommoonlight> justacec: I would use your proposed approach
<re_irc> <firefrommoonlight> Owning a bus is code smell
<re_irc> <firefrommoonlight> *Eh I guess that's a little strong. It can make sense to assume bus ownership in some cases
<re_irc> <firefrommoonlight> Eg if you're doing DMA transfers and don't want to micro-manage when each device is using the bus
<re_irc> <firefrommoonlight> On a proj I'm working on now, I'm using 3 separate SPI buses, with a single periph each, to keep that stuff simple
<re_irc> <justacec> Yea, that would be the easier approach. In this case I am using an LoRa-E5 board which only exposes one I2C
<re_irc> <ryan-summers> justacec: What I meant is that you don't need to use shared-bus-rtic for I2C - you just need "shared-bus" instead. "shared-bus-rtic" is somewhat of a relic and only needed when sharing SPI buses in RTIC apps at this point
<re_irc> <justacec> Ahh, I see.
<re_irc> <justacec> So, shared-bus is compatable with rtic
<re_irc> <justacec> I will switch it over then
<re_irc> <dirbaio> embedded-hal 1.0 has split Spi traits into SpiBus and SpiDevice, to solve exactly this issue https://docs.rs/embedded-hal/1.0.0-alpha.8/embedded_hal/spi/blocking/index.html#bus-vs-device
<re_irc> <dirbaio> the plan is to do the same for i2c... probably :D
<re_irc> <ryan-summers> I2C shouldn't need it IMO. The current shared-bus design accomplishes it just fine. The only reason SPI was broken was because of the CS/BUS ownership issues
<re_irc> <ryan-summers> And that's the only reason that shared-bus-rtic still exists
<re_irc> <ryan-summers> But yeah, I'm glad to see those fixes landing in e-h. I'd love to remove shared-bus-rtic and point everyone to shared-bus
<re_irc> <dirbaio> hmm
<re_irc> <ryan-summers> I've been passively watching the PRs :P
<re_irc> <ryan-summers> Take a look at https://github.com/Rahix/shared-bus/issues/4 for some detailed history on the issue going way back
<re_irc> <dirbaio> why is it not needed?
<re_irc> <ryan-summers> I assume it would somewhat eliminate the need for "shared-bus" entirely?
* re_irc justacec is watching closely
<re_irc> <ryan-summers> I haven't watched closely honestly as to what the split actually does
<re_irc> <dirbaio> there can still be cases where you want to do multiple writes/reads while still keeping a transaction open (and the bus locked, so no other driver attempts to read/write while you're holding the bus)
<re_irc> <ryan-summers> Hmm I guess there are some uses for sure
<re_irc> <ryan-summers> Just a minor performance issue imo though, although it may have more implications for async
<re_irc> <dirbaio> currently the trait has "_iter" and "transaction" methods to kinda allow that
<re_irc> <dirbaio> so 1 method call = 1 transaction
<re_irc> <dirbaio> but they're still not as flexible: "transaction" requires you to have all the data upfront, you can't generate it on the fly
<re_irc> <dirbaio> and the "_iter" methods are not very nice to impl with DMA, you have to either do 1-byte DMA transfers, or buffer on the HAL side
<re_irc> <ryan-summers> Hmm that's a good point. I've personally never really thought about I2C + DMA
<re_irc> <ryan-summers> Since oftentimes I2C is a register transaction interface, although obviously not always the case for e.g. external EEPROMS
<re_irc> <dirbaio> yeah... for async being able to DMA is nice, otherwise the performance is trash
<re_irc> <ryan-summers> Interesting thoughts for sure
<re_irc> <dirbaio> so with the "I2cBus + I2cDevice" setup, "I2cBus" needs just "read(&mut [u8])" and "write(&[u8])".
<re_irc> <dirbaio> just 2 methods, vs the current 7
<re_irc> <ryan-summers> I don't disagree the current API isn't the most ergonomic
<re_irc> <dirbaio> you open a transaction, do as many reads/writes as you want, then close it
<re_irc> <Tom> yessssss
<re_irc> <ryan-summers> I think the most important point is to ensure that the various types still play well with e.g. RTIC, so no typestating on the I2cBus
<re_irc> <ryan-summers> Otherwise it can cause a lot of annoyance on ownership issues
<re_irc> <dirbaio> yeah, no typestates
<re_irc> <ryan-summers> Anyways, gotta get back to work. Thanks for the topics, that's definitely an interesting use case
<re_irc> <ryan-summers> And I'd love to start using async. I really want it to hit stable already
<re_irc> <dirbaio> drivers own a I2cDevice, where you can do ".transaction()" and get temp access to the inner bus to do reads/writes
<re_irc> <ryan-summers> GAT dang it
<re_irc> <Tom> just use the lifetime of the object to be the lifetime of the transaction?
<re_irc> <dirbaio> async is already usable on stable
<re_irc> <ryan-summers> Are GATs enough along to avoid nightly?
<re_irc> <dirbaio> it's just async traits, but you can get stuff done without them
<re_irc> <ryan-summers> Ah, yeah
<re_irc> <ryan-summers> But traits are like the glue that hold projects together
<re_irc> <dirbaio> kinda
<re_irc> <ryan-summers> Unless you have a monoproject
<re_irc> <dirbaio> in embassy I made inherent methods for everything, in addition to the embedded-hal impls
<re_irc> <dirbaio> aside from the nightly issue, IMO it makes the HAL more usable: it's more discoverable, you don't have to import any trait to use it
<re_irc> <dirbaio> so you only use the embedded-hal traits if you're really writing a hal-independent driver
<re_irc> <ryan-summers> I'm interested to see what you present at the CTFT next week :P
<re_irc> <dirbaio> :D
cr1901_ is now known as cr1901
<re_irc> <firefrommoonlight> Same. Native interface using whatever API makes sense. EH backup for compatibility
<re_irc> <jannic> mJkimnwa
<re_irc> <James Munns> I should probably write my talk :D
<re_irc> <James Munns> I was thinking about writing an embedded project from scratch in 15 minutes, commenting on the history and techniques as I go
<re_irc> <James Munns> but that might be too much for 15 minutes :D
<re_irc> <firefrommoonlight> Challenge
<re_irc> <James Munns> The goal would be to start from scratch:
<re_irc> - Fill in the HAL (nrf52)/todos
<re_irc> - Use the knurling app-template/rtic-app-template
<re_irc> - Run a "hello world" program, show off cross-compilation and logging
<re_irc> <James Munns> I'm pretty sure I could do that all in 15 minutes, while explaining the history and theory of how it all works?
<re_irc> <James Munns> it might be too show-offy/not really as effective tho lol
<re_irc> <James Munns> but for a 15 minute demo, I think it makes the point of how "just rust" the experience is.
<re_irc> <James Munns> (I assume retention of anything I can teach in 15 minutes is going to be basically zero, outside of "big picture" concepts anyway, so leaning into it and showing off possibilities instead might be okay)
<re_irc> <dirbaio> live speedcoding, oh boi
<re_irc> <firefrommoonlight> I like that approach
<re_irc> <robtsuk> I would have gotten a lot of value out of that talk
gsalazar has quit [Ping timeout: 256 seconds]
<re_irc> <ryan-summers> robtsuk: Check out Ferrous Systems Oxidize Global talks from a few years back if you're curious - there's some good run downs on the ecosystem: https://www.youtube.com/c/FerrousSystemsGmbH/playlists
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #rust-embedded
aspe has joined #rust-embedded
dc740 has joined #rust-embedded
vancz has quit []
vancz has joined #rust-embedded
aspe has quit [Quit: aspe]
<re_irc> <Phil Markgraf> I'm working with the error handling code in the embedded_hal_mock and am perplexed by the example at https://docs.rs/embedded-hal-mock/latest/embedded_hal_mock/serial/index.html#testing-error-handling
<re_irc> This has a "use std::io::ErrorKind;" statement, but the code we want to test with the mock is decidedly no_std. Am I missing something?
aspe has joined #rust-embedded
aspe has quit [Remote host closed the connection]
<re_irc> <Phil Markgraf> I'm working with the error handling code in the embedded_hal_mock and am perplexed by the example at https://docs.rs/embedded-hal-mock/latest/embedded_hal_mock/serial/index.html#testing-error-handling This has a "use std::io::ErrorKind;" statement, but the code we want to test with the mock is decidedly no_std. For me this statement is unable to find std:io, as soon as we add no_std to the library under test, or...
<re_irc> ... pull the library into a no_std program. (Is there a different version of io::Error somewhere in the embedded_hal structure? I've had no luck finding one.)
<re_irc> <GrantM11235> Phil Markgraf: Replace "#[no_std]" with "#![cfg_attr(not(test), no_std)]"
<re_irc> <GrantM11235> That will allow you to use "std" for your tests while still keeping "no_std" compatibility