Trouble using different CS and DC pins on Teensy 3.2 with ILI9341 touchscreen

[bboyes]

I'm using two identical sets of Teensy 3.2, with Paul's ILI9341 adapter board and the 2.8" touchscreen. I have a version of the touch test working fine.

I want to use different CS and DC pins so that I can also use the WIZ820io Ethernet adapter. So on the one display adapter we hacked the traces so we can move CS and DC.

But I can't get any alternate CS and DC pins to work. I change them in the code here:

#define TFT_CS 6    // 10 is default, different on ethernet/touch combo
#define TFT_DC 5    // 9 is default, different on ethernet/touch combo

// MOSI=11, MISO=12, SCK=13

XPT2046_Touchscreen ts(CS_PIN);

ILI9341_t3 tft = ILI9341_t3(TFT_CS, TFT_DC);

The touchscreen still works and outputs to the USB Serial Monitor. If I look at the TFT CS pin on a scope, it is always high, never goes asserted. DC is changing.

I've tried DC on digital pin 6 and CS on pin 5 or pin 15, same result. Something is not allowing the alternate TFT CS to assert low.

What am I doing wrong?

Thanks

 

[WMXZ]

did you try to declare the cs pin as output before using it?

pinmode(TFT_CS,OUTPUT);

 

[PaulStoffregen]

But I can't get any alternate CS and DC pins to work. I change them in the code here:

#define TFT_CS 6    // 10 is default, different on ethernet/touch combo
#define TFT_DC 5    // 9 is default, different on ethernet/touch combo
[/QUOTE]

Only pins 9, 10, 15, 20, 21 are supported by ILI9341_t3.  This is documented on the display pages:

http://www.pjrc.com/store/display_ili9341.html
http://www.pjrc.com/store/display_ili9341_touch.html

Pins 5 and 6 aren't supported.  If you're using 9 and 10 for the Wiz820, then you have 3 pins left to choose: 15, 20, 21.  Pick any 2 of those 3.

 

[bboyes]

Thanks: I must have looked at that table of Connections 10 times and didn't notice the list of alternate CS and DC pins. That's what I get for working late in a bit of a panic. Sometimes it's better to just call it quits and take a fresh look the next day. I will try this again today.


On a related note: display RESET is tied to 3.3V, but I have seen the display sometimes not start up correctly - weird color patterns getting drawn across the screen and I wondered if that was because the display hadn't had a clean reset recently enough. Removing and applying power gets it out of that funky state. So if we do assign the reset to some processor pin, when does the driver assert that? (On our own board we plan to drive the display reset from a system reset signal which comes from a power supervisor chip and could also be driven by a watchdog.)

 

[bboyes]

did you try to declare the cs pin as output before using it?

pinmode(TFT_CS,OUTPUT);

We did and that stuck CS low. We were not using one of the special SPI pins, as it turns out.

 

[Frank B]

So if we do assign the reset to some processor pin, when does the driver assert that? (On our own board we plan to drive the display reset from a system reset signal which comes from a power supervisor chip and could also be driven by a watchdog.)

You can use a teensy-pin as reset:

ILI9341_t3::ILI9341_t3(uint8_t cs, uint8_t dc,[U][I][B] uint8_t rst[/B][/I][/U], uint8_t mosi, uint8_t sclk, uint8_t miso)

If rst is not controlled by the teensy, make sure that the display is ready (after reset) before begin() is called.

 

[bboyes]

You can use a teensy-pin as reset:

ILI9341_t3::ILI9341_t3(uint8_t cs, uint8_t dc,[U][I][B] uint8_t rst[/B][/I][/U], uint8_t mosi, uint8_t sclk, uint8_t miso)

If rst is not controlled by the teensy, make sure that the display is ready (after reset) before begin() is called.

The PJRC adapter ties display reset to 3.3V, so I'm not using that at the moment. Is the reset output defined in the constructor actually used? And if so, when - the begin() function?

I'm a bit suprised that if you call the ILI9341_t3 constructor with bad values there is no exception thrown. Maybe that is bad practice for a constructor but maybe a flag could be set? Just wondering... it bothers me when things just quietly fail.

 

[bboyes]

Only pins 9, 10, 15, 20, 21 are supported by ILI9341_t3. This is documented on the display pages:

http://www.pjrc.com/store/display_ili9341.html
http://www.pjrc.com/store/display_ili9341_touch.html

Pins 5 and 6 aren't supported. If you're using 9 and 10 for the Wiz820, then you have 3 pins left to choose: 15, 20, 21. Pick any 2 of those 3.

OK, to allow for use with Ethernet, I chose DIO20 and 21 as TFT_CS and TFT_DC. LCD working just as expected with these pins.

 

[bboyes]

Now Ethernet and touchscreen can co-exist!

And I am happy to report that I have a stack of PJRC touchscreen adapter, Teensy 3.2, and PJRC WIZ820io adapter all together, and I can run the touchscreen test program, or run the DHCP stress test, and each works separately. Now I can move on to integrate the software to support displaying Ethernet status and traffic data on the touchscreen. This opens up some new commercial applications which I will be prototyping for customers.
<Later>
Well, mostly. There seems to be an issue where if the 820io is present, you can't just ignore it. If it is not properly reset it clashes with signals on the Touchscreen and the touch controller thinks there are continuous touches... this sounds like the 820io W5200 reset weirdness previously reported.
If the 820 is reset then it lets me use the screen. So to touchscreen-only code, if the WIZ820io is present but otherwise ignored, I add this code

#define ETHERNET_RESET 9	// WIZ820io
  /**
   * WIZ820io/W5200 must be at least reset to avoid it clashing with SPI
   */
  pinMode(ETHERNET_RESET, OUTPUT);
  digitalWrite(ETHERNET_RESET, LOW);
  delay(1);
  digitalWrite(ETHERNET_RESET, HIGH);
  delay(200);

And now the combined system powers up OK.

 

[PaulStoffregen]

Yes, the W5200 always need a reset, if used together with other SPI chips.

That's why we've had the "Chip Select Pins During Initialization" code at the bottom of the Wiz820+SD product page. It's also the reason why we redesigned that board to have a dedicated reset chip, so the W5200 gets properly reset even if you don't put that code into your program.