|
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 |
OT: QVGA LCD module with builtin SED1335
Started by ●February 24, 2005
Reply by ●February 24, 20052005-02-24
|
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 "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 > > > Yahoo! Groups Links > > To > |
Reply by ●February 24, 20052005-02-24
|
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 "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 >> >> >> >> >> >> >> >> Yahoo! Groups Links >> >> To >> >> >> >> >> >> >> >> >> >> >> > > > > Yahoo! Groups Links > |
Reply by ●February 25, 20052005-02-25
|
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 |
Reply by ●February 25, 20052005-02-25
|
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 |
Reply by ●February 25, 20052005-02-25
|
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 > |
Reply by ●February 25, 20052005-02-25
|
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.... |
Reply by ●February 25, 20052005-02-25
|
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 |
|
|
Reply by ●February 25, 20052005-02-25
|
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 |
Reply by ●February 25, 20052005-02-25
|
> -----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 |
