We are going to add SPI compatible device into Argon+Ethernet feather
But it looks like we cannot use both of SPI and SPI1 for our additional component.
I notice the SP1 is currently used for Argon Ethernet solution which is also something we need.
(SPI is used for main SPI for Wiz5500, SPI1 pins(D3, D4) are used for select pin and reset pin for Wiz5500)
Can we remap the pin assignments to align with our hardware design?
@chargeMan, @tommy_boy, because the DeviceOS operates asynchronously to the user thread, you can’t depend on the SPI bus being free. You would need to use SINGLE_THREAD_BLOCK() or ATOMIC_BLOCK() around the use SPI code to be sure.
@chargeMan, upon reflection I now believe that what is needed is a MUTEX and resource locking mechanism for the SPI port. Locking out the system threads will not guarantee at anytime that an existing SPI transaction has not been started. A MUTEX would allow both system and user threads to wait on the SPI resource. Problem is, if you do bulk transfers or use DMA, that creates a complex requirement. Ideally, device requests are queued and handled by a separate thread. This is way too mush of a hassle to implement IMO.
Problem is, the Ethernet Featherwing is hardwired so changing pins is not really feasible and spinning up a new board to change the CS and RST pins is likely not a bit priority for Particle. You may need to rethink your approach.