??? 02/08/05 00:18 Read: times |
#86847 - Sounds specialized Responding to: ???'s previous message |
Alejandro Javier Pizarro said:
What I had in mind was using the external memory to hold the "icons". All the 8052 would do is route that information to a screen controller. The refresh rate doesnt haven to be very high at all, just enough so that the user presses an icon, and it responds, the data on the screen would be refreshed every so often. I was looking at the displays from Pacific Display (provided link in earlier message) and the thing I didn't like about them (aside from the voltage and the physical size) was that every single screen update required a full update of all the pixels on the screen. A graphics controller that could accept some kind of optimized commands (i.e. "Draw line from a,b to c,d with width e" or "Draw pixel at x,y", etc.). The link Andy posted might be very close to exactly that--thought it wasn't immediately clear in browsing the datasheet very quickly whether this is only monochrome LCD or can also handle color, and to what resolution. I'll take a closer look later. Resolution of a PDA would be about where I wanted to go. I was looking at about PDA resolution, too. Really, a Palm-sized color screen would be perfect--maybe just a hair larger. I really haven't found anything that satisfies me. Also i've heard of using per pixel drawing on an LCD, but that the 8052 would get really bogged down. Any experience with that? The ones from Pacific Display do it that way--if you wanted to change a single pixel you had to update the entire screen. At 320x240 with 3 bits per pixel that would come out to 28,800 bytes to update the screen. Assuming a memory-mapped approach with MOVX, that could be clocked out in about 345,600 instruction cycles (rough estimate assuming reading from XRAM, incrementing DPTR, writing it out to the LCD, no auto-increment of DPTR available) which is about 1/3rd of a second on a standard 8052 at 11.0592 MHz. But you slap in a high-speed micro with automatic DPTR increment, say the DS89C420, and clock that at 22.184 MHz and suddenly it would be closer to 230,400 instruction cycles which could be executed in about 1/100th of a second. That's significantly more tolerable. Still, you have the problem of having to have XRAM available to keep a copy of the graphics for the MCU to work with. If the IC Andy mentioned above does what it looks like it does at first glance, it might be a good solution. It even looked like it handles object such that you can tell it "Put this graphic at x,y" and if you later want to move it you can just update the position rather than redrawing it and/or the whole screen. If so, that might be a really good option. I hope to have time to read it all later tonight. Regards, Craig Steiner |
Topic | Author | Date |
GUI and LCD for 8052 | 01/01/70 00:00 | |
Most graphic interfaces... | 01/01/70 00:00 | |
Really GUI? | 01/01/70 00:00 | |
Realities of 8051 and LCD/GUI | 01/01/70 00:00 | |
forgot name | 01/01/70 00:00 | |
Zylogic; nee Triscend | 01/01/70 00:00 | |
same discussed recently | 01/01/70 00:00 | |
Amulet | 01/01/70 00:00 | |
What I had in mind | 01/01/70 00:00 | |
Sounds specialized![]() | 01/01/70 00:00 |