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
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 252 seconds]
cr1901_ is now known as cr1901
<re_irc> <willeml> What is the correct way of using an SPI device driver with esp-idf-hal when it requires direct access/ownership to CS and MISO pins? I am trying to use the SSD1681 display driver, or rather a fork of it that was made to compile for the esp32
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
lowq has quit [Ping timeout: 256 seconds]
<re_irc> <willeml> Or is there a way of changing what the SPI struct does on .write and .exec so that I can set chip select and MISO?
<re_irc> <gauteh> willeml: You can maybe use shared-bus if you have several devices on the same SPI pins
<re_irc> <gauteh> (works at least for I2C)
<re_irc> <gauteh> Doesn't each device have its own CS pin? So that it can take ownership of that one
explore has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
gsalazar has quit [Ping timeout: 240 seconds]
lowq has joined #rust-embedded
<re_irc> <willeml> That still doesn't fix the issue I have where the driver for the SPI device (a display) needs control of the MISO pin which the SPI Master takes ownership of when you "create" the SPI interface in code.
<re_irc> <firefrommoonlight> Not showing it take control of the MISO pin
<re_irc> <firefrommoonlight> That's not MISO
<re_irc> <willeml> The DC pin is the MISO pin AFAIK
<re_irc> <firefrommoonlight> DC is a GPIO
<re_irc> <firefrommoonlight> So is RST
<re_irc> <firefrommoonlight> and BUSY
<re_irc> <willeml> Its on the same pin as the MISO as far as I can tell looking at datasheets
<re_irc> <firefrommoonlight> It's not
<re_irc> <firefrommoonlight> There probably isn't a MISO pin, since the display is read only
<re_irc> <willeml> So I should put a dummy pin there for the SPI interface Master::new command?
<re_irc> <firefrommoonlight> I think all of those are required
<re_irc> <firefrommoonlight> so, no
<re_irc> <firefrommoonlight> Put a GPIO there
jr-oss_ has quit [Ping timeout: 256 seconds]
<re_irc> <firefrommoonlight> Busy is input (Display tells you when it's busy or not, which may take a while on EPDs!)
<re_irc> <firefrommoonlight> DC and RST need to be output pins, although I don't remember what they do
<re_irc> <firefrommoonlight> *I think DC indicates if you're sending a command, or display data
<re_irc> <willeml> Data/Command (select what is being sent) and RST is just to reset the driver
<re_irc> <firefrommoonlight> You set DC low if you're sending a command, and high if sending display data
<re_irc> <firefrommoonlight> Yep
<re_irc> <firefrommoonlight> it's not part of the SPI interface
<re_irc> <firefrommoonlight> Standard SPI interface pins are MISO, MOSI, and SCK. This display only uses MOSI and SCK, since the display is read-only. It also uses those additional GPIOs, which are _not_ part of the SPI interface
<re_irc> <firefrommoonlight> *Also uses CS obviously
<re_irc> <firefrommoonlight> willeml: I'm sorry - I misread this
<re_irc> <firefrommoonlight> I don't know how that HAL has it set up. If it requires ownership of a pin, not sure
jr-oss has joined #rust-embedded
<re_irc> <willeml> Oh cool, I was just writing a question about that 😄, the ESP32 hal requires ownership of the pin
<re_irc> <willeml> (more precisely esp-idf-hal)
<re_irc> - If ESP uses the pin, it would make sense to PR the hal to use an "Option<Pin>"
<re_irc> <firefrommoonlight> Ideally:
<re_irc> - If ESP doesn't, it would make sense to PR it to remove taking ownership
<re_irc> <firefrommoonlight> Ideally:
<re_irc> - If ESP's SPI peripheral uses the pin, it would make sense to PR the hal to use an"Option<Pin>"
<re_irc> - If ESP's SPI doesn't, it would make sense to PR it to remove taking ownership
<re_irc> <firefrommoonlight> (Example of former: nRF. Example of latter: STM32)
<re_irc> <willeml> Guess I'll have to figure out which of the two it is, also need to order a new devboard because this one is dead (let out the magic smoke when I pressed the reset "button")
<re_irc> <firefrommoonlight> *For now, maybe Dummy pin like you said, or a bogus pin you're not using elsewhere
<re_irc> <firefrommoonlight> Sry to hear about your board!!
<re_irc> <firefrommoonlight> Consider a smoke catcher for next ti e
<re_irc> <willeml> Haha, need to buy some of that IBM bottled magic smoke so I can refill my chips 😆
<re_irc> <willeml> Thanks the help though!
starblue has quit [Ping timeout: 256 seconds]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc> <Clark Kozak> Maybe I'm wrong, though shouldn't East point to the right, instead of the left: https://github.com/rust-embedded/discovery/blob/master/microbit/src/09-led-compass/src/led.rs
<re_irc> <Clark Kozak> When looking at the answer it looks very flipped when you map it onto a graph; for example; the range of "5PI/8" to "7PI/8" points to north west, though it would make more sense if it points to north east. Since it's postive, and points to the right
<re_irc> <Clark Kozak> Oh never mind. I got my graph wrong. It isn't very intuitive to have "EAST" point to the left
starblue has joined #rust-embedded
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded