Re: [PD] call for [comport] testing!
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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for [comport] testing!
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for [comport] testing!
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(n0) in a situation where n stays 0. __ | Mathieu BOUCHARD - téléphone : +1.514.383.3801 - Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for [comport] testing!
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(n0) 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for [comport] testing!
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___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for [comport] testing!
Hi, thanks for that great feature Hans ! Hans-Christoph Steiner wrote: You can still set a 1ms poll time with the [pollinterval 1( message. That's great, because it depends on the serial hardware, which are mostly usb-serial converters these days. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for [comport] testing!
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] call for [comport] testing!
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/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] call for [comport] testing!
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=revisionrevision=16050 Then added handling for err == 0 in this commit: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=revisionrevision=16051 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
