Alright, well, I am by no means knowledgeable in how this is done, so I'm going to try to lay out the plans w/o assumptions or other caveats. I'll explain the situation to show the drive behind WHY I want to do this.
For the greater 99.99% of everything I work on and attempt to do with microcontrolling, programming, and other ventures, my father sees it as "the things the college son wastes his time doing". Today we were standing in the garage and he pulls out an old Ceiva 2 photo viewer and tells me it would be neat to see some life be brought out of it to allow it to display photos.
For those of you who don't know, a Ceiva photo viewer requires a network connection and photos must be network-uploaded to a subscription service to be 'streamed' to the viewer. There are no direct onboard ports for viewing things directly from a file source.
Now, I've done my fair bit of homework on this over the past couple hours, but again, I am by no means knowledgeable in LCD coding or controlling. Y'all will have to help me from here. For me, this isn't a simple matter of building a driver. This isn't the rodeo I'd be going to if I could - I wouldn't be doing this otherwise, but for me this serves as a method of connecting my interests with my father, of finally showing him that what I do can matter on a level that he'll realize.
I know, cry me a river, huh? [/inspiration]
Okay, so here's what I've gathered about this LCD. It's a resistive touchscreen, although it'll be enough of an engineering feat to get to drive it, much less have it output commands to be controlled. It is a Hitachi SX21V001-Z4A screen, datasheet here.
Finding a datasheet was almost more than I expected from this. The information on the screen itself is sparse, although through looking at the mechanical specs one can infer that it is a TFT. I can't find any information about driver mechanics or what driver was used.
There isn't a schematic for the photo viewer it came out of, so looking at it from that perspective is out-of-the-question. What I can gather about the driver, however, is that it is powered by a Sharp LH7A400-N0B SoC. I'm not that knowledgeable about SoCs other than the ones used in single-board comps & devices, but judging from the fact that it is mounted less than an inch from the ribbon cable is a fair guess that it is the driver logic controller.
The photo viewer had the capacity for storing 30 photos off-network, so it could still be used in-interim between connections. There are three other (major) SMT modules on the driver board, two of which I am presuming are flash banks as they seem to be identical "dual-inline" (to be exact, SOIC) chipsets.
Now, from what I've gathered so far, the main issue is that the Arduino a) lacks a suitable buffer size, and b) cannot operate at frequencies quick enough to handle input-to-output processing within the time reference of a frame.
The requirements for this project of mine are different from other projects: simply make it work. It only has to be still frames. It doesn't have to be fast - I don't care if it takes an hour to generate an image. If it works it will mean the world to me.
Here's my idea for how to go about this:
- Use atmega2560 (4 serial connections)
- SD interface (explained below)
- serial0 for PC-to-Arduino commanding
- serial1 for UD0-7 communications
- serial2 for LD0-7 communications
- serial3 for latchup/readiness commands (FLM, CL1-2, DISP*OFF)
Since the idea of the frame buffer comes into question, here's an idea I came up with to solve that:
If we assume that the calculations from this thread
are accurate, we'd need 38.4kb of RAM onboard to handle it. The atmega2560 has 8kb of RAM. Suppose we break an image on the PC interface down into 10 different data registers - 5 upper (UD commands) and 5 lower (LD commands). This would mean each data register would only read in around 3.8kb. This could be sent to the serial line, and as it is transferred, pumped to flash.
Once all 10 registers are in flash, prime it with code at serial3 that forces execution of the main body - taking each register, transmitting it to the appropriate lines, loading the next, so on, so forth - essentially demuxing the image registers to the screen at >1.2kHz. In a nutshell, it would break the image into 10 (or possibly more) pieces and flash them onto the screen in their respective positions. With a clocking speed at 16MHz and a refresh rate at 120Hz typical, that would allow a lot of headroom with command operation.
Is this feasible? Again, I'm not very knowledgeable in this, but I'm definitely not taking this approach to make my life difficult.