2009-06-02 10 views
22

Sto eseguendo il debug delle comunicazioni con un dispositivo seriale e ho bisogno di vedere tutti i dati che fluiscono in entrambe le direzioni.Come posso monitorare i dati su una porta seriale in Linux?

Sembra che questo dovrebbe essere facile su Linux, dove la porta seriale è rappresentata da un file. C'è un modo in cui posso fare una sorta di "t-shirt bidirezionale", in cui dico al mio programma di collegarmi a un tubo che copia i dati in un file e lo rimescola anche dall'attuale dispositivo della porta seriale?

penso potrei anche sapere come scrivere una bestia, ma sembra non banale, soprattutto per ottenere tutti i ioctls passati attraverso di configurazione delle porte, ecc

Qualcuno ha già costruito una cosa del genere ? Sembra troppo utile (per le persone che eseguono il debug dei driver dei dispositivi seriali) non esistere già.

+6

Allora ... come hai fatto a finire a fare questo, esattamente? – detly

+1

Sì, sarei interessato anche a saperlo, dato che finora non sono riuscito a capire come usare strace per questo. Saluti! – mac

+1

Questo potrebbe essere di interesse per coloro che hanno difficoltà con la risposta data: http://unix.stackexchange.com/questions/12359/how-can-i-monitor-serial-port-traffic – geekboyUK

risposta

18

strace è molto utile per questo. Hai una visualizzazione di tutte le chiamate ioctl, con la struttura corrispondente decodificata. Le seguenti opzioni sembrano particolarmente utili nel vostro caso:

-e leggere = impostati

Eseguire un esadecimale e ASCII dump completo di tutti i dati letti dal descrittori di file elencati nella set specificato. Ad esempio, per vedere tutte le attività di input sui descrittori di file 3 e 5 usare -e leggere = 3,5. Si noti che questo è indipendente dalla normale traccia della chiamata di sistema di lettura (2) che è controllata dall'opzione -e trace = read.

scrittura -e = impostato

Eseguire un esadecimale piena e ASCII discarica di tutti i dati scritti su file descrittori elencati nella specificato set. Ad esempio, per visualizzare tutte le attività di produzione sui descrittori di file 3 e 5 utilizzare -e scrivere = 3,5. Si noti che questo è indipendente dalla normale traccia di la chiamata di sistema write (2) che è controllata dall'opzione -e trace = write.

+0

Perfetto, grazie! Sapevo che doveva esserci un modo semplice per farlo. Uso strace tutto il tempo, ma non l'ho nemmeno preso in considerazione per questo. – divegeek

+4

Sembra fantastico. Ma mi chiedo: come posso capire qual è il numero del descrittore di file rilevante? –

3

Ho trovato che lo pyserial è abbastanza utilizzabile, quindi se ci si trova in Python non dovrebbe essere troppo difficile scrivere una cosa del genere.

2

Un metodo semplice sarebbe quello di scrivere un'applicazione che ha aperto il lato master di una pty e la tty sotto test. Avresti quindi passare la tua applicazione tty al lato slave del pty come 'dispositivo tty'.

Si dovrà monitorare gli attributi Pty con tcgetattr() sul master Pty e chiamare tcsetattr() sul reale tty, se gli attributi modificati.

Il resto sarebbe un semplice select() su entrambi i file di copia di fd in modo bidirezionale e la copia su un registro.

+0

Come è possibile monitorare gli eventi di una modifica effettuata con 'tcsetattr()'? Verrebbero segnalati ascoltando con 'select'? – dolmen

+0

Il driver tty (e il sistema operativo) hanno solo un contratto sulla risposta select() con input e output. Il più semplice sarebbe chiamare semplicemente tcgetattr() dopo una chiamata di selezione avvenuta con successo, prima di elaborare qualsiasi input/output. – codeDr

1

Ho guardato un sacco di sniffer serial. Tutti si basano sull'idea di creare una porta seriale virtuale e di sniffare i dati da quella porta. Tuttavia, qualsiasi variazione di baud/parità/flusso interromperà la connessione.

Quindi, ho scritto il mio stesso annusatore :). La maggior parte delle porte seriali ora sono solo convertitori USB-seriale. Il mio sniffer raccoglie dati da USB tramite debugfs, li analizza e li invia alla console. Vengono inoltre registrate anche eventuali variazioni di baudrate, controllo di flusso, eventi di linea e errori seriali. Il progetto è nella fase iniziale di sviluppo e per ora è supportato solo FTDI.

http://code.google.com/p/uscmon/

+0

Questo aspetto interessante. Sarebbe bello se tu potessi aggiornare per usare qualsiasi vid/pid e dove cambiarlo? – not2qubit

+0

sarebbe bello se avesse un make-up – nhed

+0

Un'altra posizione è qui (https://github.com/after5cst/uscmon) e problemi di discussione aiuta a costruirlo ma non sembra in realtà fare il lavoro @MBR hai una versione aggiornata o documentazione? – nhed

Problemi correlati