Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
11/06/08 23:35
Read: times


 
#159864 - It's not as easy as one might think
Responding to: ???'s previous message
Jan Waclawek said:
... he said he's on wireless now...
Richard Erlacher said:
A mid-sized CPLD, e.g. XC2C256, or a small FPGA, e.g. XC3S150 or thereabouts should be quite suitable,

I think this is the core of your message.

For LCDs, you don't need a DAC, the input is pure digital (5-6 wires per color). So you just need a sequencer producing incremental address and the syncs; a memory (a.k. framebuffer); and glue logic to be able to access that memory from both the sequencer and the microcontroller (this is usually the toughest part); plus maybe some output buffers.


This is quite true, but several of the timing + RAMDAC devices I've seen have the RAMDAC addresses externally accessible, IIRC. In reality, I guess, all he has to do is to attach an 18-bit-wide RAM (or three paralleled 256 x 8 SRAMs, or the equivalent, using only 6 of the bits) to his three 6-bit color channels.

The 6845 is not usable without significant glue logic - it's basically just the sequencer, and also it's low speed (2MHz max), so at least 2 bits of address have to be sequenced "externally". It is definitively doable - it's none more complex than a CGA graphics of which it was a constituent - but a bit out of date (not to mention that the youngest 6845 you can get nowadays is out of factory at least for 20 years).


Yes, they're VERY old. However, they don't require that much external logic. They require external registers to keep data movement synchronized with the pipeline around which the chip is designed. Since there's typically a delay for the refresh RAM, and a delay for the character generator or RAMDAC, an internal parameter can be set to compensate for that timing skew.

Actually, I believe they're rated for 2.5 MHz or greater in their later incarnations, with the 2 MHz limit mainly impacting the bus interface. However, since the pixel clock is always external to the 6845, his pixel rate won't outrun the MC6845. Since there are several "free" IP's for the 6845, and since he doesn't really need the entire 6845, I would guess he'd simply do that job in programmable logic, though, where his clock rate can go MUCH higher. The 6845 architecture can provide conceptual guidance, though. The bigger part of the 6845 is the microcontroller interface, which can be omitted in this case, since, as you say, it's a sequencer, and doesn't affect the data. IIRC, the datasheet for the 6845 indicates that what it expects to "see" as a clock is the "character clock" meaning that the pixel clock is divided by the number of pixels per character before being fed to the 6845.

So, nowadays it seems to be easier to put both the sequencer and the glue into the CPLD/FPGA; however, it might be easier and faster to get a dedicated chip, which contains also the RAM (see the link to Epson devices I gave above).


A few of those EPSON devices might work, but will be difficult to implement in prototype, not that it's much easier with current-generation programmable devices.

JW


Much depends on whether he wants a working display, as he might if he's doing this on his job, or if he wants to learn how to do this sort of thing. Because the type of device he's got is somewhat dated, I'd guess it's the latter. Only he can clear that up. Unfortunately, programmable logic is not generally sold in convenient-for-prototyping packaging these days. Perhaps he can find an appropriate part in PGA or PLCC-84 package. Prototyping sockets for current-generation parts tend to cost upwards of a week's pay, and the adapters to allow you to work with them cost as much again. Generally, unless you can afford to spend on the order of $15K on your device, you can't use 'em in the raw. The "easy" way is to buy an evaluation board that provides enough I/O's.

Can you suggest a commercial device that actually does this job on its own?

RE

List of 12 messages in thread
TopicAuthorDate
How do you drive a RGB color LCD display?            01/01/70 00:00      
   Look for processors or display controllers            01/01/70 00:00      
   Search?            01/01/70 00:00      
   Epson            01/01/70 00:00      
   Thanks            01/01/70 00:00      
   Back to basics            01/01/70 00:00      
      Richard, you flooded Bert's connection...            01/01/70 00:00      
         It's not as easy as one might think            01/01/70 00:00      
            ready-made device            01/01/70 00:00      
            buy an evaluation board            01/01/70 00:00      
               a quick peek into the code library            01/01/70 00:00      
                  That's what I would recommend            01/01/70 00:00      

Back to Subject List