First the serial, in this context generally refers to EIA RS-232C serial interface, or at least something more-or-less compatible with that (most notably electrically). Per standard, this would be DB-25 M for DTE
(Data Terminal Equipment - e.g. the terminal itself), and F for DCE
(Data Communication Equipment - e.g. the serial phone modem). The specification was written primarily to standardize the communication
between terminal and modem. E.g. one would have terminal, connect that
to modem, connect the modem to phone line (might be acoustic coupled,
or possibly direct connection), phone would generally dial up some
computer - well, actually a modem on the other end, which would go to
serial port on another computer - and even that often not directly, but through, e.g. port sharing equipment (e.g. to allow one to select which computer at a location that one wanted to connect to).
Also beware that just because it's, e.g. DB-25 or DE-9, doesn't
necessarily mean it's at all RS-232C or signal compatible with such,
so connecting the wrong things together could cause damage. However
RS-232C specification is such that improperly interconnecting two
RS-232C interfaces, regardless of how they're miswired between each
other and/or themselves, shouldn't cause any electrical damage (in about
40 years experience, I've only seen one fail in such a case). So, e.g.,
DB-25 and DE-9 may be Centronics parallel, or SCSI, or video (e.g.
MDA or CGA), among many possibilities other than RS-232C, so
interconnecting electrically incompatible could be quite bad and
damaging.
However, even early on, the specification wasn't always strictly
followed, e.g. though DTE calls for M, many terminal manufacturers would
in fact make their connectors F rather than M (my guess is to not have
to deal with servicing bent pins on the connector for the terminal
itself - easier to replace an external cable if the pins get bent on the
cable end instead). And, though the IBM PC and PC-XT followed the
standard, using DB-25M for their DTE ports that they supplied via
adapter card(s), when it came to the PC-AT, they switched to DE-9 M for
DTE, so in subsequent years, that became more common - especially on the computer end, though most modems still used DB-25F. The full RS-232C specification supports two full sets of communication lines. Most of
the time only one set is used, so between that, and some other rarely
used connections, that made use of DE-9 feasible for most of the more
common purposes. In fact if software flow control is used,
communication can be done with as few as three for basic serial
communication, but that may drop some functionality - e.g. like RI for
Ring Indicator/Indication signal from the modem. Though many modems can
or will send the string RING to indicate line is RINGing, that may not
be distinguished from transmission of such characters that isn't an
actual RINGing telephone line - hence, e.g. a separate RI signal line
for that. Other hardware may further modify things, e.g. with original specification and staying within it, maximum achievable distance would
be 15m/50ft., and maximum speed of 19200 bps. But with some tweaking of hardware specifications/tolerances, and low cap(acitance) wiring, that
could be extended up to 200' in many cases, and speeds could also
potentially go much higher, so about 56K is the limits on what could be
handled over a typical analog phone line (due to its signal
characteristics and limitations), but with direct wired connection, significantly higher speeds can be achieved, and notably including newer standards that are also generally backwards compatible.
153600 or something close to that is probably the highest that's
typically supported on any such interfaces, and not all such hardware necessarily supports such higher speeds. In fact relatively early
modems had a top speed of 300 bps - for text, that's generally far below
the speed most people can read at.
So, that's the serial bit - originally primarily aimed for between data/computer terminal (e.g. vt-100, Teletype 33-ASR, etc.) and modem
(or directly to computer), but has been used more generally for a fair
amount of communication beyond that (e.g. two computers can directly communicate with each other over a serial connection - e.g. UUCP worked
as dial-up based networking, or could likewise work over directly
connected serial lines). But because of its popularity and (relative) standardization, it got used for many additional things (e.g. serial
printer).
And console - notably computer console. That concept goes way back.
Generally referred to the primary input/output/display on the computer
itself, intended for computer operator. Notably to be used to control
the computer to view status, start and boot it and control that, stop
it, etc. On older computers it may be nothing more than a bunch of
lights and toggle switches (e.g. early DEC PDP-11 series). Some would
have a hex keypad for input, and might have some type of digital
display. As hardware became more capable, most systems moved to the
console being some type of terminal or terminal-like device, perhaps
with additional controls and functionality, but mostly looking and
acting like a terminal. And, many computer systems evolved so they'd
use a serial terminal as their console device - so that would serve as
the input and output to control basic operations such as boot, etc. For
many computers, this is still an option. E.g. Raspberry Pi can do this
- it has a serial-like interface ... 3 pins ... but at TTL rather than
RS-232C levels, but a simple hardware circuit can shift that, or one
could connect as-is to use such for two Raspberry Pis to be able to
directly communicate over such.
In the land of Linux, though there may be more serial devices, the first
two are /dev/ttyS0 and /dev/ttyS1. Those are the first and second
serial ports, and can be used as serial console. In fact Linux can do
quite a variety of consoles, and can even output to more than one -
though it will only use one as console input. Linux can do display
adapter console (e.g. whatever the typical screen built-in to the
computer is, or the display that's connected to it via cable - and
likewise keyboard for input), it can do serial console (e.g. for
terminal), it can do console over network, and if I recall correctly, it
even has parallel port console capabilities.
So, Linux, compiled in and/or from hardware detection, or from arguments
passed when booting kernel, it will pick console device(s), it will use
only one for input, but can use more than one for output. Many boot
loaders, notably including GRUB, can also deal with at least some
different types of consoles (e.g. the typical built-in or installed
graphics card and connected keyboard, or serial).
So, tty1-tty63 are virtual consoles on Linux, and one can switch among
them, though commonly tty1-tty4 are used, possibly more up to tty12, but
most commonly additional beyond tty12 aren't activated. There's also
tty0, which is always the current active virtual console. So, that's
what Linux will typically use by default, if it has relevant hardware
for that.
Here are example arguments from a running kernel:
console=tty0 console=ttyS0,9600n8
That first specifies the more typical console - that would be via
display adapter and attached keyboard. The second is for serial, and
also specifies additionally some communication parameters to set on the interface. In the case when more than one such console= argument is
present, the last is used to specify what is used for console input, and
all are used for console output. Now, that particular host happens to
be VM, so that serial is virtual rather than physical, but within the VM infrastructure there are ways to connect to and use that virtual serial
port, including for input and output, quite as if one were using it via
an actual physical serial terminal. And I do also have physical host
hardware where I've set them up to be able to use actual serial terminal
for console, though I don't have them doing that presently.
Note also that enabling login in regular multi-user mode on serial ports
is different than serial console. May use same port for both, but if,
e.g., login isn't enabled on the serial port - even if it's serial
console, once the host is up and running in regular multi-user mode,
there's no login prompt there nor listening process to allow login
there.
On Wed, Jul 30, 2025 at 4:59 PM mick.crane <
mick.crane@gmail.com> wrote:
I've never really known what a serial console is.
Say in relation to a Raspberry Pi or Arduino
I assumed a serial console was a device with a screen and keyboard.
When people talk about a serial console they are talking about
connecting a Debian PC to a device with a parallel, wired cable to a
parallel port or an adaptor on a PC and emulating this console thing
with software?
Like a telnet connection?
mick
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)