Sounds like you have things figured out quite well. Good luck!
--- In l..., "stangelanda" wrote: >
> The video data will come through ethernet. So if we go to an external
processor--which I think we will--it needs to have ethernet. It wouldn't
seem worth it to add another processor and still have to pipe all the
information through the first processor.
>
> I'm currently leaning toward the 500MHz TI TMS320DM6433. TI has software
codecs available for it, and it has everything we would need for about $15. The
total board cost will be considerably higher than $15 after a PHY, DDR memory,
oscillators/crystals, etc. But it has 10/100 Ethernet, LCD controller, hardware
resizing, and on-screen overlay. The only ARM9s that I found that came close
were over $30.
>
> NXP's ARM9s and ARM7s have an amazing set of peripherals, and we make
full use of them on our current board. But I think for this new design a
specialized processor probably makes more sense.
The video data will come through ethernet. So if we go to an external
processor--which I think we will--it needs to have ethernet. It wouldn't
seem worth it to add another processor and still have to pipe all the
information through the first processor.
I'm currently leaning toward the 500MHz TI TMS320DM6433. TI has software
codecs available for it, and it has everything we would need for about $15. The
total board cost will be considerably higher than $15 after a PHY, DDR memory,
oscillators/crystals, etc. But it has 10/100 Ethernet, LCD controller, hardware
resizing, and on-screen overlay. The only ARM9s that I found that came close
were over $30.
NXP's ARM9s and ARM7s have an amazing set of peripherals, and we make full
use of them on our current board. But I think for this new design a specialized
processor probably makes more sense.
--- In l..., "abrpbay12" wrote: >
> Ahhh... a vga LCD display... understood. Definitely, I can understand your
issue here trying to decide whether or not to use a separate, additional
processor just for the display (like the computers use now) or get a fast
processor to handle both the display and the application program.
>
> Kind of difficult to say as there are a lot of variables involved. I mean, as
you undoubtedly know, computers having dedicated video cards with 500MHz
processors is now common. From what you have said though, I doubt your video
demands would be that high but that still leaves quite an open field.
>
> I assume you are in the design stage now... I would definitely consider using
an ARM9 with an LCD controller such as the LH7A404 for example. It seems to be
designed for it. You might want to consider writing some sample code for such a
device and try it in a simulator to get an idea of the execution speed to see if
it will meet your demands before you commit yourself to a hardware design.
>
> --- In l..., "stangelanda" wrote:
> >
> > The larger displays like VGA or even just quarter-VGA have far more pixels
to be updated. Even to update the whole display fairly slowly you have to
stream the data very quickly.
> >
> > We're trying to decide if we want to do any processing on the data. If
so we may have to add a faster TI DSP or something to handle the LCD. However
if we decide not to do any processing the EMC might be fast enough on some of
the ARM9 chips with a faster system clock.
>
Reply by abrpbay12●October 1, 20092009-10-01
Ahhh... a vga LCD display... understood. Definitely, I can understand your issue
here trying to decide whether or not to use a separate, additional processor
just for the display (like the computers use now) or get a fast processor to
handle both the display and the application program.
Kind of difficult to say as there are a lot of variables involved. I mean, as
you undoubtedly know, computers having dedicated video cards with 500MHz
processors is now common. From what you have said though, I doubt your video
demands would be that high but that still leaves quite an open field.
I assume you are in the design stage now... I would definitely consider using an
ARM9 with an LCD controller such as the LH7A404 for example. It seems to be
designed for it. You might want to consider writing some sample code for such a
device and try it in a simulator to get an idea of the execution speed to see if
it will meet your demands before you commit yourself to a hardware design.
--- In l..., "stangelanda" wrote: >
> The larger displays like VGA or even just quarter-VGA have far more pixels to
be updated. Even to update the whole display fairly slowly you have to stream
the data very quickly.
>
> We're trying to decide if we want to do any processing on the data. If
so we may have to add a faster TI DSP or something to handle the LCD. However
if we decide not to do any processing the EMC might be fast enough on some of
the ARM9 chips with a faster system clock.
>
Reply by stangelanda●September 30, 20092009-09-30
The larger displays like VGA or even just quarter-VGA have far more pixels to be
updated. Even to update the whole display fairly slowly you have to stream the
data very quickly.
We're trying to decide if we want to do any processing on the data. If so
we may have to add a faster TI DSP or something to handle the LCD. However if
we decide not to do any processing the EMC might be fast enough on some of the
ARM9 chips with a faster system clock.
--- In l..., "abrpbay12" wrote: >
> I have read over your question various times and I am a little puzzled why you
would want to communicate with an LCD at 25MHz or do you mean you just want to
communicate with an LCD and the frequency of your microcontroller is running at
25MHz? I am a little puzzled because LCDs are typically slow devices. Very fast
changes on the LCD will not be distinguishable with the human eye.
>
> Also information on the LCD display would help. Obviously, timing constraints
of the LCD display have to be respected.
>
> I have used a LPC2103 to control a 2x20 LCD display with no problem using the
fast GPIO and if I remember correctly, the PCLK of the LPC2103 is running at
60MHz. A total of 11 signals/pins on the LPC were used: 8 for the data, one for
the LCD enable, one for the register select, and one for the R/W signal.
>
> I suspect that DMA could be used, but is the available time of your LPC2368 to
work with the LCD that tight? I mean updating an LCD doesn't take much time
at all, even if you are doing it 4 or 5 times a second. The overhead is very
small.
>
> --- In l..., "stangelanda" wrote:
> >
> > I want to communicate with an LCD using an 8bit parallel interface with a
clock speed of around 25MHz. I'm currently using the LPC2368 which
doesn't have an LCD controller.
> >
> > I'm wondering if I can use the GPDMA to continuously write values to a
GPIO register. It would output on 9 pins, the 8bits of data and an alternating
clock signal. I don't know a lot about how DMA works. But I was hoping
someone would know if this was possible, and how fast the DMA transfers data.
Could it change the GPIO register on every CPU clock transition?
> >
> > Another solution would be to try to use the EMC controller. It is 8bits
wide, so if you ignore all of the addressing pins and just write to the same RAM
location each time you should be able to clock out 8bits of parallel data. Does
anyone know if the EMC could be configured for this simple operation, or how
fast the EMC can operate?
> >
> > There is also the question of where the data would come from. Right now
I'm just acting like the data is in RAM to determine if it would even be
possible to output it.
> >
> > We've considered switching to a different part like an LPC24xx or an
ARM9 that has a built-in LCD controller peripheral, but we want to stay away
from BGA packages for the added assembly cost. Also we need an 100Mbps Ethernet
connection, which as far as I can tell pretty much requires a built-in MAC. If
someone knows of a way to handle 100Mbps Ethernet data through SPI or some other
means, I would also be very interested to hear about that.
>
Reply by abrpbay12●September 27, 20092009-09-27
I have read over your question various times and I am a little puzzled why you
would want to communicate with an LCD at 25MHz or do you mean you just want to
communicate with an LCD and the frequency of your microcontroller is running at
25MHz? I am a little puzzled because LCDs are typically slow devices. Very fast
changes on the LCD will not be distinguishable with the human eye.
Also information on the LCD display would help. Obviously, timing constraints of
the LCD display have to be respected.
I have used a LPC2103 to control a 2x20 LCD display with no problem using the
fast GPIO and if I remember correctly, the PCLK of the LPC2103 is running at
60MHz. A total of 11 signals/pins on the LPC were used: 8 for the data, one for
the LCD enable, one for the register select, and one for the R/W signal.
I suspect that DMA could be used, but is the available time of your LPC2368 to
work with the LCD that tight? I mean updating an LCD doesn't take much time
at all, even if you are doing it 4 or 5 times a second. The overhead is very
small.
--- In l..., "stangelanda" wrote: >
> I want to communicate with an LCD using an 8bit parallel interface with a
clock speed of around 25MHz. I'm currently using the LPC2368 which
doesn't have an LCD controller.
>
> I'm wondering if I can use the GPDMA to continuously write values to a
GPIO register. It would output on 9 pins, the 8bits of data and an alternating
clock signal. I don't know a lot about how DMA works. But I was hoping
someone would know if this was possible, and how fast the DMA transfers data.
Could it change the GPIO register on every CPU clock transition?
>
> Another solution would be to try to use the EMC controller. It is 8bits wide,
so if you ignore all of the addressing pins and just write to the same RAM
location each time you should be able to clock out 8bits of parallel data. Does
anyone know if the EMC could be configured for this simple operation, or how
fast the EMC can operate?
>
> There is also the question of where the data would come from. Right now
I'm just acting like the data is in RAM to determine if it would even be
possible to output it.
>
> We've considered switching to a different part like an LPC24xx or an ARM9
that has a built-in LCD controller peripheral, but we want to stay away from BGA
packages for the added assembly cost. Also we need an 100Mbps Ethernet
connection, which as far as I can tell pretty much requires a built-in MAC. If
someone knows of a way to handle 100Mbps Ethernet data through SPI or some other
means, I would also be very interested to hear about that.
>
Reply by redwire85●September 25, 20092009-09-25
I am using the EMC to control an 8-bit wide LCD (EA-DOG) on my LPC2468 board.
Just make sure you tie up the lines to the controller per the datasheet and you
should be fine. With the EA-DOG (uses Sitronix controller) you can tie CS low
and control "E" as a combination of OE and WE from the processor.
As long as you are thinking about using EMC perhaps consider the 2468 then
you'd have the Ethernet as well.
And it comes in a PQFP package.
--- In l..., "stangelanda" wrote: >
> I want to communicate with an LCD using an 8bit parallel interface with a
clock speed of around 25MHz. I'm currently using the LPC2368 which
doesn't have an LCD controller.
>
> I'm wondering if I can use the GPDMA to continuously write values to a
GPIO register. It would output on 9 pins, the 8bits of data and an alternating
clock signal. I don't know a lot about how DMA works. But I was hoping
someone would know if this was possible, and how fast the DMA transfers data.
Could it change the GPIO register on every CPU clock transition?
>
> Another solution would be to try to use the EMC controller. It is 8bits wide,
so if you ignore all of the addressing pins and just write to the same RAM
location each time you should be able to clock out 8bits of parallel data. Does
anyone know if the EMC could be configured for this simple operation, or how
fast the EMC can operate?
>
> There is also the question of where the data would come from. Right now
I'm just acting like the data is in RAM to determine if it would even be
possible to output it.
>
> We've considered switching to a different part like an LPC24xx or an ARM9
that has a built-in LCD controller peripheral, but we want to stay away from BGA
packages for the added assembly cost. Also we need an 100Mbps Ethernet
connection, which as far as I can tell pretty much requires a built-in MAC. If
someone knows of a way to handle 100Mbps Ethernet data through SPI or some other
means, I would also be very interested to hear about that.
>
Reply by stangelanda●September 25, 20092009-09-25
--- In l..., "cheezemanrich" wrote: >
> I don't know much about DMA but Microchip makes a 10/100Mb SPI or
parallel interface.
> It contains both the MAC and PHY. Also has hardware security engine, auto
polarity, and pre-programmed MAC address.
> ENC624J600
> http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en541877
> $3.22 @ Qty 100
>
> Hope this helps.
>
> --- In l..., "stangelanda" wrote:
> >
> > I want to communicate with an LCD using an 8bit parallel interface with a
clock speed of around 25MHz. I'm currently using the LPC2368 which
doesn't have an LCD controller.
> >
> > I'm wondering if I can use the GPDMA to continuously write values to a
GPIO register. It would output on 9 pins, the 8bits of data and an alternating
clock signal. I don't know a lot about how DMA works. But I was hoping
someone would know if this was possible, and how fast the DMA transfers data.
Could it change the GPIO register on every CPU clock transition?
> >
> > Another solution would be to try to use the EMC controller. It is 8bits
wide, so if you ignore all of the addressing pins and just write to the same RAM
location each time you should be able to clock out 8bits of parallel data. Does
anyone know if the EMC could be configured for this simple operation, or how
fast the EMC can operate?
> >
> > There is also the question of where the data would come from. Right now
I'm just acting like the data is in RAM to determine if it would even be
possible to output it.
> >
> > We've considered switching to a different part like an LPC24xx or an
ARM9 that has a built-in LCD controller peripheral, but we want to stay away
from BGA packages for the added assembly cost. Also we need an 100Mbps Ethernet
connection, which as far as I can tell pretty much requires a built-in MAC. If
someone knows of a way to handle 100Mbps Ethernet data through SPI or some other
means, I would also be very interested to hear about that.
>
I'm not sure I understand everything about how Ethernet works. SPI is a
1bit interface, whereas RMII is a 2bit parallel interface, and MII is 4bit
parallel. So MII runs at 25MHz, RMII runs at 50MHz, and SPI would have to run
at 100MHz to get that transfer rate. And since SPI only runs at half the speed
of the system clock, you would need a system clock running at 200MHz. Which as
far as I know, NXP only offers 200+MHz in BGA packages.
Reply by cheezemanrich●September 24, 20092009-09-24
I don't know much about DMA but Microchip makes a 10/100Mb SPI or parallel
interface.
It contains both the MAC and PHY. Also has hardware security engine, auto
polarity, and pre-programmed MAC address.
ENC624J600 http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en541877
$3.22 @ Qty 100
Hope this helps.
--- In l..., "stangelanda" wrote: >
> I want to communicate with an LCD using an 8bit parallel interface with a
clock speed of around 25MHz. I'm currently using the LPC2368 which
doesn't have an LCD controller.
>
> I'm wondering if I can use the GPDMA to continuously write values to a
GPIO register. It would output on 9 pins, the 8bits of data and an alternating
clock signal. I don't know a lot about how DMA works. But I was hoping
someone would know if this was possible, and how fast the DMA transfers data.
Could it change the GPIO register on every CPU clock transition?
>
> Another solution would be to try to use the EMC controller. It is 8bits wide,
so if you ignore all of the addressing pins and just write to the same RAM
location each time you should be able to clock out 8bits of parallel data. Does
anyone know if the EMC could be configured for this simple operation, or how
fast the EMC can operate?
>
> There is also the question of where the data would come from. Right now
I'm just acting like the data is in RAM to determine if it would even be
possible to output it.
>
> We've considered switching to a different part like an LPC24xx or an ARM9
that has a built-in LCD controller peripheral, but we want to stay away from BGA
packages for the added assembly cost. Also we need an 100Mbps Ethernet
connection, which as far as I can tell pretty much requires a built-in MAC. If
someone knows of a way to handle 100Mbps Ethernet data through SPI or some other
means, I would also be very interested to hear about that.
>
Reply by stangelanda●September 24, 20092009-09-24
I want to communicate with an LCD using an 8bit parallel interface with a clock
speed of around 25MHz. I'm currently using the LPC2368 which doesn't
have an LCD controller.
I'm wondering if I can use the GPDMA to continuously write values to a GPIO
register. It would output on 9 pins, the 8bits of data and an alternating clock
signal. I don't know a lot about how DMA works. But I was hoping someone
would know if this was possible, and how fast the DMA transfers data. Could it
change the GPIO register on every CPU clock transition?
Another solution would be to try to use the EMC controller. It is 8bits wide,
so if you ignore all of the addressing pins and just write to the same RAM
location each time you should be able to clock out 8bits of parallel data. Does
anyone know if the EMC could be configured for this simple operation, or how
fast the EMC can operate?
There is also the question of where the data would come from. Right now
I'm just acting like the data is in RAM to determine if it would even be
possible to output it.
We've considered switching to a different part like an LPC24xx or an ARM9
that has a built-in LCD controller peripheral, but we want to stay away from BGA
packages for the added assembly cost. Also we need an 100Mbps Ethernet
connection, which as far as I can tell pretty much requires a built-in MAC. If
someone knows of a way to handle 100Mbps Ethernet data through SPI or some other
means, I would also be very interested to hear about that.