The problem is that these libraries are not compatible with each other (yet). Currently when installed on Arm including Teensy, the read and write to the SPI is done by bit twiddling. i.e.
[code]void UTouch::touch_WriteData(byte data)
{
byte temp;
temp=data;
cbi(P_CLK, B_CLK);
for(byte count=0; count<8; count++)
{
if(temp & 0x80)
digitalWrite(T_DIN, HIGH);
else
digitalWrite(T_DIN, LOW);
temp = temp << 1;
digitalWrite(T_CLK, LOW);
digitalWrite(T_CLK, HIGH);
}
}
word UTouch::touch_ReadData()
{
word data = 0;
for(byte count=0; count<12; count++)
{
data <<= 1;
digitalWrite(T_CLK, HIGH);
digitalWrite(T_CLK, LOW);
if (digitalRead(T_DOUT))
data++;
}
return(data);
}
[/code]
But the display code is using the hardware SPI. As the CS pin in this case pin 8 is not one of the IO pins that can be directly controlled by the hardware SPI CS processing (2=10, 9=6, 20=23, 21=22, 15), note the ones with = are alternative pins, so only for most part only one of the two can be used, unless you do fancy footwork. Note: the ILI9341 driver is using the high speed SPI where the SPI hardware itself controls the CS and DC signals for the display and as part and as such it updates the Pin MUX for the SPI pins to mode 2 (SPI). But the bitblitting code assumes it is in mode 1… So one will stomp on the other…
But code can be udated to work like what I did the STMPE library, where if the MISO, MOSI, SCLK are the right pins for the hardware, it can use the standard hardware SPI library. Which would get you part way there. BUT then you run into the next issue that I had with my test program. Both the ILI9341 driver and the SPI library both muck with some of the SPI registers. Details about these registers are in the datasheet for the processor (pjrc.com/teensy/K20P64M72SF1RM.pdf)
So in my test program, I had to detect when I was switching gears between the two SPI devices and restore registers. There are still parts of this I wish to figure out better. Also wondering about how some of this code is setup. Will probably ask some questions up on Teensy forum.
Note: Our problem about multiple devices conflicting is not unique. In fact Paul (PJRC - Teensy), is working on some ideas on this, along with some of the main Arduino people. Hopefully they will come up with a standardized way to deal with some of this.
If I get a chance maybe I will muck up the UTouch library the same way I did with the other one and also hack up some calls to do the mode switching and see if I can get their example to work.
Kurt
