<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>
<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>
<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> 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
<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