On Mon, Jul 11, 2016 at 6:46 PM Martin Ling <martin-sig...@earth.li> wrote:
> libserialport is *not* specific to sigrok. It is a completely generic
> cross-platform serial port access library that is already in use by
> other unrelated projects. It should not make any assumptions about what
> is connected to a port. It would be perfectly normal and sensible to use
> libserialport for a program that did talk to modems rather than
> multimeters and oscilloscopes, or indeed anything else.
>
Ah, in that case, my first impulse - to use the same check that linux does,
and just look for /dev- was the correct one. I backed it out because I
wasn't sure how it would interact with the USB device checking.
> FreeBSD seems to break that assumption. Rather than having a single
> device node for the port, there are apparently two different device
> nodes for the same port, with the choice between them implicitly
> applying certain settings, in particular the DCD behaviour. So it seems
> you need to know in advance which settings you want before opening the
> port.
>
This isn't a BSD-specific behavior, it comes from Unix before BSD was a
bootable system. FreeBSD (and OS X, apparently) still maintains backwards
compatibility to that era. Systems that post-date dedicated call units had
no reason to duplicate this behavior.
Frankly, this doesn't fit the libserialport model. That could be seen as
> a failure on my part to come up with a sufficiently cross-platform API.
> But we are where we are. The API is out there and in use, and we need to
> figure out the best way of fitting FreeBSD into that.
>
Make it look more like linux.c.
> So I have some questions:
>
Just to make sure, I'm checking my answers against the sources for
FREEBSD-STABLE 10.3; which is the current production version.
> - Having chosen which device node to open, are the settings that differ
> between the nodes locked down? Or is it possible to change them? I.e.
> can you open /dev/ttyuX and turn off the DCD behaviour, or to open
> /dev/cuaX and turn it on?
They cua & tty devices use the same device driver. In fact, they are the
same device, with code in the kernel to insure you don't open them both at
once. The ioctl doesn't distinguish between the two - anything you can
change on one, you can change on the other.
- Exactly which behaviours (in terms of termios/stty settings) are
> preset for which device nodes?
>
Can't say exactly, because each driver (i.e. usarts, the usb serial driver,
etc.) gets it's own set of initial termios flags for both directions. The
one thing that's hardwired is that cua devices (and the console) get the
CLOCAL flag set, which causes modem status lines to be ignored, including
skipping the initial wait on DCD.
- Are these presets guaranteed, or are they just conventions? Is it
> possible to find a system in which the nodes have been given different
> settings?
>
Beyond CLOCAL, nothing is guaranteed. And even that can be changed if
you're willing to hack the source.
> - Is there a convention within the FreeBSD user community over which
> name to use when identifying a physical port?
>
YES!!!!! They use /dev/tty for pretty much anything that can't dial the
phone. And even for things that can. That's the violation of POLA.
> As such, the expectation after opening a port with libserialport is that
> it will *not* wait for DCD to be asserted before being able to transmit
> and received data; that is not a capability libserialport offers, and
> so it should be turned off. It seems to me that this would argue for the
> library continuing to use /dev/cuauX on FreeBSD, unless /dev/ttyuX can
> be opened and the DCD behaviour then turned off.
>
Well, if you've got an honest-to-goddess call unit dialing for the serial
device, then you really need to be waiting for DCD, as there isn't anything
on the other end to talk to before it goes on. If libserialport can't do
that, then the API isn't up to dealing with call units (not something I'd
call a serious problem, as I don't think anyone makes them any more).
Either that, or you depend on the kernel to make sure you are actually
connected before the open finished, meaning you need to use /dev/tty
instead of /dev/cua (which in fact was how they were used).
If you don't have a call unit, then DCD is nonsense. Device drivers for
such things just say that DCD is on, and use DTR when they aren't ready.
Old data terminals didn't connect anything to DCD - that line came to them,
not from them - and we'd short it to DTR in the cable. Of course, if you
simply let users use whatever name they want, then the cua device can be
used if you're really stuck (maybe an old UPS with a proprietary serial
cable that doesn't connect DCD? I dunno).
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
