Close

Dual-Pixel Thoughts

A project log for sdramThing4.5 "Logic Analyzer"

An AVR, 128MB SDRAM DIMM, old laptop LCD, and a handful of TTL chips -- 30+MS/s 32-channel logic-analyzer interface for an analog 'scope

esot.ericesot.eric 10/23/2015 at 07:360 Comments

Now that I've managed to repair a pretty-decent LCD Monitor (#Ridiculous [LCD] Display Hacks) that's been dead in my collection for nearly a decade... I'm feeling a little less stingy with the ol' 15inch monitors in my collection...

So I've some ideas...

One of those 15inchers is 1024x768, same as the one used in sdramThing, except that it's dual-pixel.

What's this mean as far as sdramThing...?

Well, it might be *difficult* to see, but it would allow for visualization of 5 of the logic-analyzer's channels rather'n 2, on the LCD.

Currently, only two channels can be "seen" on the (single-pixel) LCD, "red" and "green." (Though, 32 channels are sampled and repeated, regardless of what can be *seen* on the LCD.).

Why two? The LCD's "blue" "channel" is tied-together with the LCD-timing-signals which shouldn't change, regardless of sampling, so "blue" can't exactly (easily) be tied-together with the displaying of sampled data. This isn't a bad thing, though... It leaves that color/channel available for other purposes, such as the cursors... which are quite handy.

That said... A dual-pixel display would allow for *5* channels to be viewed simultaneously on the LCD... The first two, mentioned before, "red" and "green," would be displayed in the first, third, fifth, and other "odd" columns... The remaining three would be visible in the second, fourth, and remaining "even" columns, in red, green, and blue. The cursors could remain in the odd columns...

It's a weird concept, but not exactly useless. Weird: well, even and odd columns of pixels would be displaying different sets of samples that were all taken at the same time. The first two channels' samples in one column, the next three in the next... You can imagine how hard it would be to *see* a particular waveform/pattern in that manner. OTOH, *seeing* a waveform on this "rasta"-display is difficult anyhow. That's the whole point behind sample-and-repeat (to be fed into an oscilloscope). The LCD, basically, allows for visualizing that there is data, and allows for the cursors to be used to zoom in on that data (on the oscilloscope).

So, it seems useful, despite being hard to view. Consider how hard it is to view data anyhow... First of all, there's the fact that rather than displaying waveforms in the typical ____----____-___----___ fashion, they're displayed as basically: *** * **** . That's hard enough to view. Then there's the fact that the Red and Green channels are overlapped, and acting, roughly, like they're "transparent"... When the first channel is 1, and the second is 0, you get red. When the first channel is 0 and the second is 1 you get green... When both are 1 you get yellow. Then, take it a step further: Because the display is LVDS, it's actually visualizing *seven* samples at each pixel... (is that right? must be...). And, it's not exactly... well, it's *far from* the typical expectations of how one might merge seven samples of data into a single pixel... (typical ideas might be: average the seven samples and display that as the brightness, or maybe: turn the pixel full-on if any of the samples are 1). Instead (as I recall, and slightly simplified): It's displaying the first sample as 1/128th of the brightness of that color of that pixel, the second sample as 1/64th... that last sample displayed in that pixel is 1/2 brightness, not because it's of any more importance than the others, but just that that's how it works out.

So, considering all that, the LCD is basically just a means to select a portion of data to be zoomed in on... if/where there's data to be zoomed in on. So, then, maybe dual-pixel (pairs of columns displaying a total of 5*7 samples) makes sense...

(An easy alternative, actually, might be simply to take the 32 channels and OR them all together into the two on the original single-pixel display... hmm...)

Anyways... it's a contemplation. Another consideration, though... At 1024x768(*7, being LVDS, and *4 since the SDRAM's 32-bits wide, nevermind the display's "porches"), we're nearing the limit of a single bank of my SDRAM (the "side-kick", used for sample/repeat). BUT. If using dual-pixel, we'd actually cut in half the number of samples we can display at a time... 512x768(*7). Graphically, again, it's not a huge deal... we don't see *every* sample anyhow...

The bigger problem is that *as-implemented* it's a temporal problem... If the original single-pixel setup displayed, say, 2 seconds worth of data on the LCD, the new dual-pixel setup would only display 1 second worth.

So... I'm contemplating things... I have some ideas.

Another issue, of course, is the use of "blue" as a data-channel *and* as a cursor-channel. In the grand-scheme of things, assuming you're not so close to the display to actually see each individual pixel, the cursors would either be 50% bright-blue, or *not* blue... And sampled-data on the alternate pixels would never exceed 50% blue-brightness, either... So, I think, there should be some amount of visibility/discernation between cursor-blue and data-blue.

So, quick brainstorm...

I've been contemplating ways to select portions for viewing on the LCD... LCD-zooming, in a sense. This one would require significant hacking to sdramThing... we'd probably be at 5.0 or 5.5 by that time... Probably some additional logic and/or multiplexers... But, seems plausible. I've already got *two* (three? It's been a while) entirely different sets of instructions stored simultaneously in the "FreeRunner", why not add more for LCD-zooming? Possible.

Another possibility: Most LCDs I've worked with don't mind if you keep sending data on the current row, even after you've passed the end of its displayable row... In that way, it might be possible to send *two* full "LCD-Rows" worth of data to the display (and in "repeat" mode, to the oscilloscope) but only display one... So, some lost-data visually, but still transmitted for "ultimate-zooming" on the 'scope.

There's probably a ton of options, really... I have to call it a night, though, at least on this front.

Discussions