UART

This presentation describes about the High Speed UART present on Intel Quark SoC's.

It is so called because of the DMA capability present in the driver of Intel Quark HSUART.

Before diving into this specific UART, let us first understand some basics about serial communication and UART chips in general.

UARTs and different standards

A UART is a serial chip present on the motherboard of PC.

In Intel Quark SoC, this chip is present on the AMBA fabric.

Such a UART can be any of the following :-8250 Without any FIFO

16450- Without any FIFO

16550- Without any FIFO

16550A- 16 bytes FIFO

16750- Auto Hardware Flow enabled and with 64 bytes FIFOetc.

UARTs and different standards

The ones without FIFO are commonly termed as dumb UARTs and those with FIFO are termed as FIFO UARTs.

However, the driver in Linux for all these UARTs are commonly called by 8250.

There are various standards for serial communication between UARTs :-RS232

RS422

RS485etc.

RS232

Let us deal with RS232 first:-This standard defines the electrical signal characteristics such as voltage levels, signaling rate, timing and slew-rate of signals, voltage withstand level, etc.

Interface mechanical characteristics, pluggable connectors and pin identification.

Functions of each circuit in the interface connector.

The standard does not define character encoding or error detection protocols.

MAX232 and translation of Voltage levels

MAX232 are transceivers. MAX232 IC converts the voltage levels required for communication via UART. Through T*in, TXD/CTS signal is received from uC which is at TTL level (0/1). MAX 232 converts this level to (+-12V) and transmits the signal (RXD/CTS) through T*out, which then goes to the PC, which has 16550/8250, etc. compatible UART.

While receiving from the remote Host (PC),the signal TXD/RTS is received through R*in. This RS-232 voltage levels which are at Logic level 0/1 are converted to (+-12V), and sent to the uC (RXD/RTS) through R*out. Control Signals(Logic 0=5V TTL=>(-3)to(-12)V RS232), (Logic 1=0V TTL=>+3 to +12 V RS232) and Data Signals(Logic 0=0V TTL=>+3 to +15 V RS232),(Logic 1=5V TTL=>(-3)to(-15)V RS232) get changed to different RS-232 levels by MAX232.

Refer to the image on the next slide

MAX232

Pins on the UART chip

Tx- Data going out of the UART goes through the Tx line.

Rx- Data coming into the UART is received through the Rx line.

RTS- This is a control signal and is used to control the flow of data into the UART. Used only when Hardware Flow Control is enabled.Whenever the UART FIFO threshold level is attained (often set at 8 bytes or 14 bytes for a 16 bytes FIFO), RTS line is asserted which signals the transmitter to stop sending data . The transmitter gets this signal through its CTS line. This is because RTS and CTS lines are crossover. As soon as the FIFO has space to accommodate further incoming data, RTS line is de-asserted again and hence transmitter's CTS is de-asserted and the data flow resumes.

CTS- This is a read-only signal and acts as a signal from the remote receiver to stop/resume transmission of data.

RTS and CTS lines are active low and remain de-asserted during normal flow of data

A 16550 UART chip

Intel Quark HSUART

Intel Quark SoC has 16550A UART chip(s) with 16 bytes FIFO and capable of Hardware Flow Control.

These UART chips are memory-mapped in contrast to the ones present on the PCs which are port mapped and present in the legacy I/O space.

The DMA functionality is incorporated into these UARTs with the help of DMA controllers present on this SoC.

An SoC-specific platform-model driver takes care of this High Speed UART with DMA capability.

The MFD driver

MFD stands for Multifunctional Device.

The MFD driver intel_quark_hsuart_dma creates platform devices for UART and DMA.

These platform devices then use their respective upstream drivers dw_dmac and 8250_dw to carry out their tasks.

The layering of these drivers has been discussed in the subsequent slides.

Layering of various drivers

Layering and Functionalities of various drivers

This section will describe how the flow of communication happens from the user space via system calls through the various drivers to the various UART registers

Let us first start with the MFD driver intel_quark_hsuart.c

This driver registers the multifunctional device with the PCI subsystem.

It generates 2 platform devices-each for UART and DMA.

Refer to the next slide for code snippets.

Registration with PCI subsystem

Registration with PCI subsystem

Initialization of DMA and UART devs

As seen in the previous slide, static int intel_quark_hsuart_dma_probe(struct pci_dev *pdev, const struct pci_device_id *id) in the MFD driver calls the probe functions for DMA as well as UART- intel_quark_dma_device_probe(pdev, id) and intel_quark_uart_device_probe(pdev, id) respectively.

Initialization of DMA device

structure to hold DMA spec. values

Initialization of UART device

Initialization of UART device

Allocation of resources and enablement of PCI busmastering is also done during initialization of the UART device.

The device is registered to the MFD core with the API mfd_add_devices().

Same happened in case of DMA device probe also.

structures to hold UART spec values

dw_dmac.c

This is the standard driver for the DMA controller.

init() function here registers this device with the platform bus framework.

The structure shows the various methods needed for initialization,de-initialization and shutdown of the DMAC device.

8250_dw.c

This is the standard driver for the 8250 UART device.

8250_dw.c

8250_dw.c

8250_dw.c

dw_set_termios() function calls serial8250_do_set_termios() function defined in 8250.c . This function is responsible for configuration of the serial UART port(s) with the settings supplied from the user space using stty utility or Termios library.

8250.c

8250.c

8250.c

8250.c

8250.c

serial8250_do_set_termios() is exported so that this function can be called in 8250_dw.c driver code.

serial_core.c

serial_core.c

serial_core.c

Software flow controluart_throttle() in serial_core.c controls the arrival of characters as part of IXOFF with the help of uart_send_xchar(tty, STOP_CHAR(tty)) function.

uart_unthrottle() in serial_core.c resumes the arrival of characters as part of IXON with the help of uart_send_xchar(tty, START_CHAR(tty)) function.

Hardware flow control

same as in software flow control.The difference lies in uart_throttle() calling uart_clear_mctrl() and uart_unthrottle() calling uart_set_mctrl().

tty_ioctl.c

tty_ioctl.c

tty_ioctl.c

The function displayed in the previous slide is responsible for updating various termios values with respect to the software flow control macros and parameters.

The next set of slides will show the driver code snippets for various mode related ioctls supported by the driver through tty_mode_ioctl() function. ioctl() system call invokes this function.

tty_ioctl.c

tty_ioctl.c

tty_ioctl.c

tty_ioctl.c

tty_ioctl.c

tty_perform_flush() handles flushing the input line data,output line data and/or input and output line data which have not yet been read. tcflush() system call invokes this function.

tty_ioctl.c

tty_ioctl.c

tty_ioctl.c

tty_ioctl.c

Software Flow Control through tty_ioctl.c

n_tty_ioctl_helper() function controls the arrival of characters in almost the similar way. It checks for TCIOFF and TCION and calls the function send_prio_char(tty, STOP_CHAR(tty)) and send_prio_char(tty, START_CHAR(tty)) respectively which sends a high priority character to the device/tty.

Whenever tcflow() system call is made from the user space, the above mentioned n_tty_ioctl_helper() function is called and transmission of data is resumed or paused based on the parameter passed in the system call.

tty_throttle(struct tty_struct *tty) indicates that a tty should stop transmitting data down the stack.

tty_unthrottle(struct tty_struct *tty) indicates that a tty may continue transmitting data down the stack.

Software Flow Control captured on Logic Analyzer

The image on the next slide shows the transfer of Software flow control signals on the Tx line of the reciever .

For Software flow control to work, the functionality must be enabled using stty utility or Termios program.

When Tx sends '19' , i.e., XOFF ,The Rx line on the reciever stops receiving data because the sender on the other end stops transmitting.

As soon as Tx sends '17' ,i.e., XON the Rx line on the receiver starts receiving data again because the sender on the other end resumes sending the data.

XON/XOFF

XOFF

XON

RTS/CTS

RTS/CTS flow control also works on the same line, just the difference is that instead of software flow control signals '19' and '17', here the actual hardware interfaces come into play.

The condition here lies that The UART chip should have RTS and CTS pins, and that the Hardware flow control functionality should be enabled using some utility like stty or Termios.

During normal data transmission, RTS and CTS lines remain de-asserted all the time, since they are pulled active low. RTS and CTS lines are crossed-over.

RTS/CTS

When the data size reaches the FIFO threshold level , which normally is set to 8 bytes or 16 bytes or 64 bytes whatever(depends on the implementation ), RTS is asserted which signals the transmitter to stop sending data. The CTS on the Transmitter side receives this signal and gets asserted and the data transfer stops as long as RTS remains asserted.

When RTS is de-asserted again , the CTS again receives the signal which also gets de-asserted , and hence the normal transfer of data resumes. Hardware flow control is essential when the Receiver end is not able to cope up with the speed of transmission at the transmitter end.

Here Channel 7 is the RTS line and Channel 6 is the Rx line ,both on the Reciever node.

Conclusion

This brings us to the end of this presentation on Intel Quark HSUART.

In case of any queries, please feel free to drop the same in the comments section .