A tft addin for pbp3

[richard]

CURRENTLY tring to get an image drwn on to the display
I'm using the arduino utft ImageConverter 565.exe to generate a data file , but I'm at a loss to understand what it produces.
I have a 246x204 b&w pixel bmp file as input and expected a 246x204 word array as output (ie a word to describe the colour of each pixel) with pixels either black or white. that's not what I get

partial sample

// Generated by : ImageConverter 565 v2.1
// Generated from: duck.bmp
// Time generated: 28/06/2015 1:18:14 PM
// Dimensions : 246x204 pixels
// Size : 100,368 Bytes
#include <avr/pgmspace.h>
prog_uint16_t duck[0xC408] PROGMEM ={
0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, // 0x0010 (16)
0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, // 0x0020 (32)
0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, // 0x0030 (48)
0x0000, 0x0000, 0x0000, 0x0000, 0x0861, 0x4A49, 0x6B6D, 0xA534, 0xDEDB, 0xFFDF, 0xFFFF, 0xFFFF, 0xEF7D, 0xD69A, 0xA534, 0x630C, // 0x0040 (64)
0x4228, 0x0861, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, // 0x0050 (80)
0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, // 0x0060 (96)
0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, // 0x0070 (112)
0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, // 0x0080 (128)
0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, // 0x0090 (144)
0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, // 0x00A0 (160)
0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, // 0x00B0 (176)
0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, // 0x00C0 (192)
0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, // 0x00D0 (208)
0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, // 0x00E0 (224)
0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, // 0x00F0 (240)
0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, // 0x0100 (256)
0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, // 0x0110 (272)
0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, // 0x0120 (288)
0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x4228, 0xBDD7, 0xFFFF

you can that some pixels have become coloured or more likely I am not interpreting the file correctly
source attached

any help here would be appreciated

[richard]

tft now with duck, drawimage now works
and a python script to convert utf565 generated c file to pbp friendly format

[richard]

forgot the python script

[richard]

The dev board I'm using for this project has a w25q32 flash memory chip on board , unfortunately on the same spi port as the display. this little display does a really fine job on graphics but transferring image data from flash to display is turning out to be much more complicated than expected. the other spi port is loaded up with a rtc and an eeprom (both i2c) . I'm not sure how they will react to the spi signals if I move the display to that port.
hoping to avoid smoke
here is the flash usercommand file so far

[richard]

I have a bit of conditional compiling going on to select mssp1 or mssp2 but is there a way to conditionally check if the pic18 chosen to compile for has 1,2 or no mssp modules .

#IFNDEF TFT_SPI
    #DEFINE TFT_SPI 1 
      ;DEFAULT
 #ENDIF   



 #IF   TFT_SPI = 1
     SSP1_IF VAR pir1.3    
 #ELSE
     SSP1_IF VAR PIR3.7
 #ENDIF

      
TFT_CMD:
spi_cbyte :
    tft_port =  tft_port & (~ tft_dc_bit )
TFT_DATA:    
spi_byte :
'@       movff    INTCON , _p_int 
'@       bcf     INTCON ,7 
    tft_port =  tft_port& (~ tft_cs_bit )
    SSP1_IF = 0
    #IF   TFT_SPI = 1
    SSP1BUF = CMD 
    #else
    SSP2BUF = CMD 
    #endif
    WHILE   SSP1_IF =0 ' wait for SPI interupt flag
    wend
    tft_port = tft_port |   ( tft_dc_bit|  tft_cs_bit   )
    
'@     movff  _p_int  , INTCON 
return

the problem is that if the pic has only one mssp then sspbuffer becomes sspbuf where as for two its ssp1buf or ssp2buf.
and it would nice to have shiftout as an option.

other than that it nearly a done deal

[HenrikOlsson]

Hi Richard,
Apart from including a list of all PICs with two MSSP modules and checking against that list I don't know a way of telling at compile time. There's probably a way to have the assembler do it but then its too late.....

However, looking at the P18F45K22.INC file, as an example, one can see that SSPBUF and SSP1BUF are both declared and pointing at the same adress so I think you should be safe using SSPBUF and SSP2BUF. Obviously one can't know if Microchip will continue to alias SSPBUF to SSP1BUF on devices with multiple MSSP modules...

/Henrik.

[richard]

hi henrik

in asm I can do this

 asm
  ifdef SSPIF
     #define  ssp_1  0
    endif


    ifdef SSP1IF
     #define  ssp_1  1 
    endif

endasm

but a #define thats made here seems unreadable to the pbp compiler
and I don't really want to do the whole routine in asm

[richard]

tried using
SSPBUF = CMD
when ssp1buf exists and it syntax errors it really wants SSP1BUF = CMD

tried
sspbuf var ssp1buf

result
syntax error var is already an alias

[HenrikOlsson]

Hi Richard,
Which device are you targeting?

/Henrik.

[HenrikOlsson]

but a #define thats made here seems unreadable to the pbp compiler
and I don't really want to do the whole routine in asm

Exactly, that's what I meant by "but then it's too late". The assembler doesn't do its stuff until PBP is finished doing it stuff so whatever you do in and with the assembler is unkown to the compiler....

[richard]

Which device are you targeting?

any pic18 was what I'm aiming at , hoping to get a default compile that would use mssp1 if it exists/shiftout if no mssp exits and mssp2 if user sets a define to do so.
dare I say idiot proof , but I don't think I can do it , at this point users will need some knowledge of the pic hardware chosen for their application and will need to modify the code accordingly.

[HenrikOlsson]

Hi Richard,
I tried the following very simple program

CMD VAR BYTE
CMD = SSPBUF
CMD = SSP1BUF
CMD = SSP2BUF

I compiled it for a couple of 18F devices, all with 2 MSSP modules. Some of them (like the 18F24J11, 18F44J50 and 18F46K22) worked fine while others didn't and gave a Bad Expression error on the CMD=SSPBUF. My conclusion is that Microchip isn't consistent in aliasing SSPBUF to SSP1BUF thru all their device header files :-(

I don't know a way of doing it automatically - that's not to say it can't be done though!
I'd probably use SSPBUF in the code and add a comment saying that if the compiler complains then add SSPBUF VAR SSP1BUF to the code. That's certainly not idiot proof but you do know that's an impossible thing to achieve ;-)

/Henrik.

[richard]

henrik
I think your right and what you suggest may be as good as it gets

add SSPBUF VAR SSP1BUF on Expression error

[richard]

WILL call this version 1.0 , the python code now converts the pixels to suit (saves the pic18 from all that work)

the usercommand file has a more meaningful name but I forgot to update the demo's include to the new name
change glcd_chr include to INCLUDE "TFT_SPI.pbpmod" ;glcdc

[Tabsoft]

Richard,

Great amount of work on this library.
I have to hand it to you, a lot of coding you worked out there.

For my own edification, I have a question for you.

In "TFT_SPI.PBPMOD" you have your setxy 8-element byte array for y0, y1, x0 & x1 declared.
This I understand.
You do this to support Word variables for x0 & x1 and space for y0 and y1 to be used as Word variables in the future,
but used as byte variables today. This I assume as the TFT display's y axis in less than 255.

One thing I notice though is that you have the following ASM address mapping for the individual x&y elements.

ASM       
y0 = _setxy +1   
y1 = _setxy +3
x0 = _setxy +4
x1 = _setxy +6
ENDASM

Then you have the following PBP variable declarations.

x0 var WORD EXT 
x1 var WORD EXT
y0 var byte EXT 
y1 var byte EXT

Understood at this point.
x vars are Words and y vars are Bytes.

But here is my question, I thought I noticed you use a lot of manual (CHK?RP/movlw/movwf) manipulation within the USERCOMMANDS for
the y0 & y1 variables instead of using PBP standard macros for MOVE?xx.

Could you not change the ASM address mapping for the y0 & y1 elements to use Little Endian style, instead of Big Endian, and then use the
standard PBP macros (MOVE?BB, MOVE?CB, MOVE?WB)?
Wouldn't that simplify the ASM in the USERCOMMAND macros?
Doesn't the PBP standard MOVE?xx macros take care of the BankSel testing/switching and movement of the High and Low bytes for you?

ASM       
y0 = _setxy +0   
y1 = _setxy +2
x0 = _setxy +4
x1 = _setxy +6
ENDASM

I may be off base, but was just curious.
I didn't read through the entire "TFT_SPI.PBPMOD", to see if there was another reason you have y0 & y1 defined in ASM as Big Endian.

[richard]

good catch tabsoft , I missed that when I changed the setxy method and never finished "cleaning up" . the two hardware includes have been fixed also (same error)
y0,y1 are now words and usercommand macros are more consistent
version 1.1 for these files (already)

[richard]

now have the image rotation corrected , made all the x,y vars word sized (heading towards a portrait/landscape command)
the font now has lowercase , chars 32-127. and few other subtle changes
the image file can be located anywhere , have tested with a 127k pic18f87j11 and loading file past the 64k boundary is no problem

[ruijc]

Greetings Guys,

First of all, congrats to Richard and all the other that participated in this addin.
Very good work !

I ordered one of these displays to test but i wanted to know if ( maybe a stupid question but... ) there is any "minimum requirement" when selecting a pic to work with this addin like min size memory, min osc speed, etc?

I only have a 18F2520 at the moment and i'm wondering if this one will work fine.

Thanks for the feedback

Regards
Rui

[richard]

"minimum requirement" when selecting a pic to work with this addin like min size memory, min osc speed, etc?

the code takes < 6k with no images stored , so the chip needs at least that much code space + what your code requires , ram requirements are modest (but uncounted)
at this point the chip must have at least 1 mssp (spi) module
regarding osc :--- faster = better performance


your 18F2520 should be fine

[ruijc]

Thank you for the feedback Richard,

One last question...

Is there any quick way to display an individual pixel @ a given x,y coordinate?

I'm asking that for displaying graphs, for example.

Also,
Your addin has many commands. Do you have a list of all the commands available?

Regards
Rui

[richard]

Is there any quick way to display an individual pixel @ a given x,y coordinate?

this will set a pixel to the fg colour at x0,y0

            x0=  y coordinate
            y0=  x coordinate
            GOSUB drawpixel

Your addin has many commands. Do you have a list of all the commands available?

no. documenting code is my nemesis , but there are some comments in the code and I have tried to make most functions fairly consistent in their approach to the tasks at hand.

[richard]

try again got my x's and y's the wrong way round obviously

            x0=   x  coordinate 
            y0=   y  coordinate
            GOSUB drawpixel

[ruijc]

Thanks again Richard,

Awesome work you got here!

Cant wait to get the display and test it out

Regards
Rui

[richard]

changing the xy vars to words meant all the usercommand macros need to be changed too , I missed some .

the flash addin no works nicely if anyones interested

[ruijc]

Hi guys,

I dont have my TFT yet, but i tryed to compile the TFT-Demo.pbp file using the same pic Richard used ( 18F87J11 ) but i get lots of compile errors.
One of them is with the FONT7x8 include file.

Can everyone compile the file without any errors?
Do we have to do something in between or are these files plug-and-play?

Regards
Rui

[richard]

the demo has the following includes

  INCLUDE "TFT_SPI.pbpmod"        ;glcdc
    include "tft-ILI9431.bas"  ; or    include "tft-ST7735.bas"

    INCLUDE "DT_INTS-18.bas"
    INCLUDE "ReEnterPBP-18.bas"
    INCLUDE "Elapsed_INT-18.bas"
    INCLUDE "font7x8.bas"
    INCLUDE "duck.bas"

make sure you have the latest version of them , if they are not located in the pbp3 dir or your current dir you need to specify the full path to each file
if testing with pbp3 3.0.7.4


the font file is messed up and has redundant copies included you only need 1
I will upload a new one later

[richard]

additions

TFT_wr_mode VAR byte ;for image drawing 0= normal , 1=flip y , 2= flip x , 3=flip x and y

ie set TFT_wr_mode to 1 to flip image on y axis when DRAWIMAGE used

font file fixed

demo simplified (elapsed_int commented out)

[richard]

forgot to add

doVdline doHdline

x= 196
y= 34
TFT_j= 312
gosub doHdline

will draw a dashed horizontal line from x=196 to 312 at y =34
and a update to the flash add in

x= 256
y= 11
TFT_k= 105
gosub doVdline

bit clunky to use I might add another couple of user commands

[richard]

rui discovered a find and replace error I have made int the tft-st7735 file .
here is the corrected version

[richard]

still fiddling with things , changed external flash routines to expect a 32 byte header in the image file ( x y size and image name), moved all external flash routines to flash pbpmod file.
have uploaded a python2.7 gui pgm to convert 565c image data and add the header , then transfer data to flash via eusart2 @38400 baud . the python code can also erase blocks/read blocks and convert files to bas format (with or without header). (note its set to use com27 edit file to suit your system) all the pic routines are in the flash pbpmod file. this demo has it all setup .

have also made a touch screen addin , that is also included in this demo

[richard]

there are some slight changes in these files too

[richard]

added a draw rectangle function and animated buttons for touch screen (with long and short press detection)

[ruijc]

Hello Richard,

you are the man !
I'm still waiting for the ST7735 display but now i will order the ILI9431 display too

Amazing job!

Congrats.

[richard]

now with individually sizeable buttons

[visnja30]

hi Richard,

today arrived TFT display to me from eBay.

I can not wait to start playing with it

Do you can tell me if this is the correct way to connecting peripherals with a PIC processor (pic18f87J11)



TOUCH PANEL connection to PIC

TOUCH PANEL PIC
T_CS PORT F.2
T_DIN PORT F.3
T_DO PORT F.4
T_CLK PORT F.1
T_IRQ PORT F.5


TFT display connection to PIC

TFT DISPLAY PIC
DC PORT C.2
CS PORT C.1
RST PORT C.0
MOSI PORT C.5
SCK PORT C.3




FLASH MEMORY W25Q32 connection to PIC
FLASH W25Q32 PIC

CS PORT H.0
SO PORT D.5
SI PORT D.4
SCK PORT D.6




My TFT module have a XPT2046 touch controller is this the some controller on your board?
Model of my tft module is : TJTCM24028-SPI 2.8 TFT SPI 240X320 v1.1

[richard]

is the correct way to connecting peripherals with a PIC processor (pic18f87J11)

its not the only way but its the way my demo platform is connected

Model of my tft module is : TJTCM24028-SPI 2.8 TFT SPI 240X320 v1.1

my tft touch module is : TJTCM24024-SPI 2.8 TFT SPI 240X320 , I got no docs with it and have not been able to identify the controller. but it has XPT2046 stamped on the chip so it looks the same as yours

[ruijc]

I was looking on ebay and i could not find any 2.8" TJTCM24024.
The only TJTCM24024 i could find is a 2.4"

see here:
http://www.ebay.com/itm/2-4-240x320-...item20eaff07d1

Also the TJTCM24028:
http://www.ebay.com/itm/240x320-2-8-...item41998b289b


Maybe the 24028 means 2.8" and the 24024 means 2.4".

@Richard,
Can you double check you your display is really 2.4" or 2.8"?

Thanks

Regards
Rui

[richard]

its 2.4 TJTCM24024-SPI 2.4 TFT SPI 240X320
http://www.ebay.com.au/itm/181500077...%3AMEBIDX%3AIT

I should be more careful cutting and pasting

[ruijc]

Thanks Richard...

Pressing buy now...

Regards
Rui

[richard]

the 2.2 board before and after the flash chip added (w25q32bv)