Curious how many RS232 ports can be set in PIC

[khalis]

Hi..

Currently I'm dealing with two RFID readers that send ID through rs232 and then I need to receive both IDs from the readers and then send back to Pc for verification and to tell any specific action that has been done by the controller. So, in this situation, I need 3 rs232 ports and my question, is a PIC18F252 able to handle three rs232 simultaneously? Can I know how many rs232 comm PIC able to handle.

Thanks.

[bkamen]

Some PIC's come with 2 UARTs (like the 18FxxJ11) and I've used with success.

If you plan on having SIMULTANEOUS reception, you need hardware uarts. Software won't cut it. You'll need at least 2.

If you want to just SEND back to the PC, you could maybe get away with that in software... but it may not work depending on the situation.

Now if you can find a SPI based multi-uart, rock and roll. You'd be set.

But there's the limitations of the pic directly...

Cheers,

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[khalis]

Thanks for the response. What do you mean by hardware uart? Is it that I need to find other hardware to work with the pic?

[Ttelmah]

A 'UART', is the code, or hardware, to convert a byte, into the sequence of bits with the right timings, for serial, and to do the reverse (taking a sequence of bits, and putting them back together to make a byte).
The letters stand for 'universal asynchronous receiver/transmitter'. Converting 'parallel' data into asynchrnous serial, and vice versa.
Now, there two basic ways of doing this. The first is hardware. You have a clock that is some multiple of the required rate,s hift registers, and logic, to perform the transmission/reception. The second, is that you can program a microcontroller like the PIC, to do this in _software_. A 'software UART'.

CCS, offers code to support both of these methods. If you setup it's #use_rs232 statement,to talk to pins that have a hardware UART built into the chip, the compiler will generate code to use this hardware. If you instead use pins that don't have hardware, a 'software UART' will be used instead.

The software UART, has _major_ restrictions.
It can only operate 'half duplex'. Only sending _or_ receiving at any time.
Though you can program multiple software UARTs, only one can be used _at a time_.
There is no buffering. Your code must be sitting 'waiting' for the character to arrive, and must stay in the routine for the entire transmission/reception time for each character.
The software UART, is a cost saving exercise, that is ideal, if you want (for instance), to send data to another device, at a time, when nothing else is going on, or receive data in a similar way, but it is _not_ the way to go, if multiple things need to happen.

Most PIC's, have a single _hardware UART built in.
Your 18F252, has this.
With _careful proramming_, the 252, can handle 2 serial connections. What you do, is use the hardware UART for one, and the software for the other, with interrupt driven code to talk to the hardware UART, which you disable on a 'per character' basis, while using the software UART.
To go beyond this, requires you to either add another external hardware UART, or use a PIC, that has more hardware UARTs built in.

As mentioned by the original replier, there are some more sophisticated PICs with a second UART.
There are also external hardware UARTs, that interface to a microcontroller, using SPI, or I2C. The MAX3110, is an 'old' example of the latter, which can work quite well, but is large/costly (it includes two complete channels of TTL serial to RS232 interfacing, - effectively a MAX232, as well as the UART - ideal if you need this buffering, but not otherwise....). Philips do the SC16IS75x/76x families, that are smaller devices for this.
Another alternative, is to connect a second PIC, via I2C/SPI, and use this to give extra channel(s).

Best Wishes

[asmboy]

if you want really serious , multiple serial function check the datasheet for the 16550 family - in particular the TL16C552 or (16554) which offer two or 4 very hi performance bi directional FIFO'd operation

there are many more advanced family members going up into parts like the 16c854 etc with HUGE fifos etc

on the downside - you have to provide a ref oscillator for it and is uses parallel access - a 16552 ( 2 port ) design will typically need a full B or D port - for bi directional transfers--
PLUS at a minimum -
the multiplexed use of 6 or 7 additional data lines to the PIC ( with an INT edge B port line - ideally ONE of these dedicated lines) NB: 4 of the control lines could be provided via bussed latches - and the data bus could be shared with other parallel chips - which was what i have done to use the part in a design that has an ADS8717 A/D and an 82c54 - already being used in parallel mode as well. In operation -
the XMIT/RCV fifos and the ability to set the INTR trip points makes for very very efficient background serial com. in cases where the entire receive data packet is shorter than 15 chars - the fifo INT trip point can be set to not interrupt until the entire packet is in the receive fifo

the "pin loss" pain is not so great in your design if you already need to use other devices in parallel - but if U R tight for I/O pins or codespace NOW - this won't be so doable.

[bkamen]

[John P]

Is it the ID-20 sensor from SparkFun? If so the output is only at 9600 baud, not alarmingly fast.

I tried to program a multiple serial port reader on a PIC16F877 at 20MHz to take data from these, using an interrupt rate of 38400/sec. I had to avoid CCS's interrupt routine and use the Global interrupt instead, but I checked it with a scope and the processor could handle 4 ports receiving data at 960 bytes/second on all 4 ports at once. And that was keeping the hardware port for communication with a computer. If the processor were one of the PIC18's at maximum speed, I assume 8 ports would work. But a scan rate of 4x the baud rate only works if the sending unit is accurate!

You do need to take care that if the data comes in at maximum rate, even if you can handle it on a short-term basis, can the processor do whatever has to be done to respond to it? Like, if packets have to be made up to be sent from another port, is there enough storage to hold data waiting to be sent? I'm not sure what the limit is there.

If you have the ID-20, you might look at the "magnetic stripe emulation" output. It's weird, but it seemed to me that it might be easier to deal with than a serial port.

[khalis]

Thanks again for those who willing to give a deep explanation and some ideas toward my problem. I'll read and need to understand first all the explanations and the ideas from all of you. One more thing, anyone of you know where I can find a simple example to use hardware uart. It is quite interesting.
Once again, Thank you

[khalis]

I'm maybe already understand what thelmah has said before..correct me if i'm wrong.

- if i use #use RS232 with pin C6 and C7, the compiler will assume that i want to use the hardware uart provided in the pic

-if i use #use RS232 with other pins from the pic, the compiler will assume that i want to use software uart

[khalis]

For John P question, I'm using Tagsense RFID reader. My plan was to use two readers with one controller where the controller communicates with those readers simultaneously by using 2 rs232 and another rs232 connection to communication with PC.

[bkamen]

btw,

I realized today some of the higher-end PIC's have 3 and 4 serial ports! (like some of the 24H series...)

Neato...
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D