Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Playing with a 1.8" 128X60 RGB TFT_LCD

Status
Not open for further replies.

DrG

Active Member
For no particular reason, I purchased a small color display (this one **broken link removed**) for US$6.54. It came relatively quickly - ~two weeks.

I hooked it up to an Arduino ProMini 3V3 clone. The usual SPI connections (usual in the Arduino world). Here is a quick video of an example to get you to read further:

I first tried the ucglib, but that was problematic:
119145


You can see what appears to be an obvious offset problem. In fact, I did some digging and found that to be the case (e.g., here and here). I tried this fork that was designed to address the problem, but it did not work for me. Eventually, I found this library which works quite well. I think some modification to ucglib can be made to correct the offset, but since I don't even know what I am going to use it for, I am not getting into that now.

Here are a couple pics from library examples:
MinionDisplay Fonts IMG_1076.jpg


119147


All-in-all, this little screen appears to be pretty impressive (and very easy to use in the Arduino world)...all for less than $7.
 
All-in-all, this little screen appears to be pretty impressive (and very easy to use in the Arduino world)...all for less than $7.

Yes, I've used a number of them (along with various others), with PIC's as well as Arduino, but I've never likely ugclib, I've stuck to Adafruit (and a PIC port of it).

You find the offset problems on various displays, and it usually takes a fair bit of messing about to cure it - it's never as simple as finding one suggested cure, and it working first time.
 
I've used the same screen with a driver based on the one from this site - see half way down the page:

That has three different possible initialisation routines included and you can pick the one that works best with the specific version of that module you are using.
 
I've used the same screen with a driver based on the one from this site - see half way down the page:

That has three different possible initialisation routines included and you can pick the one that works best with the specific version of that module you are using.

Thanks, I have bookmarked that page and the driver (the one linked from the page and based on Adafruit's driver). A bunch of these 1.8 LCDs have been around. The one I got (the Minion display for lack of a better term) looks different than the one in the linked page. Is yours identical to the Minion? No SD card? Same markings? Even a green tap is no longer definitive :) (see below)/

Reading a bit, look at the approaches in the two code fragments:

https://drive.google.com/file/d/1ZbYxD9z3GDZ6bDljXUSFTnQxRait5AQZ/view
// some flags for initR() :(
#define INITR_GREENTAB 0x00

#define INITR_GREENTAB 0x0
#define INITR_GREENTAB2 0x3 // Use if you get random pixels on two edges of green tab display

I'm not suggesting that the simple #define is the key, but rather suggesting that I gives me the sense that these displays have multiplied, if not have evolved. I think the problem is probably a combination of the ST7735S being able to accommodate a larger resolution than 128X160 and some discrepency/ambiguity in querying the hardware.

Take a look at this thread by Bodmer, who wrote the Adafruit adaption I linked to. I thought it spelled things out well.

Nevertheless, if the PIC code works with the display, that is a big plus for me. Even if not, I appreciate your response.
 
Status
Not open for further replies.

Latest threads

Back
Top