Hi, everyone!
I'm trying to develop a Human-Machine interface using a combo Keypad,
graphic lcd Panasonic EDMGRB8KJF (7.8 inch STN colored passive matrix
type. The display consists of 640 x 3(RGB) x 480 dots).
Unfortunatelly, I've had problems in integrating the LCD on my HC12
EVM board. All else fails: I can't find documentation about LCD type
(same at Matsushite Electric Co.!), I can't get help of design houses
here in Brazil because nobody knows the LCD, my LCD supplyer doesn't
have any other documentation instead LCD datasheet... Conclusion: I'm
lost!
First, I used 3 PWM channels to synchonize Vertical, Horizontal and
Data signals but doesn't work. Now I'm implementing Timers to do this
job. Am I on the right way?
Does somebody any application note of similar LCD or examples of how
to program HC12 to drive a color graphic LCD?
Hints will be helpful.
Thanks,
Fabio
Graphic LCD x HC12
Started by ●April 20, 2006
Reply by ●April 25, 20062006-04-25
Fabio,
Generating video with software is challenging. It helps to have some sort
of hardware assistance, even if it is just some sort of timed DMA system
to move data to the LCD. Most people who interface LCDs to an HC12 use
LCD modules that have built-in controller chips, rather than LCD panels
with low-level interfaces like the one you are using. Then the controller
chip takes care of the detailed timing and the HC12 need only store data
into the controller's video memory to make it appear on the display.
You can probably generate the correct sync signals with the timers,
but how will you pump the data out fast enough? The panel needs 115200
bytes of data (640x480x3 bits), 70 times a second. That's 8MBps.
That would probably be difficult even for an S12X CPU. On top of that,
where will you store the data? If your video buffer stores every pixel,
you will need at least 115200 bytes of storage. If you don't buffer
every pixel individually, you will need to compute some or all of the
data on-the-fly, and that would make the bandwidth requirements even
more difficult to meet.
You're probably better off putting a suitable LCD controller chip between
the HC12 and the LCD. The controller chip manages the video buffer and
generates the critical LCD timing in hardware, freeing the HC12 to manage
the user interface and write pixel data into the video buffer whenever
it likes.
In theory, one can buy an LCD controller chip as a separate product,
but usually one gets one by buying an LCD module that has the controller
built-in. You could also to make a controller from an FPGA, perhaps
with an external SRAM.
It might also be possible to come up with some simpler, but creative
controller hardware that could do things like duplicate pixels and rows
so that the HC12 could stream data out more slowly, in exchange for a
lower effective display resolution.
I don't know of any app notes about using the HC12 as an LCD controller,
but Analog Devices has one about using the Blackfin DSP that I found
helpful in understanding the issues. Note how much they rely on the DSP's
DMA controller, and in particular its two-dimensional array capabilities,
to manage the bitstream and offload the CPU. That's basically what an
LCD controller chip does.
http://www.analog.com/UploadedFiles/Application_Notes/74670263ee256Rev2March706.pdf
Stephen
--
Stephen Trier
Technical Development Lab
Cleveland FES Center
s...@po.cwru.edu
Generating video with software is challenging. It helps to have some sort
of hardware assistance, even if it is just some sort of timed DMA system
to move data to the LCD. Most people who interface LCDs to an HC12 use
LCD modules that have built-in controller chips, rather than LCD panels
with low-level interfaces like the one you are using. Then the controller
chip takes care of the detailed timing and the HC12 need only store data
into the controller's video memory to make it appear on the display.
You can probably generate the correct sync signals with the timers,
but how will you pump the data out fast enough? The panel needs 115200
bytes of data (640x480x3 bits), 70 times a second. That's 8MBps.
That would probably be difficult even for an S12X CPU. On top of that,
where will you store the data? If your video buffer stores every pixel,
you will need at least 115200 bytes of storage. If you don't buffer
every pixel individually, you will need to compute some or all of the
data on-the-fly, and that would make the bandwidth requirements even
more difficult to meet.
You're probably better off putting a suitable LCD controller chip between
the HC12 and the LCD. The controller chip manages the video buffer and
generates the critical LCD timing in hardware, freeing the HC12 to manage
the user interface and write pixel data into the video buffer whenever
it likes.
In theory, one can buy an LCD controller chip as a separate product,
but usually one gets one by buying an LCD module that has the controller
built-in. You could also to make a controller from an FPGA, perhaps
with an external SRAM.
It might also be possible to come up with some simpler, but creative
controller hardware that could do things like duplicate pixels and rows
so that the HC12 could stream data out more slowly, in exchange for a
lower effective display resolution.
I don't know of any app notes about using the HC12 as an LCD controller,
but Analog Devices has one about using the Blackfin DSP that I found
helpful in understanding the issues. Note how much they rely on the DSP's
DMA controller, and in particular its two-dimensional array capabilities,
to manage the bitstream and offload the CPU. That's basically what an
LCD controller chip does.
http://www.analog.com/UploadedFiles/Application_Notes/74670263ee256Rev2March706.pdf
Stephen
--
Stephen Trier
Technical Development Lab
Cleveland FES Center
s...@po.cwru.edu
Reply by ●April 25, 20062006-04-25
Check out epson at http://www.erd.epson.com/vdc/html/products.htm
I've interfaced the 13706 to ARM7 but the interface can be very generic.
I don't see why an xgate chip couldn't do a great job. I'd actually
recommend the A04 or A05 which have a buffer capable of 1/4 VGA in 16bit
colour.
Don't expect a 40MHz chip to give you full animation capability. The
ARM7 ASIC had a 29MHz clock and was capable of only 5 frames/sec at 8bpp
(single thread in PSOS).
More challenging is the creation of your own graphics library if you
don't have a cots solution.
-rob
I've interfaced the 13706 to ARM7 but the interface can be very generic.
I don't see why an xgate chip couldn't do a great job. I'd actually
recommend the A04 or A05 which have a buffer capable of 1/4 VGA in 16bit
colour.
Don't expect a 40MHz chip to give you full animation capability. The
ARM7 ASIC had a 29MHz clock and was capable of only 5 frames/sec at 8bpp
(single thread in PSOS).
More challenging is the creation of your own graphics library if you
don't have a cots solution.
-rob
