Due to high demand, expect some shipping delays at this time - orders may not ship for up to 2-3 business days.
0

3.5" TFT library not conforming to SPI expectations
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

3.5" TFT library not conforming to SPI expectations

by davide3 on Tue Jun 28, 2016 2:49 am

According to the Arduino library file SPI.h,
Code: Select all | TOGGLE FULL SIZE
  // Before using SPI.transfer() or asserting chip select pins,
  // this function is used to gain exclusive access to the SPI bus
  // and configure the correct settings.
inline static void beginTransaction(SPISettings settings)


That is, SPI.beginTransaction() is supposed to be called before asserting the chip select pin.

But the HX8357 library is full of calls to SPI.beginTransaction() after asserting the TFT chip select pin.

For example, the drawPixel function sets the chip select pin low (asserting it), and then calls spiwrite(). Then spiwrite() calls SPI.beginTransaction().

Also, the SPI.endTransaction() is supposed to occur after the chip select is released. From https://rheingoldheavy.com/the-arduino-spi-library/, SPI.endTransaction() is called "...immediately after having raised the logic level of the CS pin back to high, signifying an end of the SPI interaction." But the HX8357 library calls SPI.endTransaction() before taking CS high.

Why doesn't the HX8357 library conform to the SPI requirements? What are the implications of not conforming? Could it be the cause of the issue I previously raised regarding mirroringhttps://forums.adafruit.com/viewtopic.php?f=22&t=89280 or this problem https://forum.arduino.cc/index.php?topic=408081.0

Should the HX8357 library be fixed?

davide3
 
Posts: 47
Joined: Wed Aug 14, 2013 5:21 pm

Re: 3.5" TFT library not conforming to SPI expectations

by adafruit_support_mike on Wed Jun 29, 2016 1:04 am

The library has to toggle CS outside the spiread() and spiwrite() functions to handle multi-byte operations. Putting the calls to .beginTransaction() and .endTransaction() inside spiread() and spiwrite() looks like a bit of code economy that isn't perfect.

I can't wholeheartedly say that moving the .begin and .end calls outside those functions would be better though.. that kind of "repeat this everywhere or something dies" code breeds its own bugs. We'll have to look at some options for refactoring that put all the operations in the best order without inviting a train wreck.

The existing code shouldn't have any effect on an SD card though.. both the SD card and the TFT are mode-0 devices, so there shouldn't be any clock glitches when the clock polarity is stored. The TFT runs at 8MHz while the default is 4MHz, but that only matters while the SPI clock generator is running. CS has to be low before that happens, and setting the clock rate shouldn't produce any signal on the SCK pin, so the order of operations there shouldn't matter.

adafruit_support_mike
 
Posts: 64527
Joined: Thu Feb 11, 2010 2:51 pm

Re: 3.5" TFT library not conforming to SPI expectations

by davide3 on Thu Jun 30, 2016 9:10 pm

Wouldn't something like this work to handle multi-byte operations "properly"?

Code: Select all | TOGGLE FULL SIZE
void Adafruit_HX8357::drawPixel(int16_t x, int16_t y, uint16_t color) {

  if((x < 0) ||(x >= _width) || (y < 0) || (y >= _height)) return;

  setAddrWindow(x,y,x,y);

  SPI.beginTransaction(SPISettings(8000000, MSBFIRST, SPI_MODE0));

  *dcport |=  dcpinmask;
  *csport &= ~cspinmask;

  SPI.transfer(color >> 8);
  SPI.transfer(color);

  *csport |= cspinmask;
 
  SPI.endTransaction();
}


I understand that overhaul of code is prone to generate problems, but it seems like leaving things as they are isn't....right.

davide3
 
Posts: 47
Joined: Wed Aug 14, 2013 5:21 pm

Re: 3.5" TFT library not conforming to SPI expectations

by adafruit_support_mike on Thu Jun 30, 2016 11:11 pm

It would work for that function, but that isn't the only function that communicates with the TFT.

You'd have to add the same transaction calls to every function that uses the SPI bus or there's no point in using them at all, and that kind of "do it everywhere" repetition is notorious for breeding hard-to-find bugs.

We'll have to think about ways to refactor the code that won't produce more bugs than they fix.

adafruit_support_mike
 
Posts: 64527
Joined: Thu Feb 11, 2010 2:51 pm

Please be positive and constructive with your questions and comments.