-
bunnie authored
Some basic progress on the LCD, such that the interface can turn-on and draw. The implementation uses a slow sequential-write method to update the display; the vestiges of an auto-copy system are also in place but not yet debugged. The system seems to support two methods for issuing commands and data to the LCD. One is a simple write-to-commit method. The other is a more sophisticated command list that's set up, and then dispatched. The write-to-commit kind of works now, although it's left to be seen if we aren't running too far ahead of commands or missing some wait states. To get the demo to work, run the following commands in fernly: bl 5 (turns on backlight) lcd su (sets up GPIOs and timing) lcd init (initializes the LCD-side controller) lcd tp1 (blasts a small test pattern to the top of display) You'll note that the VCOM setting looks to be off (alternate light/dark lines). Next steps include: 1) verify that commands are being issued correctly to the LCD (no missing commands due to writes happening faster than the interface can keep up) 2) cross-check with LCD datasheet for the initialization of the controller -- there are some undocumented commands I left out in this implementation, maybe they need to go in there; I also left out the gamma table. 3) get the autocopy method to work. I think, from what I can tell, the autocopy will take a region of interest from memory, composite it with up to four other regions with alpha blending, and then auto-copy this to the LCD. You can insert commands into the auto-copy stream as necessary, but I believe this, combined with the TE (tearing effect) sync bit, will allow you to just write to a region of memory as a frame buffer and have it show up on the display without any CPU intervention. Could be wrong tho....
8f13d99d