Hello, we are starting a new Arm9 project, but we need 6 serial ports. We are thinking on using the 9302, but currently it only has 2 ports. We are going to use a CPLD chip to provide the extra ports, but I would like to know if anyone has already done this.
I would like to know which would be the best PLD to use and if there is any open Linux source drivers and available PLD code already written.
Thanks.
You could also add a quad UART for about ~$18. What I’m doing on my project is using a lpc2103, at ~$5 for two additional ports, and use SPI for coms. There is so much example code for UARTS and SPI for the 2103 that it becomes almost trivial, and the distributed processing will help out a bit.
Andy
We thought about using a SPI interface to a uart, but worried about timing. We will be talking with 6 serial devices in real time and it is very important that the interface does not create any lag. I have seen people implement a PLD to handle the uart data. Now I am not sure on the speed difference between using the CPLD and the SPI. But I would think that the CPLD would be faster. If we are only talking at 9600 baud, then interface speed may not be that big of a factor.
Thanks for the feedback.
CPLD may be faster but you have to attach it somehow to EP9302 do you?
so you have to implement some kind of protocol anyway
Tsvetan
The LPC3180 offers up to seven UARTs. It’s based on an ARM926EJ-S core clocked at up to 204 (or was it 208?) MHz with 32kB of I-Cache and 32kB of D-Cache. It also features an ARM VFP (Vector floatingpoint processor) that could considerably improve floating point performance.
Without knowing more about your requirements (other than 6 serial ports) it’s going to be hard to give any sensible recommendation. You said you’re starting an ARM9 based project, but didn’t mention what made you choose the ARM9.
Best regards,
Dominic
oopicwow:
We thought about using a SPI interface to a uart, but worried about timing.
SPI can run at PCLK/8. I haven’t implemented the protocol yet, but I don’t expect any issues. My serial lines runat 250Kbs, a protocol converter to Ethernet.
Andy
Basically the device breaks three serial lines and just communicates over the other 4 ports. This device sits in the middle of these three serial lines and modifies data as needed as the serial data passes though it. If a message come by that needs to be modified then it modifies the message as it is coming in and passes it on with the new message. Most of the communications runs at 9600. There is no need for handshaking on these ports. We have timing constraints that we have to deal with. For example a message must not take longer than 250ms to reach the destination and per character of 50ms. That is why I am somewhat worried about timing. The problem is finding a processor that has all the ports we need. That is why we are thinking of using a PLD chip to handle that. I have seen it done with some development boards, but we are looking for some open-source drivers and PLD code to help in the decision. If a PLD is the answer, which would be the best to go with? We don’t want a BGA package so Phillips is out (with other features we want). We are left with Atmel and Cirrus for an Arm processor, they have QFP packages. Which would have better debug/development tools to get started with?
Hope this helps.
Why an ARM? Do you really need that much computing power? With that data rate it seems to me an AVR could handle this without breaking a sweat.oopicwow:
Basically the device breaks three serial lines and just communicates over the other 4 ports. This device sits in the middle of these three serial lines and modifies data as needed as the serial data passes though it. If a message come by that needs to be modified then it modifies the message as it is coming in and passes it on with the new message. Most of the communications runs at 9600. There is no need for handshaking on these ports. We have timing constraints that we have to deal with. For example a message must not take longer than 250ms to reach the destination and per character of 50ms. That is why I am somewhat worried about timing. The problem is finding a processor that has all the ports we need. That is why we are thinking of using a PLD chip to handle that. I have seen it done with some development boards, but we are looking for some open-source drivers and PLD code to help in the decision. If a PLD is the answer, which would be the best to go with? We don’t want a BGA package so Phillips is out (with other features we want). We are left with Atmel and Cirrus for an Arm processor, they have QFP packages. Which would have better debug/development tools to get started with?Hope this helps.
we are currently using an 8 bit zworld rabbit processor running at around 20 MHz and have run into limitations with ram and speed. We see problems arise from the devices we are in the middle of. The original design we have is starting to morph into a device that has other uses. It will allow us to create modules for the device that we can use for other projects. We figure with an ARM running embedded Linux we would always have the horse power we need. From the Arm stand point it would seem we would get better debugging and performance and honestly would be a lot more fun. We have other hydraulic controllers we have done that use the 8 bit PIC processors, but is really basic in design. This project just seemed perfect for getting into the Arm realm. It may be a bit over kill, but we would not have to worry about expansion.
With the 8-bit processor, we are limited to reading a character at a time. When we try to read an entire message before sending it out we run into timing issues. With the ARM we will be able to read the entire message and still be able to process it and send the data out with out too much timing lag. Least that is the idea.
Thanks.