USB to UART using Terminal

Discussion in 'Mac Programming' started by Bobby Digital, Sep 17, 2015.

  1. Bobby Digital macrumors newbie

    Joined:
    Sep 17, 2015
    #1
    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.
     
  2. ocabj macrumors 6502a

    ocabj

    Joined:
    Jul 2, 2009
    #2
    Did you try executing screen without the -r parameter?
     
  3. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #3
    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:
    Code:
    man screen
    man talk
     
  4. Bobby Digital thread starter macrumors newbie

    Joined:
    Sep 17, 2015
    #4
    Yes, I've tried with and without a few different parameters as well as leaving out the baud rate and 8N1.

    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.
     
  5. Bobby Digital, Sep 17, 2015
    Last edited: Sep 17, 2015

    Bobby Digital thread starter macrumors newbie

    Joined:
    Sep 17, 2015
    #5
    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.
     
  6. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #6
    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:
    Code:
    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:
    Code:
    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.
     
  7. Bobby Digital thread starter macrumors newbie

    Joined:
    Sep 17, 2015
    #7
    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.
     
  8. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #8
    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.
     
  9. JonasCalhoun macrumors member

    Joined:
    Aug 26, 2012
    #9
    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!
     

Share This Page