ST7735 Library

[Pepe]

Yes, it is not the library updated by Les

[Pepe]

I have written the readpixel procedure for the ST7735 screen and I have simulated it in proteus, I do not have the hardware to test it, someone has tried to simulate in proteus the command to read the video ram because I think it has an error that makes it not put back in input mode after executing the read command and the only way I found is resetting the screen to continue communicating with it.

[joesaliba]

I can test it if you want to on real hardware.

Is it slower than the previous method?

Joe

[Pepe]

Being a serial communication it is slower than parallel but if it works you can make it read a window instead of a single pixel
I enclose the library to test and the simulation in proteus for pic 18f2550, modify it for your pic.

I have also corrected the register reading procedure, now you can consult any register on the screen.

For example, to read the color configuration mode write

colmod = ST7735_ReadReg8(ST7735_cRDDCOLMOD)

if it is in 16 bits it returns a 5, in 18 bits it returns a 6


I am looking forward to your response.

[Yasin]

I am currently working on a universal graphic library that will work with the most different screens. (monochrome or color).

And a little later publish here on the forum.

Here is an example of the simplest oscilloscope on them.

Dear @atomiks and forum members. As far as I know, only one-way data can be sent to the nokia 5110 lcd. I'm also trying to find a non-bulky method to write a single pixel. My goal is to draw graphics, make floating menus. The method I'm thinking of using right now is to allocate a space in ram memory for screen data (84x6=504 bytes). Processing the data in the ram and sending it to the screen at once. It's not a neat method. I couldn't find another way. I'm following the thread.


https://www.youtube.com/watch?v=ckMDemmqBLY
https://github.com/HA4ever37/Sim800l-Nokia

[atomix]

I have this method and implemented. I will try to lay out today at least a raw version.

[Pepe]

Demonstration in proteus of new procedures
ST7735_getwindow and ST7735_putwindow

[joesaliba]

I will try it later in the week Pepe.

I have an issue I might send you the files for you to test them if you don't mind.

Regards

Joe

[Pepe]

If you want you can send them to me, I can only simulate them in proteus.

[Pepe]

Joesaliba I have found the problem, the line procedure has as input parameters variables of type word with sign and the procedure plot only of type unsigned byte, therefore any value that was negative or greater than 255 was drawn on the screen in any position.
I enclose your modified library for your screen and mine.

In your program add two spaces at the end of this lines to erase
characters

Print At 3,10,  "Roll:  ", SDec3 Roll,"    "
Print At 70,10, "Pitch: ", SDec2 Pitch,"    "

[joesaliba]

HI Pepe,

I will try your files later today when at my PC.

I noticed some typing errors in the file you supplied.

Line 738 and 762: -

Code Select Expand

If pStartXpos > = 0 And
should be?: -

Code Select Expand

If pStartXpos >= 0 And
or it does not make a difference?

Regards

Joe

[Pepe]

I tried the universal atomix library, for now it doesn't work because it doesn't support drawing lines with negative values ​​and I don't know what the procedure is to rotate the screen.

[Pepe]

Your algorithm that you use to get the values ​​to draw the lines generates negative values ​​and the line procedure in the atomix universal library doesn't handle negative parameters so it looks like this.

[Pepe]

Joesaliba I have corrected the fillrec procedure redownload the library
it should stay like this

ST7735_FillRect(0,  0, 128, 80, clSkyBlue)
ST7735_FillRect(0, 81, 128, 80, clBrown)

[joesaliba]

Pepe,

I download from post #49?

I can confirm that now it works how it should be, however I noticed that it slowed down a bit more than it was.

Is it a case because SPI is slow or the library itself is slow?

Regards

Joe

[Pepe]

if you want it to be faster, modify your algorithm for calculating the horizon so that it doesn't generate too large negative values.

[top204]

I haven't looked at the code yet, but remember, some signed comparisons and expressions do take a little longer than unsigned comparisons and expressions, because they have to also check the sign of the variables/values when comparing, and adjust the sign when performing an expression.

A good example is signed divide, which takes longer because it has to re-adjust the signs. If you look at the assembler code for the signed divide library subroutine, you will see it is larger than the unsigned divide library subroutine.

[joesaliba]

Ok,

Will further investigate the matter. I was also suggested to include a table for COS and SIN which will improve speed. I will have to think about how to implement it. But so far happy.

Thanks

Joe

[joesaliba]

@top204 Have you updated the ST7735 library on your website to the optimised one you mentioned?

Pepe found a problem in this library, mentioned in post #49, just in case you update the one on your web site and have same anomaly.

Regards

Joe

[Pepe]

add this

Declare Float_Display_Type = Fast

and this in the library

    Dim wDeltaX    As SWord Access
    Dim wDeltaY    As SWord Access
    Dim wStepX     As SWord Access
    Dim wStepY     As SWord Access
    Dim ST_wWidth  As SWord Access
    Dim ST_wHeight As SWord Access
    Dim wDeviation As SWord Access