Archive for March 22nd, 2018
The chip reset seems remarkably slow, even at maximum VCC:
As far as I can tell, the
bitbang class handles all the setup and teardown around the actual data transfers, but it’s not clear (to me, anyway) how it interacts with the underlying hardware SPI machinery.
So, let’s add some sleepiness to the Reset code:
if self._RST is not None: self._gpio.output(self._RST, self._gpio.LOW) # Reset device time.sleep(1.0e-3) self._gpio.output(self._RST, self._gpio.HIGH) # Keep RESET pulled high time.sleep(1.0e-3)
A few milliseconds, rather than a few (hundred) microseconds, won’t make any perceptible difference.
Similarly, the Chip Select and Address (Command/Data) signals require more delay than might occur between successive Python statements:
This should do the trick, again with excessive delay:
if self._DC: self._gpio.output(self._DC, self._cmd_mode) time.sleep(1.0e-3) ... snippage ... if self._DC: self._gpio.output(self._DC, self._data_mode) time.sleep(1.0e-3) ... snippage ... if self._CE: gpio.output(self._CE, gpio.LOW) # Active low time.sleep(1.0e-3) ... snippage ... if self._CE: gpio.output(self._CE, gpio.HIGH) time.sleep(1.0e-3)
Although it shouldn’t be necessary, I blew away the
pyc files to prevent future confusion over who’s doing what with which.
Once again, this will require several weeks to see whether the situation changes for the better.