THE ISSUE
Because of some unfortunate SPI-compliance issues with an ST7920 LCD screen, (which seems not to fully respect slave select, and hence won't ignore crosstalk from other SPI devices) I've had to dedicate a software SPI connection on the following GPIO pins, in parallel with the Hardware SPI to drive an RFID reader...
Code: Select all
{
"miso":16,
"mosi":5
"sck":4,
"ss":15
}
FIXING THE ISSUE?
The issue at https://github.com/micropython/micropython/issues/2986 suggests it might be possible to omit the Mosi pin from the SPI declaration for devices with no actual MISO, but this is apparently not possible even in micropython 1.9 ( esp8266-20170526-v1.9.bin ). If I fail to set miso in the SPI function, I get...
Code: Select all
>>> from machine import SPI
>>> from machine import Pin
>>> screenMosi = Pin(5)
>>> screenSck = Pin(4)
>>> screenSpi = SPI(-1, baudrate=1800000, polarity=0, phase=0, mosi=screenMosi, sck=screenSck)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: must specify all of sck/mosi/miso
Is there any official way to set up a Software SPI without allocating MISO?
WORKAROUNDS FOR THE ISSUE?
Are there any other pins on a NodeMCUv2 that I can 'attach' to the Screen SPI MISO, especially given it doesn't even need to be broken out or wired to anything.
I have proven using GPIO1 or GPIO3 for MISO but using either of these kills my serial connection, so makes debugging very hard.
Are some of the flash pins free, if the NodeMCU uses dual IO for flash control, perhaps one of GPIO6-11 can be assigned to MISO without future impact.
Equally, since the screen and reader are both used at different times, the code is single threaded and 'guarded' by slaveselect, perhaps I can reuse some pins already in use for the Hardware SPI within the SoftwareSPI, wiring some subset of the SPI pins in parallel, but not so many that there is crosstalk (e.g. avoid sharing SCK so no clocking happens in the idle SPI). However, so far any attempt to share MISO,MOSI,SCK between software SPI and hardware SPI has been a failure. Perhaps it only works with certain pins. I've tried some different configurations, but so far all my experiments with sharing pins between Software and Hardware SPI have caused the reader's Hardware SPI to be non-responsive. Given the number of combinations I probably haven't tried all, but maybe someone can suggest likely-compatible configurations.
Welcome thoughts for other workaround pin specifications I can use to keep the SPI declaration happy, without actually sacrificing GPIO16 for no reason.