Someone with ST Lcd Controllers/drivers experience ?

Go To Last Post
32 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I bought a Barton LCD controller by a STE2004S used in I2C mode. (extended instruction set)

I just can't get the thing to display a thing.

Voltage is ok, fuses and such ok, I2C code works as I can talk to an eeprom and RTC.

The doc is really messy, sometimes they talk about 2 bytes command words, then three bytes...

Has someone ever managed to display something with that beast ?

Thanks.

Chris.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Really would help if you posted datasheet and the part of code where you try to talk to LCD

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lennart wrote:
Really would help if you posted datasheet and the part of code where you try to talk to LCD

Indeed ...

Datasheet :
http://www.st.com/stonline/produ...

Code to setup checkboard on lcd:

#define STE_RESET_PIN PINC2
#define STE_RESET_PORT PORTC
#define STE_RESET_DDR DDRC

#define DevSTE2004 (0x78+1)

// DC high=write to ram    DC low=command
#define DC (64)
// CO high=last command/byte   CO low=stream
#define CO (128)


	STE_RESET_PORT&=~_BV(STE_RESET_PIN); 	// set RESET to LOW to reset lcd.
	_delay_ms(10);
	STE_RESET_PORT|=_BV(STE_RESET_PIN);		// set RESET to high to activate lcd.
	_delay_ms(10);

	i2c_start_wait(DevSTE2004+I2C_WRITE);     // set device address and write mode
	i2c_write(0); // page 0, more commands follow, command mode (CO=0 DC=0)
	i2c_write(_BV(3)+0x4); // lcd normal mode
	// i2c_write(0); // not clear if 1 or 2 databyte needed, then what's in second ??
	i2c_write(1); // page 1, more commands follow, command mode (CO=0 DC=0)
	i2c_write(_BV(5)); // powerup
	// i2c_write(0); // not clear if 1 or 2 databyte needed, then what's in second ??
	i2c_write(CO+1); // page 1, last command, command mode (CO=1 DC=0)
	i2c_write(1); // generate checker board
	// i2c_write(0); // not clear if 1 or 2 databyte needed, then what's in second ??
	i2c_stop();     

Code to read status

	i2c_start(DevSTE2004+I2C_READ);
	t=i2c_readAck();
	i2c_readAck();
	i2c_stop();     
// status is : PD=1 BSY=0 D=0 E=0 MX=1 MY=0 DO=1

The write commands seems to work ok, as device respond to selection and ack.

I'm using Peter Fleury's lib "I2C Master Interface" with hardware I2C.

Last Edited: Mon. Aug 13, 2007 - 05:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In the doc the main things that are not clear to me are :

-Command words are 2 or three bytes ???
Illustrations show 1 control 1 data only, doc talks about three bytes, but then nothing describes what's in the second and third.
-How H[0;1] command pages are selected... Either in the control byte with bits 7=CO 6=DC ... 2=H1 1=H0 as the illustration shows, or using a "page selector" command with Bit5=1 ?

I tried various approches but none worked so far.
I just can't switch the PD bit to zero.

It really looks like that doc was generated by copy/pasting from another device, without checking content...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looking at the datasheet, the Slave address is 0x78. Depending on the addressing pins, you may want to OR in (0..3)<<1. But it will never be 0x79. I am not familiar with your library code. But check to see what you should send. i.e. with a 24LCxx device do you send 0xA0 or 0x50 ?

The other thing to check is whether there is a return value from i2c_start_wait(). The datasheet is a little confusing, but I would just print the Figure 33. and double check the initialisation code for your checkerboard.

I hope you get it working because it looks quite a handy chip.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
But it will never be 0x79.

Damn you're right... That what happens when you try stupid things all around to make it work and forget to remove the bugs...

I'll try some more with the right address.

Thanks for spotting that error.
Do you know what are the recommended pullup resistor values for i2c ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Recommended values depend on the bus capacitance, supply voltage and speed. The capacitance depends on how long the bus is. The real truth is in the Philips I2C spec, found on wikipedia article on I2C or google.

But for 5V I've used 4k7 or 10k in my experiments, even 2k2 should be fine. 10k might be a bit on the high side. For 3.3V systems as low as 1k8 is ok, but I guess anything from 2k2 to 4k7.

- Jani

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It works !

Checking the return values of the I2C write commands really helped.
Some commands needed a delay to execute and writing too fast made following writes to fail.
Also all the default settings make sure nothing is displayed... :-(

For those interrested, here's the code that works ok now.
LCD is from Farnell (BT96040AV1-COG-SRE-12-I2C — BATRON — LCD MODULE, 96X40 I2C)
and cost around 25€.

Quote:

// RESET is active low
#define STE_RESET_PIN PINC2
#define STE_RESET_PORT PORTC
#define STE_RESET_DDR DDRC

#define DevSTE2004 (0x78)

// DC high=write to ram DC low=command
#define DC (64)
// CO high=command CO low=stream
#define CO (128)

void writeFailed()
{
while(1)
{
PORTB=0xFF;
long_delay_ms(200);
PORTB=0;
long_delay_ms(200);
}
}

void i2c_write_check(uint8_t v)
{
if (i2c_write(v)!=0) writeFailed();
}

void command(uint8_t command)
{
i2c_write_check(0); // more commands follow, command mode (CO=0 DC=0)
i2c_write_check(command); // page 1, more commands follow, command mode (CO=0 DC=0)
}

void setFunction(uint8_t page,uint8_t cmd)
{
command(_BV(5)+page);
command(cmd);
}

void LCD_Reset()
{
uint8_t t;

STE_RESET_PORT&=~_BV(STE_RESET_PIN); // set RESET to LOW to reset lcd.
long_delay_ms(100);
STE_RESET_PORT|=_BV(STE_RESET_PIN); // set RESET to high to activate lcd.
long_delay_ms(100);

i2c_start_wait(DevSTE2004+I2C_WRITE); // set device address and write mode
PORTB=~0xF1;
setFunction(0,_BV(3)|_BV(2)); // lcd normal mode
setFunction(1,_BV(0)); // checkerboard
_delay_ms(10);
_delay_ms(10);
setFunction(0,_BV(2)+2+1); // PRS VLDC 10.62v
setFunction(0,_BV(4)+2); // Charge pump X4
setFunction(1,_BV(4)+4); // Bias ratio 3

i2c_write_check(CO); // NO commands follow, command mode (CO=0 DC=0)
i2c_write_check(_BV(5)); // page 0
i2c_stop();

i2c_start_wait(DevSTE2004+I2C_READ); // set device address and write mode
t=i2c_readNak();
i2c_stop();

PORTB=~t; // output status to port B

}

Thanks for your support !

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And to clarify the doc...

There's no such 3 bytes thing. Commands are 2 bytes.
The illustration is confusing, the H[1;0] page select is not in the control byte with CO/DC.
It is set by the page select command, the one with bit5=1.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there any application notes for STE2004S controller?
Or a second source that uses same I2C inteface?

I must say STE2004S dataheet is really confusing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am starting with the same display. This topic is really helpfull. The only thing which is still not clear to me: what voltage needs to be put on the VLCD pin (pin 6) of the module?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You leave the VLCD pin disconnected. The default is for the chip to generate its own VLCD.

You do need to connect the RESET line. I have not got the Software Controller Reset command to work.

Which C Compiler and which I2C library are you intending to use ?

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using the AVR studio with Winavr added.

The I2C sources I have found are simple TWI routines which were presented in an application note to access a serial eeprom if I remember correctly. I don't have them at work so I can't check.

For the display I have found sources at http://www.hcilab.org/projects/d... which need to be modified a bit because they use a slightly different display (with the same basenumber, just to make things worse...).

If you have more suggestions then I am always interested.

Greetings,
Dreeke

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your display has a slave address of 0x78. The sample code is 0x7A.

I would recommend the Fleury TWI code. But the calling conventions are different to your source.

The code appears to be for PIC but looks as if it should go OK. Good Luck. I may well have a play myself.

If you want help just shout. Killertoffy and I have both got working Avr-gcc code.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for your remarks. I noticed the code is originally not for AVR so I am slowly porting some parts to my project. If I am not mistaken I have the Fleury TWI code at home.

Thanks for your help.

Greetings,
Dreeke

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a link which I would like to share with all of you for the creation of fonts:
http://www.scienceprog.com/simul...

This is a java application which can generate a .h file from any installed windows font. Just create a new font and import the font you like.

The only missing item is a similar programm for bitmaps.

Greetings,
Dreeke

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dreeke wrote:
The only missing item is a similar programm for bitmaps.

Try a Google for "bmp2lcd"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dreeke wrote:
I am using the AVR studio with Winavr added.

The I2C sources I have found are simple TWI routines which were presented in an application note to access a serial eeprom if I remember correctly. I don't have them at work so I can't check.

For the display I have found sources at http://www.hcilab.org/projects/d... which need to be modified a bit because they use a slightly different display (with the same basenumber, just to make things worse...).

If you have more suggestions then I am always interested.

Greetings,
Dreeke

I followed your link. The code that I found there requires:

an initialisation function
a correct driver function for the ST2004S chip
Ellipse and filled object drawing.

A VERY large amount of code memory.
A VERY large amount of SRAM.

There are better graphics libraries. The drawing functions generally write a bitmap buffer in SRAM. One Update routine transfers the buffer to your display.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are right, the code is huge! I didn´t look that close to the code. I only wanted to have some indication of how to start up(problem has been solved). I will try to find better code.

Dreeke

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I thought that you would be impressed by the size. It also required quite a bit of editing to function.

The startup is no great problem when you know how. The advanced controller commands do not all seem to work.

The Batron display has the i2c interface. If the other interfaces of the driver chip are used then I think you should be able to READ the display memory.

I can only read the display status code via the i2c. I would dearly like to read the memory. Have you succeeded ?

This means that you are obliged to hold a complete display buffer in SRAM. Do all the drawing to this buffer, and update the LCD from this buffer. This works well but is expensive in SRAM.

Obviously you can overwrite the display with text or a bitmap aligned to byte boundaries.

I can suggest several graphics libraries that will write to the SRAM buffer. These just interface to an initialisation and paint routine to update the Batron display.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

According to the datasheet it should be possible to read back the display memory even with i2c. I did not try this out yet but I will look into it. Maybe it should be something like:
-write X
-write Y
-write Read command
-read memory
The i2c bus switches to read directly after receiving address+read so the chip needs to know what it should put on the bus in advance. In the past I have developed i2c slaves.

My initial plan was to overwrite with bitmap aligned text. But I am sure interrested in graphical libraries.

André

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dear Andre,

I have tried that, with no success.

Function_page(?), Read Command just return status.

Function_page(0), Set Ram X, Y.
Ext_Function_page(1), Set Read mode crashes.

I use a display buffer in SRAM. But it would be nice to use the chip display memory.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I quite agree. Also, I think that it would get slow because of the i2c interface. Anyhow, I will give it a try in a later stage.

I´ll keep you informed.

André

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I got an answer from ST about reading the sram via i2c. Unfortunately only the status can be read. Seems we're stuck with the good old external buffer....

Sorry, but dont shoot the messenger :?

André

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had also come to that conclusion. Re-reading the data sheet had made it clear.

I have been playing with Graphics libraries. To my surprise, Gcc performs much better than CodeVision in both speed and size of code. I have tidied the ks0108 library from Fabian Thiele. It is now more efficient and independent of the Graphics chip.

There is a lot to be said for a display controlled completely by two I2C lines with software bias and contrast control. The update speed is not unreasonable at 400kHz I2C.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi David,

For compilation I use AVRStudio with the WinAVR plugin. Since I can't see anything other yet on my display than the testpattern (married, with children :) )I have no idea yet about speed.

I'm also charmed about the display which needs only one power supply with software control.

I was just planning to tidy up the ks0108 library, seems we're on the same wavelength. Is it permitted to ask a copy? That would surely speed things up for me. I'll contact you by PM.

André

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I'm with very difficulty to understand the instruction set of this driver in I2C mode.

Can anyone explain the basic instructions to send the pages?

Thanks in advance.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

any help?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Im also trying to make this LCD work, im using the evaluation kit of MAXIM TINI DS80C400, it has a I2C protocol implemented, the adress that i use for the LCD is 0x78, but because of the way that my I2C class works i have to shift it right, making it 0x3C, the code used is java, i tried to implement killertoffy C code to java....every time i make the CheckersBoard command, the LCD gets stuck, and doesnt acknowledge any more commands.....can anyone help?

import com.dalsemi.system.*;



public class I2CBoot {
	
	final static byte command=(byte)0x80;
	final static byte data  =(byte)0x40;
	final static byte page0 =(byte)0x00;
	final static byte page1 =(byte)0x01;
	
	//page 0 commands
	
	final static byte read  =(byte)0x00;
	final static byte funcSet=(byte)0x24;        //Set function with PD=1
	final static byte funcSeton=(byte)0x20;      //Set function with PD=0  
	final static byte blankM=(byte)0x01;
	final static byte scroll=(byte)0x02;
	final static byte vlcd  =(byte)0x04;
	final static byte dMode =(byte)0x08;
	final static byte setCP =(byte)0x10;
	final static byte ramY  =(byte)0x40;
	final static byte ramX  =(byte)0x80;
	
	//page 1 commands
	
	final static byte checker =(byte)0x01;
	final static byte tempC   =(byte)0x04;
	final static byte biasR   =(byte)0x10;
	
	//other required variables and objects
	
	static byte dados [] = new byte [3000];
	static byte instru [] = new byte [1];
	static byte def [] = new byte [1];
	static byte cmd [] = new byte [1];
	static I2CPort port = new I2CPort();    
	static BitPort resetLCD;
	
	public static void main (String[]args){
		 
		def [0] = 0;
		
		for (int i=0;i

The output to this code is...

Reset ao LCD
Sent comand word: 0
Sent comand word: 24
Sent comand word: 0
Sent comand word: c
Modo normal enviado
Sent comand word: 0
Sent comand word: 25
Sent comand word: 0
Sent comand word: 1
Fail comand word: 0
Fail comand word: 24
Fail comand word: 0
Fail comand word: 7
VLCD 10.62 enviado 
Fail comand word: 0
Fail comand word: 25
Fail comand word: 0
Fail comand word: 14
Bias 3 Enviado
Fail comand word: 0
Fail comand word: 24
Fail comand word: 0
Fail comand word: 12
Charge pump 4x enviado 
Fail comand word: 80
Fail comand word: 20

Any help would be apreciated, sorry for any bad english

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have had one of these BT96040 displays for a while and got it working with some help from this thread.

I just got another one from Farnel and unfortunatly it has changed. It is the same to look at but the controller is now a ST7549T http://www.sitronix.com.tw/sitro...$FILE/ST7549T%20V13.pdf
The basic workings are the same but the instruction set has some differances and the initalisation needs to be changed.

Here is the sequence I am using.

        bartonLcdTxtWriteCommand(1,1,0x14);    // page 1, PD=1, Bias = 7 (0x4)
        bartonLcdTxtWriteCommand(1,1,0x0c);    // page 1, PD=1, DO = 1
        bartonLcdTxtWriteCommand(1,0,0x76);    // page 1, PD=1, start line = y    // has to be before VOP write. some sort of bug.
        bartonLcdTxtWriteCommand(1,1,0xd8);    // page 1, PD=1, VOP= 0x58
        bartonLcdTxtWriteCommand(0,1,0x05);    // page 0, PD=1, PRS = 1 HIGH
        bartonLcdTxtWriteCommand(0,0,0x0c);    // page 0, PD=0, power up display mode normal.
        // manual clear
        for (y = 0; y < 9; y++)
        {
            bartonLcdTxtSetXY(0,y);
            for (x = 0; x < 17; x++)
            {   
                //bartonLcdTxtPutChar('0'+y+x);
                bartonLcdTxtPutChar(' ');
            }
        }

Ifor

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know it is an old thread... but for the record I published my graphic library as LPGL :

https://sites.google.com/site/do...

It is using the Barton with STE2004S but can be tweaked to any other LCD easily.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ifor wrote:
I have had one of these BT96040 displays for a while and got it working with some help from this thread....I just got another one from Farnel and unfortunatly it has changed. It is the same to look at but the controller is now a ST7549T

ifor - Thank you so much - I was getting nowhere with this display and had tried what felt like every possible cominations of commands from the STE2004S datasheet with no luck, until I finally found this forum post.

So, just for the sake of Google finding this for others:

Farnell 1323370 (COG-BT96040A-08) now uses ST7549T not STE2004S, and just for reference it's I2C address is 0x7E not 0x78.

Now to try and re-insert the hair I pulled out yesterday.