ILI9341 read pixels problem

[Anobium]

Stay with the PIC until it is resolved.

Post as an attachment the whole program. I will generate an ASM here. I will compare. And, I will post a HEX for you to test.

OK?

[Anobium]

Stan... see the next page....

[stan cartwright]

I setup my uno breadboard to use the logic level converter again with ili9341.

chip mega328p,16

include <glcd.h></glcd.h>

option explicit

;--------------

define GLCD_TYPE GLCD_TYPE_ILI9341

define GLCD_DC portb.0 ; DIGITAL_8 ' Data command line

define GLCD_CS portb.2 ; DIGITAL_10 ' Chip select line

define GLCD_RESET portb.1 ; DIGITAL_9 ' Reset line

define GLCD_DI portb.4 ; DIGITAL_12 ' Data in | MISO - Not used therefore not really required

define GLCD_DO portb.3 ; DIGITAL_11 ' Data out | MOSI

define GLCD_SCK portb.5 ; DIGITAL_13 ' Clock Line

define ILI9341_HardwareSPI ' remove/comment out if you want to use software SPI.

if commented --- it's same as pic ie cls then no printing.
It is working in that the display is working...it sets up the screen and sets to portrait and cls to black fine. plots points to test etc. ie ok
Using your last include it says 2164063484 for any read pixel test.
I shall try the code I posted and see.
I shall try the original include as you said it worked,
Thanks for you time.

[stan cartwright]

Hi Anobium. Here is a test that compiles and gives wrong results. I don't get pics but seems to work as far as the display ok just the pixel test is not working as expected.
just change
;test
pset 100,100,ILI9341_WHITE
pset 120,100,ILI9341_BLACK
and see the results.
Cheers.

    #chip 18f25k22,64
    #config MCLRE=on
    #option Explicit
    #include <glcd.h>
    #define GLCD_TYPE GLCD_TYPE_ILI9341
    'Pin mappings for ILI9341
    #define GLCD_DC portc.2
    #define GLCD_CS portc.0
    #define GLCD_RESET portc.1
    'As we are using Harware SPI this cannot be change on this chip. This is a non-PPS chip.
    #define GLCD_DI portc.4
    #define GLCD_DO portc.5
    #define GLCD_SCK portc.3
    #define ILI9341_hardwarespi
;
GLCDRotate ( Portrait_Rev )  ;xy=0 top left, optionally you can rotate the screen.
GLCDCLS ILI9341_BLACK
;
dim pixel_colour_left,pixel_colour_right as long ;test pixel colour
;
;test
pset 100,100,ILI9341_WHITE
pset 120,100,ILI9341_BLACK

pixel_colour_left = ReadPixel_ILI9341 (100,100)
pixel_colour_right = ReadPixel_ILI9341 (120,100)
GLCDPrint 70,10,Str32 (pixel_colour_left)
GLCDPrint 70,20,Str32 (pixel_colour_right)
do
loop

[Anobium]

asm please.

[stan cartwright]

with
pset 100,100,ILI9341_WHITE
pset 120,100,ILI9341_BLACK

[stan cartwright]

Strange you got uno to work but it always says the same value for me ie does not work at all.
the display functions fine just read pixel not working.
the miso line from ili9341 GLCD_DI to low side of logic converter then to 5V logic DIGITAL_12 on uno.
So I can't get uno to work with pixelread it seems.

[Anobium]

OK. Try two tests.

Disconnect the GLCD.
1. Ground the DI line to 0V. Run the code. You will have to write the value to serial port.
2. Pull the DI in line to the operating voltage. Run the code. Again. you will have to write the value to serial port.

Test one should 0 and test two should be FFFFFF or may be FFFFFF.

If both 0... then, look at the volatage leveler.

[stan cartwright]

The logic leveller is bi-directional as tested with a multi-meter.
ie tie any port on 3.3V side high ie 3.3V then 5V side goes high and ground 3.3V side and 5V side goes low.
leave 3.3V side floating and 5V side goes high.
Was that the purpose of the test to see if the logic level converter was working bi-directional?

[Anobium]

I meant.

1. Disconnect the GLCD only.
2. Put the DI and test with the same program. As you no longer have a GCLD, Setup the serial to output the values, So, rather that the output to the GLCD, send to the Serial terminal.
3. Then, test with DI pulled down,

I expected FFFFFF and 0

[stan cartwright]

This prints nothing to the terminal set to9600 com 9...as uno is com 9.
glcd still connected

#chip mega328p,16
#include <glcd.h>
#option explicit
;--------------
#define GLCD_TYPE GLCD_TYPE_ILI9341

#define GLCD_DC      portb.0 ;   DIGITAL_8           ' Data command line
#define GLCD_CS      portb.2 ;   DIGITAL_10          ' Chip select line
#define GLCD_RESET   portb.1 ;   DIGITAL_9           ' Reset line
#define GLCD_DI      portb.4 ;   DIGITAL_12          ' Data in | MISO    - Not used therefore not really required
#define GLCD_DO      portb.3 ;   DIGITAL_11          ' Data out | MOSI
#define GLCD_SCK     portb.5 ;   DIGITAL_13          ' Clock Line

#define ILI9341_HardwareSPI    ' remove/comment out if you want to use software SPI.

#define USART_BAUD_RATE 9600
#define USART_TX_BLOCKING
#define USART_DELAY 10 ms
;rename colours to make less typeing
#define bk ILI9341_BLACK
#define re ILI9341_RED
#define gr ILI9341_GREEN
#define bl ILI9341_BLUE
#define wh ILI9341_WHITE
#define pu ILI9341_PURPLE
#define ye ILI9341_YELLOW
#define cy ILI9341_CYAN
#define dg ILI9341_D_GRAY
#define lg ILI9341_L_GRAY
#define si ILI9341_SILVER
#define ma ILI9341_MAROON
#define ol ILI9341_OLIVE
#define li ILI9341_LIME
#define aq ILI9341_AQUA
#define te ILI9341_TEAL
#define na ILI9341_NAVY
#define fu ILI9341_FUCHSIA
;
GLCDRotate ( Portrait )  ;xy=0 top left, optionally you can rotate the screen.
GLCDCLS bk
;
dim pixel_colour_left,pixel_colour_right as long ;test pixel colour
;
;test
do
pset 100,100,wh
pset 120,100,bk

pixel_colour_left = ReadPixel_ILI9341 (100,100)
pixel_colour_right = ReadPixel_ILI9341 (120,100)
hserprint str32 (pixel_colour_left)
HSerPrintCRLF
;GLCDPrint 70,10,Str32 (pixel_colour_left)
;GLCDPrint 70,20,Str32 (pixel_colour_right)

loop

[Anobium]

You need to use HSerPrint.... to show the values.

[stan cartwright]

Either that or got to click connect...terminal looks complicated.
Removed glcd.
Connected the line on 3.3V side that went to glcd miso and connected to 3.3V got screen capture.
Connecting to 0V gives zeros.

[stan cartwright]

I've tried 3 ili9341 for this and they behave the same with pic and uno. Strange the pic results were better than uno.
Thanks for your time sorting this. I hope it's not an error on my behalf.

[Anobium]

Sorry for delay.

No electricity yesterday. Went off at 515 and back on at 2045. It was very cold in the house!

Anyway... the HSerPrint results are not what we need.

You need two sets of tests.

1. With the GLCD side of the leveler connected to 0v. We need the reset of the left and right read.
2. With the GLCD side of the leveler connected to 3v3. We need the reset of the left and right read.

The value of 4294967296 is Zero, you are correct. But this only one read for left. So, this one result give no insight into the root cause of the issue.

[stan cartwright]

Sorry about your supply going. What happened?
Back to uno. Using a new uno board and the clk,mosi and miso on the 6 pin header instead of the digital 10,11 etc. and the glcd still connected. Results HSerPrint and glcdprint-
leftpixel = black = 2147483648
rightpixel=white=2164063484
;
leftpixel = white= 2164063484
rightpixel=black= 2147483648

This seems that the read_pixel works on a uno. I will test more.
When using a pic, as the thread started, black gave a value of 0, not 2147483648

[Anobium]

Are these values with the GLCD side of the voltage strapped high and low? If they are then they are meaningless.

[stan cartwright]

"Are these values with the GLCD side of the voltage strapped high and low? If they are then they are meaningless." No, these are working values with the glcd connected and using as normal to test pixel colours.
The original problem with ilirread-rixel with a pic was...as said earlier.
The results now with a uno are different in that if you test a black then a white pixel it gives different results for black and white.
If you test a white pixel then a black pixel it gives the same value for the white pixel as before and same value for black pixel.
On a pic if the first pixel was white and the second pixel was black it read them both as white.
This is not happening using a uno.

Since using ili9341 we are limited to

#define bk ILI9341_BLACK
#define re ILI9341_RED
#define gr ILI9341_GREEN
#define bl ILI9341_BLUE

etc. Would it be easier if the ili9341_read_pixel returned a text variable of the colour instead of a long number ie the colour you typed in the code?

Does 2147483648 mean black and does 2164063484 mean white?
if so it's working. at least it's consistant.

[stan cartwright]

Don't have to reply straight away. Sort other priorities first. I like experimenting and trying to sort things myself.
I don't understand what your advice means sometimes...guess you use a phone a lot :)
But again, thanks for your time answering.

[Anobium]

OK. A picture.

Test 1. Force DI to 0V. Write two pixels, the read two pixels and send the value to the terminal.
Test 2. Force DI to %V. Write two pixels, the read two pixels and send the value to the terminal.

The returned values are 24bit color values. So, to understand these numbers AND with 0xFFFFFF.
So, you will get back 0xFCFCFC and 0x00. Which I think is WHITE and BLACK respectively.

These tests are to show that if you strap Low and High the returned values are consistent. This has nothing to do with the write operation but everything to do with the read operation. If the Low test returns 0x00 and the high test returns 0xFCFCFC then we know the circuit is correct and that the code is reading the port correctly.

[stan cartwright]

On new uno and different pins wiring it seems ok.
On the lander prog this works. Note I AND the results with 0xfffff. This gives black as 0,
which is what I wanted and no problems I have with pic.
This could be 6 jumpers stuck next each other ie bad connections on the other uno.
A bit of momentum and increasing gravity and could be nice demo/game.
A poor video,my camera is no good for filming close up cos it uses edge contrast to focus and cls messes it up. https://www.youtube.com/watch?v=lD5kULvRvhs&feature=youtu.be
It shows the values of 2 pixels under the sprite and if it hits left says dead left.
if it hits right it says dead right
if it hits a flat horizontal it says landed.
Code for testing is so simple, in this landscape designed to make it simple.
A few triangles to navigate around and limited fuel?
Should I still test your hardware as it seems to work on uno ok?
edit The following code did not work on a pic at 3.3V...which was the point of this post. Sorry it got side tracked. It was when you said my pic code worked on an uno...and it didn't.
Some where in the libs it says the values for ili9341 colours. I'll try to correlate something.

do ;main loop
pixel_colour_left = ReadPixel_ILI9341(sprite_x ,sprite_y + sprite_height) and 0xfffff ;left pixel colour
pixel_colour_right =  ReadPixel_ILI9341(sprite_x + sprite_width,sprite_y + sprite_height) and 0xfffff ;right pixel colour

GLCDPrint 140,10,Str32 (pixel_colour_left)
GLCDPrint 140,20,Str32 (pixel_colour_right)

if (pixel_colour_left > 0) and  (pixel_colour_right > 0) then ;both pixels lit so flat
    GLCDPrint 100,100,"LANDED",wh
    do
    loop
end if

if pixel_colour_left > 0 and pixel_colour_right = 0 then
  GLCDPrint 100,100,"Dead Left",wh ;hit left
  do
  loop
end if

if pixel_colour_left = 0 and pixel_colour_right > 0 then
  GLCDPrint 100,100,"DEAD Right",wh ;hit right
  do
  loop
end if

[Anobium]

I think you are telling us that all is good. Sounds like a connection problem to me.

Add that extra functionality and you have a proper game. I am away for a week, but, hopefully you have it all sorted for when i get back!

[stan cartwright]

All is good on avr and just tested on pic and works ok now. samecode with AND 0xfffff.
Strange that without AND 0xfffff the pic gave black as 0 but not uno which gave long number for black.
Think uno version would be better than pic but the code has both, just commented so it's pic or uno. better meaning 18f25k22 not as popular as uno.

[stan cartwright]

Reply in a month.
top of my head for getting string values from ReadPixel. VERY basic idea.
From the colour values as defined in ili9341 include.

'sub pixelcol
'  pix=ReadPixel_ILI9341 (xp,yp) and 0xfffff
'    for ptr=1 to 36 step 2
'      ReadTable colval,ptr,ilicol
'      if pix=ilicol then pix= ReadTable colval,ptr+1,ilicol 
'    next ptr
'end sub

table colval
0x0000,"BLACK"
0xf800,"RED"
0x07e0,"GREEN"
0x001f,"BLUE"
0xffff,"WHITE"
0xf11f,"PURPLE"
0xffe0,"YELLOW"
0x07ff,"CYAN"
0x528a,"D_GRAY"
0x7997,"L_GRAY"
0xc618,"SILVER"
0x8000,"MAROON"
0x8400,"OLIVE"
0x07e0,"LIME"
0x07ff,"AQUA"
0x0410,"TEAL"
0x0010,"NAVY"
0xf81f,"FUCHSIA"
end table

'#define ILI9341_BLACK   0x0000
'#define ILI9341_RED     0xF800
'#define ILI9341_GREEN   0x07E0
'#define ILI9341_BLUE    0x001F
'#define ILI9341_WHITE   0xFFFF
'#define ILI9341_PURPLE  0xF11F
'#define ILI9341_YELLOW  0xFFE0
'#define ILI9341_CYAN    0x07FF
'#define ILI9341_D_GRAY  0x528A
'#define ILI9341_L_GRAY  0x7997
'#define ILI9341_SILVER  0xC618
'#define ILI9341_MAROON  0x8000
'#define ILI9341_OLIVE   0x8400
'#define ILI9341_LIME    0x07E0
'#define ILI9341_AQUA    0x07FF
'#define ILI9341_TEAL    0x0410
'#define ILI9341_NAVY    0x0010
'#define ILI9341_FUCHSIA 0xF81F

[Anobium]

Not sure.

The basics. We write 16bit colors but we read 24bit colors. That is the way it is. So, to test for 24bit colors you need to create a table of 24bit colors. There are many online websites tbat do this conversion. Why? the compare of a constant representing the color will be faster, a lot faster, than the AND of two long variables and then the compare.

So, you know two 24bit colors. fcfcfc and 0. Its a start.