LATEST: New posts daily — circuits, tech news, and DIY builds from CircuitMasters
20 Terminal Commands Every Electronics Engineer Should Know
Electronics Linux Firmware Embedded Systems Terminal

20 Terminal Commands Every Electronics Engineer Should Know

4 min read

What You'll Be Able to Do

After reading this, you'll stop fumbling through GUIs and start controlling your hardware, flashing firmware, debugging serial ports, and automating tedious tasks directly from the terminal. These 20 commands aren't just productivity tricks — they're the difference between an engineer who waits for tools and one who builds them.

Before You Start

Prerequisites: A Linux, macOS, or WSL2 environment. Most of these commands work identically across all three. A basic understanding of file paths helps, but it's not required.

Tools needed:

  • A terminal emulator (Terminal, iTerm2, Windows Terminal with WSL2)
  • A USB-to-serial adapter or microcontroller board for serial commands
  • Package manager: apt, brew, or pacman
  • Optional: an Arduino, Raspberry Pi, or ESP32 to make the firmware commands immediately practical

Safety note: Never run commands as root unless explicitly required. Flashing the wrong device or wiping the wrong partition will ruin your day. Always double-check device paths like /dev/ttyUSB0 before writing anything to them.

Electronics circuit detail
A closer look at the circuit in action

Understanding The Basics

Your operating system treats hardware as files. Serial ports, USB devices, GPIO interfaces — they all live somewhere under /dev/. This is the UNIX philosophy at its most powerful: everything is a file, and files can be read, written, and piped. Once that clicks, the terminal stops feeling like a black box and starts feeling like a direct wire to your hardware.

Commands operate in a pipeline. The output of one command feeds the input of the next using |. That single character is the foundation of every automation script you'll ever write. Understand it early.

Step-By-Step Guide — 20 Commands

  1. List connected USB and serial devices: Run ls /dev/tty* before and after plugging in your device. The new entry — likely /dev/ttyUSB0 or /dev/ttyACM0 — is your target.
  2. Identify USB hardware: Run lsusb to list all connected USB devices with vendor and product IDs. Expected result: your microcontroller appears with a recognizable name like Silicon Labs CP210x.
  3. Check kernel messages for device errors: Run dmesg | tail -20 immediately after plugging in hardware. Any driver failures or connection issues appear here first.
  4. Open a serial monitor: Use screen /dev/ttyUSB0 115200 to connect at 115200 baud. Press Ctrl+A then K to exit. This replaces any GUI serial monitor.
  5. Communicate via serial with minicom: Run minicom -D /dev/ttyUSB0 -b 9600 for a more configurable serial session. Set hardware flow control to off for most hobby hardware.
  6. Flash firmware with avrdude: Run avrdude -c arduino -p atmega328p -P /dev/ttyUSB0 -U flash:w:firmware.hex. Verify the port and MCU part number match your board before executing.
  7. Flash an ESP32 or ESP8266: Use esptool.py --port /dev/ttyUSB0 write_flash 0x0 firmware.bin. Hold the BOOT button during upload if auto-reset fails.
  8. Measure file sizes of firmware binaries: Run ls -lh *.bin *.hex to verify your compiled output. A suspiciously large or zero-byte file means the build failed silently.
  9. Convert binary to Intel HEX: Use objcopy -O ihex firmware.elf firmware.hex when your toolchain outputs ELF format. This is standard in GNU ARM Embedded toolchains.
  10. Inspect ELF binary sections: Run size firmware.elf to see RAM and Flash usage broken down by text, data, and BSS segments. Know your limits before you hit them.
  11. Disassemble firmware: Use objdump -d firmware.elf | less to inspect assembly output. Invaluable when debugging optimized code that misbehaves at runtime.
  12. Monitor real-time serial output to a log file: Run cat /dev/ttyUSB0 | tee output.log to display and simultaneously capture serial data. Your debugging session is now documented automatically.
  13. Set serial port parameters manually: Use stty -F /dev/ttyUSB0 115200 cs8 -cstopb -parenb to configure baud rate, data bits, and parity without a monitor application.
  14. Ping a networked device (Raspberry Pi, ESP32 WiFi): Run ping 192.168.1.x to confirm your embedded device is alive on the network before attempting SSH or HTTP.
  15. SSH into a Raspberry Pi: Use ssh pi@raspberrypi.local. If that fails, substitute the IP address. Add -v for verbose output when troubleshooting connection issues.
  16. Transfer files to embedded Linux: Run scp firmware.bin pi@raspberrypi.local:/home/pi/ to copy files over the network without a GUI.
  17. Automate a build with make: Run make clean && make all in any project with a Makefile. Consistent builds, no IDE required.
  18. Search through large log files: Use grep -n "ERROR" debug.log to find every error line instantly. Add -i for case-insensitive matching.
  19. Watch a file update in real time: Run tail -f /var/log/syslog to monitor live system events while your hardware operates. Filter with grep for specific device messages.
  20. Kill a hung serial process: Run pkill -f screen or pkill minicom when a serial session locks your port. Frees the device without rebooting.
Electronics engineering
Engineering precision — every component counts

Pro Tips

  • Alias your most-used port: Add alias myboard='screen /dev/ttyUSB0 115200' to your ~/.bashrc. Open a serial monitor in two keystrokes forever.
  • Create a flash.sh script combining build and upload steps. One command to go from source code to running firmware.
  • Always verify device paths with ls /dev/tty* before flashing. Plugging in a second device shifts numbering from USB0 to USB1. Flashing the wrong one is a painful lesson.
  • Use tmux to run serial monitoring and code editing side-by-side in one terminal window. Split panes change how you debug embedded systems.
  • Pipe dmesg output through grep usb to filter out noise and isolate exactly what happened when you connected your hardware.

Frequently Asked Questions

Q: My device shows up as /dev/ttyACM0 sometimes and /dev/ttyUSB0 other times. Why?
A: ACM devices use the CDC-ACM protocol (common on Arduino Uno). USB devices use FTDI or CP210x chips. The protocol depends on the hardware, not the cable.

Q: I get "Permission denied" accessing /dev/ttyUSB0. How do I fix it?
A: Add yourself to the dialout group: sudo usermod -aG dialout $USER. Log out and back in. Done.

Q: Can I use these commands on Windows?
A: Yes — install WSL2 with Ubuntu. USB passthrough requires usbipd-win to forward devices into WSL2. It works, but takes 20 minutes of setup once.

Q: screen vs minicom — which should I use?
A: screen is faster to open. minicom gives you configuration menus for tricky baud rates and flow control. Start with screen, reach for minicom when things get complicated.

Watch the full tutorial on CircuitMasters YouTube →

▶ Watch more on CircuitMasters YouTube