> >>Can you send a couple of links to the modules you are considering? > > >there are some 320x240 from EDT (Emerging Display Technologies) with > S1D13305 > >S1D13700 > >http://www.actron.de/graphic_displays_edt.htm > > > >also from Powertip a 320x240 with S1D13305/ S1D13704 is available > >http://www.actron.de/graphic_displays_powertip.htm > > > >and also from ampire is one ... (available /w or w/o Epson's S1D > controller) > >http://www.ampire.com.tw/AmpireCatalogue/P082-AT320240Q3.pdf > > > > Ok, I see the problem with the S1D13305, but the S1D13704 looks ok. > In order to work as a linux framebuffer, the cpu must be able to directly > address > pixels. You can't have a controller like the 13305 that makes you write a > pixel address and then write the pixel. A controller like the 13704 just > makes > the pixel memory look like RAM, so it's easy to interface.
I have done this in the past when the cpu could not directly access the pixels. I created a virtual framebuffer in RAM, and had a timer-driven routine that regularly sent the contents of the virtual framebuffer to the LCD device through the "register bottleneck" of the LCD device interface. It actually worked well. I expected a big performance hit with all the additional bus activity, but it was not bad (no, I don't remember any numbers). The platform had a 48 MHz mpc8xx if I remember correctly, and the LCD device was an old Epson chip that had a registered interface (no direct access to pixels). It is not an optimal situation, but if you find yourself stuck with an LCD device that does not provide a RAM-like interface to the pixels, then it is at least a known-working solution. Chuck Meade The PTR Group
