Weird bug re: initial operation

[dwblair]

Need to explore this again, but it seems like communication via the 'pull' command freezes until one tries to read values from the Arduino IDE serial monitor; then it works afterwards ...

[cversek]

One possible problem is that a previous session of the Arduino IDE serial monitor could have stolen all the bytes from a linux serial port if it was open at the same time as another connection, say one held by a pyserial serial.Serial object - this should only be a problem during development, hopefully not deployment. Normally there is little restriction for which processes can read/write from/to a given serial port.

Another potential issue is that our fork of SerialCommand is set up to use the newline character "\n" (ASCII 0x0A) for command termination; the serial monitor by default is set up to send characters in groups that don't contain line termination unless it is selected from the drop-down menu near the bottom.

[cversek]

One thing we should be checking in the pull driver is that the serial port is not already open by another process. If it is, then we wait a short time-out before failing and sending an error message via OPK (do we have a mechanism for this?). Unfortunately, there is no simple way to know if another process has the port open and might at sometime read or write it - unless that process had obtained an exclusive lock on the ports file descriptor.

If we look top answer in this Stack Overflow thread, How to check if serial port is already open (by another process) in Linux, using Python 2.7 (and possibly pyserial)?, we see a way to accomplish this in Python. I did a little testing with my [https://www.pjrc.com/teensy/teensy31.html](Teensy 3.1) and the IPython shell:

• opened IPython shell Weird bug re: initial operation #1 and ran:

In [1]: import fcntl, serial

In [2]: s = serial.Serial("/dev/ttyACM0")

In [3]: s.isOpen()
Out[3]: True

In [4]: fcntl.flock(s.fileno(), fcntl.LOCK_EX | fcntl.LOCK_NB)

• opened IPython shell #2:

In [1]: import fcntl, serial

In [2]: s = serial.Serial("/dev/ttyACM0")

In [3]: s.isOpen()
Out[3]: True

In [4]: fcntl.flock(s.fileno(), fcntl.LOCK_EX | fcntl.LOCK_NB)

---------------------------------------------------------------------------
IOError                                   Traceback (most recent call last)
<ipython-input-4-882a1b5ae528> in <module>()
----> 1 fcntl.flock(s.fileno(), fcntl.LOCK_EX | fcntl.LOCK_NB)

IOError: [Errno 11] Resource temporarily unavailable

Ah, so we can't prevent the process from opening the already open serial port, but we can prevent it from acquiring an exclusive lock that is already held.

• now jump back to shell Weird bug re: initial operation #1 and close the port:

In [5]: s.close()

In [6]: s.isOpen()
Out[6]: False

• jump back to shell #2 on more time:

In [5]: s.isOpen()
Out[5]: True

In [6]: fcntl.flock(s.fileno(), fcntl.LOCK_EX | fcntl.LOCK_NB)

Obtaining the lock now succeeds without an exception.