One of two things is generally meant by this, either using a Mac as the interface to a serial device (accomplished by running a terminal emulator program on the Mac), or using another machine to connect to the Mac over serial and accessing the shell provided by the Mac. This page is dedicated to the latter.
I first tried googling around, and I encountered a few references to this issue on various Mac forums. Many were quite old, and it appears that the process has gotten more difficult with more recent versions of OS X (at least Snow Leopard 10.5+). People have generally had more success with the Xserve OS X server versions. I was working with 10.6, non-server edition. The technique described here has been reported to work at least as recently as 10.10.4.
For completeness, here are some links to several of the sites I encountered, which should give you the basic idea of the problem:
Getting a serial port
The first step is to get an RS232 serial port on your Mac, which hasn't been built-in for a long, long time. You probably want a USB to serial converter, of which there are a variety. Given variability in driver quality and compatibility, you may want to try a few models and driver implementation. For instance, two common chips include the FTDI series (official driver here) and the Prolific PL2303 chipset (open source driver here, closed source driver here). Of the two, I found the open source PL2303 driver to be slow and observed occasional data corruption (I did not try the closed source driver but heard worse things). I have found FTDI devices to perform more consistently.
Mac OS X 10.9 and belowThese versions do not come with drivers for any USB to serial converter of which I am aware. You will need to install a third-party driver, e.g. from one of the above links.
I often have to do router configuration via a console port, so I use a Keyspan Serial Adapter to get access. Two problems then present themselves: ZTerm is a horrible Mac OS X app. It hasn't been updated in five years or so, and isn't a Universal Binary. The easiest way to connect to a serial console over USB is to use some software that is already built for that purpose. PuTTy, MobaXTerm, GNU Screen, Android Serial Console, Android Serial USB Terminal, and Arduino IDE are examples of software you can use. Let's look at some examples of how to do this in Windows, Linux, Mac, and Android.
Mac OS X 10.10 and above
Starting with 10.10, a driver for at least FTDI-based converters now ships with the OS. Drivers for other converters may also be present, but I have not used them.
If you are lucky enough to have a converter identifying itself using one of the common FTDI USB product IDs, then the serial device will simply appear. If not, you will have to alter the expected device ID in the driver configuration. If you encounter strange issues of any kind with the built-in driver, try the official FTDI driver as well. Supposedly, the driver priority of the built-in driver is set so that installing the official driver will override it without causing any conflicts, however I have not conclusively verified this. For an example of how to alter the device ID or disable the built-in driver (follow just step 1), see this blog post. For official documentation on manipulating the FTDI driver or uninstalling it, see FTDI Application Note 134.
In the process of doing this myself, I learned a bit about the kernel extension (of which these drivers are each an instance) system in OS X. The basic idea is that each has a [drivername].kext directory somewhere under /System/Library/Extensions or /Library/Extensions, which if removed or renamed to not end with .kext (e.g. by switching .kext with .disabled) will prevent the driver from being loaded in the future. For an immediate load or unload, run kextload [path to .kext directory] or kextunload [path to .kext directory] as root. To see the list of currently installed extensions, run kextstat (e.g. | grep -i ftdi). After re-enabling a driver, the driver may not reload even after the next reboot because a separate cache of kernel extensions is kept to speed up enumeration on boot. This can be manipulated directly by the kextcache program, or more easily by simply running touch /System/Library/Extensions (which updates its timestamp to the current time) so that the cache is rebuilt on next boot.
Testing your serial port
If you have this working, a new device file should show up in /dev. Run ls /dev/tty.* to see what yours is showing up as. The next step is to test the serial port using some sort of terminal emulation program. I used goSerial, which happened to be the first one I found. It worked fine for my purposes, but better ones may exist.
Getting a getty running
In the Unix world, getty is the program that presents a login prompt. In earlier versions of Mac OS, one could add the appropriate line to /etc/ttys and have a prompt appear on a serial port. It appears that as of 10.6 (and possibly somewhat earlier), this is no longer possible.
Instead, I found that creating a script to spawn the getty that is run by launchd does the trick. Note that running the getty on the command line appears to fail because the login_tty syscall can only be invoked by the init process (which on Mac OS is launchd). I therefore created a file called serialconsole.plist (name it as you wish) in /Library/LaunchDaemons/ containing the following:
Note that first bit sets the daemon name, the second bit sets the program arguments (one 'string' per argument), and the last bit (keepalive) instructs launchd to restart the daemon when it exits (eg, the user logs out of the console). The first program argument is the getty program to execute, the second is the relevant line in /etc/gettytab that defines the desired serial port configuration (in this case the typical 115200 baud, 8 data bits, no parity, 1 stop bit; '8N1'), and the third argument to getty must be the name of the serial port device in /dev, which for the two devices I had were one of the two listed. As noted later, the 'cu.' version of the serial port rather than the 'tty.' version may need to be used. Initially, this was reported in only some cases but seems to be the norm as of 10.10
Using the program launchctl, you can manually reload these configuration files and restart daemons. Here are some self-explanatory commands you might use, of which only the first two should be necessary to start the getty manually after creating the configuration file above.
Of course, rebooting should also work if you're lazy. Note that in my case, the usb serial device appears in /devafter launchd attempts to run the getty, causing an error message to be logged to this effect in /var/log/system.log. However, the next time it attempts to restart it (within a minute or so), it should succeed. Check that log file for other errors.
Serial Console Linux
As of 10.10, launchctl load and launchctl unload Cannot delete an app on mac. are considered legacy (but still supported for now), and a new scheme should be used. Supposedly the following is the preferred sequence:
However, in my case these did not seem to be sufficient, whereas launchctl load did the trick. Let me know what seems to work for you.
Automatic login
https://yellownm419.weebly.com/blog/how-to-end-apps-on-mac. For my application, I wanted a shell prompt to be immediately presented, without asking for username or password or displaying the login messages (last time logged in, new mail, etc.). To accomplish this, I needed to add the following entry to /etc/gettytab:
as well as change the std.115200 to custom.115200 in the serialconsole.plist file. Note that this changes the login banner message to just a carriage return and newline, automatically logs in as user <username>, and spawns the login program /usr/bin/quietlogin.sh, which is a script I wrote (that wraps the default /usr/bin/login) containing the following:
The reason this additional script was required was due to stupidity on the part of the login program that I observed. First, it seems to ignore the presence of a .hushlogin in the user's home directory requesting that no welcome messages be printed. Further, the -f argument passed to login must be first on the command line (before a '-q' which forces quite mode). (See the login man page for some of idea of what I'm talking about.) The above script performs this necessary munging.
Hiccups
Things not working? I'm not a mac user myself, so I can't offer too much help with debugging. Serial stuff in Mac OS appears to be of little interest to Apple, so things may change and break with each new version. If you learn something new during your own tinkering, let me know and I'll post it here. My email address may be derived from the URL of this document.
If you're using the 'tty' device and it's not working, definitely try the 'cu' device (replacing tty.<device name> with cu.<devicename>, thus using the 'cu' call-out device instead of 'tty' terminal device). This was first reported when using somewhat unusual hardware as a Hackintosh, but more recent reports suggest this is now the norm. Perhaps it depends on the usb-to-serial driver used? I'm seeking input on this, so send me email with datapoints.
Other thoughts
One reader suggested the possibility of using serial port emulation on a bluetooth connection as an alternative to USB-to-serial dongles. I would be curious to hear reports from anyone attempting this, particularly on behavior prior to bluetooth peering, during radio hiccups, and after reconnects (assuming the idea works at all). Before going too far down this road, do remember you can run IP over bluetooth and just use proper networking if your application permits.
Changelog
Last modified 8/9/2015
Use 'screen' as a serial terminal emulator | 29 comments | Create New Account
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Can you not just save all that as terminal profile and then double click it, or select it from the Terminal dock menu? No applescript involved.
--- ~/.sig: not found
I use the following keyspan.term (string-style plist for readability): Note that you can control the terminal baud rate and other characteristics with the last argument (see the WINDOW TYPES section of screen(1)).
Or just use QuickTerm
Hello No need to shell out for Keyspan's admittedly very good drivers. Many USB-serial adapters use the same chip, Prolific Industries' PL-2303 controller. Prolific's own Mac OS X driver is currently not very good; you can't send a break signal via screen in Terminal, for example. However, there's an open-source driver that works better.
I am not a programmer. What shall I do when I've setted the port of QuickTerm, and came back to the window 'RS-232 Terminal'. I clicked on 'Connect'. It probably connected but the window is empty, I cannot type anything in it, and anyway I don't know what to type. I want to use it for our French 'minitel'. I think it is V33, but not sure. I use a laptop and MacOs 10.4.9. My modem is inside : Modele : MicroDash Type d'interface : USB Modulation : V.92 Nom de serie : Euro Version Matériel : 1.0F Version du programme interne : APPLE VERSION 2.6.6 Gestionnaire : InternalUSBModem.kext (v2.6.6) Pays : 3D (France) Is X11 necessary ? I am not keen on the terminal, so could you give basic explanations. Thank you.
I use this with an unbranded PL-2303-equipped adapter bought from eBay for six of our English pounds, compared to thirty-odd for a Keyspan device, and it talks perfectly to my Cisco routers. I haven't tried talking to PDAs or GPS devices though.
'Shell' out. See what I did there? Heh - oh dear. Calibre app download mac.
You can also use C-Kermit 8.0. Unfortunately a binary is not available, we must compile it by ourselves, but it's really easy, as Mac OS X is supported.
Download the source at the following address: ftp://kermit.columbia.edu/kermit/archives/cku211.zip Copy it in a folder, then, using terminal: % cd <the folder you copied it in> % unzip -a cku211.zip % make macosx103 % sudo make install it will compile and install Kermit in the folder /usr/local/bin/kermit; the binary is called wermit. It's ready! to launch it: % /usr/local/bin/kermit/wermit and here it is: C-Kermit 8.0.211, 10 Apr 2004, for Mac OS X 10.3 Copyright (C) 1985, 2004, Trustees of Columbia University in the City of New York. Type ? or HELP for help. (/Users/wallybear/) C-Kermit> Compiling from source give also the chance to tweak compiler settings so to make a PPC, Intel or Universal binary application.
I last used C-Kermit when Jaguar was out. It worked great. PowerPC binaries for 10.3 and earlier can be found here: http://www.columbia.edu/kermit/ck80binaries.html#apple
Wow! Kermit - I haven't used that for at least a decade, but I seem to remember that it was very good.. must give it a try..
Anyway, that aside, for those who like minicom, Jeffrey Frey has done a Mac port which can be found at the bottome of his page here:
http://turin.nss.udel.edu/programming/
also the awesome thing about kermit which i've been using recently for a few years is that it lets you send files via xmodem (useful when ur cisco gear pukes on itself), and also kermit is scriptable (useful when you have 50+ apc power strips you have to configure the same way, enter non-interactive script).
I'm not saying I'd recommend it, but you could also use tip, 'man tip' for more info.
osx unfortunately doesn't come with tip . i was disappointed quite a bit when I found out
There are quite a few installer packages for minicom that remove the need for fink or darwin(er. mac)ports.
one's at http://turin.nss.udel.edu/programming/
This is an excellent solution (I've been a regular, frustrated, user of ZTERM). I am, however, unable to configure the serial port settings (I routinely connect to a serial device running 38400/n/8/1) I've tried every combination I can imagine with stty to set the port before starting screen and it is still always stuck at 9600 baud.
Update: I found on Apple's discussions board the following, which works: Here is an addition I made to select the serial port and the baud rate:
screen -U /dev/tty.KeySerial1 38400 Adjust the script accordingly and it works perfectly! set baudList to {1200, 2400, 4800, 4800, 9600, 19200, 38400, 57600, 115200, 230400}
set baudRate to (choose from list baudList default items {38400})
tell application 'Terminal'
set serialDevices to (do shell script 'ls /dev/cu*')
set theDeviceList to (paragraphs of serialDevices) as list
set theDevice to (choose from list theDeviceList)
do script 'screen ' & theDevice & ' ' & baudRate
display dialog 'To quit you terminal session type then '
end tell
the second to last line should have been:
display dialog 'To quit you terminal session type <ctrl-a> then <ctrl->'
The second to last should have read:
thanks for all your help, especially bboy for the cheaper cable, and wcontello for the AppleScript.
I am currently taking 2 classes that use HyperTerminal, a Cisco test prep class and a basic Telecommunications classes. I've wanted to use my MacBook Pro to use something HyperTerminal related. I have a beta of Windows 7 in Boot Camp and VMWare, and MS got rid of HyperTerminal in Vista. And of course no Mac (except for Xserves) have a serial port. --- Startup Shortcuts - Shortcuts for debugging your Mac on startup, on your iPhone http://web.me.com/maxeverde/Startup
You wrote: 'type Control-A followed by Control- to exit your screen session. If you fail to do this and exit a Terminal session, you'll leave the screen session alive and the serial resource unavailable until you kill the screen session manually.' Look for a process called 'SCREEN' using ps. Here's the output of my Terminal:
OK, I boo-booed. Now how can I kill the screen session manually? (I wish I knew Unix better.) --Gil
Kill the process associated with SCREEN (i.e. '
kill -TERM 327 '), and the SCREEN will go away.
You can also reattach to a detached screen by running '
screen -rD '.
Another solution would be using the ZOC Terminal application. I used zterm initially and found it horrible too. ZOC is a lot more modern in every regard and works with a serial/usb adapter.
If you want to use screen as an terminal, but don't want it to go into the background when the window dies, you will need to turn off auto-detach.
To do this, edit ~/.screenrc (it probably won't exist) and add the following line: autodetach off The next time you start screen, if you kill the window you will kill the session.
Edison email app mac. How about simply 'cu -l /dev/whatever -s 19200' and that's all it takes.
Thanks! Working great w/an IOGEAR GU232A USB to Serial adapter which uses the PL2303 chip set.
Serial Console Application For Mac
This is a fantastic thread. Saved me from using Zterm. One problem though. I'd like to be able to scroll up past the top to show more than one page of data. Anyone figure out a way to do that?
Never mind. A little googling found the answer I was looking for. To turn on the scrollback buffer for SCREEN you have to add one more line to ~/.screenrc More info here: http://stackoverflow.com/questions/1039442/mac-os-x-terminal-apps-buffer-and-screen-command
What Is Console On Mac
since people are still posting to this 4 year old thread, I think it's useful to point out that iTerm - http://iterm.sourceforge.net/ - is a cocoa terminal editor that is up to date and under continued development (and that's not to mention the Terminal application packaged with os X).
Serial Console For Windows 10
I found Furrysoft's goSerial rather nice for my AVR hacking projects:
http://www.furrysoft.de/?page=goserial Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |