Multiple UART communication with single PIC16F887

[akshaymathur39]

Dear Friends,

I have two devices which has RS232 interface. I would like to know how can I interface them with single PIC16F887.

Do I need to use 1 H/W UART and 1 S/W UART or both can be communicated via 1 H/W UART only. For both the device, I issue an command and read the reply.

If anybody can provide me an example code, that would be highly beneficial.

Thanks,
Akshay Mathur

[John P]

Are you a pal of Ivan_Ult?

[n-squared]

Hi,
If you do NOT need to communicate with BOTH devices at the same time and can modify the hardware, you can add a multiplexer chip between the MCU and an RS-232 chip such as MAX232. An additional output from the MCU will cause the multiplexer to switch between the two channels.
Implementing a software UART is the other alternative. CCS does the job for you with the built-in functions.

Good luck
Noam
_________________
Every solution has a problem.

[akshaymathur39]

@ John P: I am not pal of Ivan_Ult.

Thanks for the reply.
However, I do not want to use an additional multiplexer b/w MAX232 and MCU.
Is it possible to configure a software USART on some pins of UART and use the H/W UART simultaneously.
If yes, can you please let me know how can I instruct, which UART (S/W or H/W) to use at any time.

Looking forward to your reply.

Thanks,
Akshay Mathur

[n-squared]

Hi Akshay,
It is possible to use the software UART in conjunction with the hardware UART, by defining a second #USE RS232(...) line. You need to define the two pins for this port. However, you should realize that the software UART relies on software delay loops and is not hardware driven in any way. My suggestion is to associate the RX of this UART with an INT pin (RB0), and define the interrupt as falling edge. enable the external interrupt to detect beginning of start bit and call the fgetc(stream) function.
You should probably disable all interrupts while transmitting or receiving a byte on this channel to prevent errors in data.

The two #use lines should look like this:

[Ttelmah]

It is possible to use a software UART. The compiler generates this, if you setup a #USE RS232 on any pins other than the hardware ones, _but_ there are severe limitations:
Software UART, for receive, _must_ poll the incoming receive pin, at an interval less than 1/2 the bit time, or characters _will_ be missed. You can 'get round' this, by using a pin supporting a hardware interrupt for the receive, but only at relatively low data rates.
Communication, can be half duplex, or simplex _only_.
If using the hardware UART at the same time, then you either need to poll this _between_ the software characters, or disable it's interrupt, during each character receive/transmit.

On 'how to instruct', this is handled by the streams directive. You set up two #USE RS232 statements, with different names, and use these with the fputc/fprintf/fgetc operations, rather than the 'standard' putc/getc operations.

A lot will depend on the 'nature' of the communications involved. If (for instance), one link, is receiving data sent by another device, at intervals, without any 'warning', then this is better handled by the hardware UART. Provided the other link is a connection, where you 'ask for' data, and preferably at a lower data rate, then this can be handled well by the software UART. At higher _receive_ speeds, it becomes increasingly difficult to handle the sotware link reliably while other things are going on. However a high rate transmit, is actually 'easier' to handle, since it involves disabling the interrupts for less time.
Now I'm being 'vague' about what is higher, and lower in this regard, since it depends on the clock rate being used.

A search of the forum, will find examples of using a software UART wth an interrupt to receive data, examples of how to disable the interrupts on a per character basis, and examples of setting this all up.

Best Wishes

[John P]

I thought Ivan_Ult asked basically this same question a few days ago.

The way you do it is indeed to bring one RX to an interrupt pin, most likely PORTB.0. When that interrupt occurs, disable it and start a timer-based interrupt, initially for 1.5 times the baud rate and then 1 bit time, grabbing data off the port pin until you have 8 data bits, at which point you re-enable the interrupt-on-lowgoing-bit feature. The CCS software UART uses delays, which prevent other things from being responded to, such as data arriving on other pins, so if performance is an issue, you have to handle things another way. Note that it's very important, every time you switch one interrupt off and another on, to clear the flag for that interrupt first! (INTF for RB.0, TMR2IF for timer 2, if that's what you used.)

That leaves the issue of how to read the hardware UART. You really need to poll it rather than using an interrupt, as you need an immediate response if a character starts to arrive on the software UART. But this is workable if you don't have a huge amount to do in the main() function. While the timer interrupt is running, you can poll it there.