USB OTG on ARM7 based MCU

This may seem like a dumb idea, but I just read where NXP has a Cortex M3 out with a USB OTG controller. You can use that chip as a controller and have it communicate by any of several interfaces that it supports. Although the binary may be different between the two CPUs, you can use the same tools.

Rick

Why not use a CPU with onboard ethernet, USB etc.?

On Mon, 29 Dec 2008 09:50:57 +0000, Mike Harrison

Because it should satisfy the following

- LCD Controller

- 32bit external BUS

- nonBGA package

LH79520 is the only chip on the market! There is NXP LPC2478 but it has no cache so LCD doesn't work when CPU is executing from external memory (picture disappears, not enough bandwidth). LH79520 runs on ARM720T core with cache and MMU so cache eliminates that problem.

Mad I.D. schrieb:

Maybe it's easier to go for an external LCD controller (Epson or Fujitsu) or to use an LCD with internal controller.

I know both devices fairly well, the 2478 and the 79520. You are correct that the 2478 does not have a cache, but it has a powerful DMA. If you can't get the job done with the 2478, I can not imagine you get it to work with the 79520, as the 2478 offers much better overall bandwith to memories. The cache does NOT eliminate your problem, unless you can execute ALL you code from cache and lock it down, which seems difficult with 8KB cache size. The 2478 offers much more SRAM, from which you execute same speed as directly from cache or the flash which offers more than 90% execution speed compared to cache/ SRAM execution. On the 79520, the cache needs to be filled from external memory as well, that can create strange effects to your picture too.

I don't know whether you really tried it with a 2478, it seems by far the best solution to your problem, unless you want to upgrade to an ARM9

Der Schwob

Thank you very much for your answer. I've spent few days gathering information about that particular controller and found this:

It is the only reason I switched my design to LH79520. Cause of that, right not I'm implementing Ethernet and USB OTG with external IC controllers :(

On Mon, 29 Dec 2008 21:30:14 +0100, Mad I.D. wrote: /cut

Ohh, there are new replays there. Now I'm not sure could it work with code executing only from external SDRAM ? LCD Frame buffer would be in SDRAM to. Thank you.

If yes, I just spent 3 weeks with the wrong chip... (I'm a student working alone on this)

Sorry for 3 posts. Plus for LH79520 is a better core (720T with cache

• MMU). With MMU present it is much easyer to drive a (better) RTOS.

I was just about to suggest this (without knowing whether it actually helps on that micro).

It is usual in systems with SDRAM to copy the program into it during startup. SDRAM is usually faster than flash, with a wider bus, and is very cheap.

So it could be that they can get away with poor performance when executing from flash, since perhaps normally that would only be during startup.

The 79520 is actually quite old now, for a chip of this type. I started using it ~7 years ago. Its still a pretty useful device but I would look very hard at the alternatives now becoming available. Especially if they come with the other peripherals built-in.

Mad I.D. schrieb:

Well, look here:

What display do you use?

General idea with LH79520 is to use SD card as a "hard drive" for program storage. Startup code would sit in FLASH and fill SDRAM with program code and then remap controller to start executing from SDRAM. My biggest concern right now is could LPC2478 drive a decant TFT display with 60Hz refresh rate without flicker? I can't assume a thing and lose time and money in the future.

Believe me, LH79520 is THE ONLY AVAILABLE controller on the market with needed features in nonBGA (double layer PCB limited) package. I spent days doing research for suitable IC.

On Mon, 29 Dec 2008 22:38:35 +0100, Frank-Christian Krügel

Depending on the budget (there will be about 10 systems produced) it will be a TFT display with resolution somewhere about 320x240 to

That's the reason I commented - it was the only one 7 years ago too :)

But I still went for a 4 layer board. I think it will be difficult routing a 32 bit bus system on 2 layers and maintain signal integrity. You really need a ground plane too, which does not leave many layers for routing the address/data bus :)

If you know exactly what you are doing, maybe it can be done. But for more than one device on the bus (external peripherals) it could be impossible.

The LPC2478 is available in QFP - I would try really hard to make it work in your application before giving up on it. With just the SDRAM as the external bussed device perhaps you can make it work on 2 layers.

On Mon, 29 Dec 2008 22:44:02 +0000, John Devereux

Of course, but I have to be absolutely sure that executing from SDRAM will not block or flicker the LCD (at least 320x240 TFT). Don't know what to do now, maybe contact NXP support...

It has to be done on a 2 layer PCB mostly because of the cost.

Mad I.D. schrieb:

If you can live with a display size of max 3.2" you really should look for displays with integrated controller, eg Himax HX8346 or Ilitek ILI9325. These displays don't need a controller at all, 8 or 16 bit data bus, /cs, /rd, /wr, rs (register select) and reset is enough. It's just as simple as driving a character display.

Such displays are manufactured by Ampire, LG, Arima, ...

Places to start are

"Gloucestershire Physical Exercise & Gyms" ? :)

That's funny; I live there (the county, not the gym unfortunately)!

(Looks like the right link is , looks useful.)

I was brought up in Gloucestershire (Forest of Dean). My mother and two sisters still live there. Beautiful countryside relative to the flat East Anglia of my current abode.

Back on topic I fount that the bandwidth requirement for 640x480 TFTs was too close to the liit while 320x240 wa no problem. In between there is

Peter

On Tue, 30 Dec 2008 11:00:00 -0000, "Peter Dickerson"

Sorry, what chip are U referring to? LPC24XX or LH795XX ? If LPC, can you confirm that when executing from external x32 SDRAM driving a 320x240 TFT is not an issue ?