Board development ESP32 yang terhubung melalui bridge USB-to-UART CH341 tidak muncul di Fedora sebagai port COM seperti di Windows. Linux mengikat interface USB tersebut ke driver serial lalu mengekspos character device seperti /dev/ttyUSB0.

Koneksi yang bekerja dapat menghasilkan pesan kernel berikut:

usb 5-1: ch341-uart converter now attached to ttyUSB0

Baris itu mengonfirmasi enumerasi USB, binding ke driver serial ch341, dan pembuatan ttyUSB0. Karena itu, path yang digunakan flasher atau serial monitor adalah /dev/ttyUSB0.

ttyUSB0 berasal dari bridge USB-UART

Banyak board development ESP32 menempatkan bridge USB-UART di antara konektor USB dan UART microcontroller. Keluarga bridge yang umum antara lain CH340/CH341, CP210x, dan perangkat FTDI.

Pada board CH341, alurnya secara konseptual adalah:

ESP32 UART
    |
CH341 USB-UART bridge
    |
USB
    |
Linux ch341 driver
    |
USB serial core
    |
/dev/ttyUSB0

Device node tersebut milik interface serial yang diekspos oleh bridge. Itu bukan “port ESP32” universal. Board dengan bridge berbeda dapat terikat ke driver lain tetapi tetap memperoleh nama ttyUSB*.

Varian dan board ESP32 dengan fungsi native USB serial dapat muncul sebagai /dev/ttyACM0. Sumber yang dapat diandalkan adalah state perangkat pada mesin saat ini, bukan nama port yang ditebak dari model board.

Baca log kernel, jangan menebak port

Di Fedora, pemeriksaan cepat dapat dilakukan dengan:

sudo dmesg | grep tty

Koneksi CH341 dapat menampilkan:

[ 4353.664165] usb 5-1: ch341-uart converter now attached to ttyUSB0

Token terakhir langsung dipetakan ke path device:

ttyUSB0 -> /dev/ttyUSB0

Untuk melihat perubahan secara live saat board dihubungkan, gunakan kernel journal:

sudo journalctl -kf

Jika kernel melaporkan attachment berhasil ke ttyUSB0, enumerasi USB dan binding driver sudah berjalan cukup jauh untuk membuat endpoint serial. Kegagalan flashing setelah titik tersebut tidak seharusnya langsung dianggap sebagai driver USB yang hilang.

Pesan disconnect dan attach menunjukkan perubahan state

Log dapat berisi:

ch341-uart converter now attached to ttyUSB0
ch341-uart ttyUSB0: ch341-uart converter now disconnected from ttyUSB0
ch341-uart converter now attached to ttyUSB0

Baris tengah berarti perangkat serial sebelumnya dilepas. Baris terakhir berarti sebuah interface terpasang kembali.

Urutan itu sendiri tidak membuktikan driver bermasalah. Koneksi fisik yang terputus dan tersambung lagi, USB reset, gangguan daya, atau kejadian enumerasi ulang lain dapat menghasilkannya. Siklus disconnect/reconnect berulang tanpa tindakan pengguna lebih penting untuk diperiksa; cek kabel, konektor, daya USB, hub, dan board sebelum melakukan debugging aplikasi flashing.

Pengujian yang berguna adalah:

sudo journalctl -kf

Hubungkan board satu kali, lalu perhatikan apakah perangkat tetap attached.

Konfirmasi device node yang tersedia sekarang

Log kernel menyimpan riwayat, jadi verifikasi node yang aktif secara terpisah:

ls -l /dev/ttyUSB*

Untuk perangkat native USB serial, periksa juga:

ls -l /dev/ttyACM*

Jika tidak ada file yang cocok, perangkat saat ini tidak tersedia pada pola tersebut walaupun entri dmesg lama mencatat koneksi yang berhasil.

udevadm dapat memeriksa properti perangkat yang aktif:

udevadm info --query=property --name=/dev/ttyUSB0

Properti vendor USB, product, dan identifier berguna ketika beberapa adapter terhubung.

ttyUSB0 bukan identitas hardware permanen

Suffix angka bergantung pada alokasi perangkat saat itu. Board yang memakai /dev/ttyUSB0 dapat berubah menjadi /dev/ttyUSB1 jika adapter serial lain memperoleh nomor lebih dahulu.

Untuk script, periksa symlink udev persisten jika tersedia:

ls -l /dev/serial/by-id/

Entri by-id menunjuk ke node ttyUSB* atau ttyACM* yang aktif dengan memakai informasi identitas yang diberikan perangkat dan udev. Tidak semua adapter menyediakan identitas unik yang berguna, jadi periksa isi direktori tersebut alih-alih menganggap link tertentu pasti tersedia.

Hard-code /dev/ttyUSB0 masih masuk akal untuk setup sederhana dan sementara. Path udev yang stabil lebih aman jika otomasi harus membedakan beberapa adapter serial.

Pisahkan masalah deteksi dari permission

Keberadaan /dev/ttyUSB0 tidak menjamin user saat ini dapat membukanya. Periksa node dan ACL-nya:

ls -l /dev/ttyUSB0
getfacl /dev/ttyUSB0

Perintah tersebut menunjukkan ownership, mode bit, dan entri access-control list. Fedora dapat memberikan akses device melalui ACL dari udev dan logind tergantung session dan kelas perangkat, sementara konfigurasi lain mengandalkan permission group.

Pisahkan jenis kegagalannya:

device tidak ada    -> tidak ada /dev/ttyUSB0 yang aktif
device tersedia     -> /dev/ttyUSB0 ada
access denied       -> node ada, aplikasi tidak dapat membukanya
device busy         -> proses lain mungkin sedang memakai port

Mengubah keanggotaan group atau permission device sebelum memeriksa ownership dan ACL dapat menutupi penyebab sebenarnya.

Berikan path yang sudah diverifikasi ke tool flashing

Setelah log dan device node sama-sama menunjukkan /dev/ttyUSB0, gunakan path tersebut pada aplikasi.

Arduino CLI menerima port serial melalui option port:

arduino-cli upload -p /dev/ttyUSB0 ...

Pada esptool:

esptool --port /dev/ttyUSB0 flash-id

Command esptool yang tepat dapat berbeda menurut versi yang terpasang, tetapi path serial Linux tetap merepresentasikan endpoint yang sama.

Batas diagnosis ini berguna: log kernel menunjukkan apakah interface USB-UART berhasil attached, /dev menunjukkan apakah endpoint masih tersedia, permission menentukan apakah user boleh membukanya, dan tool flashing menangani protokol setelah itu. Memisahkan lapisan tersebut membuat sumber kegagalan serial ESP32 jauh lebih mudah ditemukan.

Linux Fedora ESP32 USB Serial