OT: QVGA LCD module with builtin SED1335

Started by Edward Karpicz February 24, 2005
Hi

Sorry if not very HCS12 related subject.

I have to interface D64 to QVGA monochrome LCD module. Module has builtin
SED1335 controller and 32k of display memory. It's too late to change LCD
module and controller. It's not to late to use S12 MCU having more RAM. I
ordered but haven't got LCD module yet. SED1335 documentation has some bugs
and doesn't have answers to some very important questions. I'd like to
experiment and find answers myself but can't do it in next view weeks. I
hope someone of you have been working around SED1335 controllers ...

Details:
Application mostly will display text using proportional fonts, some lines,
and very view bitmaps. There's no requirement for animations or very fast
graphics, though it's GUI and display has to react to buttons, RS232, other
events smoothly.

320x240 graphics. It means one graphic page has 9600 bytes.
SED1335-MCU bus read/write cycle ~0.5us. To update whole graphicscreen it's
enogh to set SED memory pointer, write single MWRITE command and write all
bytes. Fastest possible SED screen memory update would seem to be
0.5us*9600=4.8ms if there weren't some very hard to avoid limitations. The
biggest problem is that SED doesn't care about memory conflicts. SED
constantly reads RAM to refresh display. If MCU at the same time tries to
access display RAM - LCD panel will get garbage, display will flicker. I
have no idea how bad it will look but I'm concerned. The only good method to
avoid SED and MCU memory "conflicts" is to wait until the end of line and
write/read SED memory there. At recommended screen frame rate of 70Hz each
line will be refreshing/redrawing (1/70)/240Yus. SED reads line data 36us.
This means i have 23us to read/write. To detect the safe period I have to
constantly read SED status flag. Status flag is delayed a bit and I have
~19us for flickerless display RAM access. Now in theory screen update time
is ~15ms. But what about interrupts? The rest of control software is done.
Interrupt latency is ~15us @ 24MHz ECLK. :-). It seems I can write up to 4
or less bytes every 59us. Flickerless refreshing of whole screen can take me
141ms outputing 4 bytes per line, 566ms outputing 1 byte per line.

The funny thing is whole code seems to fit in C32 <32k. Should I use A256
indeed? A256 has anough 12k of RAM > 9600. To use D64/A64 parts I have to
RMW (read modify write) display memory. One RMW cycle consists of: set
address pointer 1.5us + read 1.0us + set address pointer 1.5us + write 0.5us
= 4.5us and it's pretty impossible to avoid flickering completely. It would
be nice if I could make display off, update whole screen faster than one
frame time (1/70Hz ~14ms) and turn display on again, don't update display
again for 0.5-1s. Will it help to reduce flicker? BTW LCD panel is FSTN with
response time Ton7ms, Toff%5ms. I'm not sure if these parameters can
help to hide short periods of missing/wrong LCD bits. It seems that if LCD
panel won't tolerate them I will have to either use 50-100MHz equivalent of
S12A64 or use S12A256.

With D64 I have to RMW display memory because there's not enough onchip RAM
to replicate display memory. Reading and modifying of 8 bytes if about 4
times faster than 8 RMWs of one byte. I'm thinking about autocaching of
RMWs. All graphical primitives (fonts, pictures, lines etc) use same RMW
routine. The idea is to have one buffer for masks (what to keep on display
not modified), one buffer for bits to set. Doing RMW when buffers are empty
will simply remember new mask and bits. Second RMW will determine direction
of move (SED can autoincrement it's pointer in all four directions). If
there was no move modify buffered bits/masks. If bits are on the cross with
center in first address - store direction, buffer bits,mask. Else flush
buffer to sed. On every next RMW decide to flush buffers or buffer bits and
masks, or modify buffered bits/masks. I think this buffering scheme should
help drawing everything. It will help buffering fonts too, though a bit less
effective. Are there related resources online? SED1335 seems to be very odd chip. It seems also that there's no better
alternative for 320x240. Epson of course has better chips but LCD module
manufacturers keep using SED1335. It's almost standard for monochrome QVGA
LCDs. Is there source of QVGA LCD modules with builtin and better controller
than SED1335 ?

I would appreciate much any ideas of how to avoid flicker using SED1335. I
can't use another LCD controller now. It's not too late to switch to
A256/D256 or to use additional extra MCU to speak with SED. Thanks

Edward


Hi Edward,

I hate this chip and suggest that you move to 13706/A05 etc. if possible.
Epson coninues to make the 13305 (1335) because it is so pervasive but
there is no workaround for your pb. Synchronizing on LP is the only route
and the best I could pump flicker free was 9 bytes/LP. The performance
was not too bad if you can afford the interrupt overhead which in our case
we could not (our asic is already too loaded to afford a ~24usec ISR).

If your images are static bitmaps/graphic fonts the flicker is hardly
noticeable. If you want animation find another controller.

Rob Milne

> Hi
>
> Sorry if not very HCS12 related subject.
>
> I have to interface D64 to QVGA monochrome LCD module. Module has builtin
> SED1335 controller and 32k of display memory. It's too late to change LCD
> module and controller. It's not to late to use S12 MCU having more RAM. I
> ordered but haven't got LCD module yet. SED1335 documentation has some
> bugs
> and doesn't have answers to some very important questions. I'd like to
> experiment and find answers myself but can't do it in next view weeks. I
> hope someone of you have been working around SED1335 controllers ...
>
> Details:
> Application mostly will display text using proportional fonts, some lines,
> and very view bitmaps. There's no requirement for animations or very fast
> graphics, though it's GUI and display has to react to buttons, RS232,
> other
> events smoothly.
>
> 320x240 graphics. It means one graphic page has 9600 bytes.
> SED1335-MCU bus read/write cycle ~0.5us. To update whole graphicscreen
> it's
> enogh to set SED memory pointer, write single MWRITE command and write all
> bytes. Fastest possible SED screen memory update would seem to be
> 0.5us*9600=4.8ms if there weren't some very hard to avoid limitations. The
> biggest problem is that SED doesn't care about memory conflicts. SED
> constantly reads RAM to refresh display. If MCU at the same time tries to
> access display RAM - LCD panel will get garbage, display will flicker. I
> have no idea how bad it will look but I'm concerned. The only good method
> to
> avoid SED and MCU memory &quot;conflicts&quot; is to wait until the end of
> line and
> write/read SED memory there. At recommended screen frame rate of 70Hz each
> line will be refreshing/redrawing (1/70)/240Yus. SED reads line data
> 36us.
> This means i have 23us to read/write. To detect the safe period I have to
> constantly read SED status flag. Status flag is delayed a bit and I have
> ~19us for flickerless display RAM access. Now in theory screen update time
> is ~15ms. But what about interrupts? The rest of control software is done.
> Interrupt latency is ~15us @ 24MHz ECLK. :-). It seems I can write up to 4
> or less bytes every 59us. Flickerless refreshing of whole screen can take
> me
> 141ms outputing 4 bytes per line, 566ms outputing 1 byte per line.
>
> The funny thing is whole code seems to fit in C32 >;32k. Should I use A256
> indeed? A256 has anough 12k of RAM >
>
> Yahoo! Groups Links
>
> To >




Hi Rob,

Thanks for response.

>
> Hi Edward,
>
> I hate this chip and suggest that you move to 13706/A05 etc. if possible.


I hate this chip too. But currently I don't want to struggle with LCD
column/row drivers, termocompensation of contrast and other voltages.
Ordered LCD modules have all necessary features except quite flickering
controller.

> Epson coninues to make the 13305 (1335) because it is so pervasive but
> there is no workaround for your pb. Synchronizing on LP is the only route
> and the best I could pump flicker free was 9 bytes/LP. The performance
> was not too bad if you can afford the interrupt overhead which in our case
> we could not (our asic is already too loaded to afford a ~24usec ISR).

LCD module cable doesn't include LP signal. If it was hobby project I'd
wired LP to interrupt capable pin, probably.

>
> If your images are static bitmaps/graphic fonts the flicker is hardly
> noticeable. If you want animation find another controller.

I don't want animations. Though some parts of display will change on button
presses, RS232 commands and timed events. I can limit these to update only
when necessary and no more often than say 0.2-0.5 s . I'd like if it would
work like static image, flickerless.
What pixel response time stands for? It's 170-255ms. What if I ignored LP
and D6 status and quickly, per ~10ms, purged as much data as needed; then
stopped display trafic for a while. Will it still flicker? If yes then I'm
lost and I need second MCU. Of course replacing D64/A64 with S12X+XGATE
would be the best, unfortunately they aren't available. Should I use second
MCU to talk to SED?

Best regards,
Edward >
> Rob Milne
>
>> Hi
>>
>> Sorry if not very HCS12 related subject.
>>
>> I have to interface D64 to QVGA monochrome LCD module. Module has builtin
>> SED1335 controller and 32k of display memory. It's too late to change LCD
>> module and controller. It's not to late to use S12 MCU having more RAM. I
>> ordered but haven't got LCD module yet. SED1335 documentation has some
>> bugs
>> and doesn't have answers to some very important questions. I'd like to
>> experiment and find answers myself but can't do it in next view weeks. I
>> hope someone of you have been working around SED1335 controllers ...
>>
>> Details:
>> Application mostly will display text using proportional fonts, some
>> lines,
>> and very view bitmaps. There's no requirement for animations or very fast
>> graphics, though it's GUI and display has to react to buttons, RS232,
>> other
>> events smoothly.
>>
>> 320x240 graphics. It means one graphic page has 9600 bytes.
>> SED1335-MCU bus read/write cycle ~0.5us. To update whole graphicscreen
>> it's
>> enogh to set SED memory pointer, write single MWRITE command and write
>> all
>> bytes. Fastest possible SED screen memory update would seem to be
>> 0.5us*9600=4.8ms if there weren't some very hard to avoid limitations.
>> The
>> biggest problem is that SED doesn't care about memory conflicts. SED
>> constantly reads RAM to refresh display. If MCU at the same time tries to
>> access display RAM - LCD panel will get garbage, display will flicker. I
>> have no idea how bad it will look but I'm concerned. The only good method
>> to
>> avoid SED and MCU memory &quot;conflicts&quot; is to wait until the end
>> of
>> line and
>> write/read SED memory there. At recommended screen frame rate of 70Hz
>> each
>> line will be refreshing/redrawing (1/70)/240Yus. SED reads line data
>> 36us.
>> This means i have 23us to read/write. To detect the safe period I have to
>> constantly read SED status flag. Status flag is delayed a bit and I have
>> ~19us for flickerless display RAM access. Now in theory screen update
>> time
>> is ~15ms. But what about interrupts? The rest of control software is
>> done.
>> Interrupt latency is ~15us @ 24MHz ECLK. :-). It seems I can write up to
>> 4
>> or less bytes every 59us. Flickerless refreshing of whole screen can take
>> me
>> 141ms outputing 4 bytes per line, 566ms outputing 1 byte per line.
>>
>> The funny thing is whole code seems to fit in C32 >;32k. Should I use
>> A256
>> indeed? A256 has anough 12k of RAM
>>
>>
>>
>>
>>
>>
>>
>> Yahoo! Groups Links
>>
>> To
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
> >
>
> Yahoo! Groups Links >




Hi Edward,

I wish that I could offer better advice for your problem other than simply
dumping this chip, but if you have to rely on that status bit you are
going to have one very slow display. One of our POS terminals uses this
chip with no regard to the memory access window and the display quality is
acceptable (100% flicker) as long as we don't use animations with a black
background. Another terminal does synchronize on LP signal to produce
very clean imagery but suffers from slow performance.

It becomes an aesthetic decision since a technical analysis would never
recommend this controller.

Regards,
Rob Milne



Hi Rob,

What I've decided is:
1st plan: Without extra MCU it's impossible to restrict display memory
accesses to LP(D6 bit) periods. Doing so will lead to unacceptably heavy
loads to CPU and unacceptably slow display. Even lowering LCD frame rate
from 70 to 30Hz can't help doing things right way, display will be still
very slow.
2nd plan: Ignore LP(D6 bit) completely. Write to display in bursts. I mean
about 200ms-500ms of silence then ~10ms of heavy traffic, then again silence
and so on. Maybe I'm wrong but one frame is 1/70Hzms. Is it possible to
notice one frame of garbage at 70Hz when LCD response time is more than
150ms? Performance of display updates would be acceptable updating display
this way.
3rd plan: Reconcile with flicker, forget about maitenance, convert as mach
as possible all strings to bitmaps (may help reducing display traffic),
update display regions only and only when necessary.

Hm, 100% flicker is acceptable? Hope buyer will agree with that :-). Rob, do
you think plan two won't help making flicker less visible then in case of
your fast POS terminal? Anyway I should try and see how bad things are. Thank you very much

Edward ----- Original Message -----
From: <>
To: <>
Sent: Friday, February 25, 2005 3:50 PM
Subject: Re: [68HC12] OT: QVGA LCD module with builtin SED1335 >
> Hi Edward,
>
> I wish that I could offer better advice for your problem other than simply
> dumping this chip, but if you have to rely on that status bit you are
> going to have one very slow display. One of our POS terminals uses this
> chip with no regard to the memory access window and the display quality is
> acceptable (100% flicker) as long as we don't use animations with a black
> background. Another terminal does synchronize on LP signal to produce
> very clean imagery but suffers from slow performance.
>
> It becomes an aesthetic decision since a technical analysis would never
> recommend this controller.
>
> Regards,
> Rob Milne


Hi Edward,

When I say 100% flicker I only mean flicker during the period while the
display buffer is being written to (I'm stating the obvious). Once the
memory write is complete the flicker is gone because the memory is not
changing. This is why non-animated imagery is OK because the writes are
not continuous. Even if the fonts are graphical (bitmap glyphs) the
amount of time to display a line of text is very small and the flicker is
finished before the user can perceive it. As long as changes to the
screen are limited to static text/bitmap responses to user interactions
then ignoring this issue should be visually acceptable.

Another visual quality issue to consider with STN displays is the long
decay times. Typically 300ms which obviates animation anyway. TFT is
fast and they have recently become the same price as CSTN. They also do
not suffer any burn-in.

Regards,
Rob Milne

>
> Hi Rob,
>
> What I've decided is:
> 1st plan: Without extra MCU it's impossible to restrict display memory
> accesses to LP(D6 bit) periods. Doing so will lead to unacceptably heavy
> loads to CPU and unacceptably slow display. Even lowering LCD frame rate
> from 70 to 30Hz can't help doing things right way, display will be still
> very slow.
> 2nd plan: Ignore LP(D6 bit) completely. Write to display in bursts. I mean
> about 200ms-500ms of silence then ~10ms of heavy traffic, then again
> silence
> and so on. Maybe I'm wrong but one frame is 1/70Hzms. Is it possible to
> notice one frame of garbage at 70Hz when LCD response time is more than
> 150ms? Performance of display updates would be acceptable updating
> display
> this way.
> 3rd plan: Reconcile with flicker, forget about maitenance, convert as mach
> as possible all strings to bitmaps (may help reducing display traffic),
> update display regions only and only when necessary.
>
> Hm, 100% flicker is acceptable? Hope buyer will agree with that :-). Rob,
> do
> you think plan two won't help making flicker less visible then in case of
> your fast POS terminal? Anyway I should try and see how bad things are. > Thank you very much
>
> Edward > ----- Original Message -----
> From: >;; >
>
> Yahoo! Groups Links
>
> To >





In a message dated 2/25/05 12:16:19 P.M. Eastern Standard Time,
writes:

flicker during the period while the
display buffer is being written to =============================
This is just like the cga cards... you can only write to frame memory during
'horizontal retrace'... you can read this bit in the status register... I
was bitbanging bytes into the sed1335... could do 6 or 8 bytes during this
blanking time between lines....


Hi Bob,

> =============================
> This is just like the cga cards... you can only write to frame memory
> during
> 'horizontal retrace'... you can read this bit in the status register... I
> was bitbanging bytes into the sed1335... could do 6 or 8 bytes during this
> blanking time between lines....

The problem is interrupts is a must. If interrupts were off I could catch
these retrace periods quite easily. Target LCD module has time of one line
tYus. Retrace period I can use for reads/writes is 19us. If interrupts
were off I could do 10 and more bytes per retrace. Longest interrupt I have
is 11us @ 24MHz. It can't be eliminated or made shorter easily. There are
other simultaneous interrupts and total interrupt latency is ~15us. I can do
0 to 1 bytes per retrace.

Edward


Hi Rob,

Things being obvious to you are not so obvious for me. Thank you for
answering these stupid questions.

SED has to read display memory. Every time SED reads a byte to be displayed,
SED shifts this byte out to column drivers. Display memory bus is busy until
the end of line (there's no free time slot SED could do both: read data for
column drivers and complete MCU requested memory access). From what you said
and from other sources on the web it seems SED grants every MCU memory
request and sacrifices reading data to be displayed. So 8 horizontal pixels
are driven incorrectly. These 8 pixels are driven incorrectly only for
(1/framerate)/number_of_lines, 59microseconds in my case. This time is too
short to user to notice these wrong pixels. User can notice them only if
same pixels are driven incorrectly for several frames. Like in PWM short
pulses are accumulated? If 8 wrong pixels aren't visible then whole frame of
wrong pixels will be also invisible, right? One frame time is 1/70ms. Lot
of time to update many things on display. After frame of complete nonsens I
have to stop writing/reading display memory else randomly driven pixels will
start to accumulate to wrong on/off levels.

If above is true then it's not very hard to use this chip. Are there other
reasons why should I try to limit all MCU display memory accesses to line
retrace periods?

Thanks,
Edward >
> Hi Edward,
>
> When I say 100% flicker I only mean flicker during the period while the
> display buffer is being written to (I'm stating the obvious). Once the
> memory write is complete the flicker is gone because the memory is not
> changing. This is why non-animated imagery is OK because the writes are
> not continuous. Even if the fonts are graphical (bitmap glyphs) the
> amount of time to display a line of text is very small and the flicker is
> finished before the user can perceive it. As long as changes to the
> screen are limited to static text/bitmap responses to user interactions
> then ignoring this issue should be visually acceptable.
>
> Another visual quality issue to consider with STN displays is the long
> decay times. Typically 300ms which obviates animation anyway. TFT is
> fast and they have recently become the same price as CSTN. They also do
> not suffer any burn-in.
>
> Regards,
> Rob Milne
>
>>
>> Hi Rob,
>>
>> What I've decided is:
>> 1st plan: Without extra MCU it's impossible to restrict display memory
>> accesses to LP(D6 bit) periods. Doing so will lead to unacceptably heavy
>> loads to CPU and unacceptably slow display. Even lowering LCD frame rate
>> from 70 to 30Hz can't help doing things right way, display will be still
>> very slow.
>> 2nd plan: Ignore LP(D6 bit) completely. Write to display in bursts. I
>> mean
>> about 200ms-500ms of silence then ~10ms of heavy traffic, then again
>> silence
>> and so on. Maybe I'm wrong but one frame is 1/70Hzms. Is it possible
>> to
>> notice one frame of garbage at 70Hz when LCD response time is more than
>> 150ms? Performance of display updates would be acceptable updating
>> display
>> this way.
>> 3rd plan: Reconcile with flicker, forget about maitenance, convert as
>> mach
>> as possible all strings to bitmaps (may help reducing display traffic),
>> update display regions only and only when necessary.
>>
>> Hm, 100% flicker is acceptable? Hope buyer will agree with that :-). Rob,
>> do
>> you think plan two won't help making flicker less visible then in case of
>> your fast POS terminal? Anyway I should try and see how bad things are.
>>
>>
>> Thank you very much
>>
>> Edward





Re: OT: QVGA LCD module with builtin SED1335
> -----Original Message-----
> From: Edward Karpicz [mailto:]
> Sent: Friday, February 25, 2005 4:47 PM
> To:
> Subject: Re: [68HC12] OT: QVGA LCD module with builtin SED1335 > Hi Bob,
>
> > =============================
> > This is just like the cga cards... you can only write to
> frame memory
> > during
> > 'horizontal retrace'... you can read this bit in the status
> register... I
> > was bitbanging bytes into the sed1335... could do 6 or 8
> bytes during this
> > blanking time between lines....
>
> The problem is interrupts is a must. If interrupts were off I
> could catch
> these retrace periods quite easily. Target LCD module has
> time of one line
> tYus. Retrace period I can use for reads/writes is 19us. If
> interrupts
> were off I could do 10 and more bytes per retrace. Longest
> interrupt I have
> is 11us @ 24MHz. It can't be eliminated or made shorter
> easily. There are
> other simultaneous interrupts and total interrupt latency is
> ~15us. I can do
> 0 to 1 bytes per retrace.
>
> Edward

Can your idle process poll for the retrace rather than interrupt? This
might necessitate a buffer for the data to be written to the LCD. But,
if the buffer was empty, you would not have to poll and could go about
the rest of your idle process.

Emmett Redd Ph.D. mailto:
Associate Professor (417)836-5221
Department of Physics, Astronomy, and Materials Science
Southwest Missouri State University Fax (417)836-6226
901 SOUTH NATIONAL Dept (417)836-5131
SPRINGFIELD, MO 65804 USA