>--- In l..., Mike Harrison wrote:
>>
>> On Sun, 15 Mar 2009 00:06:20 -0000, you wrote:
>>
>> >> This will probably work. I'm using an LPC2478 with an external SRAM
(256K x 16) for video RAM, and it's working fine. My LCD is 480x272;
I'm using 8 bits/pixel and I double-buffer the video RAM.
>> >
>> >I assume that's a Sharp (or compatible) display? I'm curious how
that's worked out for you. I'm interested in the same LCD since
it's inexpensive, easy to find, and has a nice size for many applications
(particularly displaying text, etc.). I've been playing with getting this
screen working with an Epson S1D13743, but that controlled is the same price as
a 2478, and only allows double-buffering on 320x240 screens due to memory
constraints.
>> >
>> >If you wouldn't mind offering some advice on any difficulties you had
getting this combination to work (things to look out for, etc.), I know I'd
appreciate it at the very least. How did you go about doing the double
buffering, for example?
>>
>> The double-buffering ought to just be a case of changing the start address of
the display in memory,
>> synced to the frame timing of course to get a clean switch.
>>
>> There are a few displays I'm potentially interested in driving - the PSP
one mentioned above,
>> (wow these are really cheap now :
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item50174912608)
>> this cheap 3.5" QVGA
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item0290627726
>> as well as the Sparkfun $1 QVGAs I bought a load of a while ago
>> http://www.sparkfun.com/commerce/product_info.php?products_id43
>>
>> I also want to try running two QVGA displays off one controller - probably
either by telling the LPC
>> to double the pixclk rate and divide it externally to drive each display on
alternate pixclks, or
>> maybe tweak the line timing to output lines alternately to each display -
may have to get creative
>> with the PWMs to fake some extra display timing signals!
>> Another plan is to feed a DVI transmit chip to drive the TI Pico projector
devkit :
>> http://focus.ti.com/dlpdmd/docs/dlpdiscovery.tsp?sectionId`&tabId"35
>>
>> I've just ordered one of these to figure out some details before diving
in with my own PCB
>> http://www.embeddedartists.com/products/uclinux/oem_lpc2478_oem.php
>>
>> I was originally going to use SRAM, but looking at RAM prices 16 or 64M of
SDRAM looks cheaper than
>> 4M of SRAM (I found some 64M for $1!) - ISTR reading a while ago about some
bandwidth issues running
>> SDRAM with the LCDC - does anyone have any max bandwidth/pixclock figures for
16 bit wide SDRAM?
>>Re - "The double-buffering ought to just be a case of changing the start
address of the display in memory, synced to the frame timing of course to get a
clean switch."
>
>Yep - I declared two pointers to buffers of equal size (let's call them P1
& P2) and set LCD_UPBASE = P1 when I initialized the LCD controller. P1 is now
considered the pointer to the active or "foreground" buffer, with P2 pointing to
the "background" buffer. I do all my drawing in the "background" buffer then
point LCD_UPBASE to the background buffer to display the new screen. Now, P1
has become the background buffer pointer, and P2 points to the new the
"foreground" buffer. The process repeats from there.
>
>You don't have to worry about synchronizing switching the buffer pointer
to vertical sync timing with this processor. The LCD controller double buffers
the frame base address register, and copies LCD_UPBASE to LCD_UPCURR at the
start of each vertical interval; see sec. 7.6 in the LPC24XX Users'
Guide.
>
>As to running two displays from this controller, it already supports dual
displays to some extent; the lower display is accessed thru LCD_LPBASE. I
haven't looked into the details of driving dual displays; you might want to
see if NXP has an appnote regarding this feature. This is mainly aimed at STN panels that have seperate drivers at the top
& bottom of the panel -
from a quick read of the UM, I'm not sure it would be possible to enable
this with in TFT mode but
will have a play once I get some hardware.
--- In l..., Mike Harrison wrote: >
> On Sun, 15 Mar 2009 00:06:20 -0000, you wrote:
>
> >> This will probably work. I'm using an LPC2478 with an external SRAM
(256K x 16) for video RAM, and it's working fine. My LCD is 480x272;
I'm using 8 bits/pixel and I double-buffer the video RAM.
> >
> >I assume that's a Sharp (or compatible) display? I'm curious how
that's worked out for you. I'm interested in the same LCD since
it's inexpensive, easy to find, and has a nice size for many applications
(particularly displaying text, etc.). I've been playing with getting this
screen working with an Epson S1D13743, but that controlled is the same price as
a 2478, and only allows double-buffering on 320x240 screens due to memory
constraints.
> >
> >If you wouldn't mind offering some advice on any difficulties you had
getting this combination to work (things to look out for, etc.), I know I'd
appreciate it at the very least. How did you go about doing the double
buffering, for example?
>
> The double-buffering ought to just be a case of changing the start address of
the display in memory,
> synced to the frame timing of course to get a clean switch.
>
> There are a few displays I'm potentially interested in driving - the PSP
one mentioned above,
> (wow these are really cheap now :
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item50174912608)
> this cheap 3.5" QVGA
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item0290627726
> as well as the Sparkfun $1 QVGAs I bought a load of a while ago
> http://www.sparkfun.com/commerce/product_info.php?products_id43
>
> I also want to try running two QVGA displays off one controller - probably
either by telling the LPC
> to double the pixclk rate and divide it externally to drive each display on
alternate pixclks, or
> maybe tweak the line timing to output lines alternately to each display - may
have to get creative
> with the PWMs to fake some extra display timing signals!
> Another plan is to feed a DVI transmit chip to drive the TI Pico projector
devkit :
> http://focus.ti.com/dlpdmd/docs/dlpdiscovery.tsp?sectionId`&tabId"35
>
> I've just ordered one of these to figure out some details before diving
in with my own PCB
> http://www.embeddedartists.com/products/uclinux/oem_lpc2478_oem.php
>
> I was originally going to use SRAM, but looking at RAM prices 16 or 64M of
SDRAM looks cheaper than
> 4M of SRAM (I found some 64M for $1!) - ISTR reading a while ago about some
bandwidth issues running
> SDRAM with the LCDC - does anyone have any max bandwidth/pixclock figures for
16 bit wide SDRAM?
>
Re - "The double-buffering ought to just be a case of changing the start address
of the display in memory, synced to the frame timing of course to get a clean
switch."
Yep - I declared two pointers to buffers of equal size (let's call them P1
& P2) and set LCD_UPBASE = P1 when I initialized the LCD controller. P1 is now
considered the pointer to the active or "foreground" buffer, with P2 pointing to
the "background" buffer. I do all my drawing in the "background" buffer then
point LCD_UPBASE to the background buffer to display the new screen. Now, P1
has become the background buffer pointer, and P2 points to the new the
"foreground" buffer. The process repeats from there.
You don't have to worry about synchronizing switching the buffer pointer to
vertical sync timing with this processor. The LCD controller double buffers the
frame base address register, and copies LCD_UPBASE to LCD_UPCURR at the start of
each vertical interval; see sec. 7.6 in the LPC24XX Users' Guide.
As to running two displays from this controller, it already supports dual
displays to some extent; the lower display is accessed thru LCD_LPBASE. I
haven't looked into the details of driving dual displays; you might want to
see if NXP has an appnote regarding this feature.
Chris
Reply by Tim Mitchell●March 16, 20092009-03-16
----Original Message----
From: l...
[mailto:l...] On Behalf Of Kevin
Townsend Sent: 16 March 2009 01:57 To:
l... Subject: [lpc2000] Re: Using
LPC2470 with no Flash at all... >
> Where are you currently at with the PSP display? I've
> been working on a project with a custom LPC2478 board,
> and was thinking about using that same display ... just
> curious if it was more effort than you expected to get it
> working with the internal LCD controller, etc., since
> I've heard very mixed results. Because you have to share
> all the bandwidth, it's easy to make the display glitch,
> etc., which is why I started playing with the Epson
> controllers just in case.
>
We're using a PSP-type display with 2478 (480x272 in 16 bit mode). There
was a bit of fun getting it to work with the internal controller but
it's great now. The glitching problem is easily preventable once you
know what is going on. It's much better than an external LCD controller
because the framebuffer is in the processor's RAM which saves a whole
load of shifting data around, not to mention the cost reduction. You can
make a very nifty little unit with just 3 chips (2478, SDRAM, and NOR
Flash if you need more than the processor's 512KB) + PSU.
I have that same display (from the same seller), but haven't taken the time
to try to get it working yet. It seems like a fairly interesting display,
though, for the price. If you get a chance to play with it, I'd love to
discuss it with you. It will give me a reason to try to get it working myself
as well.
I also picked up a few, but the lack of a dependable supply sort of turned me
off to them along with no video controller, etc.
Where are you currently at with the PSP display? I've been working on a
project with a custom LPC2478 board, and was thinking about using that same
display ... just curious if it was more effort than you expected to get it
working with the internal LCD controller, etc., since I've heard very mixed
results. Because you have to share all the bandwidth, it's easy to make
the display glitch, etc., which is why I started playing with the Epson
controllers just in case.
Kevin.
Reply by Mike Harrison●March 14, 20092009-03-14
On Sun, 15 Mar 2009 00:06:20 -0000, you wrote:
>> This will probably work. I'm using an LPC2478
with an external SRAM (256K x 16) for video RAM, and it's working fine. My
LCD is 480x272; I'm using 8 bits/pixel and I double-buffer the video
RAM.
>
>I assume that's a Sharp (or compatible) display? I'm curious how
that's worked out for you. I'm interested in the same LCD since
it's inexpensive, easy to find, and has a nice size for many applications
(particularly displaying text, etc.). I've been playing with getting this
screen working with an Epson S1D13743, but that controlled is the same price as
a 2478, and only allows double-buffering on 320x240 screens due to memory
constraints.
>
>If you wouldn't mind offering some advice on any difficulties you had
getting this combination to work (things to look out for, etc.), I know I'd
appreciate it at the very least. How did you go about doing the double
buffering, for example?
The double-buffering ought to just be a case of changing the start address of
the display in memory,
synced to the frame timing of course to get a clean switch.
I also want to try running two QVGA displays off one controller - probably
either by telling the LPC
to double the pixclk rate and divide it externally to drive each display on
alternate pixclks, or
maybe tweak the line timing to output lines alternately to each display - may
have to get creative
with the PWMs to fake some extra display timing signals!
Another plan is to feed a DVI transmit chip to drive the TI Pico projector
devkit : http://focus.ti.com/dlpdmd/docs/dlpdiscovery.tsp?sectionId`&tabId"35
I was originally going to use SRAM, but looking at RAM prices 16 or 64M of SDRAM
looks cheaper than
4M of SRAM (I found some 64M for $1!) - ISTR reading a while ago about some
bandwidth issues running
SDRAM with the LCDC - does anyone have any max bandwidth/pixclock figures for 16
bit wide SDRAM?
Reply by Kevin Townsend●March 14, 20092009-03-14
> This will probably work. I'm using an LPC2478
with an external SRAM (256K x 16) for video RAM, and it's working fine. My
LCD is 480x272; I'm using 8 bits/pixel and I double-buffer the video
RAM.
I assume that's a Sharp (or compatible) display? I'm curious how
that's worked out for you. I'm interested in the same LCD since
it's inexpensive, easy to find, and has a nice size for many applications
(particularly displaying text, etc.). I've been playing with getting this
screen working with an Epson S1D13743, but that controlled is the same price as
a 2478, and only allows double-buffering on 320x240 screens due to memory
constraints.
If you wouldn't mind offering some advice on any difficulties you had
getting this combination to work (things to look out for, etc.), I know I'd
appreciate it at the very least. How did you go about doing the double
buffering, for example?
Reply by Chris Lawton●March 12, 20092009-03-12
--- In l..., Mike Harrison wrote: >
> I'm looking at a possible application using LPC2470 (flashless 2478) as
an intelligent QVGA LCD
> controller - it looks like working out similar in cost to standalone LCD
controller ICs & you get
> the CPU thrown in for free!
>
> As far as I can see, it should be possible to use it with no internal or
external flash, by loading
> code into internal SRAM on every startup via ISP from a host system. (reason
for not using 2478 is
> cost).
> The only other chip needed will be an external SRAM for the LCD frame buffer.
Anyone see a reason
> this wouldn't work?
> As code would be ruuning in internal SRAM, I'm assuming I can use 16 bit
wide external SRAM, or
> maybe even 8 bit? Only need about 1Mbit for a couple of QVGA frames so no need
for SDRAM,
>
> I use IAR & J-Link on other LPC's - I vaguely recall seeing something
about being able to load &
> debug code to internal SRAM on other parts - can anyone forsee any problems
debugging a flashless
> system ? (I realise I may need to do some minor fiddles between JTAG
debugging & normal
> ISP-downloaded operation due to the bootloader remapping the int vectors.)
>
This will probably work. I'm using an LPC2478 with an external SRAM (256K
x 16) for video RAM, and it's working fine. My LCD is 480x272; I'm
using 8 bits/pixel and I double-buffer the video RAM.
IAR Tech Note 11578 discusses executing code in RAM after copying from flash;
this note relates to the STR912, so the process may not be exactly what you
need.
Good luck with this - please let us all know how it works out!
Chris
Reply by Mike Harrison●March 12, 20092009-03-12
I'm looking at a possible application using LPC2470 (flashless 2478) as an
intelligent QVGA LCD
controller - it looks like working out similar in cost to standalone LCD
controller ICs & you get
the CPU thrown in for free!
As far as I can see, it should be possible to use it with no internal or
external flash, by loading
code into internal SRAM on every startup via ISP from a host system. (reason
for not using 2478 is
cost).
The only other chip needed will be an external SRAM for the LCD frame buffer.
Anyone see a reason
this wouldn't work?
As code would be ruuning in internal SRAM, I'm assuming I can use 16 bit
wide external SRAM, or
maybe even 8 bit? Only need about 1Mbit for a couple of QVGA frames so no need
for SDRAM,
I use IAR & J-Link on other LPC's - I vaguely recall seeing something
about being able to load &
debug code to internal SRAM on other parts - can anyone forsee any problems
debugging a flashless
system ? (I realise I may need to do some minor fiddles between JTAG debugging
& normal
ISP-downloaded operation due to the bootloader remapping the int vectors.)