I've got 5 TFT touchscreens (WaveShare) hooked up to a DUE using ILI9486 on MOSI/SCK and pins 22-52, with an external PSU.
One of the screens has an SD card and MISO hooked up. On this screen, touch events work as expected. Also, JPGs are rendered as expected from this SD card onto all 5 screens.
I'm hoping to be able to read touch events on the other four screens. Once I hook up another MISO, however, the SD card starts failing - either it won't initialize at all, or it will initialize but partially render JPGs as if MISO devices are conflicting somewhat. Also, any touch events on other screens get registered to the last initialized touchscreen.
It seems like I'm missing something fundamental about sharing MISO between mutiple devices (compared to MOSI)? Any tips in the right direction would be much appreciated!
I've got 5 TFT touchscreens (WaveShare) hooked up to a DUE using ILI9486 on MOSI/SCK and pins 22-52, with an external PSU.
One of the screens has an SD card and MISO hooked up. On this screen, touch events work as expected. Also, JPGs are rendered as expected from this SD card onto all 5 screens.
I'm hoping to be able to read touch events on the other four screens. Once I hook up another MISO, however, the SD card starts failing - either it won't initialize at all, or it will initialize but partially render JPGs as if MISO devices are conflicting somewhat. Also, any touch events on other screens get registered to the last initialized touchscreen.
It seems like I'm missing something fundamental about sharing MISO between mutiple devices (compared to MOSI)? Any tips in the right direction would be much appreciated!
Would you post a diagram of the circuit?
TO what are you hooking up the second MISO (master in, slave out)
Do you want the touch screens to be accessed separately?
DO you want to daisy-chain the touch screens?
in separate touch screens
sck of the master and the 'n' slaves is common.
mosi of master and the 'n' slaves is common.
miso of master and the 'n' slaves is common.
the master will need 'n' SS (Slave select) lines
in daisy-chain touch screens
sck of the master and the 'n' slaves is common.
mosi of master and and slave0 mosi are connected.
slave0 miso is connected to slave1 mosi.
slave1 miso is connected to slaveNth mosi
miso of master and the nth slave miso are connected.
ss of the master and the 'n' slaves is common.
in separate touch screen, each screen must wait to be polled by the master.
the slave touch screen cannot send data until selected.
there must be some agreement on when the slave screens will be polled by the master.
daisy-chain is fine for LED strips
If any data is being returned to the master is must be shifted through the 'n' slaves.
I could post a diagram but it'd take me a while to create one as I've never done so. I will though if it'll be useful.
Unfortunately, it seems I was confused. I can indeed connect the MISO of each TFT without causing real problems, it just seems a bit finicky - sometimes upon uploading a new sketch, the SD card doesn't initialize the first time the due loads, but then it works on subsequent reloads of the serial monitor. Since sharing MISO wasn't my problem, perhaps this thread should just die or get deleted...
If not, my issue with the touchscreens seems to be with using XPT2046_Touchscreen on multiple devices. I'm setting them up and initialize them as follows:
#include <XPT2046_Touchscreen.h>
XPT2046_Touchscreen ts(25, 23); // First
XPT2046_Touchscreen ts2(31, 29); // Second
XPT2046_Touchscreen ts3(37, 35); // Third
void setup(void) {
ts.begin();
ts2.begin();
ts3.begin();
}
void loop() {
if (ts.tirqTouched()) {
if (ts.touched()) {
TS_Point p = ts.getPoint();
Serial.print("1 Pressure = ");
Serial.print(p.z);
Serial.print(", x = ");
Serial.print(p.x);
Serial.print(", y = ");
Serial.print(p.y);
delay(30);
Serial.println();
}
}
if (ts2.tirqTouched()) {
if (ts2.touched()) {
TS_Point p = ts2.getPoint();
Serial.print("2 Pressure = ");
Serial.print(p.z);
Serial.print(", x = ");
Serial.print(p.x);
Serial.print(", y = ");
Serial.print(p.y);
delay(30);
Serial.println();
}
}
if (ts3.tirqTouched()) {
if (ts3.touched()) {
TS_Point p = ts3.getPoint();
Serial.print("3 Pressure = ");
Serial.print(p.z);
Serial.print(", x = ");
Serial.print(p.x);
Serial.print(", y = ");
Serial.print(p.y);
delay(30);
Serial.println();
}
}
}
But only the last initialized screen will send touch events. In the above example, the third screen would send touch events but not the first or second. If I initialize in a different order, such as:
ts3.begin();
ts2.begin();
ts.begin();
Then the first screen will send touch events but not the second or third.
There is one static variable to store the instance of the touchscreen. So only the last instance who's begin() method is called will be called for serving touch interrupts.
This touch library seems not usable for multiple instances with interrupt pin specified, as far as I can see.
Surely you would attach all the interrupt pins together. From memory, the IRQ pin is open-drain.
When you receive an interrupt, you scan each device to see which Touchscreen requires attention.
If you want to have separate interrupts for each device, simply edit the library to make *isrPinptr a (private) class variable.
The Due allows you to attach external interrupts to all pins. (The Uno only allows 2 external interrupts)
You are using an Adruino Due. That bit of finicky is not the touch screens it is the Due.
There is a past thread in the forums about how some Arduino Due boards do not reset properly:
They get "stuck". I have two such Arduino Due. I still have to fix them.
artisticforge:
You are using an Adruino Due. That bit of finicky is not the touch screens it is the Due.
There is a past thread in the forums about how some Arduino Due boards do not reset properly.
They get "stuck". I have two such Arduino Due. I still have to fix them.
Unfortunately, it seems I'm having an issue different than the "stuck" issue mentioned and a bit more problematic than I first realized. Indeed, I'm apparently having some sort of problems related to MISO. Here's the best way I can explain it:
With only one screen (the one with the SD card) plugged into MISO (in addition to MOSI/SCK), every time I reload the serial monitor the SD card loads upon first attempt. Once I plug any other screen into MISO, the SD card rarely reliably loads. Sometimes it takes a try or two through a loop, sometimes it takes dozens without succeeding. It seems like the more screens I plug into MISO, the greater the chance of failure, especially with 4 or 5 screens. Furthermore, the more screens plugged into MISO, the greater the chance of the SD card initializing but files not being found on it.
My setup loop tries to initialize the SD card until successful with 5 second pauses between each try.
My only other clue is that each time I reload the serial monitor and/or each time the 5 second loop runs, any screens plugged into MISO dim/flicker briefly, which the one with the SD card being the most obvious. This is despite using an external power supply for the screens.
As Jean-Marc said, MISO is tri-state when the SPI Slave is deselected.
I would guess that you have two or more CS pins active. A bus should only have one device active at any time.
Do you have a schematic for your screens?
Your Due is 3.3V. So there is no need for any level shifters.
Some "Arduino" displays are inappropriately designed e.g. the Esplora TFT
I would expect 6 slaves on the same SPI bus should be fine i.e one SD + five XPT2046.
David.
Edit. Ah-ha. You have Waveshare 3.5" displays that use 74HC4094 shift registers to drive a 8080-16 parallel TFT module.
The SD Card has got 4k7 pullups on MISO, MOSI, SCLK, SD_CS.
By the time you put 5 of these boards on the SPI bus, these pullups become an effective 940R pullups on the SPI signals even with empty SD cages.
Either remove R1, R2, R3 from each unused SD socket
Or replace each 4k7 with 47k.
The SD_CS 4k7 R4 is fine. You would have a separate GPIO line for each SD_CS anyway.
Wow, thanks guys. This is a bit out of my league, so much appreciated.
I'd hate to damage the screens so removing R1, R2, R3 on 4 of them seems the safer way to go. To clarify, it's enough to just remove R1/R2/R3 and leave the old connection open since I won't be using these 4 of the cages? Then if I might ever want to use these other 4 SD cages (or one of them) I could just add in 47k pullups later?
Also, could you please help me confirm where these 3 are based on the attachment? I think I've circled them in red. On my screens, these seem to say "472".
I am not going to try and guess your grainy photo. You can compare your pcb with the schematic. Identify R1, R2, R3 for yourself. Check with continuity from the SD cage pins 3, 5, 7.
My testing seemed to confirm the red ones I circled, so unless I tested wrong, I should have removed R1, R2, and R3. Unfortunately, things seem to be working the same as before with the SD card often failing, so maybe I did it wrong?
