| View previous topic :: View next topic |
| Author |
Message |
Will Reeve
Joined: 30 Oct 2003
Posts: 209
Location: Norfolk, England
|
| Bug in “SED1335.c” ? |
 Posted: Fri Nov 26, 2004 8:54 am |
 |
|
I believe there is a bug in the SED1335.c driver software, to read a byte from a SED1335 controller the A0 line needs to be high! I have modified that procedure:
| Code: |
// Purpose: Read a byte of data
// Outputs: The byte of data
int8 glcd_readByte()
{
byte data;
set_tris_d(0xFF);
output_low(GLCD_CS);
output_high(GLCD_A0); // new line
delay_cycles(1);
output_low(GLCD_RD);
delay_cycles(2);
data = input_d();
output_high(GLCD_RD);
output_high(GLCD_CS);
return data;
}
|
It now works. Anyone else use this driver?
Keep well,
Will |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Nov 26, 2004 1:15 pm |
|
|
I think it has more to do with the design of the driver program,
rather than a bug.
In the driver, these two routines are the lowest level routines:
| Code: | glcd_readByte()
glcd_sendByte() |
It's the intention of the programmer that these are not stand-alone
routines. They're only to be called by higher level functions in
the driver. This is not stated, but it's implied.
Near the start of the file, they have these two macros:
| Code: | #define TGLCD_COMMAND output_high(GLCD_A0);
#define TGLCD_DATA output_low(GLCD_A0); |
In the higher level functions, they use these macros to setup
the proper level for A0 before calling the lower level functions.
References:
Full data sheet for SED1335:
http://www.blue-technology.com.hk/blue-tech/SED1335.pdf
Alternate driver:
Go to http://www.baso.no/ then click on "Programming", and then
on "ImageCraft AVR", and then on "Library for Graphic LCD Displays" |
|
|
Will Reeve
Joined: 30 Oct 2003
Posts: 209
Location: Norfolk, England
|
|
| Posted: Fri Nov 26, 2004 2:41 pm |
|
|
I did notice that (sort of) after I posted and actually changed a couple of the higher level functions to get it working instead:
| Code: | // Purpose: Get a byte of data from the display at the address
// Inputs: A 16 bit integer containing the address
// Outputs: An 8 bit integer with the read data
int8 getData(int16 addr)
{
setCursorAddress(addr);
glcd_sendCMD(GLCD_CMD_DISPLAY_READ);
TGLCD_COMMAND // changed from TGLCD_DATA
return glcd_readByte();
}
|
Also
| Code: | // Purpose: Get the current address of the cursor
// Outputs: A 16 bit integer containing the cursor address
int16 getCursorAddress()
{
int16 addr;
glcd_sendCMD(GLCD_CMD_GET_CSR_ADDR);
TGLCD_COMMAND // changed from TGLCD_DATA
*(int8*)(&addr ) = glcd_readByte(); // Read low part
*(int8*)(&addr + 1) = glcd_readByte(); // Read high part
return addr;
}
|
As far as I can see you would not ever want to call the read byte procedure with A0 low unless you were doing a “status flag read”; there isn’t a higher level function which uses getData to do this they (CCS) has written:
| Code: | // Purpose: Get the status
// Outputs: The status in an 8 bit integer
int8 getStatus()
{
int8 status;
TGLCD_DATA
output_low(GLCD_CS);
output_low(GLCD_RD);
delay_us(1);
status = input_d();
output_high(GLCD_RD);
output_high(GLCD_CS);
return status;
}
|
Who knows why! Anyway don’t take this as a complaint at ccs as I am more than grateful at the generous driver libraries they supply, just this time an error has crept in.
I just wish there was a driver for the ADS7846 and AD7843 touch controllers as I am going to have to write my own on Monday (I’ll publish it in the code forum when finished!)
As an aside I can’t recommend craftdata (http://www.craftdata.co.uk) highly enough as they shipped me another LCD next day to try and get me out of a hole! It was only when both displays showed the ‘fault’ did I start to literally play with the code and figured out what was causing the problem. If you don’t set A0 high then line D6 has a 32Hz square wave on it, D0 to D5 and D7 behave exactly as they would with A0 high, you just end up with a random state on D6 which has the effect to corrupting the read on that bit, very confusing!
Thanks for that link to the full datasheet; I have been working from the easier to find on the web cut-down version which doesn’t have that A0 logic table on page 6 in it which now confirms the fix which is re-assuring. |
|
|
Will Reeve
Joined: 30 Oct 2003
Posts: 209
Location: Norfolk, England
|
|
| Posted: Sat Nov 27, 2004 9:47 am |
|
|
Actually the getStatus() function is not very nice to the hardware. It sets the LCD to output on it’s data bus (the output_low(GLCD_RD) line) while the PIC could still be outputting it’s data on the data bus as well! Either could be trying to drive ‘high’ into low!
Solutions; re-write getStatus to:
Or
| Code: | // Purpose: Get the status
// Outputs: The status in an 8 bit integer
int8 getStatus()
{
set_tris_d(0xFF);
int8 status;
TGLCD_DATA
output_low(GLCD_CS);
output_low(GLCD_RD);
delay_us(1);
status = input_d();
output_high(GLCD_RD);
output_high(GLCD_CS);
return status;
} |
But might as well use the getData lower level function:
| Code: | // Purpose: Get the status
// Outputs: The status in an 8 bit integer
int8 getStatus()
{
int8 status;
TGLCD_DATA
status = glcd_readByte();
return status;
} |
|
|
|
sbk
Guest
|
| bug |
| Posted: Tue Aug 22, 2006 5:40 am |
|
|
| Quote: | Code:
// Purpose: Get a byte of data from the display at the address
// Inputs: A 16 bit integer containing the address
// Outputs: An 8 bit integer with the read data
int8 getData(int16 addr)
{
setCursorAddress(addr);
glcd_sendCMD(GLCD_CMD_DISPLAY_READ);
TGLCD_COMMAND // changed from TGLCD_DATA
return glcd_readByte();
} |
Correct. That was a bug, after I altered the drives as you did, pixel based routines become working correctly |
|
|
hansolo
Joined: 06 Oct 2006
Posts: 20
|
|
| Posted: Wed Oct 18, 2006 6:14 pm |
|
|
| Will Reeve wrote: | I did notice that (sort of) after I posted and actually changed a couple of the higher level functions to get it working instead:
| Code: | // Purpose: Get a byte of data from the display at the address
// Inputs: A 16 bit integer containing the address
// Outputs: An 8 bit integer with the read data
int8 getData(int16 addr)
{
setCursorAddress(addr);
glcd_sendCMD(GLCD_CMD_DISPLAY_READ);
TGLCD_COMMAND // changed from TGLCD_DATA
return glcd_readByte();
}
|
Hope someone can give me some pointers.
Also
| Code: | // Purpose: Get the current address of the cursor
// Outputs: A 16 bit integer containing the cursor address
int16 getCursorAddress()
{
int16 addr;
glcd_sendCMD(GLCD_CMD_GET_CSR_ADDR);
TGLCD_COMMAND // changed from TGLCD_DATA
*(int8*)(&addr ) = glcd_readByte(); // Read low part
*(int8*)(&addr + 1) = glcd_readByte(); // Read high part
return addr;
}
|
As far as I can see you would not ever want to call the read byte procedure with A0 low unless you were doing a “status flag read”; there isn’t a higher level function which uses getData to do this they (CCS) has written:
| Code: | // Purpose: Get the status
// Outputs: The status in an 8 bit integer
int8 getStatus()
{
int8 status;
TGLCD_DATA
output_low(GLCD_CS);
output_low(GLCD_RD);
delay_us(1);
status = input_d();
output_high(GLCD_RD);
output_high(GLCD_CS);
return status;
}
|
Who knows why! Anyway don’t take this as a complaint at ccs as I am more than grateful at the generous driver libraries they supply, just this time an error has crept in.
I just wish there was a driver for the ADS7846 and AD7843 touch controllers as I am going to have to write my own on Monday (I’ll publish it in the code forum when finished!)
As an aside I can’t recommend craftdata (http://www.craftdata.co.uk) highly enough as they shipped me another LCD next day to try and get me out of a hole! It was only when both displays showed the ‘fault’ did I start to literally play with the code and figured out what was causing the problem. If you don’t set A0 high then line D6 has a 32Hz square wave on it, D0 to D5 and D7 behave exactly as they would with A0 high, you just end up with a random state on D6 which has the effect to corrupting the read on that bit, very confusing!
Thanks for that link to the full datasheet; I have been working from the easier to find on the web cut-down version which doesn’t have that A0 logic table on page 6 in it which now confirms the fix which is re-assuring. |
I am testing a G2432W08UBN11 GLCD from Crystal Clear Technology and this GLCD uses a SED1335 controller. I amended the SED1335.C driver to the above as suggested by a few users since it is proven that it works.
The problem is I am only getting streaks of verticle lines jumping around on the screen. I had also changed the delay timing of the glcd_sendbyte and glcd_readbyte but of no help. I had also tried adjusting the contrast pot but in vain.
I am using PIC16F877A with 20MHz crystal. I had tested with the following codes :
| Code: | #include <16F877A.h>
#device adc=8
#FUSES NOWDT, HS, PUT, NOPROTECT, NODEBUG, NOLVP, NOCPD, NOWRT
#use delay(clock=20000000)
#include <sed1335.c>
#include <GRAPHICS.C>
void main()
{
char Text1[] = "12345678", warning[] = "Warning";
set_tris_b(0x00);
glcd_init(ON);
while(1)
{
output_toggle(pin_b1);
delay_ms(200);
glcd_text57(0, 0, Text1, 1, ON); // Display text
glcd_text57(0, 20, warning, 2, ON); // Display text
}
} |
I had checked my wiring a few times and its all correct.
Can anyone give me a helping hand? |
|
|
sraiderk
Joined: 09 Feb 2005
Posts: 48
|
|
| Posted: Tue Jun 26, 2007 8:04 am |
|
|
hansolo,
Do you reach any result? Because I have same problem. Thanks... |
|
|
The Puma
Joined: 23 Apr 2004
Posts: 227
Location: The Netherlands
|
|
| Posted: Sat Nov 10, 2007 5:07 pm |
|
|
| Did someone has it to work??? |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
