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.)
Using LPC2470 with no Flash at all...
Started by ●March 12, 2009
Reply by ●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
>
> 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 ●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?
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 ●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.
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?
>> 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?
Reply by ●March 15, 20092009-03-15
> this cheap 3.5" QVGA
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item0290627726
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.
> 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 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.
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.
> 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 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 ●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.
--
Tim Mitchell
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.
--
Tim Mitchell
Reply by ●March 16, 20092009-03-16
--- 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
>
> 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 ●March 16, 20092009-03-16
On Mon, 16 Mar 2009 16:34:16 -0000, you wrote:
>--- 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.
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.
