IsThere a chip with multiple (4 or 8?) serial ports??

The TI quads all seem to use a parallel bus interface. You could glue them to the micro via an SPI bus with a CPLD or small FPGA.

Or, use a larger FPGA and instantiate as many UARTS as you need; check over at opencores.org. Possibly even incorporate the micro on it too.

It might be simplest just go with the NXP (Philips) dual SPI chips, like the SC16IS752.

snipped-for-privacy@terryking.us wrote: [...]

What about using the GPIO pins of the PIC as software serial ports?

Would it be cheaper to just get a few small PICS that have a uart and SPI or i2c. Link them via a SPI or I2C bus to a master with more memory to buffer the data and sent it to the data computer.

What about adapting an existing multiport serial product? Here's one that adds up to 16 serial ports via USB:

Maxim do a SPI uart chip but rather expensive. You can do it in software reasonably easily - 4800 baud is not especially taxing

- you just need to sample an 8-bit input port at 3x the baud rate on a timer interrupt and then process each bit in turn. In the past I've implemented 16 channels at 9600 baud on an ATMEGA88, so 8x4800 shouldn't be too hard.

On a sunny day (Wed, 04 Jul 2007 18:47:38 -0700) it happened " snipped-for-privacy@terryking.us" wrote in :

It is actually quite simple to implement a serial port in software. Depending on processor speed, you can poll status for one or many status bits... use interrupts if you must.. PIC could do it. One fast PIC is all you need.

If one wanted _many_ serial ports, fast hardware, and separate processing, filtering, and lots of IO to do something, then a small FPGA can be useful. You can easily fit >100 serial ports in a low cost FPGA, and perhaps if you actually needed a processor just use some core (free of buy IP).

Thanks for the suggestions, people!

On Hardware:

I'll look at the suggesti> It is actually quite simple to implement a serial port in software.

I was originally inclined to bit-bang it too.. I agree the overhead with a timer-driven interrupt at 3x 4800 or maybe 3x 9600 wouldn't be bad with a fast PIC. And I believe that my code that would set up and sent out 80 character bursts on the hardware Serial port should be interruptible without much of a problem. And I know it worked for Mike :-) at least on another processor...

I don't have the time / money to become competent in synthesizing this kind of stuff into a FPGA. I understand it, worked once with others on instantiating a whole DSP design into multiple FPGAs, and know that my learning curve for the whole deal would be a lot more than debugging a PIC, when I already have the tools / debugger for that.

Any pointers to PIC code, suggestions, etc. would be appreciated. This will be an open-source project for DIY Boating Electronics people. I hope to have XP code that will display gauges etc. along with Navigation software such as OziExplorer, and run this on a Mini-ITX board that can run fanless in a sealed box, like the VIA-EN12000EG at about 12 watts. The PICs are for interfacing NMEA devices and probably analog sensors into the low-power PC. The project will be attached to the Wiki at:

I'm prototyping this stuff over the next month here in Vermont; In August I'm moving to Shenzhen in China for 2 or 3 years, and will continue the project from there, and get some older boat to run real stuff on.

Several atmel avr models have 4 serial ports mega644 and mega2560 I think... also avrfreaks has projects with source code for multiple sw uarts. New AVRs are clocking at 20Mhz... they're so fast they can do the sw uarts and go out for a smoke between characters.

One idea is not implementing 'serial' ports at all.

The raw bit stream for an 80 byte message packet sampled at say 8 times the baud rate could be recorded in about 1k of RAM.

If you play back that recording at 8 times the sample rate to an output 'serial' port you effectively forward the message you received at 4800 to the output at 38k4.

You need to detect the message packet boundaries which could probably be as crude as seeing a start bit at the beginning and x consecutive stop bits at the end.

If you need to identify which channel the packet was received on then it would be possible to 'play back' a bit of hard coded bit stream prior to the recorded bit stream.

A crude 8 to 1 and 4800 to 38k4 NMEA packet multiplexor. Hardware would be a fast uP with 8k of RAM and 9 I/O pins.

I've used multi-port UARTs from NXP before. I'm quite sure they have at least 4 port UARTs.

But a small FPGA may be cheaper when it comes to components costs. A Xilinx Spartan 3AN with a microprocessor core and some UARTs for instance. In that case you'll have a single chip solution (the N in the part number stands for non-volatile so the FPGA can work stand-alone).

Try

Search Digikey for "UART" and then the 4 channel filter. Should get you to the TI TL16C-family e.g, TL16C554. Nice parts but the parallel access means that you'll tie up quite a few DIO lines on your micro. If it already has an address/data bus and supporting status lines and instructions then things are simplified a bit (no pun intended) since you can set up the UARTs as memory-mapped I/O.

Philips (oops, sorry, NXP ;-) has some of these. Had a SC16C554 in my last design this is a quad uart chip, IIRC the C558 is the octal version.

Don't know if 8 uarts can be done in software by digital IN's on a micro, but it might be worth thinking of it.

Heinz

PS: Have a look at

Heinz

If all communications are async then you will have problems with multiple ports on a single pic. I have tried this with many barcode applications. The problem is that the uart must be waiting undisturbed to receive data. if you use interrupts, by the time you service interrupt the buffered data will be lost. I ended up using multiple chips.

the trick is not to interrupt on the input data, but instead interrupt only on a timer and use the timer to drive the state-machines for each port.

SC16IS752

David