I have no UART on my microcontroller so how can I add one?

Question

I am using a ATMEGA32HVB microcontroller which has a facility for cell balancing by which we can connnect 4 batteries in series and use one at a time. That is very useful for power management so I can't use a different microcontroller. Please suggest some methods to add a UART to it so I can easily interface to serial devices.

Answer 1

As others have noted, you can either add additional hardware to your system to provide the UART functionality, or you can emulate one in software. If you have control of the overall hardware design and adding another IC is an option, I would strongly consider the hardware-based approach. You can certainly make a software UART work using bit-banging, but you might not want to dedicate the CPU resources to generating the required timing.

From a glance at the datasheet, it appears that your microcontroller has both SPI and I2C (which Atmel calls a Two-Wire Interface (TWI)). These would probably be the best interfaces to use in order to attach an external UART. Said devices are available from a number of manufacturers. Some examples:

• Exar (http://www.exar.com/connectivity/uart-and-bridging-solutions/i2c-spi-uarts) has a line of SPI/I2C 1- and 2-channel UART devices available, covering the ~1.6-3.3V operating range. I've not used any of these parts specifically, but I have used Exar devices in the past (with parallel memory-bus interfaces), and they have worked well.

• NXP (http://ics.nxp.com/products/bridges/i2c.spi.slave.uart.irda.gpio/) has a line of SPI/I2C UART/IrDA/GPIO devices available, also in 1- and 2-channel varieties over a couple voltage ranges. I have used these parts (specifically the SC16IS762) extensively in the past with great success.

• Maxim (http://www.maximintegrated.com/datasheet/index.mvp/id/2052) has the MAX3110E and MAX3111E devices, which are SPI-connected UARTs. One unique feature of these devices is that they have an integrated RS-232 line driver. So, if you need your UART to interface to a device that uses RS-232 line voltages instead of logic levels (e.g. a PC), this might be useful, as it will save you from adding another line driver IC to your board.

Answer 2

If you are looking for a hardware solution, Maxim has several UART ICs with an SPI interface to the microcontroller (which is included in your part). Look at MAX3100 or the other options here: http://www.maximintegrated.com/products/interface/controllers-expanders/uart.cfm

Answer 3

You will need to use a software UART driver. Depending on exactly what you expect from this UART, you could use AVR305 (extremely compact, but no features beyond blocking half-duplex send/receive), AVR274 (interrupt driven, fairly feature complete), you could write your own software UART driver or you can use one you find on the internet, for instance by googling 'avr software uart'

Answer 4

A brief note about software "UART" design: there are at least qualitatively different approaches one may take, depending upon requirements:

• A "take over everything" bit-bang driver will disable all interrupts and use cycle-counted code to clock each bit. Receiving data with a "take over everything" driver requires that when data arrives the controller is doing nothing but waiting for it.

• A "take over main loop" bit-bang driver will behave much like the above except that it will use a timer resource for bit timings rather than cycle counting. Interrupts which do not take too long to service may be left enabled. For serial transmission, the fixed-rate timer resource may be shared with other purposes; for serial reception, however, the bit-bang driver will have to be able to reload the timer when the start bit arrives so as to make it expire in the middle of each incoming bit time.

• A fully-interrupt-driven bit-bang driver uses a fixed-rate timer that's running at some multiple of the data rate preferably (3x and 5x are both better than 4x), and does everything through that timer. Such a driver can run simultaneous with everything else, but will require a faster CPU than the former driver types would require.

To avoid having the first two styles of controller wait forever for data that may never come, it's common for read routines to include a timeout value. Note that if a a controller's loop does e.g. "get a byte while waiting up to 100ms for it, do some other stuff if none came, then get the next byte, etc." and a byte arrives between the time the "get" routine times out and the controller starts waiting again, that byte will be lost; the device it's communicating with will have to expect that possibility.

Only the third style of driver will be able to handle the possibility of a data byte starting to arrive while a data byte is being transmitted. The first two styles can, however, be used for some full speed full-duplex communication protocols if the controller only has to speak when spoken to. The trick is to have a "read and write data" routine which will wait for an incoming start bit, and when one is detected overlap a read and write such that the controller sends each bit just as it's about to examine the incoming data. Once the controller detects the incoming start bit, it will know exactly when it will should look for next 8 data bits and stop bit, and will thus know that it can safely use the time between to output its own data.

One parting note: a controller that uses one of the first two styles of bit-bang uart to receive data must process each byte of data before the falling edge of the next byte's start bit to avoid data loss. If the controller knows that processing will take at least half a bit time, it may maximimize the time available for processing by accepting each byte as soon as it has grabbed the last data bit, rather than waiting for the stop bit. As a further means of giving the controller more time, however, it may be helpful to have the device that's giving it data transmit with two stop bits rather than one. If "mark parity" can be configured, that will add another extra bit time. Transmission at e.g. 115200-8-M-2 will allow more processing time than 57600-8-N-1, even though it will feed data more than 1.6 times as fast.

Answer 5

You can simply use the I/O pin of the uC. Only thing when switch or transfer data on these pins you should have frequency of the pins double to the baud rate. This is how UART normally works, it will sample the bit signal at the middle.