Jump to content
43oh

(Universal) Color LCD graphics library


Recommended Posts

  • 2 weeks later...
  • Replies 127
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

NOTE: Those files are not current as of May 5th 2013. See the first post for the latest. PCF8833 (Nokia 6100) SPFD54124B (Nokia 6085 and 6101) ST7735R (JD-T1800, 1.8" LCD) HX8340B (BTL221722, 2.2" wi

Just FYI. In a couple of weeks, I will be updating this library with the following:   support for HX8340 (2.2" LCD) support for ILI9225 (2.2" LCD with touch panel) landscape/portrait switch most

New versions are here   UPDATE: Sep 3rd 2013 New way to configure dev boards Works with TI's G2 LaunchPad (G2553,) and my G2955, F5172, F5510, F5529 dev boards. Just one line change to switch bet

Posted Images

Hi,

 

I just got an ITDB02 2.2SP from IteadStudio (see http://store.iteadstudio.com/index.php?main_page=product_info&products_id=527 )
 that I am planning to use with the librarycode provided as it uses the HX8340 chip.

 

I have just added all necessary files to the CCS environment and the compilation went fine. I only got several warnings for line 104 in ColorLCD.c : const u_int totalPixels = LCD_WIDTH * LCD_HEIGHT;

 

The warnings are that the integer operation is out of range and that the integer conversion will result in a change of sign.

 

Did anybody encounter these before, is there anything crucial linked to this ?

 

regards

CorB

Link to post
Share on other sites

For the ease of use etc I use this on top of my main.c code to remember which connections this code uses. 

 

EDIT: now shows the connections to make when using the Itead LCD. Which worked directly from RobGs code ... fantastic !!!

 

//*******************************************************************
//
//                  G2553                                        LCD itdb02-2.2SP
//
//             -----------------
//            |                 |
//    1/5---  |VCC          GND | ---6                     1---   VDD33
//    2--- CS |P1.0         P2.6|                          2---   CS
//            |P1.1         P2.7|                          3---   SCL
//            |P1.2             |                          4---   SDA
//            |P1.3             |                                 NC
//            |P1.4         P1.7| DIO ---4                 5---   RST
//    3---CLK |P1.5         P1.6|                          6---   GND
//            |P2.0         P2.5|                          7---   VIN // for 5V systems
//            |P2.1         P2.4|
//            |P2.2         P2.3|
//            |                 |
//             -----------------
//*******************************************************************
 
Edited by CorB
Link to post
Share on other sites
  • 2 weeks later...

Hi,

 

Did anybody try generating fonts using fontfactory for use with this library ? I am currently trying to find out what settings best can be used to create larger fonts. 

 

kind regards

 

CorB

 

EDIT: found it out after a lot of trial and error. In the settings (I am using the fonts only for the HX8340) for DotFactory I am using:

FLIPROTATE NONE
BYTE Bitlayout ROWMAJOR
         Order LSBFIRST
Padding removal FIXED
Be aware that DOTFACTORY always outputs 8bit values in the arrays.
Link to post
Share on other sites

Hi,

 

Ive succesfully setup my LCD (HX8340 based) using this library and using the Anaren AIR Boosterpack. But I want to improve the speed of the LCD and the only way to do that is to switch from SW SPI to HW SPI. This should be easy as the Anaren AIR also uses HW SPI. In trying to do so I am thusfar not succesfull and would like to hear if anybody sees a flaw in my approach.

 

I start the initialisation of  the SPI connections with the following code, The TI_CC_CSn_PIN is the default CS for the Anaren AIR.

void TI_CC_SPISetup(void)
{
  TI_CC_CSn_PxOUT |= TI_CC_CSn_PIN;
  TI_CC_CSn_PxDIR |= TI_CC_CSn_PIN;         // /CS disable

  P2SEL = 0x00;  // Make sure CSn works instead of crystal
  
  UCB0CTL1 |= UCSWRST;                      // **Disable USCI state machine**
  UCB0CTL0 |= UCMST+UCCKPH+UCMSB+UCSYNC;    // 3-pin, 8-bit SPI master
  UCB0CTL1 |= UCSSEL_2;                     // SMCLK
  UCB0BR0 = 0x02;                           // UCLK/2
  UCB0BR1 = 0;

  
  TI_CC_SPI_USCIB0_PxSEL |= TI_CC_SPI_USCIB0_SIMO
                         | TI_CC_SPI_USCIB0_SOMI
                         | TI_CC_SPI_USCIB0_UCLK;
  
  TI_CC_SPI_USCIB0_PxSEL2 |= TI_CC_SPI_USCIB0_SIMO
                         | TI_CC_SPI_USCIB0_SOMI
                         | TI_CC_SPI_USCIB0_UCLK;
    
                                            // SPI option select
  TI_CC_SPI_USCIB0_PxDIR |= TI_CC_SPI_USCIB0_SIMO | TI_CC_SPI_USCIB0_UCLK;
                                            // SPI TXD out direction

  UCB0CTL1 &= ~UCSWRST;                     // **Initialize USCI state machine**
}

I then initialize the CS-pin for the LCD module (connected to P2.0 in my setup)

  P2OUT |= LCD_SCE_PIN;

  P2DIR |= LCD_SCE_PIN;

 

 

 

Ive changed the Writecommand routine (and writedata in the same way )in ColorLCD to the following code:

LCD_Select and LCD deselect are again controlling the CS status on P2.0.

HWSPI is defined. SPI9BIT is defined.

// code duplication, but we are saving clock cycles by not passing dataCommand
void writeCommand(u_char data) {
	u_char c = 0;
	LCD_SELECT; //cs low

#ifdef HWSPI

 #ifdef SPI9BIT
	LCD_SD_OUT_LO; // data low
	LCD_CLOCK;     //pulse the clock
 #else
	LCD_DC_LO;
 #endif
   UCB0TXBUF = data; // write INT to TX buffer
   while (!(IFG2 & UCB0TXIFG));
   while (UCB0STAT & UCBUSY);

#else
	while (c < 8) {
		(data & 0x80) ? (LCD_SD_OUT_HI) : (LCD_SD_OUT_LO);
		LCD_CLOCK; // pulse the clock
		data <<= 1;
		c++;
	}
#endif

	LCD_DESELECT; //cs high
}

Unfortunately the code does not seem to do anything on the display, normally the Clearscreen command will wipe the screen but ... nothing happens.

 

Did I miss something obvious ??

 

regards

CorB

Edited by CorB
Link to post
Share on other sites

This is how my function looks like, however, this works with 8bit only.

For 9bit, you would have to disable clock and data pin SPI option, manually clock first bit, then re-enable SPI option.

void writeData(u_char data) {
	u_char c = 0;
	LCD_SELECT;
#ifdef SPI9BIT
        // if hardware, disable SPI option
	LCD_SD_OUT_HI;
	LCD_CLOCK;
        // if hardware, enable SPI option
#else
	LCD_DC_HI;
#endif

#ifdef HARDWARE_SPI
	UCB0TXBUF = data;
	while (UCB0STAT & UCBUSY);
#else
	while (c < 8) {
		(data & 0x80) ? (LCD_SD_OUT_HI) : (LCD_SD_OUT_LO);
		LCD_CLOCK
		;
		data <<= 1;
		c++;
	}
#endif
	LCD_DESELECT;
}
Link to post
Share on other sites

Hi,

In the SPI code (based on the same SPI setup) I used for Lars' LCD we send 2 databytes in a sequences. The 1st databyte only contained the 0 or 1 for the 1st bit and the rest of the bits were send in the 2nd byte. Ill try if that path works since it should work completely on the HW SPI base and removes the need to manually clock the 1st bit.

Cor
P.S. Just tested and that setup worked as planned (sending 2 bytes). So the issue is purely to get the 1st bit of the 9 bits over the SPI line in a proper manner.

 

Here's the code:

void writeData(u_char data) {


 char first = (1 << 7) | (data >> 1);
 char second = (data << 7);
 LCD_SELECT; //cs low


 while (!(IFG2&UCB0TXIFG));                // Wait for TXBUF ready
 UCB0TXBUF = first;                         // Send address
 while (!(IFG2&UCB0TXIFG));                // Wait for TXBUF ready
 UCB0TXBUF = second;                        // Send data
 while (UCB0STAT & UCBUSY);                // Wait for TX to complete


 LCD_DESELECT;

}

 

writeCommand it the same but starts with (0<<7). 

This does work but seems to be not very reliable, if I write many times the same data (for instance drawrect) to the same location on the screen my screen gets filled. I guess thats due to the fact that we do not really send 9 bits but send 16bits.

Edited by bluehash
Please use code tags.
Link to post
Share on other sites

Hi all,

 

After a bit more testing I now managed to get the HW SPI working using the above code (sending 2 bytes). Still trying to find a faster setup but sending 2 bytes via HW SPI is clearly faster than sending via SW SPI. And the fact that the RF boosterpack is also still functional means I have freed 2 lines on the launchpad.

 

cheers

 

Cor

Edited by CorB
Link to post
Share on other sites
  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...