Menu
On windows, there are several decent alternatives (mostly paid) which allow you to monitor serial port communications. On OSX there are lots of terminal applications which let you talk to serial devices but I haven't found a mechanism to monitor serial port communication.
The specific use case is: I have a USB-Serial device that lives on /dev/tty.usbmodem99999
I have written an integration test that runs multiple commands (successfully).
However on re-running the command the device does not respond. I've confirmed (as well as I can) that the device is fine. It works on other platforms as expected. However on OSX I can only re-run the tests after resetting the device (power cycle).
My theory is that my code is not releasing the device properly but that's hard to confirm when I can't see the communication between my device and my application.
This application: "http://www.aggsoft.com/serial-port-monitor.htm" has a 'spy' feature that I have been unable to find similiar functionality to on OSX. I've experimented with 'serial tools' on osx, but it doesn't look like it does spy operations on a single port, in that case it looks like the use case is as a passthrough between two devices rather than monitoring at the port.
Any thoughts greatly appreciated.
serial library being used is: https://github.com/jacobsa/go-serial
630
Here's how the solution works: You connect your Serial Tap hardware over a USB cable and select it in the Serial Tap plugin. Next, you specify the baud rate at which the serial communication you are going to sniff works. Then, you click Capture and get the communication data displayed.
To use the programmer in Mac OS X, you will need to determine which names have been assigned to its serial ports. To do this, open a Terminal window, type ls /dev/tty. usb* , and press enter.
USB has become the preferred serial communication protocol between digital products like computers and peripheral devices as it can transmit data across longer cables and offers higher transmission rates. UART, however, is still is used today for certain applications and is often seen in older devices.
Have you used DTrace?
I have used it to monitor USB comms between an FTDI USB/serial converter and a 3rd party 'Black Box' application. So I could get at everything that the application sent to the USB serial port.
That was pretty straightforward because I knew the name of the application, so DTrace could observe that. I wrote DTrace script to observe the file descriptors the application opened, (looking for the '/dev/tty.usbmodem...') then observed interactions with that file descriptor.
I have not observed a device driver. In principle DTrace can do that if the kernel or device driver is compiled to work with DTrace, though there is no certainty that it is. Apple can also build code which is 'invisible' to DTrace (for example I believe iTunes was made opaque to DTrace to protect its DRM mechanisms.)
So one possible starting point is to observe all OS open/creat calls, looking for /dev/tty.usbmodemXXX, and try to identify the subsystem and observe that. You may find that the subsytem can be observed, and that should help see what the OS+device driver is doing.
This isn't trivial. If your time has any value, it may be cheaper and more reliable to get a hardware USB sniffer and put it into the cable, especially if its only 1.2Mbits or 12MBits USB (sniffers are much more expensive for higher data rates).
These links may help:
About DTrace
DTrace Guide
DTrace book
Brendan Gregg's Top 10 DTrace scripts for Mac OS X
Apple DTrace manual
Hooked on DTrace
101
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
