Problems with pull opening it's own serial port connection.

[cversek]

Currently the pull process is implemented by requiring a serial port path to be specified as an argument, e.g.:
./pull_serial_depth_json -p "/dev/ttyUSB0"
In the Python implementation pySerial is used to open this port:
ser = serial.Serial(args.path, baudrate=DEFAULT_BAUDRATE, dsrdtr=True)

There are two potential problems with this implementation:

• We have noticed that some Arduino systems (certainly the Pro-mini with FTDI cable, maybe all the official ones?) will reset their firmware every time the serial port has been opened. Unfortunately, this can cause a significant lag (up to a few seconds) before the device is receptive to serial commands. This seems to be implemented by FTDI driver pulsing the DTR pin which is connected to the board's hardware reset pin - we can find no way to disable it without an ugly hack.
• If there are two independently running OPK processes that request sensor data from that same serial device (and why not?) at close to the same time, then there is the potential for a race-condition causing command corruption and possible ruining the state of the communication protocol.

My proposal to solve these problems is to create a server that manages the serial port connection and listens on a session-persistent "named" pipe (a Unix style FIFO) for command requests which will be forwarded. Perhaps this server should be put in a startup script and it should keep looking for the appropriate udev device (match the ID fields) to attach before exporting the pipe interface. Or, maybe udev can be used to starup and shutdown this server (see Stack Exchange - "How to run custom scripts upon USB device plug-in?")? This should fix the delay on opening the port since it will only happen once per session. Now the race condition can be fixed in the pull process by waiting to obtain an exclusive lock on the pipe file. Any thoughts?

[rjcorwin]

I think you are on the right track. Sounds like the question is when to start the server.

1. The driver installs some other process that keeps the FIFO server open continuously at a specific path. I believe I've seen drivers that do this already, maybe the gpio drivers for R-Pi. Something to look at.
2. There could be a command to be more intentional about mounting a device to a FIFO server.

Either way it seems there will need to be a mount, maybe open, verb that the command has. Verbs (or subcommands) are common in CLI, and verbs are coming up a lot in regards to opk drivers. A set of suggested verbs seems to be forming. In the case we're talking about, you would opk-driver mount -p "/dev/ttyUSB0"; opk-driver pull -p /dev/fifo1;. The exact options would need to be worked out.

[cversek]

Your response has brought up a bunch of questions about nomenclature and name-spacing in my mind. Is opk-driver a name that stands for a specific implementation?
For example, could I rewrite my original pull command as
./opk-python-serial-depth-json pull -p "/dev/ttyUSB0"?

Now we know that the Depth sensor is actually a custom Arduino firmware that has now been extended to include Temperature and Conductivity. I believe Don would likely call the finished hardware something like 'riffle-CTD'. Should we say

./opk-python-serial-riffle-CTD-json mount -p "/dev/ttyUSB0"
./opk-python-serial-riffle-CTD-json pull

(where we are assuming that pull can find its own fifo) ?

Basically, what are the naming conventions that we should abide by according to the prevailing wisdom?

If this subcommand architecture is to be followed, I guess we should have a master script that parses and executes the appropriate actions (verbs)? That could save a lot of redundancy over the "one script per verb" convention, perhaps at the expense of making implementation a bit more intimidating and maybe more fragile due to its complexity. Anyway, I am a bit lost about how these components should be organized.

[rjcorwin]

Is opk-driver a name that stands for a specific implementation?

An {opk-{driverName} convention would be good for spreading the word that we're having conversations like this but typing the extra four characters would probably get old. I think what we are doing has some parallels with GNU Coreutils, (see list of commands here). Just for example, they don't prepend gnu- on any of their commands. That's not say we shouldn't though, maybe GNU Coreutils should require gnu-{utilityName}. A command's --help might be the proper place to give a shoutout to OPK.

were we are assuming that pull can find its own fifo

Drivers for devices should probably assume that more than one device of that driver's type could be connected. Taking a page out of mount for mounting disk drives.

fdisk -l
mkdir /mount-point
mount -t ntfs /dev/sda1  /mount-point

A mount point for our uses could be a directory with any number of fifo servers, one for each sensor/actuator.