OK, wrong group. But you guys are smart, and mostly aren't snobs.
So -- is there a way to tell if a device in /dev is for real? There's about a bazzilion /dev/tty in my computer at the moment, but there's only one (/dev/ttyUSB0) that's actually connected to a working serial port.
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"
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.
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.
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.