Linux question -- how to tell if serial port in /dev is for real?

I'm assuming you're looking to do this from code, not the command line. Sooner or later, the lack of reality of a given /dev/dealiewhopper will become a problem. In your case, that should be when you actually try to treat it as a serial port. So the following test code keels over and dies with the error "tcgetattr /dev/ttyS18: Input/output error"

Thanks Rob. Eventually I may get my head wrapped around all the termios stuff, probably ten minutes before I get run over by a beer truck.

You might prefer to use pyserial to access the port from Python - and let pyserial handle the messy termios stuff:

import serial

try : port = serial.Serial("/dev/ttyUSB0", 9600) print "It's a serial port :-)" except : print "It's not a serial port :-("

If you think the application level termios stuff is a mess, you should take a look at the serial port APIs in the kernel...

All of the desktop serial-port stuff I've done in the last decade has been in support of embedded work, and it's all been heavily dependent on, and used as part of the testing framework for, serial communication code that is to be embedded.

So I'm constrained to C or C++.

Basically what I do when I write embedded stuff (unless it's really teeny) is to write it so that the actual hardware layer is abstracted -- usually into a class, because I'm usually working in C++. Then all of the "middleware" that I'm seeking validation for finds its way into both the embedded software and a test-bench running on a PC that's talking to the embedded system. Finally, the PC has some GUI (I'm currently using Qt, again because I'm constrained to C++), and the embedded system has whatever it needs to have piled atop the serial port.

Knowing whether a port is real or not is really just a convenience for me

-- when you do an "open file" dialog on /dev/tty* in Ubuntu you get a buttload of stuff, most of which is not valid; I'd like to fix that.

Oh, please no!

...mostly? :)

So, you can hack the kernel.

Back to your question. It might be driver specific, but most will announce what ports they claimed: For example:

dmesg | grep tty [ 0.000000] console [tty0] enabled [ 53.006880] cdc_acm 1-3:1.1: ttyACM0: USB ACM device [ 53.008697] cdc_acm 1-3:1.3: ttyACM1: USB ACM device

If not, you can always hack the kernel. The source is available for this reason, as well as others.

If this is about embedded Linux, Python works great for that.

If you don't like the termios API you should try the serial port API in Windows. You will love termios thereafter.

Will Python run on an ARM Cortex M0 with 64k of ROM and 8K of RAM?

With room left over for actual application code?

I know both, to my sorrow.

Which one? The traditional one or the TAPI one? ;-)

I had to support the traditional API, both on Win Desktop and WinCE. Even these two are different and both are a mess, not only the initialization, but doing the real nonblocking data transfer. In Linux only the initialization is messy with termios. After that it is just a file and can be handled just as any file or socket (select, read, write).

Yea, I didn't understand why the desktop stuff was constrained to be C or C++ just because it was talking to an embedded system.

I do a _lot_ of desktop serial port stuff in support of embedded work, and all the desktop stuff is in Python -- and some of it needs response time measured in tens of microseconds. I know a lot of other embedded developers do that as well.

No, but you said it was _desktop_ serial-port stuff. Your desktop is an M0 with 64K of ROM and 8K of RAM? And it suppors network access and an NNTP client! That is impressive.

TAPI is different, but only a bit cleaner.

If one does not need any telephony related functions, why would one use the TAPI interface ?

The basic Win32 CreateFile/ReadFile/WriteFile interface is easy to use. Of course you may also need GetComState/SetComState to set line speed and parity etc.

I use to allocate a blocking thread for each serial line. If I need to monitor activity on any of these lines, each thread will set an object when something is received and use WaitForMultipleObjects in the main thread to see which line has some activity.

The only reason I like the Linux approach is when a large number of serial lines (more than a few dozen) are needed or there is a need to wait for a mix of real serial ports and serial ports connected trough ethernet/serial converters (using TCP/UDP sockets), this can all be done in a single thread with a single select statement.

Tim,

I sent an email to you about both - did you get it?