macOS USB to UART using Terminal

[Bobby Digital]

Hi there,

I have an FTDI based system that I am able to communicate with fine on a Linux machine using:
talk -d /dev/ttyUSB0
but I would like to do programming using my Mac (running 10.9.5). The FTDI drivers came with Mavericks, and I can see the device just fine as
/dev/tty.usbserial-A123456
but if I try
talk /dev/tty.usbserial-A123456 9600 8N1
I get talk: localhost: Unknown host. I searched around and it seems most people use screen so I tried:
screen -r /dev/tty.usbserial-A123456 9600 8N1
but get "cannot execute screen '/dev/tty.usbserial-A123456' no such file or directory"
Is this not commonly done over terminal? I'm fairly experienced in Linux, but never used Terminal on the Mac extensively. Thanks a lot.

 

[ocabj]

Did you try executing screen without the -r parameter?

 

[chown33]

Here's the online man page for the 'screen' command:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/screen.1.html

Find the 2nd instance of the word baud on that page, and read what it says about how to pass stty parameters to a tty device.

In short, 'screen' isn't 'talk'. They take different command-line args.


Mac OS X also has a 'talk' command, but it's completely different from the Linux talk command. You can find the OS X 'talk' man page here:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/talk.1.html

All the commands also have man pages available in Terminal:

man screen
man talk

 

[Bobby Digital]

Did you try executing screen without the -r parameter?

Yes, I've tried with and without a few different parameters as well as leaving out the baud rate and 8N1.

Here's the online man page for the 'screen' command:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/screen.1.html

Find the 2nd instance of the word baud on that page, and read what it says about how to pass stty parameters to a tty device.

In short, 'screen' isn't 'talk'. They take different command-line args.


Mac OS X also has a 'talk' command, but it's completely different from the Linux talk command. You can find the OS X 'talk' man page here:
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/talk.1.html

All the commands also have man pages available in Terminal:

man screen
man talk

Thanks. I don't really care which I use, I'm just trying to get some response out of a device that works fine on Linux. For what it's worth, I'm not specifying a baud rate on Linux (for anyone out there who is experienced with both). I wouldn't think this could be this complicated, so seems like I'm just missing something simple.

 

[Bobby Digital]

So it's not unintentional that I left a baud rate off talk on the Linux command. I'm just trying to talk from the FTDI chip to a PIC microcontroller. Don't know if that helps.

 

[chown33]

The baud rate of a tty device defaults to 9600. The framing defaults to 8N1. This is because those are the defaults for stty.

For the tty device, I think hardware handshake defaults to enabled, so maybe the cause for the lack of communication lies there. I mean the "tty" device-name (pathname, node name) as distinct from the "cu" version of the device.

I regularly connect an FTDI USB serial device to my Macs. I'm working on an embedded controller project right now, so I do this many times during a work day. To be specific, my FTDI device is a SparkFun FTDI Basic board. I have both 5V and 3.3V versions that I use daily.
https://www.sparkfun.com/products/9873

I don't recall what my FTDI driver version is, but it's one I've been using for a couple of years at least. I probably got it directly from the FTDI website.


I've used a simple redirected-output of 'cat' to spew data to the FTDI TXD at 9600 baud. The LEDs built into the SparkFun boards make it very easy to see whether this works or not. Example:

cat TEXT_FILE_NAME_HERE >/dev/cu.USB_SERIAL_NAME_HERE

I also always use the cu version of the device, not the tty version. Both are tty devices (i.e. character devices in Unix parlance), but the cu device doesn't default to hardware handshake enabled. Compare the output of the following command lines:

ls -l /dev/cu*usb*
ls -l /dev/tty*usb*

Maybe you can tell us exactly what FTDI device you're using, and the mfgr of the board.


I don't know why you mentioned i2c in the thread title, unless that's what your PIC controller is doing. The FTDI USB-to-serial I'm familiar with doesn't use I2C at all. It's a plain async UART with a USB interface, chip number FT232RL.

 

[Bobby Digital]

I don't know why you mentioned i2c in the thread title, unless that's what your PIC controller is doing. The FTDI USB-to-serial I'm familiar with doesn't use I2C at all. It's a plain async UART with a USB interface, chip number FT232RL.

You're right, I fixed the title. I got a schematic and it is USB to UART using the FT232R.

I also just found out that the Linux machine was actually not using the talk unix command but executing code that has the exact same title: talk. And since ./ is apart of the bashrc, this wasn't obvious to me. So I think I have other things going on in the board I'm using that need to be understood. Thanks a lot for the help, I think I'll pick up the sparkfun board to dig into this method of communication a little further.

 

[chown33]

You're right, I fixed the title. I got a schematic and it is USB to UART using the FT232R.

I also just found out that the Linux machine was actually not using the talk unix command but executing code that has the exact same title: talk. And since ./ is apart of the bashrc, this wasn't obvious to me. So I think I have other things going on in the board I'm using that need to be understood. Thanks a lot for the help, I think I'll pick up the sparkfun board to dig into this method of communication a little further.

Is the unspecified Linux 'talk' command a binary file, an interpreted language such as Python, or a script of some kind? Posting some additional detail on the command itself may help someone else here provide an explanation. I'm pretty sure Linux has a 'file' command, so using that on the ./talk file should tell what it is.

I don't know what you expect to gain from buying the SparkFun board that can't be accomplished with what you have now. Maybe if you posted exactly what FTDI board or USB-serial cable you have now, we could make specific suggestions. It might also help to tell us exactly what your PIC board is. For example, if I knew what it was I could read its datasheet and tell you whether it would work with the SparkFun FTDI board or not.

 

[JonasCalhoun]

You don't want the 'talk' command, that's for an old style split screen IM client.

Try looking at the 'cu' command. Something like 'cu -l <dev> -s <baud>' should be able to work. There's two devices for each serial port too--one outgoing and one incoming (something like tty.cuaa01 IIRC--it's been a while).

Good luck!