New ili9341 and t3.6 issues

Status
Not open for further replies.
Duhjoker

Duhjoker

Well-known member
Hi guys

Ok so my order of a new ili9341 TFT and T3.6 from the pjrc store came yesterday and and I spent today getting both ready to test and now I'm having trouble. The first issue has to do with the sumo toy library I was previously working with. When ever I use the ili93xx library it only shows green pixels.

The second issue comes from using KurtE's library. I plug it in and compile the graphics test and reboot but the teensy never comes on. The screen comes on but not the teensy.

Here's a link to where I got the library......

https://forum.pjrc.com/threads/3875...r-version-of-ILI9341_t3-library-(ILI9341_t3n)

And here's the link to the screen

https://www.pjrc.com/store/display_ili9341.html

I wired it to my T3.6 the exact way it says.
 
Odd - did you try with the TeensyDuino ili9341_3 library? That worked when wired right for me.

What version of TeensyDuino - another post last 24 hrs said they saw a slowdown - that seemed to be this display with TD_1.36 ?, but not sure what Teensy. Try an earlier release - perhaps something needs fixed? I have not powered on an ili9341 for some weeks - but it did work with the T_3.6 when it was in Beta and after.

The only trouble I ever saw was 'all white' so that shouldn't relate - it was a display failure.
 
Well if i use a different library i lose colors. Let me explain....

I have a sketch thats supposed to render a 21x17 tile map made of green and blue squares. Along with it is a player sprite bitps split into individual mono colored bitmaps to create a single multicolored bitmap and now that wont show up either using a didferent library.

I have the latest arduino ide i think and definitely the latest teensy library installed as well.

I would really like to use kurts library though since it has a buffer, DMA and an update screen feature which will be needed for the project at hand which is a simple gaming library that any one can use to make games with and build thier own console.

So much work to do.

Any way i think it might be the wiring. I read some thing on kurts page linked above and there are all these wiring schemes in the testgraphics sketch but i dont really understand which one to use.
 
With things like, this: you say it is wired like X... As for example the main page has at least two different wirings depending if you are using it with Audio board or not...

But again it would be good to see a picture or pictures of the actual wiring, to the actual wiring. Too many times there are subtle issues, like the pins are not soldered in. Or people quickly wire D13, like it is next to D12...

Also have you tried simple test cases? If so which one. The test cases in my code are because the board I do most of the testing with uses non standard pins and the like. There is the one test case that I tried a lot of different combinations of pins and left in ways to define them...

But if I am using default pins, I either use the combination that just has me pass in the CS/DC/Reset pins or more likely I use the full combination setup, to allow me to change things easier later. Something like:
Code: 
#define TFT_DC  9
#define TFT_CS 10
#define TFT_RST 7
#define TFT_SCK 13
#define TFT_MISO 12
#define TFT_MOSI 11
ILI9341_t3n tft = ILI9341_t3n(TFT_CS, TFT_DC, TFT_RST, TFT_MOSI, TFT_SCK, TFT_MISO, &SPIN);

Note: my library does NOT have DMA... Frank's library has DMA. I do have the ability to use offscreen memory to shadow the screen and then do refresh operations to allow you to do lots of graphic operations to memory and then say update the screen...

Again remember my main reason for this library was to allow it to work on different SPI busses. Started off to test the T3.6. I then liked the idea that Frank had in his library for the offscreen stuff and added that in and fleshed it out, plus I added in some of the graphic enhancements that were/are in the main library Pull requests, like clip rectangle, like opaque text for fonts...

As for the potential code slow down. I think more information is needed, like code showing what they are doing. I don't think Franks DMA code has changed in awhile now. Could be SD card issue? Could be compiler options issue? ...
 
Well i will still need your frame buffer and update function.

Ok like on the wiring..... I use the standard set with 9, 10, 11, 12, ground,13 and 3.3v and it works for a couole different libraries but not the t3n library.

Any way here are the pics you requested.


First we have the screen. Now i soldered each lead to its pin then insulated each lead with shrink tube to prevent shorting.

From the bottom up we have....
the first wire is the 5v for the vcc and the LED pin, the black wire is GND, Next is purple CS, then red reset, orange DC, grey MOSI, white SCK, LED and vcc wire, and top one is brown MISO.




This sows the other angle of the board. Black is ground, pin 13 is white wire.



this pic is meant to show the angle so you can see the alignment of the pins and there eyelets. Pin 9 gets the orange wire , pin 10 gets the purple wire, pin 11 is the grey wire, pin 12 is brown and the 3.3v is red.




I don't know anything about the case stuff I was just trying to use the graphics test example.
 
Last edited:
ok so iwas looking at your graphics sketch and found a bunch of if defined bits with pin outs like this...

Code: 
// Franks setup
#ifdef SPI0_DISP6
#define TFT_DC  15 //orange wire
#define TFT_CS 10  //purple wire
#define TFT_RST 4  //red

#define TFT_SCK 13 //white
#define TFT_MISO 12 //brown
#define TFT_MOSI 11 //grey
ILI9341_t3n tft = ILI9341_t3n(TFT_CS, TFT_DC, TFT_RST, TFT_MOSI, TFT_SCK, TFT_MISO, &SPIN);
#endif

I then looked at franks ili9341.h file and saw that the above was the correct pin out, so I commented out the default disp1 and uncommented the disp6 then matched the wiring accordingly but still no go. the teensy never even blinks its lil light by the program button.

EDIT::

OK So I downloaded and unzipped franks library into my arduino folder the proper way then used the wiring above and tried his graphics test example and all I get is "waiting for arduino serial monitor" in green.

EDIT:: OK Just ran the unmodified sumotoy example I was trying to update for gaming to begin with and it works just fine.
 
Last edited:
Is this correct? It looked like you have pins 8-12 and maybe 13 and 14?

I assume you started the serial port as the test code starts with:
while (!Serial) ;

Was there any debug data printed out in the Serial port?
 
i had to some editing to my posts but yes they are correct. I just tested sumotoys library and it worls just wired like pics show.

Its when i using yours or pauls libraries that give me problems.

I dont know what you mean about the serial port. Is there an extra pin that needs to be populated?

Does the buffer need spin to work or is it all included in your ili .h and .cpp

Edit::
Ok i successfully moved your frame buffer bits over to my working ili93xx library and wow!!!!! I ran the graphics test and it was fast!!!!
 
Last edited:
So if you try with my library connected properly and you download the program and then you click on the
Serial Monitor Icon or select it from tools menu, with the Serial port configured for your Teensy, does anything happen?

The code I mentioned: while (!Serial) ;
if this is the program I think it is, will be like the first line in void setup() {
It says, wait until you have a serial monitor available, before continuing... So nothing will happen to the TFT display without first opening the serial monitor...

This is to help with debug messages that the call to tft.begin() might produce.
 
Yep I see now.

Ok so yet again I started a new library using the SumoToy version of the ili9341 library or ili93XX. I'm already familiar with most of it works plus there's a ton of more graphics functions. So the first thing I did was add your frame buffer bits over to the ili93xx and ran the graphics test which was as said above noticeably quicker.

Then I added the 4 bitmap functions from the latest Adafruit GFX library and ran that no problem. So next I added your update command which was super needed. That worked so I added the update all function from Gamebuino which updates all classes like sound and buttons and display 20 X a second and then added the set frame rate function.

Here's the cool thing........ Before adding and using the updateall() command the screen flickered the graphics constantly even with the buffer but now every thing is solid.

Next i tried to add the tilemap functions and that's a problem. I managed to change all the uint8_t integers in the functions to 16 and that did help a bit but it's still just showing the upper left half of the Tilemap. Where can I go for help with the graphics functions?

Here's a pic of that........



Sorry the pic cant be better but you can see the glitch.

I guess my next step is to get the buttons to move a player sprite bitmap around the screen.
 
Last edited:
Progress today. I was able to get the buttons working. i had forgotten to add buttons.begin in beging for the screen and to update them in another spot. So now i can make my player bitmaps change when a button is pressed.

Also was able to get my int player_x and y working too. That was a } mistake.

Now it occurred to me 5 minutes after i shut down that the original int and uint's were at 8 and for an 84x48 black and white screen. Well someone gave me a hint a lil while back that int and uints needed to be higher. Well i set them to 16 which made more of the bitmaps appear. I wonder if they need to be at 32.

Also is there some kind of offset being utilized? When i center a bitmap on the tft the postion is over and down than where it should be. Same thing with whats being printed of the tilemap.
 
Colors are 16 bit - split 5,6,5 in bits - like this:
#define BLUE 0x001F
#define RED 0xF800
#define GREEN 0x07E0
Click to expand...

This seems like the function to look for tft.color565(r,g,b); to see the blending.

<edit> Is there a link to your buffered ili93XX?
 
Last edited:
No problem its attached now but why the color stuff in your post?

ok so the library attached uses KurtE's spin-master library, so you will need to add that to your library. everything is super highlighted to make navigation a lil easier. please add pauls sleep.h file into your teensy cores avr
 

Attachments

  • TFT_ILI93XX-master2.0.zip
    235.2 KB · Views: 81
  • SPIN-master.zip
    8.6 KB · Views: 78
  • sleep.h
    1.9 KB · Views: 97
Ok i keep having an issue with the screen where its intermittant. When i add power and the teensy boots, some times i get a picture sometimes i dont. At first i had the plastic clips attached but i removed to no avail. But even when you dont get a picture you can still see the white screen flashing like the pattern of the graphics test.

Heres a pic......



The jumpers are soldered and insulated with shrink tube on the tft side.

Orange--------------CS 10

Green----------------DC 9

Blue -----------------mosi 11

Purplish-marroon----sck 13

Brown---------------miso 12

The purple wire is the button and screen ground.

The other blue wire powers the TFT.

I've also tested my 3.2 with the same results. Also when I do get a picture it eventually fades to white but still flashes.


Do i need to actually solder the leads to the teensy? I was hoping to keep it modular so i could switch out MCU's
 
Last edited:
I got a screen that would over time go all white - then over time it would only show white. From description you may be seeing the same?

When I got it replaced - assuming it was now garbage I followed the linked noted on the PJRC store page for PCB edit to make the SD slot work ( IIRC:: remove the resistors and jumper over them and CLOSE J1 to bypass the onboard voltage regulator to 3.3V use only. )

After that the display was fully functional for me. The WHITE is the backlight. Closing J1 got power to the controller and it could then do it's TFT magic and show the color overlay.

Just seeing your Feb 20 reply - I assume I was showing the need for 16 unsigned bits to hold color data - not 8 and not 32.
 
I have not run into one of these displays stop working, but as defragster mentioned he has, and I believe I have heard of one or two others.

The other thing I did not see mentioned is if you have a reset pin wired up to the display. It should either go to 3.3v or to some IO pin.
 
I'm not sure it has helped anyone else - unless I missed their reply that it did work - it has shown a couple times in posts.

What I did was from this store page link noted above: We do not recommend using the SD card socket on this display. It does not work, but this hardware modification may be able to get it working.

I have seen reset change be critical for function beyond backlight power making a white display. In my case the display worked some time - got flakey toward white - then would go or stay white with controller 'offline' ASAP - soldering that jumper when I gave up on it suddenly made it work.
 
Yep definitely have reset tied to 3.3v. If you look at the left side of the case in the middle you will see a red and yellow wire coming from the screen and wrapping around to the top left corner and you can my lil bridge relay that ties the main screen power to the 3.3v on the MCU using the blue wire.

Ok I don't know if you guys saw it above but I had the TFT tied to the MCU ground that's usually used for the buttons to save space. This was the same for teensy 3.2 and 3.6. I usually tie the screen into the main ground. So I made a couple bridge relays from some pins and hooked the TFT back to main ground. Then supplied power and waited for it to boot.

Now I get picture.

Could y'all do me a favor when you get a chance? I would like to see if the grounding part changed is the problem or a glitch. Can you hook up your tft's to a teensy or multiple and tie the TFT ground to the MCU ground and see if you get a picture?

Also I had already removed the SD card slot from the TFT. I do this so I can insulate the back of the screen and attach the battery. This allows a lower profile in the case to add the MCU or other goodies.

Edit::: turned it on and letting it cycle through the graphics over and over again.

Also my new EZSBC esp32 came today but think I'm gonna wait and use the 2.8 inch TFT version. And that one needs a battery and a tp4056.

Edit:: One hour later and still no glitches or heat. So what did I learn? Do Not ground the TFT to the MCU ground.
 
Last edited:
So it seems to be working better now for you without closing the J1? As noted that I found that was incidental thinking I had a dead TFT and thought having the external SD might be nice. I didn't examine your wiring - I don't have one hooked up just now.

I'd just stick with Teensy for now - enough variation there to be distracted with multiple 3.x's. In a month or so the support for ESP32 may work itself out to let you get farther faster porting your work if it is stable and progresses like ESP8266 did.
 
FYI - I have often run them using the GND pin from the Teensy as the Connection. That is how I typically run them when running tests with just the Teensy and breadboard or the like. When I do my own boards, I tie it more to part of the ground wiring of the board...

Maybe you just had bad connection.
 
Your probably right. Modular looks and sounds cool but the practicality of it at this point in time is a lil much.i hate to do it but I'm gonna have to solder it all. You're right I've got a few people starting to build thier consoles using teensy and since I'm thier support I need to concentrate on what's needed now for the working platform. I still need a boot loader GUI that can select and load the games. And so much more that needs to actually work instead of just compiling.

The other day I wrote my readme file with complete directions and part lists for building the console plus the stl files to print a case, then finished the sdk by including all the libraries and thier dependency files. All packed up and ready to go.

Any body have any links or know any code that can be adapted to load games or other programs from the SD card? I know I can do the graphical part but need a few hints on how to make it load the games.
 
Last edited:
I finished puttibg every thing just a lil while and started testing again and about every other time it does the white screen thing. I soldered all the connections and sealed them with shrink tube but it must be shorting somewhere.

Im gonna try the j1 trick you mentioned see if that helps. I have to pull the back off any way to drill a hole for the teensy reset button.

I timed this pic just right!!!!



Heres a pic from the side, its just 21mm thick. Average but the piGrrl and the rest of the pi products end up being around 28mm.



Once i get the tft glitch fixed ill add the rear L and R buttons.

 
Case looks good. The J1 soldering is harmless - as long as you stay at 3.3V from what I heard about the versions out when I got mine, that's why I linked the 'definitive forum link' of the day that led me there - it wasn't just my random thought - just my random observation that it fixed that problem as I had it.

From notes I read the Teensy MCU Flash is write all at once. And since supported programming is USB only that would mean having a PC on hand to change games if the code is to execute on boot from Flash. Unless you just ran BYTE code from SD card/RAM and had the engine in FLASH.

There have been semi published tools for self programming of Teensy units. The re-flash programming code needs to be loaded to RAM and the RAM wipes the FLASH and runs to refill flash from 'source' of the desired HEX and then on reboot runs the new code. I watched FrankB doing this from an SD card ( by watched I mean he wrote the code and I ran it for testing with him ). He had it setup and working to fill HALF of flash with loaded code. I never looked as far as seeing why only half - and he never went far enough to try his idea to get full flash programmed - but I think others have - though perhaps not from SD. That was T_3.2 SD>Flash, not sure what the T_3.6/3.5 might do for SD loading. The keyword there is BRICK, the wrong setting or wrong byte over write puts the MCU into non-functional brick mode.
 
Lol the word brick stops me in my tracks. Rodot at the gamebuino site got so frustrated creating the current arduino boot loader thst he gave away some free hardware.

Ok so after half the day of screwing with it and even after soldering the system completely i was still having problems so i took it all back apart and cleaned the pins. I did find that pin 12 was loose on board and i could easily slide back and fourth so i smudged some flux over it resoldered it. Im hoping that was it but wait....

I also powered the teensy by the USB today and while it did make the LED backlight brighter, there was no change. Every other start up failed or failed after touching a button.

I broke the case removing everything so built a better one with better walls and a lil deeper. Gonna try to play with it some more tonorrow though and see if pin 12 did the trick.
 
With display soldered testing another isn't an easy option? No change from closing J1?

FrankB code seemed solid - he only thought he bricked one and I had his code running loading sketchA from SD - then rebooting and loading sketch and it was working with no problem.

How big is the code for a game?
 
Status
Not open for further replies.
Back
Top