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