Using portB interrupts for software USARTs.

[arunb]

Hi,

I use several software USARTs in my project about 4 in all , the trouble with software USARTs is that they do not have pre-declared interrupts like the hardware one ;INT_RDA.

What I plan to do is , use the portB pins as the RCV pins of the software USARTs, then I enable the portB interrupt on change feature to detect any change in the RCV states of the USARTs. To get the character I use getc or gets.

Do you think this scheme should work ???


thanks
arun

[Ttelmah]

At low data rates, possibly, and only if the streams are mutually exclusive (remember that while one character is being received, the edges on any other character will be missed).
The biggest problem is that there is a very significant latency in responding to an interrupt. Typically perhaps 30 instructions or more (depending on whether any other interrupts are enabled, and more on the 18 chips). So by the time the edge is 'seen, the interrupt flag is set, responded to, all the registers are saved, and the interrupt routine called, quite a long period (in processor terms), has already passed. you then will need to read the port, and work out which bit is causing the interrupt, before calling the corresponding getc. Getc, if it finds the bit already active when it is called, will assume it is at the leading edge of the start bit, and wait for 1.5 bit times to sample the first data bit. Any timing errors in the baud rate calculation, may then move the sample point even latter in the character. It is normally reckoned, that you should not get more than 4% out of timing (to allow for errors at both ends). At 9600bps, this is only about 5uSec 'late', which doesn't allow much margin.
This has been proposed here before, and works fine for a single channel, at a low data rate, like 300bps, but at much higher rates is going to give problems, and with the inability to receive on the other lines while getting the character on one line, will probably not do what you want.

Best Wishes