2106 | ADC | ARM7 | Atmel | Bootloader | CAN | CrossStudio | CrossWorks | DDS | ECos | Ethernet | ETM | FIFO | FLASH | FPGA | GCC | GDB | GNU | GNUARM | GPIO | I2C | IAP | IAR | JTAG | Kickstart | LCD | Linux | LPC | LPC-E2294 | LPC2000 | LPC2100 | LPC2104 | Lpc2106 | Lpc210x | LPC2114 | LPC2119 | LPC2124 | LPC2129 | Lpc2138 | LPC213x | LPC21xx | LPC2210 | LPC2212 | LPC2214 | LPC2292 | LPC2294 | LPC2xxx | LPC3128 | MCB2100 | Olimex | Philips | PWM | Rowley | RTC | RTOS | SPI | SSP | UART | UART0 | UART1 | ULINK | USB | Watchdog | Wiggler

Hello.

Why is there no LPC2478 chip on the market in Europe? I usually order
from FarnellUK or RS Components and they have only 2468 chips.

Is there a problem with this chip? Thank you.
I can't buy 2468 cause it lacks LCD controller.
------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

On Thu, 25 Sep 2008 23:09:30 -0000, you wrote:

>Hello.=20
>
>Why is there no LPC2478 chip on the market in Europe? I usually order
>from FarnellUK or RS Components and they have only 2468 chips.=20
>
>Is there a problem with this chip? Thank you.=20
>I can't buy 2468 cause it lacks LCD controller.
>

Digikey stock it - free shipping to UK (not sure about rest of EU) for orde=
rs over =A350

>
>------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "madid87" wrote:
>
> Hello.
>
> Why is there no LPC2478 chip on the market in Europe? I usually order
> from FarnellUK or RS Components and they have only 2468 chips.
>
> Is there a problem with this chip? Thank you.
> I can't buy 2468 cause it lacks LCD controller.
>

The problem is that it is still in ramp up and Digikey has a track
record to provide small numbers of samples fast and easy. That is why
Digikey might get devices earlier!?

Bob
------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

madid87 wrote:
> Hello.
>
> Why is there no LPC2478 chip on the market in Europe? I usually order
> from FarnellUK or RS Components and they have only 2468 chips.
>
> Is there a problem with this chip? Thank you.
> I can't buy 2468 cause it lacks LCD controller.
>

Farnell and RS are always a bit behind stocking new devices.
It's freely available from most european distributors. Try EBV.

--
Tim Mitchell
------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Tim Mitchell" wrote:
> Farnell and RS are always a bit behind stocking new devices.
> It's freely available from most european distributors. Try EBV.

Thank you and the rest for you're answers.
I'm planing a big project with this chip and I need good availability
in the next few years. Hope that shouldn't be a problem (cause this is
top of the line with ARM7TDMI core) ?
------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

madid87 wrote:
> --- In l...@yahoogroups.com, "Tim Mitchell" wrote:
>> Farnell and RS are always a bit behind stocking new devices.
>> It's freely available from most european distributors. Try EBV.
>
> Thank you and the rest for you're answers.
> I'm planing a big project with this chip and I need good availability
> in the next few years. Hope that shouldn't be a problem (cause this
> is top of the line with ARM7TDMI core) ?

What size display are you driving, because there are some problems with
the display refresh if you need a fast pixel clock (>6MHz)

--
Tim Mitchell
------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Tim Mitchell" wrote:
> What size display are you driving, because there are some problems
> with the display refresh if you need a fast pixel clock (>6MHz)

Didn't think about that yet. Project is in planning phase.
But thanks for the info, I'll look into it before I pursue the chip(s).

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

> What size display are you driving, because there are some problems
with
> the display refresh if you need a fast pixel clock (>6MHz)
>
Hi Tim

What problems have you had with the faster pixel clock?

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

pakka19692000 wrote:
>> What size display are you driving, because there are some problems
>> with the display refresh if you need a fast pixel clock (>6MHz)
>>
> Hi Tim
>
> What problems have you had with the faster pixel clock?
>

Any memory transfer operations using the EMC (ie using external flash or
SDRAM) cause the display refresh to be interrupted. This causes
distortion or blanking of the display. There are several of us on this
list experiencing the problem, we believe it is due to blocking of a
memory bus within the processor. NXP have been "looking into it" for a
while.

If you search for the LPC2478 threads on this list over the last month
or so you can read all about it.

--
Tim Mitchell
------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Tim,

to let you (and the rest of the group) know the latest fact-finding
about LPC2478 and the pixel clock issue, let me resume:

Our current hardware runs a 10.2" TFT with 1024x600 pixel in 16 bit
mode. We use a SDRAM with 8 MByte and 16 bit bus and a 512 byte-paged
NAND flash with 32 MByte (works as a 8 bit device) on the same external bus.

As the pixel count is very high in our design, we would have to use
48 MHz pixel clock to run the TFT with about 60 Hz refresh rate.
Using 48 MHz pixel clock is not possible in any case with the given
hardware design (I'm not sure if it could be done even with 32 bit
SDRAM - imagine, the uC clock is only twice the pixel clock). Lucky
as I am, the TFT choosen does work with 30 Hz refresh rate as well
without any problems. This is very unusual, and I did not mention the
necessarity of running that low refresh rate when I decided to use
this specific TFT.

So basically everything is working without problems in our design
with a pixel of 24 MHz. The problems mentioned by Tim first regarding
the flickering issue come up when I do one of the following:

* Copying a chunk of data out of or into the SDRAM via memcpy() or via DMA
* Reading or writing data to/from the NAND flash via memcpy() or via DMA

If I do not use memcpy() or DMA when using the external bus, but copy
data via a simple "while()" loop, everything works well, but

while (*t++ = *s++)
;

is so much slower than using memcpy().

I have now made a (hopefully temporary) work-around by using memcpy()
with a maximum of 8 bytes (4 bytes only when copying from SDRAM to
SDRAM) in a loop as this is still faster than using the simple
while() loop. Getting data from the NAND flash is done in a loop with
10-bytes DMA copying per call. When doing so, I can avoid any flicker
effect, but the display works much slower (believe me, handling
1024x600 pixels is a lot of work for an ARM7) as it could be when
working without this work-around.

We will send a protoype of our board (including the TFT) to NXP this
week for further analysis; hopefully they can find a workaround for
the bus arbitration problem, which obviously exists in the current
design of the LPC2478 showing up especially at higher pixel clocks.

From my point of view I would not recommend to use a TFT with more
than 800x480 pixel (needing 24 MHz pixel clock as well) in any case.
Seeing "can control up to 1024x768 pixels display with 24 bit color"
in the user manual and data sheet (and in the advertising as well)
remindes me not to believe anything I've not tested by myself before.

Regards
Herbert

At 09:14 29.09.2008 +0100, you wrote:
>pakka19692000 wrote:
> >> What size display are you driving, because there are some problems
> >> with the display refresh if you need a fast pixel clock (>6MHz)
> >>
> >
> >
> > Hi Tim
> >
> > What problems have you had with the faster pixel clock?
> >Any memory transfer operations using the EMC (ie using external flash or
>SDRAM) cause the display refresh to be interrupted. This causes
>distortion or blanking of the display. There are several of us on this
>list experiencing the problem, we believe it is due to blocking of a
>memory bus within the processor. NXP have been "looking into it" for a
>while.
>
>If you search for the LPC2478 threads on this list over the last month
>or so you can read all about it.
>
>--
>Tim Mitchell
------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

My findings are the same as Herbert. We have a 480x272 pixel TFT in 16
bit mode. We are running the pixel clock at about 9MHz which is the
minimum without flicker. I have a 32MByte 32-bit SDRAM and 4MByte 16-bit
NOR flash on the external bus.

If I break up memory transfers from the SDRAM or flash into short
packets then the LCD controller gets chance to transfer the display data
from the buffer in between my transfers. But if I transfer a large block
using DMA or memcpy the display refresh is blocked and the screen will
corrupt or go blank. The problem gets noticeably worse if I increase the
pixel clock (ie I have to transfer in smaller packets to get round the
problem).

Herbert Demmel wrote:
> Tim,
>
> to let you (and the rest of the group) know the latest fact-finding
> about LPC2478 and the pixel clock issue, let me resume:
>
> Our current hardware runs a 10.2" TFT with 1024x600 pixel in 16 bit
> mode. We use a SDRAM with 8 MByte and 16 bit bus and a 512 byte-paged
> NAND flash with 32 MByte (works as a 8 bit device) on the same
> external bus.
>
> As the pixel count is very high in our design, we would have to use
> 48 MHz pixel clock to run the TFT with about 60 Hz refresh rate.
> Using 48 MHz pixel clock is not possible in any case with the given
> hardware design (I'm not sure if it could be done even with 32 bit
> SDRAM - imagine, the uC clock is only twice the pixel clock). Lucky
> as I am, the TFT choosen does work with 30 Hz refresh rate as well
> without any problems. This is very unusual, and I did not mention the
> necessarity of running that low refresh rate when I decided to use
> this specific TFT.
>
> So basically everything is working without problems in our design
> with a pixel of 24 MHz. The problems mentioned by Tim first regarding
> the flickering issue come up when I do one of the following:
>
> * Copying a chunk of data out of or into the SDRAM via memcpy() or
> via DMA
> * Reading or writing data to/from the NAND flash via memcpy() or via
> DMA
>
> If I do not use memcpy() or DMA when using the external bus, but copy
> data via a simple "while()" loop, everything works well, but
>
> while (*t++ = *s++)
> ;
>
> is so much slower than using memcpy().
>
> I have now made a (hopefully temporary) work-around by using memcpy()
> with a maximum of 8 bytes (4 bytes only when copying from SDRAM to
> SDRAM) in a loop as this is still faster than using the simple
> while() loop. Getting data from the NAND flash is done in a loop with
> 10-bytes DMA copying per call. When doing so, I can avoid any flicker
> effect, but the display works much slower (believe me, handling
> 1024x600 pixels is a lot of work for an ARM7) as it could be when
> working without this work-around.
>
> We will send a protoype of our board (including the TFT) to NXP this
> week for further analysis; hopefully they can find a workaround for
> the bus arbitration problem, which obviously exists in the current
> design of the LPC2478 showing up especially at higher pixel clocks.
>
> From my point of view I would not recommend to use a TFT with more
> than 800x480 pixel (needing 24 MHz pixel clock as well) in any case.
> Seeing "can control up to 1024x768 pixels display with 24 bit color"
> in the user manual and data sheet (and in the advertising as well)
> remindes me not to believe anything I've not tested by myself before.
>
> Regards
> Herbert
>
> At 09:14 29.09.2008 +0100, you wrote:
>> pakka19692000 wrote:
>>>> What size display are you driving, because there are some problems
>>>> with the display refresh if you need a fast pixel clock (>6MHz)
>>>>
>>>
>>>
>>> Hi Tim
>>>
>>> What problems have you had with the faster pixel clock?
>>> Any memory transfer operations using the EMC (ie using external
>> flash or SDRAM) cause the display refresh to be interrupted. This
>> causes distortion or blanking of the display. There are several of
>> us on this list experiencing the problem, we believe it is due to
>> blocking of a memory bus within the processor. NXP have been
>> "looking into it" for a while.
>>
>> If you search for the LPC2478 threads on this list over the last
>> month or so you can read all about it.
>>

--
Tim Mitchell
------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Tim Mitchell" wrote:
>
> My findings are the same as Herbert. We have a 480x272 pixel TFT in 16
> bit mode. We are running the pixel clock at about 9MHz which is the
> minimum without flicker. I have a 32MByte 32-bit SDRAM and 4MByte 16-bit
> NOR flash on the external bus.
>
> If I break up memory transfers from the SDRAM or flash into short
> packets then the LCD controller gets chance to transfer the display data
> from the buffer in between my transfers. But if I transfer a large block
> using DMA or memcpy the display refresh is blocked and the screen will
> corrupt or go blank. The problem gets noticeably worse if I increase the
> pixel clock (ie I have to transfer in smaller packets to get round the
> problem).
>
> Herbert Demmel wrote:
> > Tim,
> >
> > to let you (and the rest of the group) know the latest fact-finding
> > about LPC2478 and the pixel clock issue, let me resume:
> >
> > Our current hardware runs a 10.2" TFT with 1024x600 pixel in 16 bit
> > mode. We use a SDRAM with 8 MByte and 16 bit bus and a 512 byte-paged
> > NAND flash with 32 MByte (works as a 8 bit device) on the same
> > external bus.
> >
> > As the pixel count is very high in our design, we would have to use
> > 48 MHz pixel clock to run the TFT with about 60 Hz refresh rate.
> > Using 48 MHz pixel clock is not possible in any case with the given
> > hardware design (I'm not sure if it could be done even with 32 bit
> > SDRAM - imagine, the uC clock is only twice the pixel clock). Lucky
> > as I am, the TFT choosen does work with 30 Hz refresh rate as well
> > without any problems. This is very unusual, and I did not mention the
> > necessarity of running that low refresh rate when I decided to use
> > this specific TFT.
> >
> > So basically everything is working without problems in our design
> > with a pixel of 24 MHz. The problems mentioned by Tim first regarding
> > the flickering issue come up when I do one of the following:
> >
> > * Copying a chunk of data out of or into the SDRAM via memcpy() or
> > via DMA
> > * Reading or writing data to/from the NAND flash via memcpy() or via
> > DMA
> >
> > If I do not use memcpy() or DMA when using the external bus, but copy
> > data via a simple "while()" loop, everything works well, but
> >
> > while (*t++ = *s++)
> > ;
> >
> > is so much slower than using memcpy().
> >
> > I have now made a (hopefully temporary) work-around by using memcpy()
> > with a maximum of 8 bytes (4 bytes only when copying from SDRAM to
> > SDRAM) in a loop as this is still faster than using the simple
> > while() loop. Getting data from the NAND flash is done in a loop with
> > 10-bytes DMA copying per call. When doing so, I can avoid any flicker
> > effect, but the display works much slower (believe me, handling
> > 1024x600 pixels is a lot of work for an ARM7) as it could be when
> > working without this work-around.
> >
> > We will send a protoype of our board (including the TFT) to NXP this
> > week for further analysis; hopefully they can find a workaround for
> > the bus arbitration problem, which obviously exists in the current
> > design of the LPC2478 showing up especially at higher pixel clocks.
> >
> > From my point of view I would not recommend to use a TFT with more
> > than 800x480 pixel (needing 24 MHz pixel clock as well) in any case.
> > Seeing "can control up to 1024x768 pixels display with 24 bit color"
> > in the user manual and data sheet (and in the advertising as well)
> > remindes me not to believe anything I've not tested by myself before.
> >
> > Regards
> > Herbert
> >
> > At 09:14 29.09.2008 +0100, you wrote:
> >> pakka19692000 wrote:
> >>>> What size display are you driving, because there are some problems
> >>>> with the display refresh if you need a fast pixel clock (>6MHz)
> >>>>
> >>>
> >>>
> >>> Hi Tim
> >>>
> >>> What problems have you had with the faster pixel clock?
> >>>
> >>
> >> Any memory transfer operations using the EMC (ie using external
> >> flash or SDRAM) cause the display refresh to be interrupted. This
> >> causes distortion or blanking of the display. There are several of
> >> us on this list experiencing the problem, we believe it is due to
> >> blocking of a memory bus within the processor. NXP have been
> >> "looking into it" for a while.
> >>
> >> If you search for the LPC2478 threads on this list over the last
> >> month or so you can read all about it.
> >> --
> Tim Mitchell
>
Hi all,

We are a company that does a lot with graphics, particularly high
resolution 1024*768*80Hz etc and greater and for what its worth, we
considered many processors but found the best was the AVR32 series.
They do displays very nicely at high frame rates with high resolution.
I would totally recommend the AVR series if you have the option of
processor over the ARM for this application. We do also use ARM
processors for other things

Richard Robson

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

> We are a company that does a lot with graphics, particularly high
> resolution 1024*768*80Hz etc and greater and for what its worth, we
> considered many processors but found the best was the AVR32 series.
> They do displays very nicely at high frame rates with high
> resolution.
> I would totally recommend the AVR series if you have the option of
> processor over the ARM for this application. We do also use ARM
> processors for other things
>

I didn't think there was an AVR32 with a built in LCD controller?? But I
might have missed it.

--
Tim Mitchell
------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Tim,

> > We are a company that does a lot with graphics, particularly high
> > resolution 1024*768*80Hz etc and greater and for what its worth, we
> > considered many processors but found the best was the AVR32 series.
> > They do displays very nicely at high frame rates with high
> > resolution.
> > I would totally recommend the AVR series if you have the option of
> > processor over the ARM for this application. We do also use ARM
> > processors for other things
> > I didn't think there was an AVR32 with a built in LCD controller?? But I
> might have missed it.

AP7000, the first AVR32 before the UC3 chips.

http://www.atmel.com/products/AVR32/ap7/ap7_5.asp

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Paul Curtis wrote:
>>
>> I didn't think there was an AVR32 with a built in LCD controller??
>> But I might have missed it.
>
> AP7000, the first AVR32 before the UC3 chips.
>
> http://www.atmel.com/products/AVR32/ap7/ap7_5.asp
Yeah, I went and looked it up after I wrote that. We use the 8-bit AVR a
lot for other stuff so I should have known about it. But we have found
Atmel's support/sample software for the 8-bit AVR to be a bit awful, the
USB application they provide is mind bending. Is the example software
for the AVR32 any better?

--
Tim Mitchell
------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Hi Tim,

> Paul Curtis wrote:
> >>
> >> I didn't think there was an AVR32 with a built in LCD controller??
> >> But I might have missed it.
> >
> > AP7000, the first AVR32 before the UC3 chips.
> >
> > http://www.atmel.com/products/AVR32/ap7/ap7_5.asp
> Yeah, I went and looked it up after I wrote that. We use the 8-bit AVR a
> lot for other stuff so I should have known about it. But we have found
> Atmel's support/sample software for the 8-bit AVR to be a bit awful, the
> USB application they provide is mind bending. Is the example software
> for the AVR32 any better?

No idea. They run Linux on the AP7000. The UC3 is more
microcontroller-like.

Why continue to use 8-bit AVRs? I just wonder why people continue to choose
them (given their price and performance) and what the great fuss over XMEGA
devices is.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

Paul Curtis wrote:
> Hi Tim,
>
>> Paul Curtis wrote:
>>>>
>>>> I didn't think there was an AVR32 with a built in LCD controller??
>>>> But I might have missed it.
>>>
>>> AP7000, the first AVR32 before the UC3 chips.
>>>
>>> http://www.atmel.com/products/AVR32/ap7/ap7_5.asp
>> Yeah, I went and looked it up after I wrote that. We use the 8-bit
>> AVR a lot for other stuff so I should have known about it. But we
>> have found Atmel's support/sample software for the 8-bit AVR to be a
>> bit awful, the USB application they provide is mind bending. Is the
>> example software for the AVR32 any better?
>
> No idea. They run Linux on the AP7000. The UC3 is more
> microcontroller-like.
>
> Why continue to use 8-bit AVRs? I just wonder why people continue to
> choose them (given their price and performance) and what the great
> fuss over XMEGA devices is.

8-bit AVR is cost effective for simple medium to high volume
applications ... really cheap now and you can get a lot of peripherals
in there.

I can't work out what the fuss is over XMEGA either, they look the same
except you can run them faster as they have an internal PLL to speed up
the clock. They rather naughtily call them "8/16 bit" when they are
clearly 8 bit. I think the fuss is being entirely generated by Atmel's
marketing department rather than any end users.
--
Tim Mitchell
------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

--- In l...@yahoogroups.com, "Paul Curtis" wrote:
>
> Hi Tim,
>
> > Paul Curtis wrote:
> > >>
> > >> I didn't think there was an AVR32 with a built in LCD controller??
> > >> But I might have missed it.
> > >
> > > AP7000, the first AVR32 before the UC3 chips.
> > >
> > > http://www.atmel.com/products/AVR32/ap7/ap7_5.asp
> >
> >
> > Yeah, I went and looked it up after I wrote that. We use the 8-bit
AVR a
> > lot for other stuff so I should have known about it. But we have found
> > Atmel's support/sample software for the 8-bit AVR to be a bit
awful, the
> > USB application they provide is mind bending. Is the example software
> > for the AVR32 any better?
>
> No idea. They run Linux on the AP7000. The UC3 is more
> microcontroller-like.
>
> Why continue to use 8-bit AVRs? I just wonder why people continue
to choose
> them (given their price and performance) and what the great fuss
over XMEGA
> devices is.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
>

Hi

Well we have just developed an application using the AVR32 AP7000 and
a grasshopper board

http://shop.embedded-projects.net/product_info.php?language=en&info=p68_Grasshopper-AVR32--AP7000--Board.html&XTCsid=d5842dd79f5a449c7e9b4a76648fb501

For example, and use the IAR compiler (limited edition which is free).
The ICE is excellent and not very expensive and we roll our own code,
no LINUX etc. I think its one of the easiest chips I have ever
programmed, although we don't use the built in USB or networking.
Support can be got from AVRFREAKS.NET

Richard Robson

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

>Why continue to use 8-bit AVRs? I just wonder why people continue to choose
>them (given their price and performance) and what the great fuss over XMEGA
>devices is.

AVRs still offer great value for money, especially the Megax8 etc. It's a pretty good compiler
target as 8-bitters go, so you get most of the avaialble performance when using C - the megax8
series added self-programming, some useful addressing modes and a multiplier, putting it pretty high
up the 8-bit price/performance league.
Although a cursory comparison might suggest that something like a LPC2101 is competitive, by the
time you add voltage regs, eeprom etc. the AVR can often be significantly cheaper in terms of
system cost where you don't need the extra performance or peripherals.
Availability in DIL and 5V operation can still be useful advantages, not to mention internal
oscillators and good low power modes.
I've not yet looked at the XMEGAs - my guess is the prime mover for these is a die shrink & would
expect pricing to be good - I'll wait for them to be available before getting too excited though.
------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

I just have one more question about LCD controller problem.

What about executing program code from external FLASH? That is around
4bytes/Hz of data and I assume LCD would flicker ?

Thank you once again.

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

madid87 wrote:
> I just have one more question about LCD controller problem.
>
> What about executing program code from external FLASH? That is around
> 4bytes/Hz of data and I assume LCD would flicker ?
>

Look back on this list for details, someone called "hjiongh" has tried
this and found that the LCD picture does not appear at all when
executing from external FLASH.

--
Tim Mitchell
------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )

hi,

Yes, I was troubled of LPC2478 LCD controller , executed external

nor flash. Now i'm contacting NXP FAE and hope they can give me some

useful feedback from their HQ.

If i get anything useful , i will tell you .

Regards

Vincent(hjiongh)

--- In l...@yahoogroups.com, "Tim Mitchell" wrote:
>
> madid87 wrote:
> > I just have one more question about LCD controller problem.
> >
> > What about executing program code from external FLASH? That is
around
> > 4bytes/Hz of data and I assume LCD would flicker ?
> > Look back on this list for details, someone called "hjiongh" has tried
> this and found that the LCD picture does not appear at all when
> executing from external FLASH.
>
> --
> Tim Mitchell
>

------------------------------------



(You need to be a member of lpc2000 -- send a blank email to lpc2000-subscribe@yahoogroups.com )