2.8 inch spi tft lcd ili9341 not working made in china

2023-01-03 12:32:11

C:\Users\User\Documents\Arduino\libraries\Adafruit_ILI9341\Adafruit_ILI9341.cpp: In constructor "Adafruit_ILI9341::Adafruit_ILI9341(int8_t, int8_t, int8_t, int8_t, int8_t, int8_t)":

C:\Users\User\Documents\Arduino\libraries\Adafruit_ILI9341\Adafruit_ILI9341.cpp:184:15: error: cannot convert "volatile uint32_t* {aka volatile long unsigned int*}" to "volatile uint8_t* {aka volatile unsigned char*}" in assignment

C:\Users\User\Documents\Arduino\libraries\Adafruit_ILI9341\Adafruit_ILI9341.cpp:186:15: error: cannot convert "volatile uint32_t* {aka volatile long unsigned int*}" to "volatile uint8_t* {aka volatile unsigned char*}" in assignment

C:\Users\User\Documents\Arduino\libraries\Adafruit_ILI9341\Adafruit_ILI9341.cpp:188:17: error: cannot convert "volatile uint32_t* {aka volatile long unsigned int*}" to "volatile uint8_t* {aka volatile unsigned char*}" in assignment

C:\Users\User\Documents\Arduino\libraries\Adafruit_ILI9341\Adafruit_ILI9341.cpp:190:17: error: cannot convert "volatile uint32_t* {aka volatile long unsigned int*}" to "volatile uint8_t* {aka volatile unsigned char*}" in assignment

C:\Users\User\Documents\Arduino\libraries\Adafruit_ILI9341\Adafruit_ILI9341.cpp:193:21: error: cannot convert "volatile uint32_t* {aka volatile long unsigned int*}" to "volatile uint8_t* {aka volatile unsigned char*}" in assignment

C:\Users\User\Documents\Arduino\libraries\Adafruit_ILI9341\Adafruit_ILI9341.cpp: In constructor "Adafruit_ILI9341::Adafruit_ILI9341(int8_t, int8_t, int8_t)":

C:\Users\User\Documents\Arduino\libraries\Adafruit_ILI9341\Adafruit_ILI9341.cpp:211:15: error: cannot convert "volatile uint32_t* {aka volatile long unsigned int*}" to "volatile uint8_t* {aka volatile unsigned char*}" in assignment

C:\Users\User\Documents\Arduino\libraries\Adafruit_ILI9341\Adafruit_ILI9341.cpp:213:15: error: cannot convert "volatile uint32_t* {aka volatile long unsigned int*}" to "volatile uint8_t* {aka volatile unsigned char*}" in assignment

2.8 inch spi tft lcd ili9341 not working made in china

The model is "TJCTM24028-SPI". The board looks like the boards on the smaller displays, but with the additional touch-ic (currently unused and not connected).

Paul - that is just a more pin exposed version of the "purple test board (https://oshpark.com/shared_projects/IWylNfzD)" from the ILI9341 page? And some added components?

Ok interested, ordered boards from oshpark and some TJCTM24028-SPI displays. Seems like I spend half my development time trying to come up with a display option that does not require "time spent fiddling".

The added components are two 10K resistors, as pullups on the two CS signals. I really should have put one on the original test board"s CS signal. These bigger displays have 5 extra pins for the touch controller chip. I just routed the SPI signals and 2 pins for CS and INT. If the board works, I"ll do to the trouble of updating that OSH Park page with good documentation.

That looks like a nice upgrade to the ILI9341 in the store now - and only minimally higher cost? Supported touch on known good units and larger screen area ++good++. Found "some" on aliexpress not noted - assume like FrankB"s it is a Resistive touch unit like the $35 Adafruit - not Capacitive like the $45 unit?

Also ++good++ any other board that makes prototyping/connecting easier - like those from your ILI9341 YouTube Demo (https://www.youtube.com/watch?v=rL_2_D3cgFg) I asked about -

Bad news Frank - if you get medieval on the Teensy and can save the pins and the underboards you"d cut your losses - as long as you can cut just the Teensy with the close contact. My limited experience at cleaning pins only works about 1 at a time - then they go cleaner and not too much heat - especially with the other boards and solder so close.

Paul: The PJRC MicroSD reader - I just got two and the first powered up and works just fine! IIRC You noted somewhere of a new version with a second pull-up, is that important for reliable use?

The rapidly switching signals for the TFT do capacitively couple to the resistive touchscreen signals. Occasionally they cause a significant error in the touch reading, and frequently they add a small amount of noise.

Are samples polled or interrupt supplied? How much response time is lost with a 2 or 4 oversample that you could sum, then shift away? That would minimize but not ignore errant readings, but also make dragging lag.

New 240x320 2.8" SPI TFT LCD Touch Panel Serial Port Module +PCB ILI9341 5V/3.3V (http://www.ebay.com/itm/New-240x320-2-8-SPI-TFT-LCD-Touch-Panel-Serial-Port-Module-PCB-ILI9341-5V-3-3V-/191531963190?hash=item2c9831d336#shpCntId)

At this moment I"m pretty happy with the performance of version 1.1, so I"m not personally planning to spend much more time on this. But if you or anyone else comes up with a much better way, I"d be happy to merge a good pull request.

I am excited about this. I am confused though regarding choosing a ili9341 with xpt2046 touchscreen that is compatible with the OSH board pointed to by Paul.

Post #30 above has this link to a "one" row supported unit in the PJRC Store. (http://www.pjrc.com/store/display_ili9341_touch.html) It is a 2.8" board though.

The 2 row types usually have 40 pins (20 per row). Those are meant for parallel connection. They can be used with the UTFT library. The parallel interface is very fast, but it requires a lot of wires that use up nearly all the pins on Teensy.

But you"ll probably do fine to get one from China. Just make sure it has 1 row of 14 pins. Take a moment to count the number of pins in the photos. If there"s a photo of the back side where signal names are printed, compare the names to the "ILI9341 Pin" column in the connections table. There"s always some small risk when you build stuff directly from Chinese merchants, but if the photo has 14 pins and you can see the same signal names in the same order, odds are very good it"ll work.

But it looks like Paul switched to through holes (for now?) on the test board that"s out on OSH Park (https://644db4de3505c40a0444-327723bce298e3ff5813fb42baeefbaa.ssl.cf1.rackcdn.c om/d00240b93fba420f650eb4e49f426273.png). I have drawers full of through hole caps, so didn"t order any of those.

Thanks, I saw the update to the board as you noted so knew the SMD was out of date. Being new to this - my desk doesn"t have those kind of drawers. I may have picked up a suitable cap assortment. Searching on Digikey is daunting knowing a few functional words can take you to the wrong list - or even the right one with a few thousand parts on many pages to differentiate - and caps having so many material types . . . and then when you find a suitable through hole - there is the the leg distance. It looks like the OSH turn around is longer than I thought so I have time it seems for Paul to update. Though looking now at the OSH images it seems the cap legs are .10"

Has anyone tried the edits to use the SD_card (https://forum.pjrc.com/threads/28106-Display_ili9341?p=72889&viewfull=1#post72889)slot as was done on the non touch ILI9341?

PJRC touch display package came today - great delivery time! - not powered up yet. I sent a note to Robin for future QC testing - If you were lucky enough to get one from the first batch - make sure glass front is secured to PCB or you could get a rude surprise. Metal frame loops may not catch the display side ears allowing it to fall out as you rotate it. Worse yet - the metal frame on one of mine was not secured to the PCB board meaning upside down the screen would drop and swing/tug on the attaching cable. Double sided tape seems to be a fix.

As noted I added double-stick tape and expect it to be fine - but it shipped adhesive free, here"s pic copy of the pic I sent to Robin. The left shows no factory tape - the right shows a jumper wire I placed under the display free of the metal loops. The invoice shows a friendly smiley face that was free! And no I didn"t get the display for $8 I checked my CC. 5292

Wired and working per the Connections and 100% success! (http://www.pjrc.com/store/display_ili9341_touch.html). Much nicer than when I did the ILI9341 unit - I wired to Teensy header rather than jumper wires - which worked but once apart seemed like too much effort to restore.

One thing I noticed is you never get the same X,Y twice (on the test with delay(100) between samples). I used a pointer and did my best to hold it still. I suppose that is the variability Paul saw and wanted to average out in some fashion.

opps:: (~4 hours later sitting on desk) Seeing the screen go WHITE after running for some time sitting IDLE? USB output shows touch data updates but display is nothing but white screen? Just saw it a 3rd time - reverted back to original example/ILI9341Test - happened in under 10 minutes? And again in like 6 mins and then very quickly a time or two. Ran from USB charger battery - same thing. Swapped to backup display and re-powered - same Teensy and same loaded code . . . will update . . . so far so good @35+ mins.

ODD: Loaded "graphicstest" and d#1 is running that? And now back running ILI9341Test ??? Seems flakey - went white again and a reset from TYQT brought it back up - 25 minutes and counting . . . came back after an hour and it was white - restored again on TYQT reset. White again at 33 mins - came back on power cycle. I"ve seen this display go WHITE now 6 times in the last 2 hours 20 minutes. It will come back but not long. As before the Touch SPI is still active - LED blinks - and the USB gives the readings. This is the display that came unstuck from the PCB. I didn"t think much of it but when first attached I did a double upload - I thought maybe there needed to be a delay in setup - there isn"t and the other doesn"t need it and it doesn"t when it starts up working.

That case is with fixed offset images adjusting for the parallax offset. The touch problem is noisy readings - compounded by user movement - intended or not.

I don"t know what return values are expected - but empirically I noticed that the dummy X and next X read are always zero when there is no touch. So after the dummy comes back zero, the next five SPI commands could be aborted as ( !touched ) - then after the SPI.endTransaction() all processing can be terminated after zraw is set zero. This cuts SPI data flow in half when there is no touch, if this is supported behavior, and then the math component goes to zero as now it is done on each update.

And perhaps in update() the assignment of msraw = now; should not be done up front, but only if there is a touch as it will delay getting back in to find the next touch.

So far seeing the raw X,Y data only shows it has a great deal of variability. But it is scaled over 10::1 to the screen pixels, so a value near +/- 15 on either axis will map to the same pixel. Over time the simple average (on the X axis) of the three points groups matches the current scheme +/-1, that time can be 6 total readings, or many more. usually the worst case difference is under 10, sometimes greater than 50, I haven"t looked at which is right more often yet, though that would be easy - but it is late. Paul"s code is right the initial X read is often not in the ball park, other times it is. There may be a simpler way to toss out errant readings, perhaps I can check if given X,Y pairs seem correlated as the current code assumes - it may be that any given X or Y is independently wild?

The cool thing is the Teensy is fast and edits and recompiles are quick! Also cool I didn"t get just one display, #2 has not gone white even once, though touch worked on the white screen and I"m now needing the big screen fed by USB to scan copious data streaming - and thinking of more compares as I wrote this.

This type of measurement is probably always going to be pretty noisy. It"s a fairly high source impedance, and there"s a matrix of switching signals to drive the TFT nearby.

The 12 bit numbers can look pretty terrible. But remember it"s nearly 3000 to 3500 across the entire width of the display. Fluctuations of 30 are only 1% of the display width. Sure it"d be nice if all 12 bit were perfect, but you have to keep some perspective about how accurately a finger can even touch a 2.8 inch display. Even 2% or 3% accuracy (of the full scale) is still better than anyone can probably touch.

Still, if anyone wants to really work on this, RANSAC or some other algorithm would be awesome on a purely technical level, even if it"s not of much practical value for the actual measurement on these small displays.

This type of measurement is probably always going to be pretty noisy. It"s a fairly high source impedance, and there"s a matrix of switching signals to drive the TFT nearby.

My reason for asking was I have an Adafruit 2.8 ILI9341 without Resistive Touch IC and was wondering if it would be beneficial to add a dedicated IC to it.

The change I made to returned X,Y is that Paul did a distance test as a paired point, which makes sense until looking at the data source and acquisition time. The three reads are under 96 SPI xfer bits apart start to end - alternated xyxyxy. We know the data is jittery and out of 6 points at least one probably wild, but calling it "paired" with one seems artificial, and one wild coordinate would get the pair tossed, even if the other coordinate better equaled a second. So I implemented diff of the 3 values as X and Y and averaged the two closest ones. In my instrumented build I was seeing about 30% of the time my pair average was unique from the initial library.

For either of the above noted calls the same internal update() is done. For touched() it still does all the math and calculations after completing the 10 word SPI data cycle in all cases. In watching the data I saw that the first X value returned after the 4th transfer is ZERO when there is no touch, the first reads are for the Pressure to detect a touch. This calc was done after the SPI cycle, but if there is no X then there is no touch [empirical not from data sheet?], that means the next 4 SPI words can be skipped as the data won"t be used in any case and we can determine that there was no touch. Not reading 40% of the data and skipping all the math means the touched() call is less expensive in SPI bandwidth and cycles.

1> I wondered if reading "xxxyyy" instead of "xyxyxy" would give a better reading not swapping the multiplexor and analog converter around, and the results got more jitter as I saw them. Perhaps the Read x then y cycle allows the alternate resistive plane to recharge?

2> I saw the code noted the first x read was always noisy, and it is, I suppose that is from "powering down" the touch panel with the final read and getting it repowered with the first read.

Considering the number of errors I may end up giving the ADC Library a try, not sure how it will handle pins being reassigned from analog to digital thou.

Managed to slap together a mostly working chunk of code using the ADC library. The xpos seems to work fine, the ypos is all over the place when not being touched. Sometimes its 0 sometimes its 3000-3400, sometimes its around the midpoint. Its way to erratic for averaging to fix. Will put a scope on it tomorrow.

Donziboy2 - to match your findings - I read this last night but didn"t post - but it relates: http://www.unclelarry.com/?p=101 in that he discovered the 5th plane hoping he could read light touches - but until the touch is hard enough there is no circuit completed. Also describes the pressure sense. Again he shows a formula different than in the code for pressure, as in the PDF doc I saw. The code there works for touch detect - but is not linear with the math used.

I updated my PULL request to Paul with a question about the time between SPI.transfer - doing actual z detect after the data from the first two reads comes back is better than assuming the x=0 on the third read is defined behavior on all units, it also allows exit one SPI word sooner when not touched. Based on the above I think in the end the z=pressure calc should be changed when touch is detected.

My SPI question would be - the transfers are blocking as we assign a return value. If we execute "a few" instructions in code as the master before we execute the next SPI transfer is that controlled or gated by master "clocking" the transfer and not by a steady UART like clock?

I tried doing the math with both float and uint32_t. It was more accurate with float but as long as you set a decent threshold to trigger on you should do fine with either. I also had some issues with float overflowing when using 12bit adc values. Makes sense since the Adafruit code uses only 10bit values they would not see issues.

Working with that I see similar or greater variability to the pressure # as in the initial PJRC lib code that is wholly different, but relies on z1 and z2. Removed the x-term as it just adds another random term to what didn"t look good.

Just looking at (z2/z-1) and expecting it to reflect on the x position I don"t see that. It changes on my display at the lightest touch seen or a firm touch - finger or spring stylus. Not only at the same point by a factor of 2 - but across the display both x and y.

I should be right on x.vs.y - as they are bits in the SPI commands - and printed in the debug spew. But it varies across both axis as well. Lowest x,y has highest z tendency on the lightest touch and it is lowest z at the highest x,y.

This is with my working #2 display - up for days. As long as it has been on #1 was off - did a power off swap and it came up white on repowering. Did a reprogram and the color is back [for 10 minutes] - but the touch works in either case - and #1 maybe better than #2,

If you don"t move your finger it is fairly accurate, the Adafruit code which i copy/pasted basically uses that formula in a different order, the outcome is the same. For my testing its very apparent when your touching the screen regardless of where you touch it, the touch values are vastly different. Based on my screwing around using uint32_t shows 0-10000(very light touch) values are only seen if the screen is being touched, the touch values from noise are 30K - 500K values. Im not using any averaging at the moment and only using 1 read per output.

They do list a second formula that uses Y also. So you could make it more accurate. On my screen the Y resistance is 524 and R resistance is 288. Really accuracy with this part is not really needed, if you can determine the screen is being touched then its good enough. For me I just need to know when to ignore the x/y pos values since Y seems to be all over the place due to noise from the LCD.

Indeed - no problem detecting touch - I was expecting the system would provide a more stable value - even re-reading it after x,y when looking good as noted showed no real improvement worth extra cpu cycles from what PJRC started with that I could see over just reading the z values up front as is.

If you want to try my updated "I:\Teensy165\hardware\teensy\avr\libraries\XPT2046 _Touchscreen\XPT2046_Touchscreen.cpp" on your 1.26 Beta 1 install file I"ll attach it. I think what I changed is noted in a prior post. Turns out one of the nits I picked made things work better for Frank in a specific case and otherwise perfectly well.

Then I"m hoping to do an interrupt LIB version to stop SPI polling for Touch. But I"ve been wondering how you attachInterrupt(TS_Pin, onTouch, FALLING); then onTouch(){ PIN___disable_irq()(TS_PIN) ... PIN___enable_irq(TS_PIN) }

At a bare minimum, an approach like Paul"s Encoder library (https://www.pjrc.com/teensy/td_libs_Encoder.html), which gives users the option to #define a flag to use or not use interrupts, is a very elegant way to do what you"re wanting to do.

@FrankB: - there is a note about the touch hardware interrupt (https://github.com/Defragster/XPT2046_Touchscreen) that says interrupts are not that straightforward for the touch display:

However, inside your interrupt function, if the display is no longer being touched, any attempt to read the touch position will cause the interrupt pin to create another falling edge. This can lead to an infinite loop of falsely triggered interrupts. Special care is needed to avoid triggering more interrupts on the low signal due to reading the touch position.

As I read this:: This is a problem in that on TOUCH the isr triggers - then the ISR gets control to query the device it will then "read the touch position". If at any point it does that - if the TOUCH is removed it triggers yet another interrupt while still within the prior interrupt. I suppose while contact it held the INT PIN is not reset - but at the point touch is lost and it does reset - any ISR call to update() will itself trigger yet another INT - which would then call update() ... repeat until touched.

Here is an update - almost cool - whenever you touch "off" it rotates the screen and redraws. This just allows your code to pick or change orientation on the fly and properly maps the touch data to the relevant x,y pixels. It won"t clip or re-arrange things outside the pixels that are in the common 0,239 area that is in the 4 rotations. Rotations 1,3 and 2,4 work on the same constraints so that adds yet another variable to my pondering:: if buttons were tagged as such they could be duplicated for use in alternate views at updated locations, and hidden as appropriate.

In case this makes it to a SAMPLE I fixed the setup() wait for serial. I also changed the debounce to 1. It does get spurious hits - something you don"t see when not painting each hit. One thing might be to add a Z threshold in the GetMap - another might be to slow down the polling rate with a 30ms delay between calls.

Paul uses a different mapping so they are not compatible. So you can"t use the Touchpaint-example from the examples-menu for "our" display without changing it.

@frank - my stuff not yet on githib - I did have that thought a post or two ago when I had to re-upload to forum - but not finding the time to complete my first pass so it shows what I want. Though the GetMap() turned out to be quickly useful for the update above! You could port that to T3TRIS and invert your screen for two players taking turns head to head!

Somehow I created a branch so it is under Beta3. This is in my fork of the PJRC code so my working XPT2046_Touchscreen LIB code is there too. Hoping that makes it into the next Beta of 1.26, but Arduino 1.6.6 dropped today and not sure where it will fall out if Paul finds it a worthy update.

I modified the TouchPaint to use Button Definitions from an Array of Structs and moved the action code to functions that loop through the array to do the work. Not a general purpose solution, but drops lines of code and uncluttered the loop for sure of repeated drawRect and fillRect. You can initialize it to start on any tft.setRotation() though 2 or 4 makes sense with how the buttons are laid out.

Hm, this will take some time, if ever.... It has little problems, like PWM (Display-Backlight) not working and if used together with Audioshield+"Connectorboard" the pins are blocking the sd-card-slot so it is not easy to replace the sd-card ...

Picture a good start to see what it was - as you know I"m looking at another ESP8266 unit - I just need to finish where I am and learn Eagle and put on it what I need. I just need to glue the power rx/tx to a raw ESP-12 layout. No audio needed and the video is a debug option - the PJRC touch OSH board would be a good start - though smaller power with SPX3819 or similar. I got the starter eagle I probably need from Constantine, but distracted by the TOUCH just now.

T_3.2 or T_3.1 gives a power choice - if 250ma is a safe average max the T_3.2 is here now. I started assuming the T_3.1 and outside LDO needed - haven"t seen my ESP board yet so not sure how high it will peak.

Changes in fours lines looks like about enough to do it to turn TOGGLE into SLIDE - but to add TOGGLE .vs. SLIDE would take a bit more. Not quite working - may need to edit a 5th line?

I"m just running from USB powered Teensy: I did not have the power supply so I just ran one wire from the VCC CAP pin hole over to the 3.3v Pin and did not need all the edits you did to bypass the power.

Paul - also this is a pretty cool post #123 is a cool TOUCH demo of windowing buttons if you want to take a 5 minute break to see what you"ve allowed us to create. Also BTW - if you have an extra minute I have that pull request on the : https://github.com/PaulStoffregen/XPT2046_Touchscreen/pull/1. I have not reverted to your B1 code to say it saves the world - but it is working for Frank and I.

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.

@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.

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.

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.

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.

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!

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.

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.

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 !

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.

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 , 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 (https://forum.pjrc.com/threads/28106-Display_ili9341?p=72889&viewfull=1#post72889)

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.

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?

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...

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.

The wiring works per the link in this thread that goes to the PJRC page: https://forum.pjrc.com/threads/30559-2-8-ILI9341-restive-touch-miso-not-connected?p=85727&viewfull=1#post85727

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.

It takes the HIT testing for buttons out of the user code, but introduces a complex data structure for buttons to feed an engine that identifies buttons. in you case the samples might be interesting but not useful for just page forward and backward.

For your purposes adding 10 on screen buttons could let you jump directly to any screen. in landscape mode the buttons would be large enough to hit and label in two rows of 5 and leave a large area to display whatever you wanted in another screen area. I diverted from the button work to get a non polling version using the interrupt pin that went pretty well, but has some anomaly.

I just moved all my examples to the new GitHub listed above as having it inside the touch screen fork of PJRC makes GitHub painful. I haven"t looked at them for some time, but left them working.

I just created this TOUCH thread for my work in progress - to minimize the pollution of this thread and the repetitious info on this and another thread: ILI9341-and-XPT2046-for-Teensy-Touchscreen-320x240-display (https://forum.pjrc.com/threads/31634-ILI9341-and-XPT2046-for-Teensy-Touchscreen-320x240-display)

Oh, the topic/issue of this thread "..miso not connected.." is solved :) (It was bad soldering of the connector between the display and pcb. Works now.)

Thanks Frank - I put the same note on both threads - the other was created after this since the title fit your problem. Hopefully my new thread will make a single spot that is findable. Even better I hope I can get back to where I was and make some improvements.

Question regarding the Color 320x240 TFT Display and the ILI9341 Controller Chip, do we have any capability to change the screen brightness? I"m running mine on a Teensy 3.2 using 3.3v and the display is "OK" but I was just wondering if we have any tweaking capabilities?

@rfresh737 - what resistor did you put inline with the power? I"m not sure about 3.3v - but on 5v it recommends 100ohm. I saw a note the other day from 5v users they went as low as 10 ohm. I"m not an EE and didn"t even try the math - but as long as the current limit works out - that should put more current to the LEDS for more brightness

EDIT: I"m using a 100 ohm resistor. Those are what was used in some of the tutorials I looked at...however, I"m not sure that"s appropriate for a 3.3v system. But I"m a newbie so I have no idea what would be "correct" for 3.3v?

EDIT: I dropped it down to a 47 ohm resistor and that made the LCD a little brighter and now the brightness looks "better" than with the 100 ohm resistor. In fact, I"d say the screen brightness is "excellent" now. So, maybe 47 ohms on a 3.3v board with this screen.

Paul - If you get to update the OSH Display board setup - don"t forget the FUSE link rating - I did - I just realized I adjusted the other needed parts - but left the low 0.14A PTC on my order list - so it won"t feed the T_3.2 enough current to use the new hardware - given that 5v feeds the display LED and the LDO output is 5v not 6v not sure if you would recommend .3A or .35A maybe?

Thanks, I"ve got the board and all the parts now. One question though - which way does the Shottky diode go? I could find any posted photos that show it and the PCB is not marked. Is a schematic for this board available? Thanks again.

Now, to reduce the pin usage, I connected the XPT2046 to the SPI and everything works fine, but if I connect the pin SDO_MISO of the display, the SDO_MISO data become crazy shooting continuously and autonomously incorrect values.

2.8 inch spi tft lcd ili9341 not working made in china

If you have other SPI devices connected leave the TFT_MISO GPIO disconnected (GPIO 19 on my configuration). I"ve found that the ILI9488 display works even if GPIO 19 is not connected. The touch works also.

Remember to define IL9488 driver and Setup21_ILI9488.h in the appropriate User Setup files appropriately even although ILI9488 is defined in the Setup21_ILI9488.h file. Also, to use the latest TFT_eSPI library !!

2.8 inch spi tft lcd ili9341 not working made in china

The TFT display is a kind of LCD that is connected to each pixel using a transistor and it features low current consumption, high-quality, high-resolution and backlight. This 2.8-inch full color LCD has a narrow PCB display. The resolution is 320×280 pixels and it has a four-wire SPI interface and white backlight.

2.8 inch spi tft lcd ili9341 not working made in china

(The following is the touch screen signal line wiring, if you do not need to touch function or the module itself does not have touch function, you can not connect them)

2.8 inch spi tft lcd ili9341 not working made in china

In this Arduino touch screen tutorial we will learn how to use TFT LCD Touch Screen with Arduino. You can watch the following video or read the written tutorial below.

For this tutorial I composed three examples. The first example is distance measurement using ultrasonic sensor. The output from the sensor, or the distance is printed on the screen and using the touch screen we can select the units, either centimeters or inches.

The next example is controlling an RGB LED using these three RGB sliders. For example if we start to slide the blue slider, the LED will light up in blue and increase the light as we would go to the maximum value. So the sliders can move from 0 to 255 and with their combination we can set any color to the RGB LED, but just keep in mind that the LED cannot represent the colors that much accurate.

As an example I am using a 3.2” TFT Touch Screen in a combination with a TFT LCD Arduino Mega Shield. We need a shield because the TFT Touch screen works at 3.3V and the Arduino Mega outputs are 5 V. For the first example I have the HC-SR04 ultrasonic sensor, then for the second example an RGB LED with three resistors and a push button for the game example. Also I had to make a custom made pin header like this, by soldering pin headers and bend on of them so I could insert them in between the Arduino Board and the TFT Shield.

Here’s the circuit schematic. We will use the GND pin, the digital pins from 8 to 13, as well as the pin number 14. As the 5V pins are already used by the TFT Screen I will use the pin number 13 as VCC, by setting it right away high in the setup section of code.

I will use the UTFT and URTouch libraries made by Henning Karlsen. Here I would like to say thanks to him for the incredible work he has done. The libraries enable really easy use of the TFT Screens, and they work with many different TFT screens sizes, shields and controllers. You can download these libraries from his website, RinkyDinkElectronics.com and also find a lot of demo examples and detailed documentation of how to use them.

After we include the libraries we need to create UTFT and URTouch objects. The parameters of these objects depends on the model of the TFT Screen and Shield and these details can be also found in the documentation of the libraries.

So now I will explain how we can make the home screen of the program. With the setBackColor() function we need to set the background color of the text, black one in our case. Then we need to set the color to white, set the big font and using the print() function, we will print the string “Arduino TFT Tutorial” at the center of the screen and 10 pixels down the Y – Axis of the screen. Next we will set the color to red and draw the red line below the text. After that we need to set the color back to white, and print the two other strings, “by HowToMechatronics.com” using the small font and “Select Example” using the big font.

Next is the distance sensor button. First we need to set the color and then using the fillRoundRect() function we will draw the rounded rectangle. Then we will set the color back to white and using the drawRoundRect() function we will draw another rounded rectangle on top of the previous one, but this one will be without a fill so the overall appearance of the button looks like it has a frame. On top of the button we will print the text using the big font and the same background color as the fill of the button. The same procedure goes for the two other buttons.

Here’s that function which uses the ultrasonic sensor to calculate the distance and print the values with SevenSegNum font in green color, either in centimeters or inches. If you need more details how the ultrasonic sensor works you can check my particular tutorialfor that. Back in the loop section we can see what happens when we press the select unit buttons as well as the back button.

2.8 inch spi tft lcd ili9341 not working made in china

According to my experence for another 2.2" LCD display with D/C Pin, I am using CD4050BE to convert the UNO pin 5v to 3.3v to fit to the TFT signal standard.

The product page (china seller) said it is using ILI9341, but I read the attachment which seller send to me, attachment said it is ILI9340. And I did a research from google, someone said it is HX8347A.

PS: I have tried using Adafruit_ILI9340 & Adafruit_ILI9341 with Adafruit_GFX, but I am no luck to see anything, the screen just got some flash (slightly dimmed and go back to bright).

2.8 inch spi tft lcd ili9341 not working made in china

ILI9341 is a 262,144-color single-chip SOC driver for a-TFT liquid crystal display with resolution of 240RGBx320 dots, comprising a 720-channel source driver, a 320-channel gate driver, 172,800 bytes GRAM for graphic display data of 240RGBx320 dots, and power supply circuit. ILI9341 supports parallel 8-/9-/16-/18-bit data bus MCU interface, 6-/16-/18-bit data bus RGB interface and 3-/4-line serial peripheral interface (SPI). The moving picture area can be specified in internal GRAM by window address function. The specified window area can be updated selectively, so that moving picture can be displayed simultaneously independent of still picture area.

You can find ILI9341-based TFT displays in various sizes on eBay and Aliexpress. The one I chose for this tutorial is 2.2″ length along the diagonal, 240×320 pixels resolution, supports SPI interface, and can be purchased for less than $10.

Note that we will be using the hardware SPI module of the ESP8266 to drive the TFT LCD. The SPI communication pins are multiplexed with I/O pins D5 (SCK), D6 (MISO), and D7 (MOSI). The chip select (CS) and Data/Command (DC) signal lines are configurable through software.

For ILI9341-based TFT displays, there are some options for choosing the library for your application. The most common one is using Bodmer. We will use this library in this tutorial. So go ahead and download the

The library is based on the Adafruit GFX and Adafruit ILI9341 libraries and the aim is to retain compatibility. Significant additions have been made to the library to boost the speed for ESP8266 processors (it is typically 3 to 10 times faster) and to add new features. The new graphics functions include different size proportional fonts and formatting features. There are a significant number of example sketches to demonstrate the different features.

Configuration of the library font selections, pins used to interface with the TFT and other features is made by editting the User_Setup.h file in the library folder. Fonts and features can easily be disabled by commenting out lines.

Now you are all set to try out tons of really cool built-in examples that come with the library. The following output corresponds to the TFT_Pie_Chart example.

My favorite example is TFT terminal, which implements a simple “Arduino IDE Serial Monitor” like serial receive terminal for monitoring debugging messages from another Arduino or ESP8266 board.

2.8 inch spi tft lcd ili9341 not working made in china

I have started to speed up the lib with using DMA and direct SPI programming. To do this I have to split the code for the different platforms. To prevent unreadable code with a lot of #ifdef... I have create a new file. The #ifdef definition around is switching between the platforms.

Unfortunately this adapter is set to 9 bit SPI mode via the mode pins IM0-IM3. If you want to patch this - like I have done - you have to desolder the TFT from the pcb to cut some traces. This is a flexible print. Only for people with soldering skills !

You also have to get access to pin 36 for the dc signal. Cut the GND connection. You can use the level converter used for the LCD_LED signal. Mosfet Q1 can be driven with a logic signal without converter. Watterott will change this in a future revision.

To print characters to a graphic screen we need a font. To code a font by paper is ok for a small lcd, but for a 320*240 pixel display we need bigger fonts. A 12*12 pixel font is readable, but a lot of work to construct.

2.8 inch spi tft lcd ili9341 not working made in china

You Might Also Be Interested In