Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
02/16/05 04:21
Read: times


 
#87603 - Serial RAM is useless
Responding to: ???'s previous message
Serial RAM to be used as a buffer for a gLCD module is useless. It is way way too slow.

The fact of the matter is that the T6963C chip is a piece of junk for making a fast graphics application. Good gosh....you even have to poll status on this silly part even when you put it into the fastest possible loading mode known as "AUTO WRITE" where the address pointer auto increments. Toshiba does not even recommend using the chip in a non-polled mode where you would simply use some program step delay in lieu of the status polling...they claim that data corruption could always happen if the proper status is not polled!!

Compare this with other popular gLCD driver chips from Samsung and others that, once a row access is setup in motion, it is possible to hose bytes to the controller display memory at the bus cycle time of the display controller !! I have even used displays of this type where the two wire serial mode to the display was used as a write only interface. I have run the data clocking for such displays at just under 4 MHz bit rate and achieved getting bytes to the display at a rate of about 500K bytes per second. If you consider that the optimal way to run a graphics display of this type is with a RAM image buffer and support for copying whole rows from the buffer memory to the display controller then the average time per byte is very nearly equal to the raw data transfer rate. For your type display of 240 columns a vertical raster controller can write a whole row data in 240 write cycles. The additional setup time at the start of each block row write may take say 16 more write cycles. That is a total of 256 writes per raster row. A 128 pixel/column display such as yours has 16 if these rows to paint the whole display. Thus a rough estimate of achievable full display update time is: (500K bytes/sec) / ((256 * 16) bytes/screen) ~== 122 screens per second update rate.

I say get your self a solution with a fast RAM buffer on board the processor and a vertical byte raster display controleller and you can easily scroll the display so fast that the LCD pixels will smear into un-readability.

Michael Karas


List of 42 messages in thread
TopicAuthorDate
GLCD Project (low frequency scope)            01/01/70 00:00      
   GLCD Scrolling            01/01/70 00:00      
      Lesson learned            01/01/70 00:00      
         did you check            01/01/70 00:00      
   hi Speed GLCD displays?            01/01/70 00:00      
      Probably            01/01/70 00:00      
      Hardware scroll            01/01/70 00:00      
         PaceSetter            01/01/70 00:00      
      Best Display >> None is perfect            01/01/70 00:00      
         Sweep mode            01/01/70 00:00      
            Scope Squares            01/01/70 00:00      
            8 Bits Update            01/01/70 00:00      
               like rotate it 90°?            01/01/70 00:00      
                  90° Rotation Indeed            01/01/70 00:00      
   One step further            01/01/70 00:00      
      Animation            01/01/70 00:00      
         scan too slow!!            01/01/70 00:00      
            15 seconds? !!!            01/01/70 00:00      
               or....            01/01/70 00:00      
               slightly more            01/01/70 00:00      
               Optimization            01/01/70 00:00      
                  calculation            01/01/70 00:00      
                     Will have a look            01/01/70 00:00      
                        assembler speedup            01/01/70 00:00      
                  if it is really slow            01/01/70 00:00      
                     too smart Man            01/01/70 00:00      
                        another way            01/01/70 00:00      
                  When do you wait?            01/01/70 00:00      
                     first choice            01/01/70 00:00      
               should I use Serial RAM for buffer?            01/01/70 00:00      
                  serial RAM and time            01/01/70 00:00      
                     lcd_not_busy();            01/01/70 00:00      
                        a much faster approach            01/01/70 00:00      
                           I don't have enough XRAM            01/01/70 00:00      
                              magic            01/01/70 00:00      
                              more tweaking            01/01/70 00:00      
                                 Good thinking Jan            01/01/70 00:00      
                                    tweaking II.            01/01/70 00:00      
                                       Magic Tweeking            01/01/70 00:00      
                  Serial RAM is useless            01/01/70 00:00      
   maybe this technique will work here            01/01/70 00:00      
      Multi-microcontrollers            01/01/70 00:00      

Back to Subject List