Embedded learning log - A foray into Linux specifics: dmesg, tty and playing with minicom
This post is part of a series where I log my experience getting into embedded software development. The overarching goal is to use the ESP8266 RTOS SDK to learn how to operate my ESP8266 board using an RTOS and to learn how to integrate the Memfault real-time SDK. Disclaimer: I work for Memfault as a full-stack engineer, mostly on web stuff. Here are the other posts in the series:
In a previous post in this log I used
sudo dmesg | grep tty to find the serial port to which my board was connected. But what does
dmesg do and why am I looking for
Here’s what I know about
dmesg: it prints logs from the kernel. And here’s all my loose bits of unchecked knowledge about
- It stands for TeleTypewriter.
- In Linux, I can go to a different
- Some of the
#s are used by specific processes. In my case,
CTRL+ALT+F1takes me to GDM (which shows my log-in screen), and
CTRL+ALT+F2takes me back to my current Xorg session.
- I’ve used
CTRL+ALT+F#with numbers other than 1 and 2 to get me out of problems with me Xorg session.
- I suppose that means processes are tied to
ttys are somehow pointers to processes.
Time to strengthen this knowledge.
tty- print the file name of the terminal connected to standard input
~/Development/toastboard/hello_world => tty /dev/pts/3
I have three terminals open, and that one was number 3 apparently.
A TTY is transitively a software emulation of a TeleTypewriter, or a pseudoterminal. In Linux, there’s the concept of a pseudoterminal master and pseudoterminal slaves.
The file /dev/ptmx is a character file with major number 5 and minor number 2, usually of mode 0666 and owner.group of root.root. It is used to create a pseudoterminal master and slave pair. When a process opens /dev/ptmx, it gets a file descriptor for a pseudoterminal master (PTM), and a pseudoterminal slave (PTS) device is created in the /dev/pts directory. Each file descriptor obtained by opening /dev/ptmx is an independent PTM with its own associated PTS, whose path can be found by passing the descriptor to ptsname(3).
I suppose this is what terminal emulators such as Kitty do when they open: they get assigned a file under
/dev/pts. It must also be what
tmux does when I open a new pane or window.
So now I know!
sudo dmesg prints kernel logs and we try to find matches for
tty, which should give us logs for when devices connected. When devices connect, Linux will create files for them under
/dev, and these show up as
/dev/tty*, in my case
/dev/ttyUSB0 because my device is the first on the USB serial port adapter.
On a first attempt to verify that serial communication to my development board works, I did this:
~/Development/toastboard/hello_world => minicom -p /dev/ttyS4 minicom: argument to -p must be a pty
pty is a pseudoterminal. I guess if I open a new terminal, it’ll be assigned
/dev/pts/4 and then I can communicate to it? I’m curious to try it out.
Open a new terminal and then on terminal
minicom -p /dev/pts/4
Type some stuff… and it appears on my newest terminal! Cool! Trying to type on
/dev/pts/4 produces the same characters on
/dev/pts/3, but some get dropped. I’m curious to find out why, but let’s get back to the main course.