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

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 would like to know how to know.

Thanks.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott
Loading thread data ...

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"

--
#include  
#include  
 Click to see the full signature
Reply to
Rob Gaddi

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.

--
Tim Wescott 
Control system and signal processing consulting 
 Click to see the full signature
Reply to
Tim Wescott

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 :-("

Reply to
David Brown

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

--
Grant Edwards               grant.b.edwards        Yow! I threw up on my 
                                  at               window! 
 Click to see the full signature
Reply to
Grant Edwards

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.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

Oh, please no!

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

...mostly? :)

--
Randy Yates 
Digital Signal Labs 
 Click to see the full signature
Reply to
Randy Yates

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.

Reply to
edward.ming.lee

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

Reply to
Paul Rubin

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

--
Reinhardt
Reply to
Reinhardt Behm

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

With room left over for actual application code?

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

I know both, to my sorrow.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

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

Reply to
Robert Wessel

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).

--
Reinhardt
Reply to
Reinhardt Behm

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.

--
Grant
Reply to
Grant Edwards

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.

--
Grant
Reply to
Grant Edwards

TAPI is different, but only a bit cleaner.

Reply to
Robert Wessel

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.

Reply to
upsidedown

Tim,

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

--

-Tauno
Reply to
Tauno Voipio

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.