ILI9163C 128x128 TFT driver

Status
Not open for further replies.
Ok, I find a typo in PROGMEM reading and fixed in lib on github, but maybe something else still hiding. I'm building a small board for testing Teensy LC, UNO,nano, esp, etc. I will update lib tonight (including defragster example).
One question, I hope you are using a level converter with this display, is true?
 
Sumotoy, I don't understand what is level converter ? I'm from argentina,
maybe it's a technical term , I use a 5v regulated source and don't that is your question ? Sorry
 
You are using an Arduino, it's 5V logic level CPU. The display has 3v3 logic level, internally it has a 5V to 3V3 regulator but logic level remains at 3v3!
Accordly datasheet, ILI9163C doesn't support 5V logic levels, this mean you need a logic converter, such as CD4050 IC, powered at 3v3 between arduino and display.
It may work without, I'm surprised you got working till now, but you can destroy display soon or later, this is sure.
Teensy's 3.x, DUE have logic level of 3v3 so they can be connect directly.
This is the link to CD4050 IC, you need to connect it at 3v3 and place a polyester 100nf between VDD and ground

This has nothing to do with your current problem but better know, I will try my board in an hour (Arduino nano + HCF4050 + ILI9163C)
 
Elrico, please read here.
'Operating Voltage (logic level) 5 V'
Nothing to do with the 3v3 out that any arduino has.
It's clear now?
 
Elrico, I also find an error in library with AVR's, I will update the whole library tomorrow, too late now.
It also use less space, there was also a memory leak on AVR.
 
Just making note of the fact that Paul is on vacation through the weekend - beta update should have a couple days.

I found a line in SD .begin that sets the SPI speed - when I init that with SPI_QUARTER_SPEED instead of SPI_HALF_SPEED I can change/DOUBLE ( at 96 MHz) the system clock ratio as provided before and BOTH displays work faster with no impact on the AUDIO board playing from the SD card! It should be a super simple edit - a second optional param on SD.begin should make it work, and when not used no change - I'll try to make a PULL request and have that for Paul's review and possible inclusion in 1.29. I have the couple lines coded - I have no idea if it can be used as it may break other generic SD usage?

I'm compiling MIN and AVERAGE FFT processed FPS done at 96 MHz - testing now at 120 MHz.

Code:
boolean SDClass::begin(uint8_t csPin) {
boolean SDClass::begin(uint8_t csPin[B], uint8_t spiSpd[/B]) {
  /*

    Performs the initialisation required by the sdfatlib library.
@@ -341,7 +341,8 @@ boolean SDClass::begin(uint8_t csPin) {
    Return true if initialization succeeds, false otherwise.

   */
  return card.init([B]SPI_HALF_SPEED[/B], csPin) &&
   
	  return card.init([B]spiSpd[/B], csPin) &&
         volume.init(card) &&
         root.openRoot(volume);
}

<edit> I tested to good general effect - Audio hardware and Reading SD works and the Display is updated faster. I posted a PULL request.
 
Last edited:
I finally fixed all issues on AVR (at list looks fine, everithing works)
There was some error, in the meantime I've optimized some code so fillRectangle,fillScreen and all related functions that use this are much faster on AVR.
The overall code in AVR takes a lot of space, I know, the speed has a price.
But with latest version there's a setting called _ILI9163C_SIZEOPTIMIZER that uses almost little more than half of the optimized code and performances decrease just a little bit, this is valid on AVR, on ARM the full performance is maintained.
I'm actually working to add a faster alternative SPI on Teensy LC side...

Defragster,
I have pulled your example in library examples, thanks a lot for help!

Elrico,
try now Icons, should work.
 
Last edited:
I had to get medieval and use the command line to get GIT to get the latest updates, windows app failed to SYNC again. When I did that my samples worked fine with any changes.

Also - transported 10 seconds of FFT data from the Audio Board Example into an Array that feeds the twin VU meters in that sample. I'll see if a variant of SomeBars showing the two graphs is clean enough to share. It runs 237-275 FPS with SPI OC and text label over-write on each update. Sketch ZIP is 127KB (RAW is 435KB)

<edit>: Tested the 'benchmark' to work and look right, then tried with the SPI OC:
Benchmark[rot=2] Time (microseconds)
Screen fill 11954
Text 3295
Text2 11540
Lines 16078
Horiz/Vert Lines 5205
Rectangles (outline) 4205
Rectangles (filled) 91200
Circles (filled) 15222
Circles (outline) 14363
Triangles (outline) 5040
Triangles (filled) 31328
Rounded rects (outline) 8228
Rounded rects (filled) 99788
Done! ------------------------

// with setup():: SIM_CLKDIV1 = SIM_CLKDIV1_OUTDIV1(0) | SIM_CLKDIV1_OUTDIV2(0) | SIM_CLKDIV1_OUTDIV4(3); //SIM_CLKDIV1_OUTDIV2(0) war auf 2!!
Benchmark[rot=2] Time (microseconds)
Screen fill 5981
Text 2611
Text2 10922
Lines 10443
Horiz/Vert Lines 2660
Rectangles (outline) 2134
Rectangles (filled) 45674
Circles (filled) 7774
Circles (outline) 7824
Triangles (outline) 2881
Triangles (filled) 15727
Rounded rects (outline) 5390
Rounded rects (filled) 50081
Done! ------------------------
 
Last edited:
You are using an Arduino, it's 5V logic level CPU. The display has 3v3 logic level, internally it has a 5V to 3V3 regulator but logic level remains at 3v3!
Accordly datasheet, ILI9163C doesn't support 5V logic levels, this mean you need a logic converter, such as CD4050 IC, powered at 3v3 between arduino and display.
It may work without, I'm surprised you got working till now, but you can destroy display soon or later, this is sure.
Teensy's 3.x, DUE have logic level of 3v3 so they can be connect directly.
This is the link to CD4050 IC, you need to connect it at 3v3 and place a polyester 100nf between VDD and ground

This has nothing to do with your current problem but better know, I will try my board in an hour (Arduino nano + HCF4050 + ILI9163C)


Thanks Sumotoy, I didn't know of the importance of operating with 3v, I have seen many tutorials and never mentioned that, always connected to 3.3v smoothly.
I'll buy one then.
 
It worked your examples sumotoy , How can I do to make my own images ?
I need to use a image like bitmap suppose, that size would be to do a test and example .
I try the lcd-image-converter.exe but without good results.
Thank you


20160530_150425.jpg
 
Last edited:
sumotoy - Pull request with Updated TFT example to the faster VU code. I didn't merge the two units to a common library type, though I added a rectangle Clear...() function that includes bar spacing area and all bars, since the one speed up was to not redraw same height bars that might be needed.

Note - in what I've done I have not seen any issues from the display with this driver code!
 
It worked your examples sumotoy , How can I do to make my own images ?
I need to use a image like bitmap suppose, that size would be to do a test and example .
I try the lcd-image-converter.exe but without good results.
Thank you

You have to use LCD Image Converter! There's a step-by-step wiki for that, it's really easy and follow wiki you cannot get wrong.
Hi Defragster, thanks! I've accepted pull of course!

PS
To test display I made up an universal board to test several display's with different type of MCU's
 
Last edited:
I've updated the copy for Teensyduino to the "Pre-Release-1.0p7" branch. I'm going to release a 1.29-beta2 installer later today or tomorrow, with the goal of finalizing 1.29 sometime this week.
 
Thanks Paul, Defragster! I have some minor changes coming but all in AVR side.
Elrico, I'm gonna pull some changes to save some more space on AVR but images uses always lot of space, use Icons, not Images and small. You can use the scael command inside drawIcon.
Cutting chunks of code doesn't solve the problem, the compiler already will get rid of unused library code but in brief I have another update that force some always inline functions to be normal so the code on AVR don't grow too much.
If you use Teensy 3.2 you will not have those problems, you have much more speed and space.;)
 
defragster,
I have another version online. I have fixed a text rendering issue (now also a bit faster) that never noticed before and added autocenter features to setCursor
The text rendering has accellerated a bit the icon render as well.
I hope I don't break something in the meantime ....
 
Last edited:
sumotoy - my sample for the ILI9163C has CENTER in the LabelWrite() function did you try that?
Yes, but I have added just some code inside library to get some autocentering features on the fly since many values are already tracked inside.
Anyway, library has been updated and now pretty stable. I have ported the whole library (same exact features) to ST7735 and in this week some other display controllers.
I have ported to ILI9340/41 as well for fun, just very small changes in init, and for some reason it's actually a bit faster than t3_ILI9340... weird.
 
Screen fill(test lib)
276034
(t3)
280955
Text1460217618
Lines7323773204
Horiz/Vert Lines2305223061
Rectangles (outline)1455814628
Rectangles (filled)580512584243
Circles (filled)8109291885
Circles (outline)6471876506
Triangles (outline)1750817738
Triangles (filled)187536194921
Rounded rects (outline)2709834354
Rounded rects (filled)631303639004
Yep, this is the comparison at 96Mhz on teensy 3.2



















Small differences btw.
PS: editing this post with tables is a challenge!
 
Last edited:
I bought ten of these units on the advice I received here, and have yet to get a single one working. I've used an arduino duemilanove, another identical unit, and three different Arduino Nano boards. Tried four different TFT screens (red PCB, yellow pins) and now that I'm finally not getting any errors, I'm not getting anything at all. 100% blank screen no matter what I do.

I've used the hookups described here, I've tried redefining pins and then resetting it all back to original....nothing.

Any ideas?
 
Check the wiring and pin definitions and settings edits?

When properly connected - if you got a 1.44" ILI9163C "(red PCB, yellow pins)" board like I dropped a picture of in this thread it will work on Teensy 3.1 or 3.2. To work verify the edit to Settings as I noted earlier in the thread. YMMV on non-Teensy variants - perhaps there is another #define needed for non-Teensy usage?

sumotoy - or someone with non-Teensy usage will have to weigh in otherwise. It seems there was another on this thread using non-Teensy, and sumotoy intends that to work.

I used headers on boards using the store pin diagram for the larger 320x240 TFT displays - It has to be right justified for the signals to align as it has no SDO/MISO or TOUCH pins and those headers work to fully connect and operate this display to Teensy.
 
Status
Not open for further replies.
Back
Top