Multiple RS232 port

litoman · Joined: 04 Nov 2005 Posts: 3

I need two serial port in my proyect but the problem is that when i use #int_RDA the pic hang up.It run into the interrupt routine all time and never go out.It seems like a INT_RDA flag not cleared.Here is my code.What is wrong?.

Storic · Joined: 03 Dec 2005 Posts: 182 Location: Australia SA

Have you seen the examples (EX_PBUSM.C and EX_PBUSR.C) as stated from the header description "The program ////
//// also shows how to handle two serial ports within one program."

also try http://www.ccsinfo.com/faq/?5

it is a one wire PBUS and a Serial RS232 setup. It may help.

I will be looking at this type of application in due caurse, I will be setting up a RS485 LAN and Serial RS232 LAN on the same micro (including ethernet)

ANdrew
_________________
What has been learnt if you make the same mistake? Wink

KenMacfarlane · Posted: Tue Mar 07, 2006 3:12 am

Litoman,
I've got dual com port circular buffer based code, which I thought was working, but I'm finding that rda2 loses chars when rda is busy receiving a 6 char packet. I've been trying to promote rda2 to be the sole high priority interrupt (18f6621, pcwh v3.235) but to no avail - the compiler won't take it.

Ttelmah · Guest

It is important to understand the limits of what can be done.
If you generate a dual serial system, with one hardware, and one software UART, then you are faced with the following choices:
If the serial data arriving on the software UART, has at any point, blocks that exceed two character times for the data on the hardware UART, without a break, then data _will_ be lost on the hardware UART.
If instead you make the hardware UART have priority (you can do this with the 'priority' command, without having to use the hardware priority at all), then instead, data will be lost on the software UART, since except at very low data rates, the time needed to service the hardware UART interrupt will generate too much latency for the software handler.
This is distinct from the situation when dealing with two hardware interrupts (on the 6621). Here it should be perfectly possible to receive data happily on both ports, but the normal interrupt caveats apply. How long does each handler take?. How high is the UART data rate?. Again, with two interrupts declared, the one declared first, will have 'priority' (in the software sense). Handling an interrupt, typically takes a minimum of about 80 instruction times, plus the time in the actual handler routine. Assuming an array access, the latter will probably involve another 40 instruction times. So if the 'byte' interval on one port, is shorter than something around 120 instruction times, and the handler for this is declared first, then if data arrives continuously, it will block anything else from working. If this is shifted to have a lower priority than the other port, the second port will now be serviced, but the odds are that data wll now be lost on the first port...
The timings will get worse, if the routines take longer than the bare minimum time.
The hardware interrupt will allow you to make the second event interrupt the first, but brings the same problem, and adds another caveat. On most chips, not all interrupts can be allocated to the low priority, if hardware priorities are enabled. If a interrupt does not have a priority bt in the interrupt registers, then it defaults to 'high priority'. Most of the chips have at least one interrupt wch this applies to. On your chip, 'INT0', will behave this way. This is not a compiler limitation, but a hardware limitation of the chip. So if you use the INT0 ability, this will end up on the high priority interrupt.
I'd perhaps suggest that it may be possible to get the hardware version to work, but by being a bit more ingenious in the interrupt handling. You would have to consider 'cross linking' the interrupt handlers. So something like: