TFT 2,2" as GLCD (Norton Commander face)

[Stinen]

HALLO EVERYONE,
Excuse my english please.

I conected picaxe 20X2 with 2,2 TFT lcd (256K color deep).
It works at 64Mhz (SPI 4Mhz (spimedium)).
It works in blue mode (65K color mode is activated and chars are read from eeprom as 2color bitemap).
I have only problem with hspisetup, it is not working if I set: hspisetup spimode00, spifast...... only hspisetup spimode00, spimedium is working well.
If someone will be interest I can publish program code and schema.

https://www.youtube.com/watch?v=pXb_PvGdbvk&feature=youtu.be

Have a nice day!

 

[hippy]

Welcome to the PICAXE forum.

If the GLCD is working with 'spimedium' but not 'spifast' it could simply be that 'spifast' is simply too fast for the GLCD. Do you have a link to the datasheet of the GLCD module being used ?

 

[Stinen]

Hi hippy,
i use TFT lcd (ILI9341 driver) for arduino as GLCD lcd (2color)... This display is normaly working with much higher frequency i think... Datasheet is here: https://docs.google.com/file/d/0B9cAzTdwG1EabHJCdGdla0JtdUE/edit

 

[hippy]

Looking at pages 230-231 of that datasheet it does appear the SPI can be clocked at up to 10MHz, but it also suggests the mode required would be "spimode10" rather than "spimode00".

Might be worth trying spimode10,spimedium to see if that works then try spimode10,spifast.

 

[srnet]

I have only problem with hspisetup, it is not working if I set: hspisetup spimode00, spifast...... only hspisetup spimode00, spimedium is working well.
If someone will be interest I can publish program code and schema.

Data sheet says the display accepts a 10MHz SPI clock.

spifast at 64Mhz produces an SPI clock of 16Mhz, i.e. too fast.

 

[hippy]

spifast at 64Mhz produces an SPI clock of 16Mhz, i.e. too fast.

Thanks for pointing that out. From Manual 2 -

spifast (clock freq / 4 ) (= 1MHz with 4MHz resonator)
spimedium (clock freq / 16) (= 250kHz with 4MHz resonator)
spislow (clock freq / 64) (= 63 kHz with 4MHz resonator)

So 64MHz and spimedium will give a 4MHz SPI, 64MHz and spifast will give 16MHz.

32MHz and spifast will give 8MHz so perhaps drop to 32MHz while executing HSPIOUT and return to 64MHz for other processing. But without trying it it is hard to say if the gain of faster transfers against slower PICAXE execution would increase overall screen update speeds or reduce them.

 

[srnet]

But without trying it it is hard to say if the gain of faster transfers against slower PICAXE execution would increase overall screen update speeds or reduce them.

Indeed.

I suspect overall speed & performance will be much higher running the PICAXE at 64Mhz and the SPI at spimedium.

 

[Stinen]

Hi guys, than you for help.
I already tried what you write and at 64MHz and spi medium it working fastest.....But I dont understand, how is possible that on arduino or rapsbery this display is working more and more faster. When i connect osciloscope on pin SDI (SDA) i can see 8bits transfered and long long pause between other transmite bite, is any way how make this pause shorter? >>
hspiout (%10101010,%10101010) makes on SDI 10101010....................................................................................10101010
If i use hspiout(%1010101010101010) lcd read only 10101010............................................
Is some way how to pull up DC pin after every 8bit transfer for make lcd understand next 8bits? Or some other way?
Thanks for reply

 

[hippy]

The PICAXE is running an internal interpreter so there is the overhead of command fetch and execute which other microcontrollers often will not have when running compiled code.

The only way to speed up PICAXE execution is by running at a faster speed but you cannot go faster than 64MHz. It may be possible to write the code in a manner which allows bytes to be sent faster, with less inter-byte gap, but that may not be possible if you need to clear or set other I/O lines between each byte sent. I cannot think of any automatic way to set your DC signal high after each transmission.

Does DC need to be set or cleared every byte sent ? If you can keep that static you can probably improve throughput by writing multiple bytes in one command.

 

[Stinen]

Yes i understand what you mean. DC signal changed every 8bits is nessesary if CLOCK SCK is runing without space. If SCK is stoped, lcd driver know that new series of bites are sending. So for text and bitmaps I am using command like this:

b10=bit0*%11111000 ;65Kcolor mode BlueGreenRed(BBBBBGGG,GGGRRRRR) >> (%11111000,%00000000) = blue
b11=bit1*%11111000
b12=bit2*%11111000
b13=bit3*%11111000
b14=bit4*%11111000
b15=bit5*%11111000
b16=bit6*%11111000
b17=bit7*%11111000
;>>>>>>>>>>>>>>>>>>>>>>if bit0=0 then b10=0 and if bit0=1 then b10=%11111000=0xF8
hspiout (b10,0,b11,0,b12,0,b13,0,b14,0,b15,0,b16,0,b17,0)

and for frames:

hspiout(112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0,112,0)

I think there is no way for faster drawing frames as in video.

My first idea was that maybe there is some posibility to send two series of 8bites together, after i get two times faster drawing....

b10=bit0*%11111000
b11=0
.
.

hspiout (w5,w6,w7,w8)

but.........