Electronic – Is is possible for a microcontroller with a single serial output to interact with two serial peripherals

I'm going to be using Xbee modules. I'll be trying to use a point to multipoint network.

At the moment, I plan to have a transmitter identifier, payload type, payload length, payload and checksum - it would look something like this:

Field            Type    Description   
transmitter_id   uint8   Identifies the transmitting module (0-255)
type             uint8   Type of data (GPS coordinates, hit status, etc.)
length           uint8   Length of payload in bytes
payload          -       Actual payload
checksum         uint16  CRC16 of everything before

That's how I imagine it, the format might change but this will be the basic protocol in use.

Yes, you can implement a UART in software. Here's one in 8051 assembly, which should work for your microcontroller. This technique is called bit-banging.

Assuming by "serial" you mean RS-232¹, and assuming you're talking to something that actually wants RS-232 and not "TTL serial", you will still need an external RS-232 level-shifter like a MAX232.

The problem with software UARTs is that RS-232 doesn't have a separate clock line². As such, reliable communication is dependent on the timing accuracy of the devices on both ends of the connection. You therefore don't want to try and provide a software UART if your instruction clock is inaccurate, as with many internal RC oscillators. The AT89S52 you're using doesn't have the option of an internal oscillator, but you do still need to make sure your external oscillator is accurate to within 1% of the nominal value for a software UART to achieve reliable communication.

On top of that, for the processor's core instruction cycle time to divide evenly into the bit time of RS-232, you need to pick odd oscillator frequencies. 11.0592 MHz is popular for this. Another option is 14.7456 MHz, as explained here.

The clock frequency affects the hard-coded delay loops you need in a bit-banging approach. That's what the DJNZ R0,$ bit is in the assembly code I pointed you to: it's a pure delay loop, doing nothing but decrementing a counter to burn time. Up at the top of the file, you see the BITTIM constant, which hard-codes this particular implementation so that its timing works when using an 11.0592 MHz CPU clock. If you change the clock frequency, you have to change this constant, too. Then you should test it again carefully to make sure the timing is still good enough. Sometimes you find yourself needing to add NOP or similar instructions to pad the timing out with bit-banging approaches like this one.

The lower your serial data rate, the more slackness you can get away with. So, if you only need 1,200 bps, you might be able to get away with an internal RC oscillator or a "normal" μC instruction clock rate, particularly if you aren't transmitting or receiving continuously. Conversely, my experience is that if you need to run faster than 9,600 bps or so, you really need a hardware UART.

Footnotes

1. There are many different forms of serial communication. When used generically, the term most often means RS-232, but based on the tags defined here on Electronics.SE, I²C, SPI, CAN, and RS-485 are all quite common.

   • RS-485: I believe everything above applies just as well to RS-485, as well as to its close relative RS-422.

   • I²C and SPI: These include a synchronous clock line, so most of what I've written above doesn't apply to these communication methods. Nevertheless, it is also possible to implement them in software via bit-banging.

   • CAN bus: Not possible to implement in software, due to the need for CSMA/BA.

   There are still other forms of serial communication which are simply too fast to implement in software for a typical μC, such as USB, Ethernet, PCI Express, and SATA. You can implement them in FPGAs, but that's a separate question.

2. Well, not with DB-9 RS-232, or any of the common lower-pin-count variants. The original DB-25 based flavor of RS-232 did set aside a couple of pins for sender and receiver clocks (15 and 17) but in my decades of experience with RS-232, I've never used a device that actually depended on their presence.