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
Guest7221 has left #rust-embedded [Error from remote client]
notgull has quit [Ping timeout: 264 seconds]
notgull has joined #rust-embedded
Ekho has quit [Quit: CORE ERROR, SYSTEM HALTED.]
Guest7221 has joined #rust-embedded
Ekho has joined #rust-embedded
DanielakaCyReVol has joined #rust-embedded
<DanielakaCyReVol> 👋 sup folks? I'm trying to figure out a way to share an IO pin between peripherals - two SPI TFT displays with a common IO pin used for DC. Sooo... any idea how to share that pin?
<DanielakaCyReVol> There is https://crates.io/crates/shared-pin similar to shared-bus, but it requires an allocator, using `Rc` and `RefCell`. Is there any other way of achieving the same thing?
<DanielakaCyReVol> https://github.com/hacknus/shared-pin-rs/blob/master/src/lib.rs the code is simple, implementing `Clone` via `Rc::clone`. Any suggestions? 😬
<dirbaio[m]> you can use `&RefCell` instead of `Rc<RefCell`
<dirbaio[m]> s/`/<T>`/, s/`/<T>>` to avoid alloc/
<DanielakaCyReVol> oh hey I'll try that - for reference, code is here https://github.com/das-labor/badge-2021-rs/blob/a4c0dec86d89b2cfffe02c7b8b983cb5fde542cb/src/gfx_spi.rs#L33 (spi-display branch)
<dirbaio[m]> `&'static RefCell<T>` if you don't want to deal with lifetimes, to get that check out https://crates.io/crates/static_cell
<dirbaio[m]> also note shared_bus for spi is not quite right https://github.com/Rahix/shared-bus/issues/23
<DanielakaCyReVol> yea that looked fishy 🎣
<dirbaio[m]> if you don't do any actual concurrency it'll probably be fine tho
<dirbaio[m]> embedded-hal 1.0 adds SpiDevice to handle sharing
<dirbaio[m]> though it's not applicable to displays with DC pins
<dirbaio[m]> you can do it with RefCell<SpiBus> tho https://github.com/rust-embedded/embedded-hal/issues/478
<DanielakaCyReVol> okay so ... here's me struggling with `dyn` things again... Rust won't like `static DC_PIN: StaticCell<OutputPin> = StaticCell::new();` and wants some `dyn` and now it all explodes and I get 4 pages of red errors once again xD this can get so complicated, it's amazing :D
<DanielakaCyReVol> ... am I holding it wrong?
<dirbaio[m]> you have to use the concrete type
<dirbaio[m]> from esp32_hal
<dirbaio[m]> it's this, I *think*, from a quick look at the docs
<dirbaio[m]> `static DC_PIN: StaticCell<RefCell<GpioPin<Output<PushPull>, 2>>> = ...`
<dirbaio[m]> replace pin number
<DanielakaCyReVol> yea I did that first
<DanielakaCyReVol> and that got me `the trait `esp32_hal::prelude::_embedded_hal_digital_OutputPin` is not implemented for `GpioPin<esp32_hal::gpio::PushPull, 16>``
<DanielakaCyReVol> * and that got me ```
<DanielakaCyReVol> ```
<DanielakaCyReVol> the trait `esp32\_hal::prelude::\_embedded\_hal\_digital\_OutputPin`is not implemented for`GpioPin\<esp32\_hal::gpio::PushPull, 16>
<dirbaio[m]> `GpioPin<Output<PushPull>, ..>`, not `GpioPin<PushPull, ..>`
<DanielakaCyReVol> Oh sure... heh, more genertics :)
<dirbaio[m]> ¯\_(ツ)_/¯
<DanielakaCyReVol> Hmm... I can't quite figure out how to _use_ that thing now.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ObqVJEotrAaKwOjcmStZEbGq>)
<DanielakaCyReVol> e.g. `*dc_pin.borrow()` gets me... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/lhqGiWibWbNeOrslWbiaKFcA>)
<dirbaio[m]> ah yes..
<dirbaio[m]> you need to wrap the RefCell in a newtype, implement OutputPin for it
<dirbaio[m]> on set_high/set_low: borrow the refcell, do set_high/set_low on the inner pin
<dirbaio[m]> impl OutputPin for MyPin { ... }
<dirbaio[m]> struct MyPin(&'static RefCell<...>);
<DanielakaCyReVol> gotcha
<DanielakaCyReVol> and then the borrow works just like that?
starblue has quit [Ping timeout: 255 seconds]
<DanielakaCyReVol> I mean, when I have that implementation that uses borrow in it, I still have to pass it on again 🤔
starblue has joined #rust-embedded
<dirbaio[m]> the impl borrows, ie "locks" the refcell, uses the inner pin, then unlocks it
<dirbaio[m]> this is how you "share" the pin
<dirbaio[m]> both drivers can now do set_high/set_low on the same pin
<DanielakaCyReVol> so... I am at the same point again, except with a lot more code...
<DanielakaCyReVol> ... how do I get the second "copy" of that thing now?
<DanielakaCyReVol> I get use of moved value: dc_pin``
<DanielakaCyReVol> s//`/, s//\`/, s/``/\``/
<DanielakaCyReVol> just like in the beginning 😅
<dirbaio[m]> or you can make SharedPin Copy
<DanielakaCyReVol> oh
<DanielakaCyReVol> heck that works
<DanielakaCyReVol> lol you're a genius :) THANK YOU! 🥳
<DanielakaCyReVol> now I can peacefully sleep :D g'night 😴
crabbedhaloablut has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
notgull has quit [Ping timeout: 264 seconds]
notgull has joined #rust-embedded
emerent has quit [Ping timeout: 258 seconds]
emerent has joined #rust-embedded
Guest7221 has left #rust-embedded [Error from remote client]
Guest7221 has joined #rust-embedded
Guest7221 has left #rust-embedded [Disconnected: Replaced by new connection]
pronvis has quit [Ping timeout: 255 seconds]
gooblob has joined #rust-embedded
gooblob has quit [Remote host closed the connection]
lehmrob has joined #rust-embedded
gooblob has joined #rust-embedded
gooblob has quit [Remote host closed the connection]
starblue has quit [Ping timeout: 245 seconds]
starblue has joined #rust-embedded
JamesMunns[m] has quit [Quit: Idle timeout reached: 172800s]
crabbedhaloablut has quit []
romancardenas[m] has joined #rust-embedded
<romancardenas[m]> Hi folks! I've been playing around with `f64` in `riscv32imc-unknown-none-elf` and...... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/KHUyDCntTvEJSiJYpIzyFciw>)
<romancardenas[m]> * Hi folks! I've been playing around with `f64` on `riscv32imc-unknown-none-elf` and...... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/BdXmvzXdamIKhBVvBjYCEoDM>)
crabbedhaloablut has joined #rust-embedded
<romancardenas[m]> * Hi folks! I've been playing around with `f64` on `riscv32imc-unknown-none-elf` and...... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/RlUPXYGxVtJwMvvQkLAwIDnu>)
JamesMunns[m] has joined #rust-embedded
<JamesMunns[m]> I don't remember "why", but the fix is usually to use `libm`
mabez[m] has joined #rust-embedded
<mabez[m]> romancardenas[m]: > <@romancardenas:matrix.org> Hi folks! I've been playing around with `f64` on `riscv32imc-unknown-none-elf` and...... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/vcVcShMiPXQHHOMflMEdrJsT>)
<mabez[m]> How long this will take to get into a Rust release is unknown though, sometimes compiler builtins gets bumped quickly, some times its takes months
<JamesMunns[m]> mabez[m]: Did this get fixed for other archs like cortex-m?
<mabez[m]> JamesMunns[m]: Yes, that PR fixed it for all `-none-` targets
<JamesMunns[m]> mabez[m]: hell yeah
<JamesMunns[m]> Does that also include fixes for less-basic operations like sine and cos? Or just the bare min like fmax/fmin?
<mabez[m]> JamesMunns[m]: That is still target dependent by the looks of it: https://github.com/rust-lang/compiler-builtins/blob/master/src/math.rs
<romancardenas[m]> Good to know that this is already fixed! I hope they update it soon, having fmin in my code makes me anxious 😂
<JamesMunns[m]> mabez[m]: thanks!
AdamHott[m] has quit [Quit: Idle timeout reached: 172800s]
<romancardenas[m]> <mabez[m]> "How long this will take to get..." <- Nightly already compiles fine. Stable still does not work
IlPalazzo-ojiisa has joined #rust-embedded
notgull has quit [Ping timeout: 248 seconds]
notgull has joined #rust-embedded
<IlPalazzo-ojiisa> @thejpster[m] Pray tell, sir. Last I heard about Ferrocene, it was “a few weeks away” from being officially ASIL-D certified. By way of analogy, the rubber stamp had already been inked, and all that was left was to press it onto the paper.
<IlPalazzo-ojiisa> By then, however, a few weeks have indeed passed. Has the rubber stamp been onto the paper? If not, do we know approximately when it will?
<thejpster[m]> Sorry I’m on vacation today. I’m sure Ferrous will make an announcement in due course, but I have seen the signed certificate.
Guest7221 has joined #rust-embedded
lehmrob has quit [Ping timeout: 255 seconds]
lehmrob has joined #rust-embedded
lehmrob has quit [Ping timeout: 264 seconds]
Guest7221 has left #rust-embedded [Error from remote client]
Guest7221 has joined #rust-embedded
firefrommoonligh has quit [Quit: Idle timeout reached: 172800s]
paulyoung[m] has joined #rust-embedded
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]> I'd be very surprised if USB-C couldn't power your device? USB-C powers my laptop using power-delivery
<ryan-summers[m]> But also, STM32 and RPI devices are generally pretty well supported
<ryan-summers[m]> Also also, you don't have to use USB-serial, you could use a USB device directly without a UART-USB converter if you wanted to save BOM size, not sure on your embedded experience or hardware though
Lumpio[m] has joined #rust-embedded
<Lumpio[m]> You have a pre-existing device that has a serial interface and connects to a computer? You would need USB host side support for that in your own device then.
<Lumpio[m]> s/serial/USB/, s/interface/port/
<Lumpio[m]> That would also explain it not being able to power the device, if the existing thing is a USB device side device and not a USB host side device.
<Lumpio[m]> ("Device side device" so confusing)
neceve has joined #rust-embedded
neceve has quit [Ping timeout: 255 seconds]
Foxyloxy_ has joined #rust-embedded
Darius_ has joined #rust-embedded
inara` has joined #rust-embedded
Darius has quit [Ping timeout: 246 seconds]
Darius_ is now known as Darius
inara has quit [Ping timeout: 246 seconds]
diondokter[m] has quit [Ping timeout: 246 seconds]
waveguide[m] has quit [Ping timeout: 246 seconds]
Foxyloxy has quit [Ping timeout: 246 seconds]
Guest7221 has left #rust-embedded [Error from remote client]
d3zd3z[m] has joined #rust-embedded
<d3zd3z[m]> Hopefully quick STM32H7xx question, I see mention of the NUCLEO-H745ZI-Q, with a BSP link. The BSP configures the HAL for the H747 instead of the H745, but does say it is tested.
<dirbaio[m]> the PAC has no feature for h745 specifically, so it uses h747 because it's "close enough" that it works
<dirbaio[m]> (this does mean you have to manually ensure not to use peripherals/pins available on the h747 but not the h745, it won't be checked at compile time)
waveguide[m] has joined #rust-embedded
diondokter[m] has joined #rust-embedded
firefrommoonligh has joined #rust-embedded
<firefrommoonligh> FYSA naively using it works for the basics, both cores
chodzikman[m] has joined #rust-embedded
<chodzikman[m]> <mabez[m]> "How long this will take to get..." <- compiler-builtins 0.1.103 was published with this change already, I am not sure if further actions are needed in rustc itself
<JamesMunns[m]> chodzikman[m]: Mostly just bumping dep versions, but if it works in nightly they already did that
<JamesMunns[m]> which means it'll ride the stable train down.
<chodzikman[m]> on that note, I had hard time using this fix in my embassy project because examples from esp-rs are building their own core and alloc to turn on emulated atomics... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/PAchJBixWGuwDvOkLsFPhNNT>)
<chodzikman[m]> perhaps imac target should be used instead with plain believe that crate that provide trap handling will be there?
<dirbaio[m]> > this was fetching compiler-builtins from crates.io no matter what I did
<dirbaio[m]> no, `build-std` uses the compiler_builtins source bundled with the rustup distribution
<chodzikman[m]> oh, ok... maybe it was misconfig on my side then
<dirbaio[m]> so it should get the latest fixes
<dirbaio[m]> using -imac and the atomic emulation trap should fix it yes
<chodzikman[m]> I had sort of capped time for this project and it was just before I needed to put it on hold, but simply changing it to -imac resulted in missing atomic types, but I'll try again in another attempt
<dirbaio[m]> oh well... i'm not an expert on the riscv atomic shenanigans
<dirbaio[m]> you might have more luck asking in #esp-rs:matrix.org
<chodzikman[m]> yep
crabbedhaloablut has quit []
Guest7221 has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
JonatanMagnusson has quit [Quit: Idle timeout reached: 172800s]