|
Hi Edward, We have used this display controller for years, and it works fine for occasional display updates. The flicker when updating the display is not bad at all, as long as it is in bursts (in fact you will probably not notice it much for your application). We do not use an external frame buffer in our MPU (even though we do have the RAM), so RMW is always done with the display RAM, and has not posed a problem. For one application, we needed to scroll a large graphical waveform, and ran into the flicker issue, until we got creative. We ended up changing the controllers memory map to make a giant graphic page that was very wide, and then used the internal memory offset commands to shift the view into the image. This worked well, and other than the initial flicker of writing the image, the scrolling was smooth. Hope this helps, Mike > -----Original Message----- > From: Edward Karpicz [mailto:] > Sent: Friday, February 25, 2005 3:47 PM > To: > Subject: Re: [68HC12] OT: QVGA LCD module with builtin SED1335 > > 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 > > > Yahoo! Groups Links > > |
OT: QVGA LCD module with builtin SED1335
Started by ●February 24, 2005
Reply by ●February 25, 20052005-02-25
Reply by ●February 25, 20052005-02-25
|
In a message dated 2/25/05 7:00:34 P.M. Eastern Standard Time, writes: > > ============================= > > 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: ========================================== Here's how I did it.... the screen was 160x160 pix 4k bytes I think... I had a frame buffer in ram.... I drew everything in ram, then copied the whole 4k to the sed in a loop... took about 10ms... whole program took about 100ms.. was an 8mhz hc12... was getting 10 frames a sec no flicker.... |
Reply by ●February 25, 20052005-02-25
|
Hi Edward, I guess adding a second micro to the project is out of the question, but if you could, it could received the data at full speed from the first micro, and then sit there feeding the display at the required rate. Darren Moore > -----Original Message----- > From: Edward Karpicz [mailto:] > 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 > Yahoo! Groups Links |
Reply by ●February 27, 20052005-02-27
|
> ========================================== > Here's how I did it.... the screen was 160x160 pix 4k bytes I think... I > had > a frame buffer in ram.... I drew everything in ram, then copied the whole > 4k > to the sed in a loop... took about 10ms... whole program took about > 100ms.. > was an 8mhz hc12... was getting 10 frames a sec no flicker.... > Bob, 160x160 is absolutely different. Even at 70Hz refresh single line is 89us. 10MHz SED reads single scan line 20*900nsus. Your MCU can write for 89us-18us ~70microseconds. Feel the difference. Good enough even for HC11. Regards Edward |
Reply by ●February 27, 20052005-02-27
|
> > > Hi Edward, > > I guess adding a second micro to the project is out > of the question, but if you could, it could received > the data at full speed from the first micro, and then > sit there feeding the display at the required rate. > > Darren Moore Thanks, I was considering second micro. I think it won't be necessary. If it will I hope S12X will become available by the time I'll need them. Edward > > >> -----Original Message----- >> From: Edward Karpicz [mailto:] >> >> >> 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 >> >> >> >> >> >> Yahoo! Groups Links >> >> >> >> >> >> >> > > > > Yahoo! Groups Links > |
Reply by ●February 27, 20052005-02-27
|
Hi Mike, Thanks, you and others have made things easier. I think I know how to deal with subject. Regards, Edward ----- Original Message ----- From: "Michael Anton" <> To: <> Sent: Saturday, February 26, 2005 1:58 AM Subject: RE: [68HC12] OT: QVGA LCD module with builtin SED1335 > > Hi Edward, > > We have used this display controller for years, and it works fine > for occasional display updates. The flicker when updating the display > is not bad at all, as long as it is in bursts (in fact you will > probably not notice it much for your application). We do not use > an external frame buffer in our MPU (even though we do have the RAM), > so RMW is always done with the display RAM, and has not posed a > problem. > > For one application, we needed to scroll a large graphical waveform, > and ran into the flicker issue, until we got creative. We ended up > changing the controllers memory map to make a giant graphic page > that was very wide, and then used the internal memory offset commands > to shift the view into the image. This worked well, and other than > the initial flicker of writing the image, the scrolling was smooth. > > Hope this helps, > > Mike >> -----Original Message----- >> From: Edward Karpicz [mailto:] >> Sent: Friday, February 25, 2005 3:47 PM >> To: >> Subject: Re: [68HC12] OT: QVGA LCD module with builtin SED1335 >> >> >> >> 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 >> >> >> >> >> Yahoo! Groups Links >> >> >> >> >> >> > > > Yahoo! Groups Links > |
Reply by ●February 27, 20052005-02-27
|
----- Original Message ----- From: "Redd, Emmett R"To: <> Sent: Saturday, February 26, 2005 1:56 AM Subject: RE: [68HC12] OT: QVGA LCD module with builtin SED1335 > >> -----Original Message----- >> From: Edward Karpicz >> 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 I can't use SED LP signal to fire interrupts on line retrace. LP is not available to LCD module connector. So I can use only polling technique. Interrupt latency is comparable to line retrace period. This suggests disabling interrupts for time of single raster line. Single line is 59us. This would break another requirement : one of interrupts must have shorter than 50us jitter. Interrupts can't be disabled for such long time. So even polling technique is limited to produce 0 to 1 bytes per retrace. Buffering. It's not easy too. The easiest would be to buffer whole page of graphics. Instead of A64/D64 with 4k of RAM I'd have to use parts having more than 9600bytes of RAM. Ok, possible. But what should buffers look like on smaller parts? Simple but slow solution could be: when higher level graphics routine requests RMW of display memory - enter first wait for retrace loop, get a byte. Now compute byte to be written, enter again wait for retrace loop, write a byte. Doing it this way and having 1 read or write per retrace, complete update would take me seconds if not minutes. It's possible to lower LCD frame rate a bit and get view spare microseconds to reach enormously high productivity with 2 or more writes/reads per retrace. But higher level routines also do take some time and I have to cache their output, else I again will have single byte per retrace. I've implemented some caching. The cache works this way: If target address of next RMW matches last cached bits and mask RMW is applied to cache. If address doesn't match and isn't horizontal or vertical successor of first RMW in cache - flush cache to display and restart caching. It would be too long to cover all details so I'll stop here. Cache seems to work and helps reducing amount of display memory RMW's doing fonts and other primitives. But it's still not enough to live whith these tiny retrace periods. I have to ignore retraces anyway. FSTN is quite inertial and this feature will be used to reduce flicker. All, thanks for your help. Best regards. Edward |
