ssd1963 tft lcd mikroc pic brands

Can you provide a list of displays that work out of the box with your SSD1963 library, especially for 3.5" and 4.3" displays? If there are only a few that have been tested, can you provide a tutorial on which init values to change, and how to complete the task? Which SSD1963 specs are important and how to interpret them?

In particular, it would seem to make sense to directly support the displays from NewHaven and Displaytech, which are widely available in the US from the same distributor who carries the MikroElektronika line. A lot of users are going to buy VTFT and one of these displays, only to become a support problem when they don"t work.

* Note : SSD1963 is operating under reference clock before PLL is locked, registers cannot be set faster than half of the reference clock frequency. For instance, SSD1963 with a 10MHz reference clock is not allowed to be programmed higher than 5M words/s.

Now for the procedure. Where do you add this code? In the driver module? Are all these commands already supported in the MikroE TFT library? I assume that this would replace the existing SSD1963 init procedure. Or do I have to edit the ME init routines? Is this possible, and if so what"s the basic procedure?

It would be great if VTFT had an entry screen for this kind of data, or an xml file where it could be edited. That would make it much easier for users to share their files for various displays in the Libstock area. I have a variety of displays and would be glad to share my results once I have them working.

* Note : SSD1963 is operating under reference clock before PLL is locked, registers cannot be set faster than half of the reference clock frequency. For instance, SSD1963 with a 10MHz reference clock is not allowed to be programmed higher than 5M words/s.

* Note : SSD1963 is operating under reference clock before PLL is locked, registers cannot be set faster than half of the reference clock frequency. For instance, SSD1963 with a 10MHz reference clock is not allowed to be programmed higher than 5M words/s.

To answer some of your questions anyway: I have not used Visual TFT, only mP Pro for PIC and DSPIC. I would suggest you get the display working correctly (fill screen) in your compiler using your own code and the display application note. This reduces the amount of unknowns and then start using the compiler TFT library routines. I haven"t upgraded to the latest releases but understand they have the option of a user custom initialisation.

I am using MikroBasic Pro for PIC32 and dsPIC, and also have MikroC for PIC32. I have been using Basic for decades, but am migrating to C. MikroE makes this easy to do. Some of my recent projects have been in C, but when I need to write a lot of code, I fall back on Basic. Jumping back and forth results in syntax errors sometimes out of habit, but the compiler always catches them

My intention has been to use the 16b interface, but I had bad luck testing the 16b SSD1963 driver board for the Newhaven displays. Now that I am armed with their sample init code, I should have no trouble, and plan to try that again. FWIW, in testing my program with the EasyTFT module, I measured only a 20% or so improvement in writing speed to the display with 16b vs. 8b... a far cry from the improvement I expected. I"m not sure why this should be. Hopefully I"ll see closer to expected scaling with the 16b Newhaven display.

What kind of writing times are you seeing for a full screen background color write with your Winstar 3.5" display? If you have also used EasTFT or TFT Proto, how do they compare? In other words, is the SSD1963 implementation faster, slower or about the same as the HX8347-G implementation?

To answer some of your questions anyway: I have not used Visual TFT, only mP Pro for PIC and DSPIC. I would suggest you get the display working correctly (fill screen) in your compiler using your own code and the display application note. This reduces the amount of unknowns and then start using the compiler TFT library routines. I haven"t upgraded to the latest releases but understand they have the option of a user custom initialisation.

My intention has been to use the 16b interface, but I had bad luck testing the 16b SSD1963 driver board for the Newhaven displays. Now that I am armed with their sample init code, I should have no trouble, and plan to try that again. FWIW, in testing my program with the EasyTFT module, I measured only a 20% or so improvement in writing speed to the display with 16b vs. 8b... a far cry from the improvement I expected. I"m not sure why this should be. Hopefully I"ll see closer to expected scaling with the 16b Newhaven display.

The SSD1963 and I would expect other controllers as well, have a "hardware accelerator" built in. The controller auto increments to the next screen location after each write and to the start of the next row at the end of each row.

From the SSD1963 data sheet one can see that the TFT display is typically not the limiting factor in write speeds unless you are using a super fast processor:

Sorry, can"t answer this question as I just used the Winstar app. note initialisation and it worked. I am surprised the Newhaven example does not set the PLL frequency while Winstar set it to 113.33MHz? To get fast write speeds the SSD1963 obviously requires a fast clock.

The SSD1963 and I would expect other controllers as well, have a "hardware accelerator" built in. The controller auto increments to the next screen location after each write and to the start of the next row at the end of each row.

Sorry, can"t answer this question as I just used the Winstar app. note initialisation and it worked. I am surprised the Newhaven example does not set the PLL frequency while Winstar set it to 113.33MHz? To get fast write speeds the SSD1963 obviously requires a fast clock.

It doesn"t appear to be turning on and/or locking. I haven"t verified this 100%, but the writing speed suggests this (unless there is something radically wrong with the ME SSD1963 implementation). I set the frequency, turn it on, wait for at least 100us for it to lock, and then select PLL as the clock source. It works the same as with the 10MHz clock as the source.

I tried that with two different displays/driver boards, one 320x240 and one 480x272, although they are from the same company. I have a handful of others to try from different manufacturers. Most have SSD1963, but one has SSD1961. The init commands appear the same based on the datasheet. I will start to get very suspicious if they all have the same problem

lpmsr wrote:It doesn"t appear to be turning on and/or locking. I haven"t verified this 100%, but the writing speed suggests this (unless there is something radically wrong with the ME SSD1963 implementation). I set the frequency, turn it on, wait for at least 100us for it to lock, and then select PLL as the clock source. It works the same as with the 10MHz clock as the source.

BTW, if I use the ME library to write to EasyTFT, which uses a HX8347G driver with 8-bit addressing, the results are much faster... about 75ms for a full screen write. Not the 20ms it should be, but acceptable for many projects.

Malcolm_M wrote:lpmsr wrote:It doesn"t appear to be turning on and/or locking. I haven"t verified this 100%, but the writing speed suggests this (unless there is something radically wrong with the ME SSD1963 implementation). I set the frequency, turn it on, wait for at least 100us for it to lock, and then select PLL as the clock source. It works the same as with the 10MHz clock as the source.

I decided to run some performance tests with the TFT library. For these tests I used a simple loop of TFT_Fill_Screens and toggled a pin between screen fills to look at with my oscilloscope. Processor is PIC32MX795F512L running at 80MHz. Resolution is 320x240. Here are the measured screen fill times for various drivers and interfaces...

The 8 bit time for the SSD1963 is what I have been seeing all along, but in light of the other measurements, is puzzling. I upgraded my MikroBasic Pro to 3.30 before running these tests. Strangely enough, this version works with my display without modifying the initialization parameters as I had to do with v2.70. So perhaps they made some tweaks to the values. The data may suggest an issue with the 8 bit library though as far as speed goes. The times with the 16 bit interface are not spectacular, but acceptable in my project because I rarely do a full screen fill. Most of the time I am only updating various small objects without changing the background. Perhaps there is more optimization to be done in the initialization. Unlike the 8 bit times, the SSD1963 16 bit time is consistent with the EasyTFT time for 16 bit.

The problem is that I still can"t get anything to actually display in 16 bit mode with the SSD1963. I have attached my driver code. Maybe you could take a look and see if you can spot some obvious problem.

Malcolm_M wrote:lpmsr wrote:It doesn"t appear to be turning on and/or locking. I haven"t verified this 100%, but the writing speed suggests this (unless there is something radically wrong with the ME SSD1963 implementation). I set the frequency, turn it on, wait for at least 100us for it to lock, and then select PLL as the clock source. It works the same as with the 10MHz clock as the source.

Thin film transistor liquid crystal display (TFT-LCD) is a variant of liquid crystal display (LCD) which uses thin-film transistor (TFT) technology to improve image quality (e.g., addressability, contrast).

TFT LCDs are used in television sets, computer monitors, mobile phones, handheld video game systems, personal digital assistants, navigation systems, projectors, etc.

void TFT_Set_Brush(char brush_enabled, unsigned int brush_color, char gradient_enabled, char gradient_orientation, unsigned int gradient_color_from, unsigned int gradient_color_to);

void TFT_Rectangle_Round_Edges(unsigned int x_upper_left, unsigned int y_upper_left, unsigned int x_bottom_right, unsigned int y_bottom_right, unsigned int round_radius);

void TFT_Partial_Image(unsigned int left, unsigned int top, unsigned int width, unsigned int height, code const far unsigned short * image, unsigned short stretch);

void TFT_Ext_Partial_Image(unsigned int left, unsigned int top, unsigned int width, unsigned int height, unsigned long image, unsigned short stretch);

ER-TFTM070-4V2.1 is the updated version of ER-TFTM070-4,that is 800x480 dots 7" color tft lcd module display with ssd1963 controller board,superior display quality,super wide viewing angle and easily controlled by MCU such as 8051, PIC, AVR, ARDUINO, and ARM .It can be used in any embedded systems,industrial device,security and hand-held equipment which requires display in high quality and colorful image.

Of course, we wouldn"t just leave you with a datasheet and a "good luck!".Here is the link for7" TFT capacitive touch shield with libraries,examples,schematic diagram for Arduino Due,Mega 2560 and Uno. For 8051 microcontroller user,we prepared the detailed tutorial such as interfacing, demo code and development kit at the bottom of this page.

ER-TFTM050-5 is 800x480 dots 5" color tft lcd module display with SSD1963 controller board,superior display quality,super wide viewing angle and easily controlled by MCU such as 8051, PIC, AVR, ARDUINO, and ARM .It can be used in any embedded systems,industrial device,security and hand-held equipment which requires display in high quality and colorful image.

Of course, we wouldn"t just leave you with a datasheet and a "good luck!".Here is the link for5" TFT capacitive touch shield with libraries,examples,schematic diagram for Arduino Due,Mega 2560 and Uno. For 8051 microcontroller user,we prepared the detailed tutorial such as interfacing, demo code and development kit at the bottom of this page.

I am using WB-7 TFT LCD Module Rev2.2 in 8-bit mode with MCU dsPIC33EP512MU810 cloicking at 80 MHz. The LCD module is 7-inch 800x480 display with SSD1963 controller.

I am totally new to using LCD screens with microcontrollers. Whenever I execute the command TFT_Fill_Screen(CL_Black), the screen takes 2-3 seconds to change each line to black.

it is easily controlled by 8051, PIC, AVR, ARDUINO, and ARM via MCU interface.It supports 6800, 8080 8-bit /9-bit/16-bit/18-bit/24-bit parallel interface.