A Serial Monitor for macOS
macOS ships no graphical serial monitor. Here is how to find your device under /dev/cu, why screen and cu are awkward, and a better native option.
On Windows, when you need to look at a serial port you reach for PuTTY, RealTerm, or the vendor's tool. On macOS there is no equivalent that ships with the system. You get two command-line utilities, screen and cu, and that is the whole toolbox. For a lot of people this is the first surprise after switching to a Mac for embedded work.
This post covers how to find and open a serial device on macOS with what you already have, why those tools get frustrating quickly, and what to use instead.
Finding the device
Plug in your board or adapter and list the serial devices:
ls /dev/cu.*
You will see something like /dev/cu.usbserial-1420 for an FTDI or CP210x adapter, or /dev/cu.usbmodem14201 for a board with native USB such as a Uno R4 or a Teensy.
You may notice each adapter also has a /dev/tty.* twin. The difference is real and worth knowing. The tty.* device waits for a hardware carrier-detect signal before it opens, which is a leftover from the modem era and usually causes a program to hang. The cu.* device (short for "call-up") opens immediately. For talking to a microcontroller, always use cu.*. Serial Studio only lists the cu.* devices for exactly this reason.
Using screen, and why it grates
The quickest look is screen, giving it the device and the baud rate:
screen /dev/cu.usbserial-1420 115200
Text starts scrolling. That is about as far as the good news goes:
- There is no scrollback. Whatever left the top of the window is gone.
- There are no timestamps and no way to plot anything. You are reading raw text.
- Exiting is cryptic. You press
Ctrl-A, thenK, then confirm withy. Nobody guesses that the first time. - If you close the terminal window without exiting cleanly, the session stays attached in the background and holds a lock on the port. The next time you connect you get "Resource busy" and have to hunt down the stray
screenprocess.
cu is the other built-in. It has its own lock-file quirks and the same fundamental limits: it is a text pipe, not an instrument.
A note on drivers
Recent versions of macOS include drivers for the common FTDI and CP210x chips, so those adapters usually appear under /dev/cu.* with no extra install. The cheaper CH340 and CH341 clones sometimes still need a driver. If ls /dev/cu.* does not show your adapter after plugging it in, an outdated or missing CH340 driver is the usual cause.
A native app that does the rest
Serial Studio is a native macOS application (a universal build for both Apple Silicon and Intel), and it fills the gap those command-line tools leave. It lists the cu.* devices in a dropdown, so there is no path to type. The console gives you proper scrollback and a hex view for binary data. And because it is built for telemetry, it does the thing screen never will: if your device streams numbers, Quick Plot draws them as live graphs, and you can export the session to CSV.
You do not have to give up the terminal. screen is fine for a five-second sanity check. But when you actually want to read the data, watch it move, and keep a record of it, a real graphical monitor is the difference between squinting at scrolling text and seeing what your device is doing.
If you are new to serial ports in general, the companion post How to Read Data From a Serial Port covers baud rates and framing before you connect.
Comments