I've just been tinkering with the Olimex LPC2478 board with various LCDs
and pixel rates to get a
feel for the memory bandwith usage - thought the results may be of interest to
others as the subject
has cropped up a few times
Measured using a loop counting the number of read/writes of a block of SDRAM
that can be done in
100mS. System clock 72MHz, setup as per IAR USB_Host demo application
Tested with 32 and 16 bit SDRAM configurations
Figures indicate percentenge of memory bandwidth used by LCD DMA.
* indicates DMA fail interrupt occurs.
PSP LCD, 480x272, 24BPP
Pixel Clock.MHz % used (32 bit) % used (16 bit)
36 84* 86*
24 84* 86*
18 83* 86*
14.4 68 84*
12 55 71
10.285 49 59
9 43 53
8 37 48
7.2 34 42
6.545 31 39
6 28 34
5.538 26 32
5.142 24 30
4.8 22 28
Olimex 320x240, 24BPP
36 81* 83*
24 78* 81*
18 71* 78*
14.4 56 70*
12 45 58
10.285 41 48
9 36 45
8 31 40
7.2 28 34
6.545 26 32
6 23 29
5.538 22 26
5.142 21 25
4.8 18 24
Olimex 320x240, 16BPP
36 71 82*
24 45 58
18 36 44
14.4 28 35
12 23 29
10.285 20 24
9 17 21
8 16 19
7.2 14 17
6.545 13 16
6 12 15
5.538 11 14
5.142 11 13
4.8 10 12
Olimex 320x240, 8BPP
36 36 44
24 23 29
18 18 21
14.4 14 17
12 12 15
10.285 10 13
9 9 11
8 8 10
7.2 8 9
6.545 7 9
6 7 7
5.538 6 7
5.142 6 7
4.8 5 6
LPC2478 LCD controller memory bandwidth usage
Started by ●May 8, 2009
Reply by ●May 9, 20092009-05-09
Hi,
I find you numbers very interesting and also a little bit disappointing concerning the computing power of the LPC2478.
So just to make sure I got them right I will comment on one example.
The PSP display: I assume that to draw one picture you need 480x272x24 = 3133440 pixel clocks. If you have a pixel clock of 18MHz you get approx 60 'frames' per second. That should be OK for most applications. However that means you memory interface is almost blocked by the LCD DMA (at least 84% memory interface bus load). Do you numbers include that the ARM7 core also have to write to the LCD memory to change the picture. If not that would mean that one has to go down to approx 30 frames per second to be able to change every frame the entire picture (which of course is not very likely). More realistic would be a content change from one frame to the next of about 20%. Even then the frame rate will go down to approx 45 frames per second. I assume that for some games this is hardly acceptable. The numbers will get significantly worse (by the power of 2 I assume) if one uses a display with higher resolution (the PSP isn't that great for nowadays applications).
Can someone comment on my notes just to make sure that I interpreted the numbers from Mike correctly.
Best Regards
Markus
-----Ursprgliche Nachricht-----
Von: "Mike Harrison"
Gesendet: 08.05.09 21:18:02
An: l...
Betreff: [lpc2000] LPC2478 LCD controller memory bandwidth usage
I've just been tinkering with the Olimex LPC2478 board with various
LCDs and pixel rates to get a
feel for the memory bandwith usage - thought the results may be of
interest to others as the subject
has cropped up a few times
Measured using a loop counting the number of read/writes of a block
of SDRAM that can be done in
100mS. System clock 72MHz, setup as per IAR USB_Host demo application
Tested with 32 and 16 bit SDRAM configurations
Figures indicate percentenge of memory bandwidth used by LCD DMA.
* indicates DMA fail interrupt occurs.
PSP LCD, 480x272, 24BPP
Pixel Clock.MHz % used (32 bit) % used (16 bit)
36 84* 86*
24 84* 86*
18 83* 86*
14.4 68 84*
12 55 71
10.285 49 59
9 43 53
8 37 48
7.2 34 42
6.545 31 39
6 28 34
5.538 26 32
5.142 24 30
4.8 22 28
Olimex 320x240, 24BPP
36 81* 83*
24 78* 81*
18 71* 78*
14.4 56 70*
12 45 58
10.285 41 48
9 36 45
8 31 40
7.2 28 34
6.545 26 32
6 23 29
5.538 22 26
5.142 21 25
4.8 18 24
Olimex 320x240, 16BPP
36 71 82*
24 45 58
18 36 44
14.4 28 35
12 23 29
10.285 20 24
9 17 21
8 16 19
7.2 14 17
6.545 13 16
6 12 15
5.538 11 14
5.142 11 13
4.8 10 12
Olimex 320x240, 8BPP
36 36 44
24 23 29
18 18 21
14.4 14 17
12 12 15
10.285 10 13
9 9 11
8 8 10
7.2 8 9
6.545 7 9
6 7 7
5.538 6 7
5.142 6 7
4.8 5 6
__________________________________________________________________________
Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und viele
ausldische Netze zum gleichen Preis!
https://produkte.web.de/webde_sms/sms
I find you numbers very interesting and also a little bit disappointing concerning the computing power of the LPC2478.
So just to make sure I got them right I will comment on one example.
The PSP display: I assume that to draw one picture you need 480x272x24 = 3133440 pixel clocks. If you have a pixel clock of 18MHz you get approx 60 'frames' per second. That should be OK for most applications. However that means you memory interface is almost blocked by the LCD DMA (at least 84% memory interface bus load). Do you numbers include that the ARM7 core also have to write to the LCD memory to change the picture. If not that would mean that one has to go down to approx 30 frames per second to be able to change every frame the entire picture (which of course is not very likely). More realistic would be a content change from one frame to the next of about 20%. Even then the frame rate will go down to approx 45 frames per second. I assume that for some games this is hardly acceptable. The numbers will get significantly worse (by the power of 2 I assume) if one uses a display with higher resolution (the PSP isn't that great for nowadays applications).
Can someone comment on my notes just to make sure that I interpreted the numbers from Mike correctly.
Best Regards
Markus
-----Ursprgliche Nachricht-----
Von: "Mike Harrison"
Gesendet: 08.05.09 21:18:02
An: l...
Betreff: [lpc2000] LPC2478 LCD controller memory bandwidth usage
I've just been tinkering with the Olimex LPC2478 board with various
LCDs and pixel rates to get a
feel for the memory bandwith usage - thought the results may be of
interest to others as the subject
has cropped up a few times
Measured using a loop counting the number of read/writes of a block
of SDRAM that can be done in
100mS. System clock 72MHz, setup as per IAR USB_Host demo application
Tested with 32 and 16 bit SDRAM configurations
Figures indicate percentenge of memory bandwidth used by LCD DMA.
* indicates DMA fail interrupt occurs.
PSP LCD, 480x272, 24BPP
Pixel Clock.MHz % used (32 bit) % used (16 bit)
36 84* 86*
24 84* 86*
18 83* 86*
14.4 68 84*
12 55 71
10.285 49 59
9 43 53
8 37 48
7.2 34 42
6.545 31 39
6 28 34
5.538 26 32
5.142 24 30
4.8 22 28
Olimex 320x240, 24BPP
36 81* 83*
24 78* 81*
18 71* 78*
14.4 56 70*
12 45 58
10.285 41 48
9 36 45
8 31 40
7.2 28 34
6.545 26 32
6 23 29
5.538 22 26
5.142 21 25
4.8 18 24
Olimex 320x240, 16BPP
36 71 82*
24 45 58
18 36 44
14.4 28 35
12 23 29
10.285 20 24
9 17 21
8 16 19
7.2 14 17
6.545 13 16
6 12 15
5.538 11 14
5.142 11 13
4.8 10 12
Olimex 320x240, 8BPP
36 36 44
24 23 29
18 18 21
14.4 14 17
12 12 15
10.285 10 13
9 9 11
8 8 10
7.2 8 9
6.545 7 9
6 7 7
5.538 6 7
5.142 6 7
4.8 5 6
__________________________________________________________________________
Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und viele
ausldische Netze zum gleichen Preis!
https://produkte.web.de/webde_sms/sms
Reply by ●May 9, 20092009-05-09
On Sat, 09 May 2009 15:59:03 +0200, you wrote:
>Hi,
>
>I find you numbers very interesting and also a little bit disappointing concerning the computing power of the LPC2478.
>
>So just to make sure I got them right I will comment on one example.
>The PSP display: I assume that to draw one picture you need 480x272x24 = 3133440 pixel clocks.
No, 472x272 plus a bit for the borders. It's a pixel clock, not a byte clock.
> If you have a pixel clock of 18MHz you get approx 60 'frames' per second.
No - the PSP display is designed for 9MHz pixel clock, at 60 frames.sec, so it only uses about 45%,
and in many cases you will be able to use 16 bit mode (5:6:5) which halves that.
>Best Regards
>Markus
>-----Ursprgliche Nachricht-----
>Von: "Mike Harrison"
>Gesendet: 08.05.09 21:18:02
>An: l...
>Betreff: [lpc2000] LPC2478 LCD controller memory bandwidth usage
>I've just been tinkering with the Olimex LPC2478 board with various
>LCDs and pixel rates to get a
>feel for the memory bandwith usage - thought the results may be of
>interest to others as the subject
>has cropped up a few times
>
>Measured using a loop counting the number of read/writes of a block
>of SDRAM that can be done in
>100mS. System clock 72MHz, setup as per IAR USB_Host demo application
>
>Tested with 32 and 16 bit SDRAM configurations
>
>Figures indicate percentenge of memory bandwidth used by LCD DMA.
>* indicates DMA fail interrupt occurs.
>
>PSP LCD, 480x272, 24BPP
>Pixel Clock.MHz % used (32 bit) % used (16 bit)
>36 84* 86*
>24 84* 86*
>18 83* 86*
>14.4 68 84*
>12 55 71
>10.285 49 59
>9 43 53
>8 37 48
>7.2 34 42
>6.545 31 39
>6 28 34
>5.538 26 32
>5.142 24 30
>4.8 22 28
>
>Olimex 320x240, 24BPP
>36 81* 83*
>24 78* 81*
>18 71* 78*
>14.4 56 70*
>12 45 58
>10.285 41 48
>9 36 45
>8 31 40
>7.2 28 34
>6.545 26 32
>6 23 29
>5.538 22 26
>5.142 21 25
>4.8 18 24
>
>Olimex 320x240, 16BPP
>36 71 82*
>24 45 58
>18 36 44
>14.4 28 35
>12 23 29
>10.285 20 24
>9 17 21
>8 16 19
>7.2 14 17
>6.545 13 16
>6 12 15
>5.538 11 14
>5.142 11 13
>4.8 10 12
>
>Olimex 320x240, 8BPP
>36 36 44
>24 23 29
>18 18 21
>14.4 14 17
>12 12 15
>10.285 10 13
>9 9 11
>8 8 10
>7.2 8 9
>6.545 7 9
>6 7 7
>5.538 6 7
>5.142 6 7
>4.8 5 6
>__________________________________________________________________________
>Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und viele
>ausldische Netze zum gleichen Preis!
>https://produkte.web.de/webde_sms/sms
>
>
>Hi,
>
>I find you numbers very interesting and also a little bit disappointing concerning the computing power of the LPC2478.
>
>So just to make sure I got them right I will comment on one example.
>The PSP display: I assume that to draw one picture you need 480x272x24 = 3133440 pixel clocks.
No, 472x272 plus a bit for the borders. It's a pixel clock, not a byte clock.
> If you have a pixel clock of 18MHz you get approx 60 'frames' per second.
No - the PSP display is designed for 9MHz pixel clock, at 60 frames.sec, so it only uses about 45%,
and in many cases you will be able to use 16 bit mode (5:6:5) which halves that.
>Best Regards
>Markus
>-----Ursprgliche Nachricht-----
>Von: "Mike Harrison"
>Gesendet: 08.05.09 21:18:02
>An: l...
>Betreff: [lpc2000] LPC2478 LCD controller memory bandwidth usage
>I've just been tinkering with the Olimex LPC2478 board with various
>LCDs and pixel rates to get a
>feel for the memory bandwith usage - thought the results may be of
>interest to others as the subject
>has cropped up a few times
>
>Measured using a loop counting the number of read/writes of a block
>of SDRAM that can be done in
>100mS. System clock 72MHz, setup as per IAR USB_Host demo application
>
>Tested with 32 and 16 bit SDRAM configurations
>
>Figures indicate percentenge of memory bandwidth used by LCD DMA.
>* indicates DMA fail interrupt occurs.
>
>PSP LCD, 480x272, 24BPP
>Pixel Clock.MHz % used (32 bit) % used (16 bit)
>36 84* 86*
>24 84* 86*
>18 83* 86*
>14.4 68 84*
>12 55 71
>10.285 49 59
>9 43 53
>8 37 48
>7.2 34 42
>6.545 31 39
>6 28 34
>5.538 26 32
>5.142 24 30
>4.8 22 28
>
>Olimex 320x240, 24BPP
>36 81* 83*
>24 78* 81*
>18 71* 78*
>14.4 56 70*
>12 45 58
>10.285 41 48
>9 36 45
>8 31 40
>7.2 28 34
>6.545 26 32
>6 23 29
>5.538 22 26
>5.142 21 25
>4.8 18 24
>
>Olimex 320x240, 16BPP
>36 71 82*
>24 45 58
>18 36 44
>14.4 28 35
>12 23 29
>10.285 20 24
>9 17 21
>8 16 19
>7.2 14 17
>6.545 13 16
>6 12 15
>5.538 11 14
>5.142 11 13
>4.8 10 12
>
>Olimex 320x240, 8BPP
>36 36 44
>24 23 29
>18 18 21
>14.4 14 17
>12 12 15
>10.285 10 13
>9 9 11
>8 8 10
>7.2 8 9
>6.545 7 9
>6 7 7
>5.538 6 7
>5.142 6 7
>4.8 5 6
>__________________________________________________________________________
>Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und viele
>ausldische Netze zum gleichen Preis!
>https://produkte.web.de/webde_sms/sms
>
>
Reply by ●May 9, 20092009-05-09
Markus Krug wrote:
>
> I find you numbers very interesting and also a little bit disappointing concerning the computing power of the LPC2478.
>
> So just to make sure I got them right I will comment on one example.
> The PSP display: I assume that to draw one picture you need 480x272x24 = 3133440 pixel clocks. If you have a pixel clock of 18MHz you get approx 60 'frames' per second. That should be OK for most applications. However that means you memory interface is almost blocked by the LCD DMA (at least 84% memory interface bus load).
It means the SDRAM interface needs to be dedicated to video.
However, the numbers may in part be an artifact of the instrumentation
used to measure bandwidth. I assume there is a loop counting reads
out of the SDRAM in the background and the resulting value is used
to determine bandwidth usage, as a proportion of a calibration value
obtained from an idle bus. The problem with this method is that each
time the loop makes an access it switches the row, forcing the video
access to continuously re-RAS. If this is indeed how the bandwidth
usage is measured, then removing the instrumentation should help usage
at higher pixel clocks.
>
> I find you numbers very interesting and also a little bit disappointing concerning the computing power of the LPC2478.
>
> So just to make sure I got them right I will comment on one example.
> The PSP display: I assume that to draw one picture you need 480x272x24 = 3133440 pixel clocks. If you have a pixel clock of 18MHz you get approx 60 'frames' per second. That should be OK for most applications. However that means you memory interface is almost blocked by the LCD DMA (at least 84% memory interface bus load).
It means the SDRAM interface needs to be dedicated to video.
However, the numbers may in part be an artifact of the instrumentation
used to measure bandwidth. I assume there is a loop counting reads
out of the SDRAM in the background and the resulting value is used
to determine bandwidth usage, as a proportion of a calibration value
obtained from an idle bus. The problem with this method is that each
time the loop makes an access it switches the row, forcing the video
access to continuously re-RAS. If this is indeed how the bandwidth
usage is measured, then removing the instrumentation should help usage
at higher pixel clocks.
Reply by ●May 9, 20092009-05-09
On Sat, 09 May 2009 15:02:24 -0700, you wrote:
>Markus Krug wrote:
>>
>> I find you numbers very interesting and also a little bit disappointing concerning the computing power of the LPC2478.
>>
>> So just to make sure I got them right I will comment on one example.
>> The PSP display: I assume that to draw one picture you need 480x272x24 = 3133440 pixel clocks. If you have a pixel clock of 18MHz you get approx 60 'frames' per second. That should be OK for most applications. However that means you memory interface is almost blocked by the LCD DMA (at least 84% memory interface bus load).
>It means the SDRAM interface needs to be dedicated to video.
>
>However, the numbers may in part be an artifact of the instrumentation
>used to measure bandwidth. I assume there is a loop counting reads
>out of the SDRAM in the background and the resulting value is used
>to determine bandwidth usage, as a proportion of a calibration value
>obtained from an idle bus. The problem with this method is that each
>time the loop makes an access it switches the row, forcing the video
>access to continuously re-RAS. If this is indeed how the bandwidth
>usage is measured, then removing the instrumentation should help usage
>at higher pixel clocks.
>
Yes - there is no 'right' answer as every application will be different - I chose a method that I
think should give a fairly worst-case figure by both reading, and writing words.
I originally started measuring by just writing to the SDRAM, and found that the effective memory
bandwidth was significantly higher, presumably due to the write-buffering hardware.
Incidentally the percentage figures are relative to the SDRAM bandwidth with the LCD controller
turned off.
One thing I have subsequently noticed is that when you are getting near to the DMA failure
threshold, it can be pushed over the edge by heavy SDRAM writing, so you need to ensure thet you
leave some safety margin.
>Markus Krug wrote:
>>
>> I find you numbers very interesting and also a little bit disappointing concerning the computing power of the LPC2478.
>>
>> So just to make sure I got them right I will comment on one example.
>> The PSP display: I assume that to draw one picture you need 480x272x24 = 3133440 pixel clocks. If you have a pixel clock of 18MHz you get approx 60 'frames' per second. That should be OK for most applications. However that means you memory interface is almost blocked by the LCD DMA (at least 84% memory interface bus load).
>It means the SDRAM interface needs to be dedicated to video.
>
>However, the numbers may in part be an artifact of the instrumentation
>used to measure bandwidth. I assume there is a loop counting reads
>out of the SDRAM in the background and the resulting value is used
>to determine bandwidth usage, as a proportion of a calibration value
>obtained from an idle bus. The problem with this method is that each
>time the loop makes an access it switches the row, forcing the video
>access to continuously re-RAS. If this is indeed how the bandwidth
>usage is measured, then removing the instrumentation should help usage
>at higher pixel clocks.
>
Yes - there is no 'right' answer as every application will be different - I chose a method that I
think should give a fairly worst-case figure by both reading, and writing words.
I originally started measuring by just writing to the SDRAM, and found that the effective memory
bandwidth was significantly higher, presumably due to the write-buffering hardware.
Incidentally the percentage figures are relative to the SDRAM bandwidth with the LCD controller
turned off.
One thing I have subsequently noticed is that when you are getting near to the DMA failure
threshold, it can be pushed over the edge by heavy SDRAM writing, so you need to ensure thet you
leave some safety margin.
Reply by ●May 9, 20092009-05-09
--- In l..., Mike Harrison wrote:
>
> On Sat, 09 May 2009 15:02:24 -0700, you wrote:
>
> >Markus Krug wrote:
> >>
> >> I find you numbers very interesting and also a little bit disappointing concerning the computing power of the LPC2478.
> >>
> >> So just to make sure I got them right I will comment on one example.
> >> The PSP display: I assume that to draw one picture you need 480x272x24 = 3133440 pixel clocks. If you have a pixel clock of 18MHz you get approx 60 'frames' per second. That should be OK for most applications. However that means you memory interface is almost blocked by the LCD DMA (at least 84% memory interface bus load).
> >It means the SDRAM interface needs to be dedicated to video.
> >
> >However, the numbers may in part be an artifact of the instrumentation
> >used to measure bandwidth. I assume there is a loop counting reads
> >out of the SDRAM in the background and the resulting value is used
> >to determine bandwidth usage, as a proportion of a calibration value
> >obtained from an idle bus. The problem with this method is that each
> >time the loop makes an access it switches the row, forcing the video
> >access to continuously re-RAS. If this is indeed how the bandwidth
> >usage is measured, then removing the instrumentation should help usage
> >at higher pixel clocks.
> >
> Yes - there is no 'right' answer as every application will be different - I chose a method that I
> think should give a fairly worst-case figure by both reading, and writing words.
>
> I originally started measuring by just writing to the SDRAM, and found that the effective memory
> bandwidth was significantly higher, presumably due to the write-buffering hardware.
>
> Incidentally the percentage figures are relative to the SDRAM bandwidth with the LCD controller
> turned off.
>
> One thing I have subsequently noticed is that when you are getting near to the DMA failure
> threshold, it can be pushed over the edge by heavy SDRAM writing, so you need to ensure thet you
> leave some safety margin.
>
NXP has a bus load calculator for the LPC2478. This should give you a good idea of the bus load for a given display with different memory widths at different core speeds. Here is the link for anyone interested.
http://www.standardics.nxp.com/support/documents/microcontrollers/xls/lpc247x.lcd.bus.load.calculator.xls
>
> On Sat, 09 May 2009 15:02:24 -0700, you wrote:
>
> >Markus Krug wrote:
> >>
> >> I find you numbers very interesting and also a little bit disappointing concerning the computing power of the LPC2478.
> >>
> >> So just to make sure I got them right I will comment on one example.
> >> The PSP display: I assume that to draw one picture you need 480x272x24 = 3133440 pixel clocks. If you have a pixel clock of 18MHz you get approx 60 'frames' per second. That should be OK for most applications. However that means you memory interface is almost blocked by the LCD DMA (at least 84% memory interface bus load).
> >It means the SDRAM interface needs to be dedicated to video.
> >
> >However, the numbers may in part be an artifact of the instrumentation
> >used to measure bandwidth. I assume there is a loop counting reads
> >out of the SDRAM in the background and the resulting value is used
> >to determine bandwidth usage, as a proportion of a calibration value
> >obtained from an idle bus. The problem with this method is that each
> >time the loop makes an access it switches the row, forcing the video
> >access to continuously re-RAS. If this is indeed how the bandwidth
> >usage is measured, then removing the instrumentation should help usage
> >at higher pixel clocks.
> >
> Yes - there is no 'right' answer as every application will be different - I chose a method that I
> think should give a fairly worst-case figure by both reading, and writing words.
>
> I originally started measuring by just writing to the SDRAM, and found that the effective memory
> bandwidth was significantly higher, presumably due to the write-buffering hardware.
>
> Incidentally the percentage figures are relative to the SDRAM bandwidth with the LCD controller
> turned off.
>
> One thing I have subsequently noticed is that when you are getting near to the DMA failure
> threshold, it can be pushed over the edge by heavy SDRAM writing, so you need to ensure thet you
> leave some safety margin.
>
NXP has a bus load calculator for the LPC2478. This should give you a good idea of the bus load for a given display with different memory widths at different core speeds. Here is the link for anyone interested.
http://www.standardics.nxp.com/support/documents/microcontrollers/xls/lpc247x.lcd.bus.load.calculator.xls
Reply by ●May 11, 20092009-05-11
--- In l..., Markus Krug wrote:
>
> Hi,
>
> I find you numbers very interesting and also a little bit disappointing concerning the computing power of the LPC2478.
...
> Can someone comment on my notes just to make sure that I interpreted the numbers from Mike correctly.
>
> Best Regards
> Markus
>
Hi Markus,
I don't want to go deep in magic numbers from Mike(discussion that they measured wrong started already), but computing (and display) power of LPC2478 is really limited. I'm using 800x480 16 bpp LCD in my application with 24 MHz dot clock. You have seen user manual, it is not limit for LPC2478. But if to change settings from 16 bpp to 24 bpp, or increase dot clock frequency, power is over. Visually it looks as loosing of line synchronization. Sometimes it is possible to get situation, when synchronization lost when core is running, but if it is stoped, picture is OK.
Small computing power forced me to use special tricks to organize user interface in my application creating separate pictures of GUI in PCX format(optimal between size and conversion time), copying them onto SD card, reading them and converting to bitmap after POR, writing them in SDRAM and assebling full pictures from fragments when device is running.
If anybody wanna use "video" IMHO 320x200 8 bpp is limit.
Best regards
Vladimir
>
> Hi,
>
> I find you numbers very interesting and also a little bit disappointing concerning the computing power of the LPC2478.
...
> Can someone comment on my notes just to make sure that I interpreted the numbers from Mike correctly.
>
> Best Regards
> Markus
>
Hi Markus,
I don't want to go deep in magic numbers from Mike(discussion that they measured wrong started already), but computing (and display) power of LPC2478 is really limited. I'm using 800x480 16 bpp LCD in my application with 24 MHz dot clock. You have seen user manual, it is not limit for LPC2478. But if to change settings from 16 bpp to 24 bpp, or increase dot clock frequency, power is over. Visually it looks as loosing of line synchronization. Sometimes it is possible to get situation, when synchronization lost when core is running, but if it is stoped, picture is OK.
Small computing power forced me to use special tricks to organize user interface in my application creating separate pictures of GUI in PCX format(optimal between size and conversion time), copying them onto SD card, reading them and converting to bitmap after POR, writing them in SDRAM and assebling full pictures from fragments when device is running.
If anybody wanna use "video" IMHO 320x200 8 bpp is limit.
Best regards
Vladimir
