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.
Using DMA or EMC for fast parallel interface
Started by ●September 24, 2009
Reply by ●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.
>
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 ●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.
>
> 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 ●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.
>
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 ●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.
>
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 ●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.
>
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 ●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.
>
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 ●October 3, 20092009-10-03
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.
>
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 ●October 3, 20092009-10-03
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.
--- 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.
