I just committed a fix for the race condition that happens when a serial port gets disconnected on GNU/Linux and Mac OS X. Please test heavily on those platforms, including yanking out the USB plug and going out of range with a bluetooth. It should just cleanly close the serial port now.
http://autobuild.puredata.info/auto-build/latest/
Basically, when a serial port is open using [comport] and the connection gets broken, like if the USB gets pulled, then comport gets stuck in the while(select()) loop in comport_tick().
I changed "if (err >= 0)" to "if (err > 0)" in this commit: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revi...
Then added handling for err == 0 in this commit: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revision&revi...
Hopefully this doesn't cause any issues because it fixes a big problem :-)
.hc
"We have nothing to fear from love and commitment." - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill
Hey Hans
On Wed, 2012-03-07 at 00:03 -0500, Hans-Christoph Steiner wrote:
I just committed a fix for the race condition that happens when a serial port gets disconnected on GNU/Linux and Mac OS X. Please test heavily on those platforms, including yanking out the USB plug and going out of range with a bluetooth. It should just cleanly close the serial port now.
That's good news! Thanks a lot for this fix.
It seems to work well here. Also, it reports closed connection, if you unplug the cable, which is good. This way you can write your patch to deal correctly with the situation.
Roman
On Mar 7, 2012, at 5:48 PM, Roman Haefeli wrote:
Hey Hans
On Wed, 2012-03-07 at 00:03 -0500, Hans-Christoph Steiner wrote:
I just committed a fix for the race condition that happens when a serial port gets disconnected on GNU/Linux and Mac OS X. Please test heavily on those platforms, including yanking out the USB plug and going out of range with a bluetooth. It should just cleanly close the serial port now.
That's good news! Thanks a lot for this fix.
It seems to work well here. Also, it reports closed connection, if you unplug the cable, which is good. This way you can write your patch to deal correctly with the situation.
Roman
That's good news :) Also, I switched the default poll time from 1ms to 10ms, because based on my testing, it was only getting data every 10ms, and the other polls were for nothing. But that is also something to test. You can still set a 1ms poll time with the [pollinterval 1( message.
.hc
http://at.or.at/hans/
Le 2012-03-07 à 00:03:00, Hans-Christoph Steiner a écrit :
I just committed a fix for the race condition that happens when a serial port gets disconnected on GNU/Linux and Mac OS X. Please test heavily on those platforms, including yanking out the USB plug and going out of range with a bluetooth. It should just cleanly close the serial port now.
BTW, I have made a version of [comport] in 2008, to introduce an optional ring-buffer FIFO for outgoing data, with user-defined size, because I needed to upload large files by serial port. It might be a good idea to merge this feature into the main [comport] branch, for several reasons. One of them is that I'm not really distributing it anywhere.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Sat, Mar 10, 2012, at 15:43, Mathieu Bouchard wrote:
Le 2012-03-07 à 00:03:00, Hans-Christoph Steiner a écrit :
I just committed a fix for the race condition that happens when a serial port gets disconnected on GNU/Linux and Mac OS X. Please test heavily on those platforms, including yanking out the USB plug and going out of range with a bluetooth. It should just cleanly close the serial port now.
BTW, I have made a version of [comport] in 2008, to introduce an optional ring-buffer FIFO for outgoing data, with user-defined size, because I needed to upload large files by serial port. It might be a good idea to merge this feature into the main [comport] branch, for several reasons. One of them is that I'm not really distributing it anywhere.
Sounds interesting, how would that affect latency? Most people use comport for getting data from sensors, so that's important.
.hc
Le 2012-03-11 à 10:10:00, Hans-Christoph Steiner a écrit :
Sounds interesting, how would that affect latency? Most people use comport for getting data from sensors, so that's important.
The fifo is an option. If you don't use it, then there's hardly any difference. If you use it, then I think that the data is only being sent at poll time, according to how much data the driver accepts. For patches that only receive, it makes no practical difference : just an extra if(n>0) in a situation where n stays 0.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Mar 11, 2012, at 1:07 PM, Mathieu Bouchard wrote:
Le 2012-03-11 à 10:10:00, Hans-Christoph Steiner a écrit :
Sounds interesting, how would that affect latency? Most people use comport for getting data from sensors, so that's important.
The fifo is an option. If you don't use it, then there's hardly any difference. If you use it, then I think that the data is only being sent at poll time, according to how much data the driver accepts. For patches that only receive, it makes no practical difference : just an extra if(n>0) in a situation where n stays 0.
There is already buffering happening, my guess is at the OS level, since the bytes are read in bursts, no matter how fast the polling it for read or write. Have you tried adjusting the size of the system buffer for serial? Is that even an option?
.hc
"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman
Le 2012-03-11 à 15:35:00, Hans-Christoph Steiner a écrit :
There is already buffering happening,
But there wasn't enough of it, obviously, because I modified an existing external that I'm not maintainer for, just to have a large enough buffer. I don't remember what was the original size, but it sucked.
my guess is at the OS level, since the bytes are read in bursts, no matter how fast the polling it for read or write.
At 38400 bps with 10 bits/byte, it's 3840 bytes per second. If they are received at full speed, they are equally spaced in time every 0.2604 ms. This is a time resolution that I suppose the kernel isn't especially good with. Back in the early days of multitasking, modem constructors even had to upgrade all the UART chips because OSes were not able to keep up (and because it was a pure waste of CPU in 99,99 % of the cases). That's when the buffer was upgraded from 1 byte to 16 bytes. That was precisely when 38400 bps became a common serial rate, because 14400 bps modems all used MNP5 and/or v.42bis compression, and they needed to fake a fixed-rate COM port.
Have you tried adjusting the size of the system buffer for serial? Is that even an option?
I don't recall. If there was an option for it, then it surely was unsufficient for what I was doing, which was to send elaborate vector graphics to a plotter.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-
Charles Goyard -
Hans-Christoph Steiner -
Mathieu Bouchard -
Roman Haefeli