Device-os: Ethernet FeatherWing uncooperative with other SPI clients

[ScruffR]

As it seems Gen3 devices that are using the Ethernet FeatherWing for their cloud connectino can't be (safely) used with other SPI devices as there appears to be no synchronisation of mutual access to the bus.

IMO the device OS should at least check for currently active SPI transactions and refrain from claiming the bus then.
But an additional means to temporarily prevent the system from grabbing hold of SPI via a dedicated Ethernet.xxxx() function would be helpful for application code (e.g. libraries from before the time where transactions were introduced).

One forum discussion in that regard
https://community.particle.io/t/xenon-sd-card-and-ethernet-not-working/48238

[rickkas7]

It looks like the Wiring interface maintains its own mutex in beginTransaction() and endTransaction():

https://github.com/particle-iot/device-os/blob/develop/wiring/inc/spark_wiring_spi.h#L228

However, the Wiznet code uses HAL_SPI_Acquire with a different mutex:

https://github.com/particle-iot/device-os/blob/develop/hal/src/nRF52840/spi_hal.cpp#L488

I'd guess that the Wiring API should probably use HAL_SPI_Acquire / HAL_SPI_Release.

[ScruffR]

Another sore-point in connection with that is that the Ethernet FeatherWing also kills the use of SPI1 as an alternative for any additional SPI client due to the poor choice in pin mapping for nReset and nInterrupt which hog the MOSI1 and MISO1 pins and are currently hard wired in PCB and code.

[shanevanj]

Using an SD card alongside Ethernet is probably a pretty high feature requirement esp. in gateways where you may need an audit trail for evidentiary purposes or just a ring buffer for when the Internet disappears.... Can I suggest that the current SS definition be used as a default for the SD card (as it is already defined in the default examples of the SdFat library (I/O 14 or A5) - this would make it easier to do preemptive designs now that will work once this issue is resolved.

[jimmie11]

I am noticing the same issue. I am using an Adafruit SD Feather (changed CS to A0) with a Xenon in an Ethernet wing. I keep getting read problems on the SD card.

As shanevanj mentioned above, using an SD card along with the Ethernet wing is vital in my application as the system reads key parameters from it.

[innoagg]

The inability to remap the pins for nReset and nInterrupt are affecting us as well. We have to be able to have 2 slaves on a bus or be able to use 2 spi buses.

[shanevanj]

I suspect the DeviceOS has restrictions on interaction and this has caused the issue, A similar related issue for me is that I cannot issue the ethernet port a static IP (often required in a security context where absolute device control is mandated).

Perhaps DeviceOS must move towards supporting SPI transactions like this Arduino Library allows - https://www.arduino.cc/en/Tutorial/SPITransaction - reserve CS pins for the known peripherals (ETH / SD /...)

[shanevanj]

Another sore-point in connection with that is that the Ethernet FeatherWing _also_ kills the use of SPI1 as an alternative for any additional SPI client due to the poor choice in pin mapping for nReset and nInterrupt which hog the MOSI1 and MISO1 pins and are currently hard wired in PCB and code.

...and removes the second I2C from play as well as the CTS/RTS pins of Serial1. If these pins were moved to a general IO such as D6/D8 (yes and some will cry foul, but you get back an extra SPI bus and the RTS/CTS function as well as the second I2C - which if not used can be used as IO instead) , you now at least have SPI1 for your SD if the SPI0 bus is to be reserved for ETH only and the device suddenly becomes _MUCH_ more useful. To have 2 such subsystems disabled by what appears to be an arbitrary pin assignment is really a waste.

[ScruffR]

A SW enhancement will be implemented and a HW rework is considered by Particle too.
There is just no ETA for either yet.

Perhaps DeviceOS must move towards supporting SPI transactions

SPI transactions are used but due to some "miscommunication" two independet mutexes are used for the application and the system transactions :blush:
That bug will be addressed too.

[avtolstoy]

Fixed in https://github.com/particle-iot/device-os/pull/1879, released in 1.5.0-rc.1.