How to reuse SPI on other pins

[yanshay]

I'm using a board based on ESP32 that has a display interface, touch interface and sd-card, all on SPI but each on different pins (sck, miso, mosi, cs).

• If I understand it correctly, ESP32 has only two SPI interfaces, therefore I can only use two of these devices at the same time, is that accurate?

Let's say I can switch among them and not use all at the same time, for example start with the sd-card for initialization and then switch to use touch interface, my challenge becomes rust - how can I reuse a Spi, let's say SPI2, and change its pins after I used it for the sd-card.

When I try to reuse SPI2 with different pins for the touch, I get a compilation error that peripherals.SPI2 value used after move (because it was moved into the sd-card device).

• How can I solve that? I'm good with the sd-card not being used in favor of the touch interface.

[bjoernQ]

Sounds like an interesting design choice of that board to me. Are there schematics available for that board?

When you create the SPI driver you can pass the peripheral and the pins as &mut references instead of moving them into the driver. Then when you drop the driver you can recreate it

But usually there are multiple devices connected to the same SPI bus and the device to talk to is selected by its CS line

[yanshay]

• Sounds like an interesting design choice of that board to me. Are there schematics available for that board?

There's a repo dedicated to that board (but doesn't cover rust) - https://github.com/witnessmenow/ESP32-Cheap-Yellow-Display

Specific pointers to relevant technical information there:

• The PINS - https://github.com/witnessmenow/ESP32-Cheap-Yellow-Display/blob/main/PINS.md
• Schematics - https://github.com/witnessmenow/ESP32-Cheap-Yellow-Display/tree/main/OriginalDocumentation/5-Schematic

When you create the SPI driver you can pass the peripheral and the pins as &mut references instead of moving them into the driver. Then when you drop the driver you can recreate it

Thanks, that worked. It was enough to just pass spi as &mut. Not sure what the implications of not passing also the pins as &mut, maybe won't be usable later because they were moved and dropped together with the sdcard (first user of the spi).

[bjoernQ]

Good to hear you made some progress. Let me know if it really works for you in the end

[yanshay]

As wrote in earlier message it worked for me, at least for what I need so far, Thanks!

[bjoernQ]

Great! Closing for now ... feel free to re-open when needed

[yanshay]

I need some further assistance with this.

Originally I thought I could do with using first one device (sdcard) with one SPI and then from there on the use the other (touch) on that same SPI so the above solution was good enough. However, I need to use them both (switching from one to the other).

As a reminder -
The board is ESP32 based and has three SPI slaves (display, touch and sd-card), but each with its own bus (MOSI/MISO/etc.).
ESP32 has only two free HW SPI for me to use.

How can I share the two SPI's among three buses?

I know there is now a new separation between SPIDevice/SPIBus but even with that, if I get it right, the assumption is always sharing a bus among devices and not sharing HW SPI among buses, right?

I know in C++ this is supported as there is a project I know of using that same board that does this somehow.

Any ideas how to solve it if at all doable with the rust embedded_hal architecture?

[bjoernQ]

In theory the hardware would support reconfiguring the pins but the driver won't let you do it (since we could not guarantee safe usage and I currently don't see a way to create a safe API for this)

One thing you could do today is to pass the pins and the peripheral as &mut and drop the driver when done with one device - then you can re-create the driver again (and again use &mut). Probably not pleasant to do but should work fine this way

[yanshay]

That's a pretty severe limitation of the embedded_hal architecture, isn't it? Forcing Rust philosophy on a HW world that doesn't think in the same way. And it's not going to change for Rust.

Since I'm also using async with several tasks, each dealing with a different SPI (but not at the same time), it's going to be difficult to coordinate this dropping/recreating in a way that Rust compiler would allow it (even if technically I'll do it, the compiler would not know that).
Is there a way to workaround that in an easier way if I'm willing to use unsafe code? I couldn't find a way but maybe it's possible?

[bjoernQ]

You could try to disconnect / connect the pins yourself to the peripheral - e.g. the code which currently does it in the driver is here:

esp-hal/esp-hal-common/src/spi/master.rs

Lines 405 to 435 in dfad09d

	pub fn with_sck<SCK: OutputPin>(self, sck: impl Peripheral<P = SCK> + 'd) -> Self {
	crate::into_ref!(sck);
	sck.set_to_push_pull_output()
	.connect_peripheral_to_output(self.spi.sclk_signal());
	self
	}
	pub fn with_mosi<MOSI: OutputPin>(self, mosi: impl Peripheral<P = MOSI> + 'd) -> Self {
	crate::into_ref!(mosi);
	mosi.set_to_push_pull_output()
	.connect_peripheral_to_output(self.spi.mosi_signal());
	self
	}
	pub fn with_miso<MISO: InputPin>(self, miso: impl Peripheral<P = MISO> + 'd) -> Self {
	crate::into_ref!(miso);
	miso.set_to_input()
	.connect_input_to_peripheral(self.spi.miso_signal());
	self
	}
	pub fn with_cs<CS: OutputPin>(self, cs: impl Peripheral<P = CS> + 'd) -> Self {
	crate::into_ref!(cs);
	cs.set_to_push_pull_output()
	.connect_peripheral_to_output(self.spi.cs_signal());
	self
	}

[yanshay]

Thanks, interesting, I'll look into that.
So basically, assuming the only thing I need is to change are the pins (bus frequency for example the same), I can just call the with_* methods and change the pin?
And it's ESP specific I understand.

That's new code, not released yet into crates.io?

[bjoernQ]

Yes, that's changed API on current main branch. You can call connect_peripheral_to_output and connect_input_to_peripheral in your code
Probably you need to initialize the driver with some dummy pins and connect the right pins before you want to talk to the device

[yanshay]

I want to try this out. It seems that to use connect_peripheral_to_output and connect_input_to_peripheral I need to access the internal private spi field. I couldn't find a way to do that. Is there?

I also noticed that on main the entire consturction of Spi has changed and allows for creation of Spi with no pins, adding them only later. Will it also allow changing them after creation? It seems so, but I'm not sure. I couldn't try it out due to dependency conflict across all the libs I'm using (embassy/esp32).

[bjoernQ]

I need to access the internal private spi field

You probably want that to know which Input-/OutputSignal to use? You can just lookup what is used for your chip and use them

Probably it's currently possible to add more pins even after construction but there is no way to unmap pins this way. And also being able to add more pins after construction is probably not something we should support.

[yanshay]

I need to access the internal private spi field

You probably want that to know which Input-/OutputSignal to use? You can just lookup what is used for your chip and use them

I know the pins to use for each of the devices from the board's spec, so that's not the issue.
If I understood you correctly, to switch bus on a Spi driver, I need to call connect_peripheral_to_output on all the pins it controls, as in the code you refferred to above (copied here):

     mosi.set_to_push_pull_output() 
         .connect_peripheral_to_output(self.spi.mosi_signal()); 

Since I'm writing this in my own code, I would need access to the self.spi used in the argument. This is SPI2 or SPI3 but borrowed/owned by the Spi struct, so I don't have access to it through the peripherals and I need to gain access to the spi inside Spi struct.

• So my question was if there is a way to access that internal self.spi from the outside to use in that function call?

My plan is/was to create a shared Spi, let's say with SPI2, and dummy pins. Then before using the spi use these connect method to connect the required pins per the device needed, and switch between pins when I need to switch a device. I still don't have full understanding of how to do it Rust wise, but the starting point is being able to call the connect_ methods and that's where I'm stuck now.

• But maybe I misunderstand something?

Probably it's currently possible to add more pins even after construction but there is no way to unmap pins this way. And also being able to add more pins after construction is probably not something we should support.

Given that HW design is not always aligned with full SW safety, not even always with good HW design pratices, I think the SW should be flexible enough to support any HW with some reasonable, not main path, workarounds. Since many times HW can't be changed.
To me it seems that the right abstraction in this matter an ESP32 SPI, on which it should be possible to switch buses on which it should be possible to share devices. If I get it right, currently the ESP32 SPI and the bus are tied together at creation, and that's where my board doesn't fit the current abstraction to the point of being unprogrammable with Rust (while totally programmable with C++ which everyone else seem to be using with it).

[yanshay]

Happy to update - I got it to work!

The suggested approach here of changing pins on the SPI worked. Technically I eventually decided to recreate the Spi driver, but still behind the back of the real working Spi driver, just to be on the safe side but it wasn't required.

I couldn't find a Rust safe way to do that but then I found the 'workaround' I was looking for which is clone_unchecked.
Using clone_unchecked I think it's possible to workaround any case where the HW doesn't work well with the Rust safe way.

One code complexity which I understand is by design is the fact each Pin is a Type, so I can't just have a struct for example where I can just store four pins, I have to either specify which pins or deal with lengthy generics (I needed to switch between two sets of 4 pins, so total of 8 pins). I couldn't find a way to just specify a generic pin that also supported all traits I needed. I saw some AnyPin but couldn't get it to work.

Thanks for all the assistance!