Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
UART(4)			    Kernel Interfaces Manual		       UART(4)

NAME
       uart  --	 driver	for Universal Asynchronous Receiver/Transmitter	(UART)
       devices

SYNOPSIS
       device uart

       device puc
       device uart

       device scc
       device uart

       In /boot/device.hints:
       hint.uart.0.disabled="1"
       hint.uart.0.baud="38400"
       hint.uart.0.port="0x3f8"
       hint.uart.0.flags="0x10"

       With flags encoded as:
       0x00010	 device	is potential system console
       0x00080	 use this port for remote kernel debugging
       0x00100	 set RX	FIFO trigger level to ``low'' (NS8250 only)
       0x00200	 set RX	FIFO trigger level to ``medium low'' (NS8250 only)
       0x00400	 set RX	FIFO trigger level to ``medium high'' (default,	NS8250
		 only)
       0x00800	 set RX	FIFO trigger level to ``high'' (NS8250 only)

DESCRIPTION
       The uart	device driver provides support for various  classes  of	 UARTs
       implementing  the EIA RS-232C (CCITT V.24) serial communications	inter-
       face.  Each such	interface is controlled	by a separate and  independent
       instance	of the uart driver.  The primary support for devices that con-
       tain multiple serial interfaces or that contain other functionality be-
       sides  one  or  more  serial  interfaces	 is provided by	the puc(4), or
       scc(4) device drivers.  However,	the serial interfaces of those devices
       that are	managed	by the puc(4), or scc(4) driver	are each independently
       controlled by the uart driver.  As such,	the puc(4), or	scc(4)	driver
       provides	 umbrella functionality	for the	uart driver and	hides the com-
       plexities that are inherent when	elementary components are packaged to-
       gether.

       The uart	driver has a modular design to allow it	to be used on  differ-
       ing  hardware  and for various purposes.	 In the	following sections the
       components are discussed	in detail.  Options are	described in the  sec-
       tion that covers	the component to which each option applies.

   CORE	COMPONENT
       At the heart of the uart	driver is the core component.  It contains the
       bus attachments and the low-level interrupt handler.

   HARDWARE DRIVERS
       The  core  component  and  the  kernel  interfaces talk to the hardware
       through the hardware interface.	This interface serves as  an  abstrac-
       tion  of	 the  hardware	and allows varying UARTs to be used for	serial
       communications.

   SYSTEM DEVICES
       System devices are UARTs	that have a special purpose by way of hardware
       design or software setup.  For example,	Sun  UltraSparc	 machines  use
       UARTs  as  their	 keyboard  interface.  Such an UART cannot be used for
       general purpose communications.	Likewise, when the kernel  is  config-
       ured  for  a  serial  console, the corresponding	UART will in turn be a
       system device so	that the kernel	can output boot	messages early	on  in
       the boot	process.

   KERNEL INTERFACES
       The last	but not	least of the components	is the kernel interface.  This
       component  ultimately  determines  how  the UART	is made	visible	to the
       kernel in particular and	to users in general.  The default  kernel  in-
       terface is the TTY interface.  This allows the UART to be used for ter-
       minals,	modems	and serial line	IP applications.  System devices, with
       the notable exception of	serial consoles,  generally  have  specialized
       kernel interfaces.

HARDWARE
       The uart	driver supports	the following classes of UARTs:

       o   NS8250:  standard  hardware based on	the 8250, 16450, 16550,	16650,
	   16750 or the	16950 UARTs.
       o   SCC:	serial communications controllers supported by the scc(4)  de-
	   vice	driver.

Pulse Per Second (PPS) Timing Interface
       The  uart  driver  can capture PPS timing information as	defined	in RFC
       2783.  The API, accessed	via ioctl(2), is available on the tty  device.
       To  use	the  PPS capture feature with ntpd(8), symlink the tty callout
       device /dev/cuau? to /dev/pps0.

       The hw.uart.pps_mode tunable configures the PPS capture	mode  for  all
       uart devices; it	can be set in loader.conf(5).  The dev.uart.0.pps_mode
       sysctl  configures  the PPS capture mode	for a specific uart device; it
       can be set in loader.conf(5) or sysctl.conf(5).

       The following capture modes are available:
	   0x00	 Capture disabled.
	   0x01	 Capture pulses	on the CTS line.
	   0x02	 Capture pulses	on the DCD line.

       The following values may	be ORed	with the  capture  mode	 to  configure
       capture processing options:
	   0x10	 Invert	the pulse (RS-232 logic	low = ASSERT, high = CLEAR).
	   0x20	 Attempt to capture narrow pulses.

       Add  the	narrow pulse option when the incoming PPS pulse	width is small
       enough to prevent reliable capture in normal mode.  In narrow mode  the
       driver  uses  the  hardware's ability to	latch a	line state change; not
       all hardware has	this capability.  The hardware latch provides a	 reli-
       able  indication	that a pulse occurred, but prevents distinguishing be-
       tween the CLEAR and ASSERT edges	 of  the  pulse.   For	each  detected
       pulse,  the  driver synthesizes both an ASSERT and a CLEAR event, using
       the same	timestamp for each.  To	prevent	spurious events	when the hard-
       ware is intermittently able to see both edges of	a  pulse,  the	driver
       will  not  generate  a  new  pair of events within a half second	of the
       prior pair.  Both normal	and narrow pulse modes work with ntpd(8).

       Add the invert option when the connection to the	uart device  uses  TTL
       level  signals, or when the PPS source emits inverted pulses.  RFC 2783
       defines an ASSERT event as a higher-voltage line	 level,	 and  a	 CLEAR
       event  as a lower-voltage line level, in	the context of the RS-232 pro-
       tocol.  The modem control signals on a TTL-level	connection  are	 typi-
       cally  inverted	from the RS-232	levels.	 For example, carrier presence
       is indicated by a high signal on	an RS-232 DCD line, and	by a low  sig-
       nal on a	TTL DCD	line.  This is due to the use of inverting line	driver
       buffers	to convert between TTL and RS-232 line levels in most hardware
       designs.	 Generally speaking, a connection to a DB-9 style connector is
       an RS-232 level signal at up to 12 volts.  A connection to header  pins
       or  an edge-connector on	an embedded board is typically a TTL signal at
       3.3 or 5	volts.

Special	Devices
       The uart	driver also supports an	initial-state and a lock-state control
       device for each of the callin and  the  callout	"data"	devices.   The
       termios	settings  of a data device are copied from those of the	corre-
       sponding	initial-state device on	first opens and	are not	inherited from
       previous	opens.	Use stty(1) in the normal way on the initial-state de-
       vices to	program	initial	termios	states suitable	for your setup.

       The lock	termios	state acts as flags to disable	changing  the  termios
       state.  E.g., to	lock a flag variable such as CRTSCTS, use stty crtscts
       on  the lock-state device.  Speeds and special characters may be	locked
       by setting the corresponding value in  the  lock-state  device  to  any
       nonzero	value.	 E.g., to lock a speed to 115200, use "stty 115200" on
       the initial-state device	and "stty 1" on	the lock-state device.

       Correct programs	talking	to correctly wired external devices work  with
       almost arbitrary	initial	states and almost no locking, but other	setups
       may benefit from	changing some of the default initial state and locking
       the  state.  In particular, the initial states for non (POSIX) standard
       flags should be set to suit the devices attached	and  may  need	to  be
       locked  to  prevent  buggy  programs from changing them.	 E.g., CRTSCTS
       should be locked	on for devices that support RTS/CTS handshaking	at all
       times and off for devices that do not support it	at all.	 CLOCAL	should
       be locked on for	devices	that do	not support  carrier.	HUPCL  may  be
       locked  off if you do not want to hang up for some reason.  In general,
       very bad	things happen if something is locked to	the wrong  state,  and
       things should not be locked for devices that support more than one set-
       ting.   The CLOCAL flag on callin ports should be locked	off for	logins
       to avoid	certain	security holes,	but this needs to be done by getty  if
       the callin port is used for anything else.

FILES
       /dev/ttyu?	for callin ports
       /dev/ttyu?.init
       /dev/ttyu?.lock	corresponding  callin initial-state and	lock-state de-
			vices

       /dev/cuau?	for callout ports
       /dev/cuau?.init
       /dev/cuau?.lock	corresponding callout initial-state and	lock-state de-
			vices

SEE ALSO
       cu(1), puc(4), scc(4), ttys(5)

HISTORY
       The uart	device driver first appeared in	FreeBSD	5.2.

AUTHORS
       The uart	device driver and this manual  page  were  written  by	Marcel
       Moolenaar <marcel@xcllnt.net>.

FreeBSD	13.2			 July 11, 2020			       UART(4)

NAME | SYNOPSIS | DESCRIPTION | HARDWARE | Pulse Per Second (PPS) Timing Interface | Special Devices | FILES | SEE ALSO | HISTORY | AUTHORS

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=uart&manpath=FreeBSD+14.0-RELEASE+and+Ports>

home | help