2.8 ILI9341 restive touch miso not connected ?

[defragster]

I tried a hardware driven interrupt version of XPT2046_Touchscreen/ /examples/TouchPaint/TouchPaint.ino

It failed to function even after resolving the cascading issue.

I punted and started up a TimerInterrupt that will check for touch and works exactly the same as I modeled the Interrupt version. Somewhere the HDW interrupt chain is broken where the timer chain thrives?

Infact with three lines swapped the hardware version works intermittently where the Timer version works well - the initial touch may take 50ms to be caught - but then input is read every 10ms during the touch. So that is polling 20 times/sec and sometimes a touch is missed. Any touch is recorded then if the user app asks or not. From there as often as the user requests touch data it will be provided during a touch - on the adjustable 10ms boundary.

<edit>: the hardware interrupt is alive just fine and cascading badly. The problem is the restraint I put on it somehow makes it miss too many touches and fails to report them. I cleaned the edges and made it work on the timer and all is as expected. Time or HDW it should work the same - or at least show something different than I was seeing.

[cartere]

@defragster do you have the latest and greatest on gethub ( looked but did not see anything that looked like timer interrupts )? Been trying to use the Adafruit_Gfx_Button functions, my main frustration is trying to change the button background color when it is being pressed and back to normal on release but justReleased() just does not work. Think it might be time to abandon the Adafruit _Gfx_Button and give your code a try.

[cartere]

OOPS see it now, was looking in the wrong place.

[defragster]

cartere - let me know what you see.

[cartere]

Tried running the isr touch paint demo, runs until I try to draw on the screen, get a short line then the teensy hangs. I am on arduino 1.6.5 and teensyduino 1.26 beta-1 using your touch driver. Getting late ( not as young as some ) and will update to current release tomorrow.

Never mind - works much better with a serial monitor window open

[defragster]

Odd the SerMon windows made a diff?

Odd that it acted that way.

<edit> Not sure if you got my updated touchscreen.cpp - it will be in the next release.

[Twinscroll]

Hi,

I got my 2.8 TFT through today.
Connected it up and the screen and Touch (not using IRQ method) are working great.
The screen is slightly more "dull" than the 2.2", but I guess that is unavoidable with the extra touch element on the front of the screen.

I thought that I would give the SD card connections a go, as I would like to use an SD card for a logger.



However I have run into an issue as I am unable to establish any connection to the SD card.
I am using code that does work on another project, so I do think that the issue is hardware related.
I have offline continuity checked all the connections, all 'appears' ok from first pass, i.e all signals make it to their correct location on the SD socket - none of the lines are connected together (short between signals) or short to GND / Supply etc.

I have a known good SD card (works in another project using a micro SD socket) - and that same card is fitted into a functional micro > full size SD card adapter.
I get the same result from a 2nd (full size) SD card.

*edit - Just for clarity I am using Pin 8 for the Touch Screen Select, Pin 9 for the TFT Screen Select and Pin 10 for the SD_CS,

I am beginning to wonder if my wires (although fairly short to be honest) are creating nasty stubs and impacting the signal integrity (reflections) in some way.
Seems odd that the same MISO / MOSI and Clock signals drive the TFT and touch ok though......
I am going to look tonight with the scope, to see if there is anything looking amiss.

Just wondered, has anyone else got an SD card up and running OK on this board?
I should have tested before removing the 1K series resistors (replaced with Zero ohm links) but I was enjoying some soldering iron time!

Thanks

[defragster]

I just posted a sample that demonstrates INTERRUPT PIN USAGE as I made it work: https://github.com/Defragster/XPT204...chPaintDeb.ino

I should start a new Thread for this and I'll be updating my prior examples and adding them to this GitHub for the Struct'ured button handling I did. I did it on the TouchPaint - but it was - like this interrupt code - just the work area to test the concept.

One of the displays I got turned out to be defective (noted above) and is being replaced - Thanks Robin! When I found I didn't need to return it - I could HACK IT! - I was going to use it as a test bed for SDCARD access - I didn't wire it up yet, but I found when I closed the J1 jumper the screen came back! That 'component' on VCC is bypassed and it must have been the problem on my display. I suspected that might be that case as the WHITE SCREEN is what you get when you don't power the VCC pin.

I will run my wires to the SDCARD connect soon and post my results as I also put shorts over where the three resistors were when I soldered the J1 closed. And I re-taped the display down and it is still working after running the Interrupt code [ PIN and TIMER ] overnight from a USB battery pack.

So on two 'systems' with and without Pin interrupt they run from a USB pack - overnight and still working - I'm not sure why the post above showed failure without USB connect?

The Timer in the sample is running very fast and a well lit SPI LED - but the Interrupt device has no Touch SPI until it is touched, but the app does clear the Paint area every two seconds when not touched. This was handy for testing so I could keep testing paint on a black screen.

I also abused the lower part of the display for debug SPEW lines - made it easier to see activity ONSCREEN while I touched instead of also having to watch the USB that scrolled like crazy on interrupts.

[Twinscroll]

I spent the evening going over as much of the hardware as I could check.
The various SPI signals all look clean, good solid edges / no glitches etc.
Power rails remain solid etc.

From my investigations I was actually able to get the SD card on the Screen to function, and I also got it to function along with the TFT screen.
However, once I introduce the Touch Screen MISO line into the MISO net (i.e the return to the Teensy) – the SD card no longer functions.

I actually get the same response with my other SD card holder too – i.e not using the SD socket on the 2.8 TFT Touch screen.
It appears like maybe some form of interaction between the SD card SPI communications and the Touch SPI communications? Im not sure and will get out of my depth debugging the SPI code very quickly!
I actually even tried removing the Touch CS line, but the issue persisted……odd.

What is worth noting is that the Touch and TFT play happily together (as you would expect).
The TFT and SD card play happily together too (as I have outlined above).

This does make me start wondering if there is a reason that the SD card is on its own SPI bus (i.e not connected in with either of the other buses present on the screen) but that could be for other reasons.

I would really like to hear if anyone gets the 3 items up and running together.
TFT / Touch and an SD card (doesn’t have to be the SD card on this screen).

Thanks
Keith

[defragster]

I got mine working! Followed the linked edits indicated - Solder over J1 and wire jumper replace the three resistors going to SD.

I took the common SPI lines to my shared Touch and 9341 lines (no pullups on this board) to the three SPI lines Miso/Mosi/Clk and then added CS:

* SD card attached to SPI bus as follows:
** MOSI - pin 11
** MISO - pin 12
** CLK - pin 13
** CS - pin 4

I took and SdFileListDump.ino and dropped at the bottom of my IntTouchPaintDeb.ino and has main setup call the renamed SD setup2() and it worked! I even called it within the touch code and it runs to USB out.

This is the display that was not getting VCC until soldered over the J1 - it is now working in full for the last 24 hours. The SD card I picked has dozens of files and it did a good directory.

NOTE: When the TOUCH triggers I queue a read for the next user code query. It does not complete a read during the interrupt. It is up to the user code to request data when the code is ready to read it. As it exists the Interrupt code prevents the need for user polling until a Touch happens - but without implementing a user callback I can't force the user code to act on it until it sees the flag by asking for a point. And my debounce code requires two reads about the same pixel to call it good to return. Unless I make it read and buffer a few points to return - until the user code calls the touch is lost.

[Twinscroll]

That is great news. Thanks for testing so quickly - though obviously it makes me wonder what's going on with mine still haha

I will start afresh again today, remake the SPI wiring links ( those ended up isolated back during my investigations). I will load your code and try and replicate what you are dong that works !

It is interesting that you are using pin 4 for the SD cards CS line...I will try moving mine from pin 10 to that resource and testing again.

I will test today and let you know.

Thanks for your input.

[defragster]

@Twinscroll - I was already half done - edited the display board - just needed to hook it up - so I did as I wanted to see if it worked.

I have "#define TFT_CS 10" on mine - and the one sample I loaded seemed to suggest 'CS 4' so I went with that as I had used it on stand alone micro-SD.

Here is a pic with the SD lines in place. They are plugged into a header to make them removable. I also did the touch_int to pin 2 before the pic, and it works.

<edit this ugly board also has a battery and RTC clock

I now have the PJRC OSH board and PSupp parts for the touch so I'll build a better one.

The code I used is on : github.com XPT2046_Touch_Examples/ /IntTouchPaintDeb_SD/IntTouchPaintDeb_SD.ino

It shows that I implemented interrupts about halfway. Touch is detected - but not acted on until user code asks. I may look to fix that - but I had issues and what went stable works like this - because of how I do the Touch reading and worked around the interrupt during interrupt re-entrancy prevention.

[Twinscroll]

@defragster.

I rushed into work this morning and re-soldered up the connections, and retested and..................................It lives!!!!
I have the SD card / Touch and TFT all operating.



I will need to go back over my 'non working' setup, and do a proper comparison against yours.

Thank you so much for posting that code example.
I will update again once I have worked out anything of value.

Best Regards, have a great weekend.
Keith

[defragster]

@Twinscroll , Great news - glad I could offer you encouragement and a sample. I went on blind faith and dumb luck. As you can see my board isn't pretty - but it works. The PJRC OSH Display board puts on 10K pullups - not sure how that affects - will build one and see.

Good news is at least two of the new Touch ILI9341 screens have been edited to work per the directions that were suggested for the old Non-touch: this hardware modification may be able to get it working

[bboyes]

This color touchscreen work is so excellent: thanks to Paul, and everyone else contributing, and Adafruit for the GFX library. This has become my "go to" display for quick prototypes: with a Teensy 3.2, the purple board of Paul's, and the 2.8" TFT.

According to the best data we could find, it is OK to run the backlight at 60 mA per LED. There are four in parallel so that means 240 mA! There is a 4.9 ohm series resistor with the ganged anodes already on the TFT board. I replaced the 100 ohm purple board resistor with 5 ohms (the smallest TH part I had) and the backlight pulls 160 mA, plenty safe I would think, and the display is SO much better with a brighter backlight. We'll run it at 160 mA and then drop to 20 mA if there is no touch for say 15 seconds, just like tablets and cell phones dim the display.

We have spun our own board for a medical device prototype, and put a PFET at the top of the backlight anodes so we can PWM the backlight since we will run on batteries. I'll post more about all that once I get the board up this weekend. It's a rush project. We also have our laser driver on board, with both programmable current (capable of 700 mA or more, we are using 400 mA now) and PWM, with a closed loop servo to make the current stable and accurate. We put on 128 MBit serial flash (we can't use the huge SD card on the display in our package), a speaker, I2C temp sensor near the FET, and a few other things. It is running off a 3S R/C model battery pack with something like 14 watt hours, so it has plenty of juice. We have switcher modules for 5V and 3.3V, and use the low cell in the pack to keep the Teensy RTC running when the power switch shuts off both regulators. Our board stacks under the LCD, with standoffs in the four corners.

Immediately I have to decide whether to use bitmaps for screen buttons or simple programmatic graphic buttons. For this first prototype we have only a main screen and four sub screens with data entry (it's driving a 400 mW laser, setting current, on/off time and number of cycles).

When we are ready for production we can get displays from a reputable source, with the same or similar driver, so I am OK with using Chinese displays of unknown provenance for the prototypes. We've done some testing of 100+ hours here and so far the cheap displays are holding up well.

At the moment I'm writing test code to do some simple statistics on touches so I can decide on screen calibration and button size so that operation is reliable. We need operation with just a finger and through exam gloves too, so resistive touch might be actually better than capacitive in this case (though we plan to test cap touch also).

I'm done with character LCDs and mechanical pushbuttons when you can get these screens for $12 or less!

Thanks again to Paul and the awesome community!

[Frank B]

Yes, i'm running the backlight the same way, via PWM, and a small resistor (i use 10 ohm).
You're right, brighter is much better. I'm using it together with the Audioboard, so i removed the unused SD slot from the display.

[rfresh737]

After way to much effort here is the onoffbutton example modified for the new touchscreen.

Attachment 5405

Considering the way to much effort to get one little widget working any thoughts on a widget library that could be modified?

Do you XPT2046_Touchscreen.h ? I got a compile error because it couldn't find this file.

Thanks...

[cartere]

Yes it is in the latest Teensyduino release

https://forum.pjrc.com/threads/31351...ll=1#post87513

[rfresh737]

OK thanks...got the latest Teensyduino release and now the skitch comples and runs. I see a black outline square with the word No in the upper left corner and next to it a filled in red square. I touch them and the screen but see no changes...I'm not sure what I'm supposed to see but I guess this means my touch wiring isn't correct?

[cartere]

You might look at this
https://forum.pjrc.com/threads/30559...ll=1#post86156

[rfresh737]

I can run that sketch but when I touch nothing happens...I must not have my TFT wired up correctly for touch...I will try to find an example showing how to wire it for touch and double check my wiring...thanks...

[Twinscroll]

I was just scanning over the GitHub readme file for the touch XPT2046.

I am curious, and this may highlight my level of c programming knowledge - but why would you opt to use the readData () method to obtain the touch position over the getPoint () method or vice versa?

Thanks guys

[rfresh737]

So my TFT touch pins must not be wired correctly.

I found this link showing how to wire the 4 touch pins:

https://learn.adafruit.com/adafruit-...v2/touchscreen
Touchscreen Paint (SPI mode)
An additional 4 pins are required for the touchscreen. For the two analog pins, we'll use A2 and A3. For the other two connections, you can pin any two digital pins but we'll be using D9 (shared with D/C) and D8 since they are available. We can save the one pin by sharing with D/Cbut you can't share any other SPI pins. So basically you can get away with using only three additional pins.
Wire the additional 4 pins as follows:
Y+ to Arduino A2
X+ to Arduino D9 (Same as D/C)
Y- to Arduino D8
X- to Arduino A3

But on my TFT I don't have Y+ x+ Y- X- pin labels on my TFT board.

On my TFT board my 4 Touch pin labels are:

T_IRQ -- A2? A3? D8? D9?
T_D0 -- A2? A3? D8? D9?
T_DIN -- A2? A3? D8? D9?
T_CS -- A2? A3? D8? D9?
T_CLK -- ???

I attached my 4 wires to my 3.2 Teensy board (A2, A3, D8, D9) so now I need to connect them to the correct TFT Touch pins???

Thanks for any help!!

[defragster]

I can run that sketch but when I touch nothing happens...I must not have my TFT wired up correctly for touch...I will try to find an example showing how to wire it for touch and double check my wiring...thanks...

The wiring works per the link in this thread that goes to the PJRC page: https://forum.pjrc.com/threads/30559...ll=1#post85727

@Twinscroll - the two functions do the exact same behavior on the touch side -it is just a preference to the way the point is returned. ReadData takes 3 pointers and when called updates the data stored in the pointers, getPoint just returns a one pointer to the library stored structure of values. Two different ways to do the same thing, perhaps for compatibility reasons to other similar systems?

[defragster]

So my TFT touch pins must not be wired correctly.

If you have the PJRC style board - the SPI pins are shared - the only unique pin per device is the Chip Select. Not sure if this snippet from the code will help see the wiring if you have the PJRC XPY2046 controlled touch.
If you have the AdaFruit hardware with real Analog values from the touch - it isn't using the same touch controller - it would be like was used by another poster on this thread. In that case find his posts - it required directly reading and interpreting the analog values.

// The XPT2046 uses hardware SPI on the shield, and #8
#define CS_PIN  8
#define TIRQ_PIN  2
XPT2046_Touchscreen ts(CS_PIN);
// The display [MOSI=11, MISO=12, SCK=13] also uses hardware SPI, plus #9 & #10
#define TFT_CS 10
#define TFT_DC  9
ILI9341_t3 tft = ILI9341_t3(TFT_CS, TFT_DC);