I was looking at the '2470 for use with a 320x240 STN display. There
was some earlier discussion suggesting the '2470/'2478 may not be
the
best choice for LCD projects. I gather this is because it has no
dedicated frame buffer like other LCD controllers, and must constantly
refresh the screen from general purpose data memories, loading the
processor.
I sure don't want to lose half my processor bandwidth just to support
the LCD. What's the story?
LCD on LPC2470
Started by ●October 21, 2008
Reply by ●October 21, 20082008-10-21
Hi,
to avoid that there are coming up myths (no, I do not work for NXP, I
just think the discussion is going into the wrong direction) about
the LPC2478 let me summarize:
1) Executing out of the internal flash is always done with 100% speed.
2) There is a bandwidth calculator on the NXP website for estimating
what you have to expect:
http://www.standardics.nxp.com/support/documents/microcontrollers/xls/lpc247x.lcd.bus.load.calculator.xls
3) When driving a 320x240 STN display, the LPC247x could sleep most
of the time, you don't need much data traffic for the refreshing.
4) We originally where speaking about much higher data rates: We now
successfully run a 1024x600 pixel TFT with 16 bit colors out of a 16
bit (!) SDRAM with a pixel clock of 24 MHz, so we move 48 MBytes of
data every second (keep in mind, that the LPC2478 is running at 72
MHz !!!) without any speed impact when executing from internal flash or RAM.
5) The issue has been the higher pixel clock only in our case:
Accessing the bus is normally done via round-robin, with a little
help from our NXP friends ;-) we've now changed the bus arbitration
of the internal AHB-bus to priority based, which solves all problems for us.
6) I'm sorry if there was the impression, that the LPC2478 is a bad
thing: We're very satisfied in the meantime, we had very competent
help from NXP support.
7) Our contact person at NXP announced that there will be a technical
note with all the things you have to take care of when using the
LPC2478, until then, you should simply consider what you want to do,
it's not soooo simple like "give me the circuit for LPC display xyz,
I want to have my new application ready to use without knowing what I do".
That's the story ;-) (from my point of view)
Herbert
At 22:42 20.10.2008 +0000, you wrote:
>I was looking at the '2470 for use with a 320x240 STN display. There
>was some earlier discussion suggesting the '2470/'2478 may not be the
>best choice for LCD projects. I gather this is because it has no
>dedicated frame buffer like other LCD controllers, and must constantly
>refresh the screen from general purpose data memories, loading the
>processor.
>
>I sure don't want to lose half my processor bandwidth just to support
>the LCD. What's the story?
to avoid that there are coming up myths (no, I do not work for NXP, I
just think the discussion is going into the wrong direction) about
the LPC2478 let me summarize:
1) Executing out of the internal flash is always done with 100% speed.
2) There is a bandwidth calculator on the NXP website for estimating
what you have to expect:
http://www.standardics.nxp.com/support/documents/microcontrollers/xls/lpc247x.lcd.bus.load.calculator.xls
3) When driving a 320x240 STN display, the LPC247x could sleep most
of the time, you don't need much data traffic for the refreshing.
4) We originally where speaking about much higher data rates: We now
successfully run a 1024x600 pixel TFT with 16 bit colors out of a 16
bit (!) SDRAM with a pixel clock of 24 MHz, so we move 48 MBytes of
data every second (keep in mind, that the LPC2478 is running at 72
MHz !!!) without any speed impact when executing from internal flash or RAM.
5) The issue has been the higher pixel clock only in our case:
Accessing the bus is normally done via round-robin, with a little
help from our NXP friends ;-) we've now changed the bus arbitration
of the internal AHB-bus to priority based, which solves all problems for us.
6) I'm sorry if there was the impression, that the LPC2478 is a bad
thing: We're very satisfied in the meantime, we had very competent
help from NXP support.
7) Our contact person at NXP announced that there will be a technical
note with all the things you have to take care of when using the
LPC2478, until then, you should simply consider what you want to do,
it's not soooo simple like "give me the circuit for LPC display xyz,
I want to have my new application ready to use without knowing what I do".
That's the story ;-) (from my point of view)
Herbert
At 22:42 20.10.2008 +0000, you wrote:
>I was looking at the '2470 for use with a 320x240 STN display. There
>was some earlier discussion suggesting the '2470/'2478 may not be the
>best choice for LCD projects. I gather this is because it has no
>dedicated frame buffer like other LCD controllers, and must constantly
>refresh the screen from general purpose data memories, loading the
>processor.
>
>I sure don't want to lose half my processor bandwidth just to support
>the LCD. What's the story?
Reply by ●October 21, 20082008-10-21
I'd just like to add to what Herbert said - our problem with LPC2478 LCD
controller is also fixed thanks to NXP tech support. And I take back the
things I said about NXP support - it turns out they hadn't forgotten us,
it just took them a while to come up with a fix.
Now this issue is fixed, I would recommend LPC2470/2478 as a really good
low part count solution for a device with a TFT. The display controller
is very fast too, because it runs off the processor's SDRAM you don't
have to copy graphics data over to a controller chip all the time.
I will post the fix here for everyone's info in a couple of days when
NXP have identifed the best way of setting up the bus (there are a few
possibilities at the moment). It's just a write to the AHBCFG1 register.
I presume it will go into the next errata sheet.
--
Tim Mitchell
controller is also fixed thanks to NXP tech support. And I take back the
things I said about NXP support - it turns out they hadn't forgotten us,
it just took them a while to come up with a fix.
Now this issue is fixed, I would recommend LPC2470/2478 as a really good
low part count solution for a device with a TFT. The display controller
is very fast too, because it runs off the processor's SDRAM you don't
have to copy graphics data over to a controller chip all the time.
I will post the fix here for everyone's info in a couple of days when
NXP have identifed the best way of setting up the bus (there are a few
possibilities at the moment). It's just a write to the AHBCFG1 register.
I presume it will go into the next errata sheet.
--
Tim Mitchell
Reply by ●October 22, 20082008-10-22
--- In l..., Herbert Demmel wrote:
>
> Hi,
>
> to avoid that there are coming up myths (no, I do not work for NXP, I
> just think the discussion is going into the wrong direction) about
> the LPC2478 let me summarize:
>
> 1) Executing out of the internal flash is always done with 100% speed.
>
> 2) There is a bandwidth calculator on the NXP website for estimating
> what you have to expect:
>
http://www.standardics.nxp.com/support/documents/microcontrollers/xls/lpc247x.lcd.bus.load.calculator.xls
>
> 3) When driving a 320x240 STN display, the LPC247x could sleep most
> of the time, you don't need much data traffic for the refreshing.
>
> 4) We originally where speaking about much higher data rates: We now
> successfully run a 1024x600 pixel TFT with 16 bit colors out of a 16
> bit (!) SDRAM with a pixel clock of 24 MHz, so we move 48 MBytes of
> data every second (keep in mind, that the LPC2478 is running at 72
> MHz !!!) without any speed impact when executing from internal flash
or RAM.
>
> 5) The issue has been the higher pixel clock only in our case:
> Accessing the bus is normally done via round-robin, with a little
> help from our NXP friends ;-) we've now changed the bus arbitration
> of the internal AHB-bus to priority based, which solves all problems
for us.
>
> 6) I'm sorry if there was the impression, that the LPC2478 is a bad
> thing: We're very satisfied in the meantime, we had very competent
> help from NXP support.
>
> 7) Our contact person at NXP announced that there will be a technical
> note with all the things you have to take care of when using the
> LPC2478, until then, you should simply consider what you want to do,
> it's not soooo simple like "give me the circuit for LPC display xyz,
> I want to have my new application ready to use without knowing what
I do".
>
> That's the story ;-) (from my point of view)
> Herbert
Thanks for the info. Your numbers suggest that 30% of your SDRAM BW is
LCD data. Since you have the '2478, your code fetches are not a factor
here.
I won't be using the '2478 since that fast flash is just too small.
Using the LCD BW calculator with what looks like a typical external
memory setup (70ns, 16bit, 5wait) the BW load is around 4% which is
probably fine even with the code there too.
>
> Hi,
>
> to avoid that there are coming up myths (no, I do not work for NXP, I
> just think the discussion is going into the wrong direction) about
> the LPC2478 let me summarize:
>
> 1) Executing out of the internal flash is always done with 100% speed.
>
> 2) There is a bandwidth calculator on the NXP website for estimating
> what you have to expect:
>
http://www.standardics.nxp.com/support/documents/microcontrollers/xls/lpc247x.lcd.bus.load.calculator.xls
>
> 3) When driving a 320x240 STN display, the LPC247x could sleep most
> of the time, you don't need much data traffic for the refreshing.
>
> 4) We originally where speaking about much higher data rates: We now
> successfully run a 1024x600 pixel TFT with 16 bit colors out of a 16
> bit (!) SDRAM with a pixel clock of 24 MHz, so we move 48 MBytes of
> data every second (keep in mind, that the LPC2478 is running at 72
> MHz !!!) without any speed impact when executing from internal flash
or RAM.
>
> 5) The issue has been the higher pixel clock only in our case:
> Accessing the bus is normally done via round-robin, with a little
> help from our NXP friends ;-) we've now changed the bus arbitration
> of the internal AHB-bus to priority based, which solves all problems
for us.
>
> 6) I'm sorry if there was the impression, that the LPC2478 is a bad
> thing: We're very satisfied in the meantime, we had very competent
> help from NXP support.
>
> 7) Our contact person at NXP announced that there will be a technical
> note with all the things you have to take care of when using the
> LPC2478, until then, you should simply consider what you want to do,
> it's not soooo simple like "give me the circuit for LPC display xyz,
> I want to have my new application ready to use without knowing what
I do".
>
> That's the story ;-) (from my point of view)
> Herbert
Thanks for the info. Your numbers suggest that 30% of your SDRAM BW is
LCD data. Since you have the '2478, your code fetches are not a factor
here.
I won't be using the '2478 since that fast flash is just too small.
Using the LCD BW calculator with what looks like a typical external
memory setup (70ns, 16bit, 5wait) the BW load is around 4% which is
probably fine even with the code there too.
Reply by ●November 4, 20082008-11-04
--- In l..., "Tim Mitchell" wrote:
>
> I'd just like to add to what Herbert said - our problem with LPC2478 LCD
> controller is also fixed thanks to NXP tech support. And I take back the
> things I said about NXP support - it turns out they hadn't forgotten us,
> it just took them a while to come up with a fix.
>
> Now this issue is fixed, I would recommend LPC2470/2478 as a really good
> low part count solution for a device with a TFT. The display controller
> is very fast too, because it runs off the processor's SDRAM you don't
> have to copy graphics data over to a controller chip all the time.
>
> I will post the fix here for everyone's info in a couple of days when
> NXP have identifed the best way of setting up the bus (there are a few
> possibilities at the moment). It's just a write to the AHBCFG1 register.
> I presume it will go into the next errata sheet.
> --
> Tim Mitchell
>
Did this info ever show up?
>
> I'd just like to add to what Herbert said - our problem with LPC2478 LCD
> controller is also fixed thanks to NXP tech support. And I take back the
> things I said about NXP support - it turns out they hadn't forgotten us,
> it just took them a while to come up with a fix.
>
> Now this issue is fixed, I would recommend LPC2470/2478 as a really good
> low part count solution for a device with a TFT. The display controller
> is very fast too, because it runs off the processor's SDRAM you don't
> have to copy graphics data over to a controller chip all the time.
>
> I will post the fix here for everyone's info in a couple of days when
> NXP have identifed the best way of setting up the bus (there are a few
> possibilities at the moment). It's just a write to the AHBCFG1 register.
> I presume it will go into the next errata sheet.
> --
> Tim Mitchell
>
Did this info ever show up?
Reply by ●November 5, 20082008-11-05
----Original Message----
From: l...
[mailto:l...] On Behalf Of tclarke1
Sent: 04 November 2008 17:40 To: l...
Subject: [lpc2000] Re: LCD on LPC2470
> --- In l..., "Tim Mitchell"
> wrote:
> >
> > I will post the fix here for everyone's info in a
> > couple of days when
> > NXP have identifed the best way of setting up the bus
> > (there are a few possibilities at the moment). It's
> > just a write to the AHBCFG1 register.
> > I presume it will go into the next errata sheet.
> > Did this info ever show up?
>
There are two possible settings, NXP were going to confirm which one
worked best, so I was waiting for this info before posting. However it
seems to be taking a while, so...
Here's the information:
First you need to define the undocumented AHBCFG1 reg, if your device h
file does not have it in (Crossworks does)
#define AHBCFG1 (*(volatile unsigned long *)0xE01FC188)
On boot check that AHBCFG1==0x00000145 (the default value)
The first value to try is AHBCFG1=0x12340144;
If there is a lot of DMA transfer, this might work better:
AHBCFG1=0x10000144;
This changes the AHB1 bus priority from "round robin" to giving highest
priority to the LCD controller.
--
Tim Mitchell
From: l...
[mailto:l...] On Behalf Of tclarke1
Sent: 04 November 2008 17:40 To: l...
Subject: [lpc2000] Re: LCD on LPC2470
> --- In l..., "Tim Mitchell"
> wrote:
> >
> > I will post the fix here for everyone's info in a
> > couple of days when
> > NXP have identifed the best way of setting up the bus
> > (there are a few possibilities at the moment). It's
> > just a write to the AHBCFG1 register.
> > I presume it will go into the next errata sheet.
> > Did this info ever show up?
>
There are two possible settings, NXP were going to confirm which one
worked best, so I was waiting for this info before posting. However it
seems to be taking a while, so...
Here's the information:
First you need to define the undocumented AHBCFG1 reg, if your device h
file does not have it in (Crossworks does)
#define AHBCFG1 (*(volatile unsigned long *)0xE01FC188)
On boot check that AHBCFG1==0x00000145 (the default value)
The first value to try is AHBCFG1=0x12340144;
If there is a lot of DMA transfer, this might work better:
AHBCFG1=0x10000144;
This changes the AHB1 bus priority from "round robin" to giving highest
priority to the LCD controller.
--
Tim Mitchell
Reply by ●November 5, 20082008-11-05
--- In l..., "Tim Mitchell" wrote:
>
> ----Original Message----
> From: l...
> [mailto:l...] On Behalf Of tclarke1
> Sent: 04 November 2008 17:40 To: l...
> Subject: [lpc2000] Re: LCD on LPC2470
>
> > --- In l..., "Tim Mitchell"
> > wrote:
> > >
> > > I will post the fix here for everyone's info in a
> > > couple of days when
> > > NXP have identifed the best way of setting up the bus
> > > (there are a few possibilities at the moment). It's
> > > just a write to the AHBCFG1 register.
> > > I presume it will go into the next errata sheet.
> > >
> >
> > Did this info ever show up?
> > There are two possible settings, NXP were going to confirm which one
> worked best, so I was waiting for this info before posting. However it
> seems to be taking a while, so...
> Here's the information:
>
> First you need to define the undocumented AHBCFG1 reg, if your device h
> file does not have it in (Crossworks does)
>
> #define AHBCFG1 (*(volatile unsigned long *)0xE01FC188)
>
> On boot check that AHBCFG1==0x00000145 (the default value)
>
> The first value to try is AHBCFG1=0x12340144;
>
> If there is a lot of DMA transfer, this might work better:
> AHBCFG1=0x10000144;
> This changes the AHB1 bus priority from "round robin" to giving highest
> priority to the LCD controller.
>
> --
> Tim Mitchell
>
The register defines posted earlier suggest some kind of weighted
interleaving may be possible, but that is just a guess.
How about it NXP? I think we need some details about how this bus
priority scheme works and how much fine-tuning can be done. If we
actually have control over how many cycles are dedicated to the LCD,
that would be good to know.
>
> ----Original Message----
> From: l...
> [mailto:l...] On Behalf Of tclarke1
> Sent: 04 November 2008 17:40 To: l...
> Subject: [lpc2000] Re: LCD on LPC2470
>
> > --- In l..., "Tim Mitchell"
> > wrote:
> > >
> > > I will post the fix here for everyone's info in a
> > > couple of days when
> > > NXP have identifed the best way of setting up the bus
> > > (there are a few possibilities at the moment). It's
> > > just a write to the AHBCFG1 register.
> > > I presume it will go into the next errata sheet.
> > >
> >
> > Did this info ever show up?
> > There are two possible settings, NXP were going to confirm which one
> worked best, so I was waiting for this info before posting. However it
> seems to be taking a while, so...
> Here's the information:
>
> First you need to define the undocumented AHBCFG1 reg, if your device h
> file does not have it in (Crossworks does)
>
> #define AHBCFG1 (*(volatile unsigned long *)0xE01FC188)
>
> On boot check that AHBCFG1==0x00000145 (the default value)
>
> The first value to try is AHBCFG1=0x12340144;
>
> If there is a lot of DMA transfer, this might work better:
> AHBCFG1=0x10000144;
> This changes the AHB1 bus priority from "round robin" to giving highest
> priority to the LCD controller.
>
> --
> Tim Mitchell
>
The register defines posted earlier suggest some kind of weighted
interleaving may be possible, but that is just a guess.
How about it NXP? I think we need some details about how this bus
priority scheme works and how much fine-tuning can be done. If we
actually have control over how many cycles are dedicated to the LCD,
that would be good to know.
