# Microcontroller with more than one serial port

I have a microcontoller from ATMEL AT89S52, that has only one serial port. However, in my application the microcontroller is to be interfaced with a RFID reader and also with a WiFi board through serial port. Since I have only one serial port and the RFID reader and WIFI need to be there simultaneously, I am not able to proceed. Is there any possibility to emulate serial ports using software? If yes , how?

Or can anyone suggest me a better way to achieve this goal(except buying another controller with multiple serial port)?

-
Which microcontroller from Atmel? They have a lot; be specific. – Nick Johnson Jan 9 at 9:38
Providing a link to specific components relevant to the question (e.g. the Atmel microcontroller, WiFi board and RFID reader mentioned) helps others to understand the problem better and thus provide more meaningful answers. – Anindo Ghosh Jan 9 at 9:59
@NickJohnson, I have updated my question – gpuguy Jan 9 at 10:32
What kind of serial port? – Phil Frost Jan 9 at 12:42
Switching to another processor probably is the best solution, but multiplexing or software implementations as suggested below can work in some cases. – Chris Stratton Jan 9 at 16:04

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.

-
You only need the level-shifter if you're using RS-232 levels... The Wifi board and RFID could be using TTL levels, OP never stated. – dext0rb Jan 9 at 17:05
@dext0rb: Of course, but then it's not really "RS-232". :) – Warren Young Jan 9 at 17:05
True, however the term "RS-232" does not appear in the question, and has apparently been inserted into the answer only by assumption :) – Chris Stratton Jan 9 at 17:11
Yup. Phil Frost's question above needs answering. But as a default, RS-232 is a pretty good guess. – Warren Young Jan 9 at 17:18

There are multi-drop serial interface standards, e.g. RS-485. You could investigate if all these parts can be configured to support such a standard, and if you can arrange a suitable protocol to avoid everybody talking at once. Or you could use external gates or switches (e.g.74HC4052) to route your serial signals to one device or the other, controlled by a port pin from the processor.

This doesn't work if both RFID reader and WiFi need to be able to interrupt the CPU at random times, though you could add other connections to allow that.

-

The XMega controllers can support up to 8 UART ports :

The XMEGA A devices provide the following features: in-system programmable flash with read-while-write capabilities; internal EEPROM and SRAM; four-channel DMA controller; eight-channel event system and programmable multilevel interrupt controller; up to 78 general purpose I/O lines; 16- or 32-bit real-time counter (RTC); up to eight flexible, 16-bit timer/counters with capture, compare and PWM modes; up to eight USARTs... source

-

You can use one serial port for one of the peripheral and for the other one you can implement a software UART. Try to google this and you will find your second port.

-

Use a demux with other digital pins of the microcontroller you can get as many UARTS you need, as long as you dont need too much speed in the communications, since you will keep 1 at a time.

-

Look further up Atmel's line - some of their SAM3 series have multiple ports (I'm using the SAM3S4B for something now, and it has 2 USARTs, which can do almost any serial protocol imaginable, and 1 or two plain UARTS, which are limited to regular serial, 8-n-1 kind of applications, but work just fine within those limits.

-