Monitorare, sniffare, fare debug e loggare la porta seriale

In questa pagina impari tre modi per analizzare la comunicazione seriale tra dispositivi (PC, controller, schede embedded) e perché COM Sniffer di SerialTool è spesso la soluzione migliore: solo software, senza cablaggi, trasparente e adatta a monitor/sniff/debug/logger anche per giorni.

Che cosa troverai

• Capitolo 1: cosa significa monitorare una porta COM, come sono fatti i byte/bit e come la seriale li trasmette (start/dati/parità/stop), più TX/RX e baud rate.
• Capitolo 2: il metodo classico di sniffing fisico con due adattatori USB↔seriale: colleghi solo gli RX alle linee TX dei due dispositivi e metti le masse in comune. Perfetto per un monitor/logger semplice.
• Capitolo 3: lo stesso concetto applicato a un Master PC che parla con un Target Device tramite convertitori USB↔seriale/RS‑232/RS‑485 (stesso protocollo, cambiano i livelli fisici). Qui trovi anche una panoramica di Modbus RTU/ASCII e dei casi d’uso industriali/CNC/embedded (debug, firmware, reverse engineering).
• Capitolo 4: perché spesso conviene usare COM Sniffer di SerialTool: un serial port monitor basato su driver kernel Windows che intercetta dati, IOCTL, segnali e parametri delle porte già aperte da altri software. Nessun cavo, filtri precisi, export in pcap/pcapng (es. per Wireshark) e stabilità per acquisizioni prolungate.

Se il tuo obiettivo è analizzare rapidamente un software di terze parti o monitorare in continuo la tua applicazione, inizia da Capitolo 4 – COM Sniffer: è la via più rapida per monitor, sniff, debug e logger senza montare un banco di prova.

Capitolo 1 – Monitorare i dati dalla porta COM

1.1 Cosa significa “monitorare una porta seriale”

Monitorare una porta COM (seriale) significa osservare in tempo reale i byte che transitano sulle linee di comunicazione tra PC e dispositivo. Nel monitoraggio tipicamente si distinguono le due direzioni: TX (trasmissione dal PC al dispositivo) e RX (ricezione dal dispositivo al PC). Un buon monitor mostra i dati sia come testo (interpretazione ASCII/UTF‑8) sia come esadecimale (HEX), cioè i byte grezzi.

1.2 I byte e i bit: rappresentazione logica vs. trasmissione seriale

Quando scriviamo il testo Hello, i cinque caratteri vengono convertiti in cinque byte ASCII: 48 65 6C 6C 6F in esadecimale. Un visualizzatore di byte come quello di SerialTool permette di vedere la forma d’onda logica dei singoli bit all’interno di ciascun byte.

Come si leggono i byte nella vista logica

• Il grafico evidenzia 8 bit di dati per ciascun byte (b7…b0). In memoria possiamo elencarli come MSB→LSB (bit più significativo verso quello meno significativo).
• Questa rappresentazione non include ancora gli elementi del protocollo seriale (start, parità, stop) e non riflette l’ordine di trasmissione su filo.

Come vengono trasmessi i byte sulla porta seriale

Sulla linea fisica RS‑232/TTL, ogni byte è incapsulato secondo il frame seriale:

Start (1 bit, livello “0”) → Dati (7/8 bit, inviati LSB‑first) → Parità (opzionale) → Stop (1 o più bit, livello “1”).

• Idle: la linea del TX è stabile a livello logico “1” (mark). Quindi troveremo il segnale a 1 fino all'arrivo del bit di Start
• Bit Start: un fronte verso “0” (space) segnala l’inizio del byte.
• Bit Dati: i bit di dati sono trasmessi in ordine LSB‑first (il bit meno significativo per primo).
• Bit Stop: ritorno a “1” per 1 o più bit; assicura il ripristino dell’idle.
• Baud rate: determina la durata di ciascun bit (es. a 9600 baud ogni bit dura ~104,17 µs).

Nota su RS‑232 vs. TTL

• Nel livello TTL (UART a 3.3 V/5 V), “1” è alto e “0” è basso.
• Nel livello RS‑232 i livelli di tensione sono invertiti (logico “1” ≈ tensione negativa, logico “0” ≈ positiva), ma la sequenza start/dati/stop rimane identica.

Esempio rapido: tempo per trasmettere “Hello”

Con configurazione 8N1 (1 start, 8 dati, 1 stop) ogni byte usa 10 bit su linea. A 9600 baud, sono ~960 byte/s. Per 5 byte (“Hello”) servono ~5,21 ms.

Capitolo 2 – Monitorare/sniffare, debuggare e loggare una comunicazione seriale con due USB-seriale

2.1 Obiettivo

Creare un monitor/sniffer seriale non invasivo per osservare, fare debug e log (logger) dei byte scambiati tra Device 1 e Device 2 senza interrompere la loro comunicazione.

2.2 Collegamenti elettrici (tapping passivo)

• COM5 (USB-seriale #1): collega il pin RX dell’adattatore al TX di Device 1 (sniff dei dati spediti da Device 1).
• COM6 (USB-seriale #2): collega il pin RX dell’adattatore al TX di Device 2 (sniff dei dati spediti da Device 2).
• GND in comune: collega la massa dei due adattatori USB-seriale a quella dei due dispositivi (referenza comune dei livelli logici).
• Non collegare i TX degli adattatori al bus: restiamo in ascolto “ad alta impedenza”, così non disturbiamo la linea.
• Non alimentare i dispositivi dai 5V/3.3V degli adattatori (VCC non usato nel tapping).

Nota livelli: questo metodo vale per UART/TTL (3.3/5 V) o per bus con driver compatibili. Per RS-232 (±12 V) non collegare direttamente un RX TTL: serve un convertitore RS-232↔USB o un tap/monitor RS-232 specifico. In altre parole, se vuoi fare il logger di una linea RS-232, usa l’hardware adatto.

2.3 Individuare e impostare il baud rate

Per decodificare correttamente i dati, baud rate e parametri devono coincidere con quelli dei dispositivi (es. 9600/8N1). Se non sono noti:

• Consulta la documentazione del dispositivo o del protocollo.
• Prova i baud più comuni (9600, 19200, 38400, 57600, 115200...).
• Misura con oscilloscopio/analizzatore logico: la durata del bit è Tbit=1/baud (es. a 9600 baud ≈ 104,17 µs per bit).

2.4 Apertura delle due COM con SerialTool

1. Collega gli adattatori: il sistema vedrà due porte (nell’esempio COM5 e COM6).
2. In SerialTool, apri due sessioni:
   • Sessione A → COM5, imposta baud/bit pari/stop come i dispositivi (es. 115200/8N1).
   • Sessione B → COM6, stessi parametri della Sessione A.
3. Metti entrambe in monitor (solo RX): vedrai su COM5 i byte che trasmette Device 1 e su COM6 quelli di Device 2.
4. Per il debug usa la vista HEX e gli timestamp; per il logger salva su file (CSV/pcap/grezzo) per analisi successive.

In questo scenario agisci come man-in-the-middle fisico ma in modalità passiva: monitori/sniffi i dati a livello elettrico senza alterare i segnali.

2.5 Pins di controllo esclusi in questo esempio

Lo schema si concentra sui dati TX/RX e non monitora i pin di controllo (es. RTS/CTS, DTR/DSR, DCD, RI). Per molte applicazioni non servono; se però i dispositivi usano hardware flow control, potresti voler “tappare” anche quelle linee con sonde dedicate.

Approfondimenti: RS-232 (Wikipedia), RS-232 – Signals, Hardware flow control, UART.

2.6 Suggerimenti pratici per un monitor/sniffer stabile

• Usa cavi corti e GND ben comune; evita anelli di massa.
• Ricorda che la maggior parte dei driver UART tollera due ingressi RX (fan-out) su una linea TX, ma evita carichi inutili.
• Allinea sempre i parametri di porta fra le due sessioni (baud, dati, parità, stop).
• Per RS-485 o bus differenziali servono adattatori specifici e regole diverse di tapping.

Con questa tecnica puoi monitorare, sniffare, fare debug e loggare in modo affidabile le comunicazioni seriali tra due apparati, usando strumenti comuni: due USB-seriale + SerialTool.

Capitolo 3 – Sniffare/monitorare la seriale tra “Master PC” e “Target Device”

3.1 Scopo e concetti

Vogliamo monitorare e sniffare i byte che transitano tra un software sul Master PC e il Target Device, senza interferire con la comunicazione. È un tipico man-in-the-middle fisico passivo: due adattatori USB-seriale collegati solo in RX “leggono” ciascuna direzione. Questo è utile per debug, analisi protocollare e come logger per audit o reverse engineering.

3.2 Collegamenti (passo-passo)

1. COM5 (Sniffing PC) → collega l’RX dell’adattatore alla TX del Device (ascolta ciò che invia il Target).
2. COM6 (Sniffing PC) → collega l’RX dell’adattatore alla TX del PC (ascolta i comandi del Master PC).
3. GND comune tra i due adattatori e i due dispositivi (riferimento condiviso).
4. Non collegare i TX degli adattatori del Sniffing PC: restiamo solo in ascolto (alta impedenza), senza disturbare la linea.

In SerialTool apri due sessioni: COM5 e COM6. Imposta in entrambe baud rate e formato identici a quelli usati dal Master/Device (es. 115200-8N1). Se non conosci il baud, prova i valori comuni o misura la durata del bit con un oscilloscopio/analizzatore logico.

3.3 Stesso protocollo, livelli diversi: UART/TTL, RS-232, RS-485

Il protocollo seriale asincrono (start, 7/8 bit dati inviati LSB-first, parità opzionale, 1+ stop) è lo stesso. Cambia solo il livello fisico con cui i bit viaggiano sul filo:

• UART/TTL (3.3 V/5 V): segnali single-ended, “1” alto / “0” basso.
• RS-232: livelli invertiti e a tensione ± (tipicamente ±3…±12 V), sempre single-ended.
• RS-485: differenziale su coppia A/B, spesso half-duplex multi-drop; consigliata massa di riferimento comune.

Perciò usa l’adattatore corretto: USB↔TTL per UART, USB↔RS-232 per RS-232, USB↔RS-485 per RS-485. Il frame resta identico, ma i livelli elettrici e la topologia (differenziale/terminazioni) cambiano.

3.4 Dove si usa (CNC, industriale, altro)

Questo collegamento è comune in ambito CNC, macchine industriali, PLC/HMI, robotica, bilance, POS, sensori, strumenti di misura, automazione building e in generale in ogni sistema dove un PC/PLC comanda un dispositivo via seriale. Il metodo di sniffing qui descritto consente di monitor/sniff/debug/log il traffico per analisi funzionale, diagnosi di guasti, tracciamento comandi e validazione.

3.5 Modbus su seriale

Spesso la porta seriale veicola Modbus RTU/ASCII, protocollo master/slave (oggi client/server) molto diffuso in ambito industriale. Il Master invia richieste (lettura/scrittura di coil e register) e il Device risponde. SerialTool include un client Modbus per interrogare rapidamente i registri (diagnosi e test), oltre al monitor/hex viewer utile per vedere i frame grezzi (indirizzo, funzione, dati, CRC).

3.6 Firmware update e parametrizzazione

Nel mondo embedded la seriale è usatissima per aggiornare firmware o passare parametri al Target. Esempi: bootloader su schede custom, ecosistemi tipo Arduino, microcontrollori vari. Qui lo sviluppatore può avere due esigenze:

1. Debug dell’applicazione che dialoga con il Target (verifica dei comandi, timing, errori).
2. Reverse engineering di un protocollo esistente (c’è un software Master “chiuso” che parla con una scheda; sniffo per comprenderne i messaggi e poi replicarli con un mio software).

3.7 Note pratiche e strumenti

• Questo setup richiede tipicamente due PC (il Master e lo Sniffing PC) e almeno due convertitori USB-seriale per lo sniffing bidirezionale.
• Per RS-232 usa un tap/converter RS-232; per RS-485 collega un’interfaccia in sola ricezione ai morsetti A/B (rispettando terminazioni e polarità). Su RS-485 half-duplex riconoscerai la direzione dal contesto temporale.
• Escludiamo i pin di controllo (RTS/CTS, DTR/DSR, DCD, RI); se il sistema usa hardware flow-control, valuta sonde dedicate.
• In SerialTool puoi attivare viste HEX, timestamp, salvataggio come logger (file testo/CSV/pcap) per analisi successive.

In sintesi: stesso protocollo seriale (frame asincroni), diversi livelli fisici (TTL/RS-232/RS-485). Con il tapping passivo a due RX e un software come SerialTool puoi monitorare, sniffare, fare debug e loggare in modo affidabile la comunicazione tra Master PC e Target Device.

Capitolo 4 – COM Sniffer: monitor/sniff/debug/logger senza cablaggi fisici

4.1 Cosa fa COM Sniffer

COM Sniffer è un serial port monitor che intercetta la comunicazione sulla porta COM già aperta da un altro programma, permettendo di monitorare, sniffare, fare debug e loggare l’intero traffico (TX/RX) senza toccare i cavi, senza hardware aggiuntivo e senza influire sul funzionamento del Master PC o del Target Device.

4.2 Come ci riesce: kernel driver

Il cuore è un driver kernel per Windows che si inserisce nello stack della porta seriale e osserva in modo selettivo:

• Buffer dati letti/scritti (TX ↔ RX) con separazione direzionale chiara;
• IOCTL (Input/Output Control): aperture/chiusure, impostazioni di baud/parità/stop, time-out, segnali di controllo (RTS/DTR/CTS/DSR/DCD/RI), ecc.;
• Eventi/SEGNALI e stato della porta (line status, modem status).

Il driver è potente ma l’interfaccia è semplice: puoi filtrare per tipo (solo dati, solo IOCTL di configurazione, solo segnali, ecc.) così da concentrarti su ciò che ti interessa. È pensato per acquisizioni prolungate (ore/giorni) in maniera stabile per monitorare la tua app o una terza parte. Nota: funziona solo su Windows perché si basa su driver in kernel mode.

4.3 Perché è meglio (in molti casi) del cablaggio fisico

• Nessun “laboratorio” di due PC + due USB-seriale: risparmi tempo e riduci i punti di guasto.
• Zero impatto elettrico: non carichi le linee, non rischi loop di massa.
• Vedi tutto ciò che passa tra app e driver: dati, IOCTL, segnali, anche su più porte simultanee.

4.4 Log ed export per analisi protocollare

Puoi salvare direttamente su file come logger (testo/CSV) oppure esportare in pcap/pcapng per analisi in Wireshark. Questo è utilissimo per protocolli industriali come Modbus RTU/ASCII: con i frame e i timestamp puoi validare timing, CRC, sequenze di funzione, ecc.

4.5 Cosa puoi osservare

• Dati TX/RX separati, in ASCII e HEX, con timestamp;
• Parametri di porta impostati dal software (baud, 7/8 bit, parità, stop, time-out);
• Segnali e IOCTL di controllo (RTS, DTR, CTS, DSR, DCD, RI) e cambi di stato;
• Eventi di open/close e errori (overrun, framing, parity).

4.6 Quando usarlo

• Debug della tua applicazione seriale senza modificare codice/cablaggi;
• Monitoraggio prolungato di applicazioni di terze parti per audit/diagnostica;
• Reverse engineering di protocolli proprietari (quando lecito) per replicare funzioni con un tuo software;
• Verifica di protocolli standard (es. Modbus) e dei segnali di handshaking.

4.7 Note e approfondimenti

COM Sniffer lavora a livello di sistema con la logica del protocollo seriale asincrono (start/dati/parità/stop). Se l’applicazione usa diversi livelli fisici (UART/TTL, RS-232, RS-485) la cattura rimane identica, perché avviene al di sopra del livello elettrico, nello stack della porta COM di Windows.

Link utili: Serial port · UART · RS-232 · RS-485 · IOCTL · Windows kernel drivers · Wireshark · Modbus.

In breve: COM Sniffer di SerialTool è una soluzione “software-only” per monitor, sniff, debug e logger della porta seriale aperta da altri programmi, con un driver kernel affidabile, filtri mirati e export per analisi avanzate.