EmbeddedRelated.com
Forums
The 2024 Embedded Online Conference

USB OTG on ARM7 based MCU

Started by Mad I.D. December 28, 2008
Hello all.

I'm designing a system running on (ex Sharp) LH79520 NXP MCU with
ARM720T core. I'm currently adding USB OTG function but there is
something bothering me. By now, my system already has x32 SDRAM and
x16 FLASH memory. I've done a lot of research about OTG controllers
available on the market and picked NXP ISP1362 "Single-chip Universal
Serial Bus On-The-Go Controller". It's a memory mapped device (asks
for connection to x16 data bus already common to FLASH and SDRAM). In
the next few days I must add an additional Ethernet controller which
will probably also be a mapped device. All that has to go on double
layer PCB. 

My question is: Is there any USB OTG controller IC (with transceiver)
but with SPI interface? I'm afraid I will not be able to route my PCB
with SDRAM, FLASH, USB and Ethernet all connected as memory mapped
devices.

Thank you !
On Dec 28, 2:42=A0pm, Mad I.D. <madi...@MOOOOVEyahoo.com> wrote:
> Hello all. > > I'm designing a system running on (ex Sharp) LH79520 NXP MCU with > ARM720T core. I'm currently adding USB OTG function but there is > something bothering me. By now, my system already has x32 SDRAM and > x16 FLASH memory. I've done a lot of research about OTG controllers > available on the market and picked NXP ISP1362 "Single-chip Universal > Serial Bus On-The-Go Controller". It's a memory mapped device (asks > for connection to x16 data bus already common to FLASH and SDRAM). In > the next few days I must add an additional Ethernet controller which > will probably also be a mapped device. All that has to go on double > layer PCB. > > My question is: Is there any USB OTG controller IC (with transceiver) > but with SPI interface? I'm afraid I will not be able to route my PCB > with SDRAM, FLASH, USB and Ethernet all connected as memory mapped > devices.
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
On Sun, 28 Dec 2008 14:25:19 -0800 (PST), rickman <gnuarm@gmail.com> wrote:

>On Dec 28, 2:42&#4294967295;pm, Mad I.D. <madi...@MOOOOVEyahoo.com> wrote: >> Hello all. >> >> I'm designing a system running on (ex Sharp) LH79520 NXP MCU with >> ARM720T core. I'm currently adding USB OTG function but there is >> something bothering me. By now, my system already has x32 SDRAM and >> x16 FLASH memory. I've done a lot of research about OTG controllers >> available on the market and picked NXP ISP1362 "Single-chip Universal >> Serial Bus On-The-Go Controller". It's a memory mapped device (asks >> for connection to x16 data bus already common to FLASH and SDRAM). In >> the next few days I must add an additional Ethernet controller which >> will probably also be a mapped device. All that has to go on double >> layer PCB. >> >> My question is: Is there any USB OTG controller IC (with transceiver) >> but with SPI interface? I'm afraid I will not be able to route my PCB >> with SDRAM, FLASH, USB and Ethernet all connected as memory mapped >> devices. > >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 
>Why not use a CPU with onboard ethernet, USB etc.?
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:
> On Mon, 29 Dec 2008 09:50:57 +0000, Mike Harrison >> Why not use a CPU with onboard ethernet, USB etc.? > > 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.
Maybe it's easier to go for an external LCD controller (Epson or Fujitsu) or to use an LCD with internal controller. -- Mit freundlichen Gr&#4294967295;&#4294967295;en Dipl.-Ing. Frank-Christian Kr&#4294967295;gel
On Dec 29, 3:43=A0am, Mad I.D. <madi...@MOOOOVEyahoo.com> wrote:
> On Mon, 29 Dec 2008 09:50:57 +0000, Mike Harrison > > >Why not use a CPU with onboard ethernet, USB etc.? > > 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.
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
On Mon, 29 Dec 2008 11:51:15 -0800 (PST), An Schwob in the USA
<schwobus@aol.com> wrote:
>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
Thank you very much for your answer. I've spent few days gathering information about that particular controller and found this: http://tech.groups.yahoo.com/group/lpc2000/message/35811 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.
<madid87@MOOOOVEyahoo.com> 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)
On Mon, 29 Dec 2008 21:37:21 +0100, Mad I.D.
<madid87@MOOOOVEyahoo.com> wrote:

>On Mon, 29 Dec 2008 21:30:14 +0100, Mad I.D. ><madid87@MOOOOVEyahoo.com> 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.
Mad I.D. <madid87@MOOOOVEyahoo.com> writes:

> On Mon, 29 Dec 2008 21:30:14 +0100, Mad I.D. > <madid87@MOOOOVEyahoo.com> 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.
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.
> If yes, I just spent 3 weeks with the wrong chip... (I'm a student > working alone on this)
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. -- John Devereux

The 2024 Embedded Online Conference