I could not find the link. Is there anybody supply it to the files
section?
--- In l..., Joel Winarske wrote: >
> Sebastien Jacquemard wrote:
> > For the performance I've got on this chip a 480x272pixels LCD, I refresh 25x time a second a large bargraph (400 pixels * 30) and a
large value of 10mm height. During this time I also measure an AD
converter 600x per second, drive a keyboard, and RS232 without any
operating system. > > Another advantage when the chip is from SHarp,
Sharp give for free a graphical library, and it's very good to start but I
don't
know if NXP now give it also this library named "ABLE" > >
> I found ABLE here:
> http://www.sharpsma.com/Page.aspx/americas/en/mculibrary/
>
> Joel
>
Sebastien Jacquemard wrote: > For the performance I've got on this chip a
480x272pixels LCD, I refresh 25x time a second a large bargraph (400 pixels *
30) and a large value of 10mm height. During this time I also measure an AD
converter 600x per second, drive a keyboard, and RS232 without any operating
system.
> Another advantage when the chip is from SHarp, Sharp give for free a graphical
library, and it's very good to start but I don't know if NXP now give
it also this library named "ABLE"
> I found ABLE here: http://www.sharpsma.com/Page.aspx/americas/en/mculibrary/
Joel
Reply by Tony Vandiver●August 22, 20072007-08-22
Thanks for the advice all. I'm starting to consider the AT91SAM9261
because I'm an Atmel fan, but getting started looks daunting. Any thoughts
on running linux as an embedded RTOS vs. just writing my own os-free software
with the GNU arm toolchain? I can see the advantage of the rtos, but two
disadvantages for me are that 1) I've got to learn everything about it, and
2) I've got to add enough memory support for the linux kernel in terms of
RAM/Flash and that costs money and to me, running code out of external flash is
scary. I would love to implement an ARM9 just for the experience, but I think I
may have to stick with the ARM7 + SSD1906 for a solution that I'm fairly
confident I can get to work in a short time frame.
Thanks,
Tony
Reply by Doug Sutherland●August 22, 20072007-08-22
Or, look the Cirrus Logic EP9307 or EP9315 with raster engine
and graphics accelerator, but we're talking ARM920T.
Also, there is an ARM kit with Sharp ARM7 and LCD, in the
discussion group for which, there was the same complaint as
described by TomW, yes it can display, that is about all it can
do. Trying to do much else will be a turtle race.
-- Doug
Reply by Tom Walsh●August 22, 20072007-08-22
williamvandiver2003 wrote: >
> Hi All,
>
> I'm new to the group and ARM and LCD, but my goal is to drive a QVGA
> 24 bit rgb display directly with the LPC2214 or similar ARM. My
> display has a 24 bit RGB interface with VClk, HClk, PClk, DEN, and a 24
> bit data bus (HX8218A+HX8615A controllers) . My hope was that I could
> run at 60MHz and read each pixel value from ext sram, then write to the
> LCD controller over 320x240 pixels and still have enough time after one
> refresh to do other stuff. My question is very basic and shows how
> little I know about what the controllers are doing :
>
IMO, that is a rather ambitious task for most processors to do: run a
color graphics LCD. The clocking rate is quite high to keep the display
fed with data. An LCD is a dynamic device similar to a common CRT
monitor. In other words, it is a raster device. You continually pump a
data stream into the device for each row of pixels on the display.
While you may be able to feed an LCD from an ARM processor (maybe), that
would be all you will be doing with that processor: feeding the display
without much left for running an application.
I would suggest you stay away from the old Sharp line of processors, for
now, until NXP decides if they are going to aggressively market them or
not. AFAIK, NXP has made no pronouncements as to the future of that
line... I would suggest that you look at the Samsung S3C24x0 series, or
the Cyprus 93xx series of processors to do what you want. Either of the
two families have STN (even DSTN) and TFT LCD controllers built into them.
As far as that goes, either of those processors will run Linux quite
well as they have MMUs. The embedded Linux software is quite advanced
for the ARM processors, nearly anything you can do with a personal
computer is implemented on ARM Linux. I only mention Linux as most of
your complexity is reduced to just writing an application instead of
worrying about how to program for your hardware (LCD, RAM etc).
Reply by Sebastien Jacquemard●August 22, 20072007-08-22
Hi Tony,
The controllers HX8218/HX8615 are only the gate driver used to drive each
pixels. For your LCD you need a graphic controller like epson S1D13706 with 80K
embedded ram (it's sufficient for 320*280x8bits color) or solomon systech
SSD1905.
The other solution if you are not fixed with the LPC2214, you can use the
LH75401 also from NXP (old Sharp mcu). This controller is also an ARM7 like
LPC2214, with same footprint (TQFP144) you just need an exeternal flash and ram
but it got the color LCD controller inside.
The LCD controller has only 12bit color bus but it's not really a problem
:
It make 3 bits / color so you connect the 3 lines for each color to the MSB of
each colors of your display and the LSB lines of your display to gnd.
It's eacy and give good results.
For the performance I've got on this chip a 480x272pixels LCD, I refresh
25x time a second a large bargraph (400 pixels * 30) and a large value of 10mm
height. During this time I also measure an AD converter 600x per second, drive a
keyboard, and RS232 without any operating system.
Another advantage when the chip is from SHarp, Sharp give for free a graphical
library, and it's very good to start but I don't know if NXP now give
it also this library named "ABLE"
Sebastien
----- Original Message -----
From: williamvandiver2003
To: l...
Sent: Wednesday, August 22, 2007 12:49 AM
Subject: [lpc2000] LPC2214 QVGA LCD
Hi All,
I'm new to the group and ARM and LCD, but my goal is to drive a QVGA
24 bit rgb display directly with the LPC2214 or similar ARM. My
display has a 24 bit RGB interface with VClk, HClk, PClk, DEN, and a 24
bit data bus (HX8218A+HX8615A controllers). My hope was that I could
run at 60MHz and read each pixel value from ext sram, then write to the
LCD controller over 320x240 pixels and still have enough time after one
refresh to do other stuff. My question is very basic and shows how
little I know about what the controllers are doing :
Does a TFT LCD have to be continuously clocked to be visible? On
the one hand, I'm pretty sure that I can't just refresh the 320x240
area one time and expect the display to stay static because I don't see
a huge RAM buffer on the interface controllers, but I don't KNOW that.
Another thought I had was that if I could completely paint the display
in 10msec, I would be able to use 6msec out of every 16 for other
processing to give me a 60Hz refresh rate, but does anyone know if this
works? Am I grasping at straws? Just trying to decide if I need to go
ahead and buy a SED1335F or similar interface?
Suggestions??
Thanks in advance,
Tony
Reply by williamvandiver2003●August 22, 20072007-08-22
Hi All,
I'm new to the group and ARM and LCD, but my goal is to drive a QVGA
24 bit rgb display directly with the LPC2214 or similar ARM. My
display has a 24 bit RGB interface with VClk, HClk, PClk, DEN, and a 24
bit data bus (HX8218A+HX8615A controllers). My hope was that I could
run at 60MHz and read each pixel value from ext sram, then write to the
LCD controller over 320x240 pixels and still have enough time after one
refresh to do other stuff. My question is very basic and shows how
little I know about what the controllers are doing :
Does a TFT LCD have to be continuously clocked to be visible? On
the one hand, I'm pretty sure that I can't just refresh the 320x240
area one time and expect the display to stay static because I don't see
a huge RAM buffer on the interface controllers, but I don't KNOW that.
Another thought I had was that if I could completely paint the display
in 10msec, I would be able to use 6msec out of every 16 for other
processing to give me a 60Hz refresh rate, but does anyone know if this
works? Am I grasping at straws? Just trying to decide if I need to go
ahead and buy a SED1335F or similar interface?
