Electrical – Looking for LCD replacement (OLED)

Cell phone size OLED displays are driven much the same as cell phone size LCDs. The manufacturers try to make the interface similar to reduce engineering effort required to switch technologies. This is why LCDs, in turn, are driven similar to old CRT displays. These interfaces (for the smaller displays anyways) generally are parallel interfaces with 3 clocks. The parallel data bus will be as wide as the color depth of the display. A 24 bit display, for example, will have a 24 bit wide color bus, with 8 bits representing red, green and blue. The RGB numbers will represent the brightness of each color for an individual pixel. Just about any color can be formed by varying the intensity of the RGB values. The 3 clocks are the pixel clock, the horizontal clock and the vertical (or frame) clock. The pixel clock is the fastest, and each tick of the pixel clock moves the selected pixel horizontally across the screen, the horizontal clock ticks for every new line, and the vertical clock clicks every new frame. So for a 320 x 240 pixel screen, the horizontal clock will tick every 320 pixels, and the vertical clock will click every 240 lines. This is ignoring delays. In reality, there is a bunch of delays at the end of each line and the end of each frame. In the CRT days, the delays allowed time for the ray to physically move to the beginning of a new line or back up to the corner for a new frame. These delays provided time to "hide" digital information in the old analog days of cable (like subtitles and v-chip info). Today they are still handy because they force the display driver to share memory bandwidth (as it pulls information from the frame buffer in chunks of time). You can basically think of the interface as painting one pixel at a time across the display, line by line until the image is drawn, at which time it starts all over. The pixels are generally designed to hold the information long enough to last until the next full refresh cycle (which typical occurs at least 60Hz).

EDIT: Sorry, I thought you were looking for how the interface is driven. The pixels themselves are usually driven directly by a display driver of controller integrated with the display (and so the end user usually doesn't need to worry about implementation details). I'm not an expert here, but a simplification is to represent each pixel as a diode in parallel with a capacitor. The capacitor is charged to a certain voltage, which dictates the amount of current, which dictates the brightness of the pixel. So an analog 'programming' voltage will determine brightness, but this gets refreshed constantly.

Almost none of the prefab display modules I've seen on the market give a "user" any significant control over when information is actually displayed; many don't even let the user know when information will be displayed. The normal design pattern is for the module to accept data from the user into a buffer at times of the user's choosing, and then display the contents of that buffer at a time of the module's choosing. In cases where both the module and the eyes of anyone looking at it are stationary, having the time between when data is fed to the module and when it appears on screen arbitrarily vary between 0-15ms won't be a problem. If the module or the user's eyes are moving, however, the scanning behavior may become quite relevant.

For a 64x64 module, I would expect that it should probably be possible to supply the module with a new frame's worth of data on every scan cycle; if you're interested in controlling or at least knowing exactly when things are displayed, however, you'll have to check the data sheets of any specific modules you're considering to see what sort of control you can get. I wouldn't say that modules "typically" give any control, but some might let you program a frame rate or scanning pattern that would fit your needs even if you have to do some trickery to achieve such behavior (e.g. if the module scans one line every 100us, allows a programmable number of scan lines, and counts scan lines with a down-counter that's reloaded when it hits zero, and if one wanted a frame rate of exactly 125Hz, one could have the scan-line count register programmed with a value of 81 for 7.809ms and a value of 80 for 101us. The timing on the module would then drift until the start of frame coincided with the time when the screen was programmed for 80 lines.