Xenon with Ethernet Feather and TfT display

Trying to get and Adafruit Ethernet Feather working with the Adafruit 3.5"TFT display.

I’ve just have a simple sketch which has the Startup FEATURE_ETHERNET_DETECTION and nothing else.
If I have the Ethernet feather connected on it’s own it works fine. But when I connect the TFT display, all I get is a green flickering status and the last few debug output as below.

I’ve moved the TFT CS’s lines from D3,D4,D5 to D6,D7,D8 and have the Feather on D3,D4,D5.

Is there another pin I need to re map?

0000005905 [net.th] TRACE: Added FD61:ECAE:8BB::FF:FE00:FC00 0
0000005972 [net.th] TRACE: OT_CHANGED_THREAD_ROLE
0000006047 [system.ot] TRACE: IPv6 address was added
0000006105 [system.ot] INFO: Role changed: leader
0000006105 [system.ot] TRACE: RLOC was added
0000006171 [system.ot] TRACE: Partition ID changed
0000006172 [system.ot] TRACE: Thread network data changed
0000006238 [system.ot] TRACE: Subscribed to IPv6 multicast address

I think the problem is that, when using the Ethernet feature on Gen3 devices, you (currently) cannot use any other device on the same SPI interface since you have no control over the Ethernet stack which may at any given time pull its SS pin low either blocking or interfering with your concurrent SPI devices actions.

While both of the following conditions should be true for a painless concurrency, I’m not sure whether the Ethernet stack uses SPI transactions and if these transactions are actually blocking concurrent transactions in the Gen3 implementation of SPI.

And of course any concurrent library also needs to use transactions.

BTW, what do you mean with that?

There is only one CS line for any given SPI client device.
D3/D4 are the actual SPI1 communication lines MOSI/MISO which cannot be moved (unless you are using softSPI) - and where is your SPI clock?

And D7 is already connected to the onboard LED which may also interfere with softSPI.

1 Like

ScruffR is correct. It’s not currently possible to use SPI reliably on Gen 3 devices in an Ethernet FeatherWing.

In theory, if the library uses SPI transactions, the library would take over the SPI bus for the duration of the operation, then release it for other code to use it once the operation is done.

Unfortunately, there’s a bug in SPI transactions (0.8.0 through at least 1.2.0-beta.1) where the system and wiring (user firmware) each use a different mutex, thus they’re not actually protected against both using SPI at the same time, causing both to fail.


Rick, would this possibly apply to Gen2 devices as well as Gen3 - i.e. where 2 slaves are on SPI and controlled with 2 CS pins OR is this just for Gen3 and Xenon with Ethernet Featherwing?

Suggest you try either an I2C driven display (not going to be as good or as fast!) or something like the Nextion via the Serial.

Which Gen2 device would you expect to use SPI from system firmware opposed to application firmware?
I’m not really aware of any instance where Gen1/2 device OS uses SPI.

You have answered my question/clarification - only applies to Gen3 where with ethernet enabled the system is using the SPI. Thanks

1 Like

Hopefuly this will be remedied in later releases as it will be a show stopper for anything that would like to use both.

D2 to D8 is on the short side of the GEN3 board where all the SPI pins are on the long side. And with SPI, you generally don’t have to use the SPI’s CS line to do CS stuff if the device is the master. Both Device on thier own work fine without the other on thier corresponding pins (ANd when I say mapped I just mean rewired on the display board to connect the CS’s from the boart to the alternative pins)

What I still don’t understand is why just having the display board plugged in breaks the Ethernet feather. I’ve not yet initialized the User space SPI. Just wondering if there is another pin other than MSOI,MISO and SCK that is still being shared.

1 Like

Not sure what you mean by that.
I’m not sure what can be considered generally with SPI.
I’d think generally SPI was intended as a multi slave interface and thus CS/SS is usually required with the exception that you can omit the use of CS/SS for a bus with only one master and one slave.

If you have multiple slaves on the bus (which seems to be the case here - Ethernet and TFT) then the master must use the respective CS or SS line to actively talk to only one device at any given time.

Maybe if you can provide a schematic of your setup and the code you use we might understand your issue better.

1 Like