So right now, when [comport] is open and that device gets
disconnected, comport freezes and Pd crashes. My guess is that
comport is waiting and therefore blocking. It seems like the select()
call should prevent that, any other guesses on how to prevent comport
from locking like this? Many arduino users would be very happy.
.hc
Programs should be written for people to read, and only incidentally
for machines to execute.
- from Structure and Interpretation of Computer Programs
Hans-Christoph Steiner wrote:
So right now, when [comport] is open and that device gets disconnected, comport freezes and Pd crashes. My guess is that comport is waiting and therefore blocking. It seems like the select() call should prevent that, any other guesses on how to prevent comport from locking like this? Many arduino users would be very happy.
Is this on linux? It should be non-blocking on Windows. I suppose it crashes only when you try to send something, not if you just pull the cable out. I would have thought that if hardware handshaking was off, the port will send anyway. I seem to remember sending into an oscilloscope probe with no cable present. Select is problematic, as we have seen with recent [tcpserver], checking if each byte can be sent before it goes out slows the whole thing down a lot.
Martin
On May 8, 2009, at 8:14 AM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
So right now, when [comport] is open and that device gets
disconnected, comport freezes and Pd crashes. My guess is that
comport is waiting and therefore blocking. It seems like the
select() call should prevent that, any other guesses on how to
prevent comport from locking like this? Many arduino users would
be very happy.Is this on linux? It should be non-blocking on Windows. I suppose it crashes only when you try to send something, not if you
just pull the cable out. I would have thought that if hardware
handshaking was off, the port will send anyway. I seem to remember
sending into an oscilloscope probe with no cable present. Select is problematic, as we have seen with recent [tcpserver],
checking if each byte can be sent before it goes out slows the whole
thing down a lot.
This is on Mac OS X mostly, but maybe linux too. It seems odd that
select() would slow things down so much. Perhaps there is some kind
of flag that can lighten the load.
This stuff is definitely a pain.
.hc
Programs should be written for people to read, and only incidentally
for machines to execute.
- from Structure and Interpretation of Computer Programs
On Fri, 2009-05-08 at 08:14 -0400, Martin Peach wrote:
Hans-Christoph Steiner wrote:
So right now, when [comport] is open and that device gets disconnected, comport freezes and Pd crashes. My guess is that comport is waiting and therefore blocking. It seems like the select() call should prevent that, any other guesses on how to prevent comport from locking like this? Many arduino users would be very happy.
Is this on linux? It should be non-blocking on Windows. I suppose it crashes only when you try to send something, not if you just pull the cable out. I would have thought that if hardware handshaking was off, the port will send anyway. I seem to remember sending into an oscilloscope probe with no cable present.
Select is problematic, as we have seen with recent [tcpserver], checking if each byte can be sent before it goes out slows the whole thing down a lot.
i am still in the process of understanding things, that you have to deal with, so forgive any obvious question from my side, but why is it necessary to call select() for each single byte? wouldn't it be sufficient to call it 'from time to time' (whatever that means)?
just out of curiosity: if there is a solution, that works well for [tcpserver], couldn't it be applied also to [comport]?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman wrote:
On Fri, 2009-05-08 at 08:14 -0400, Martin Peach wrote:
Hans-Christoph Steiner wrote:
So right now, when [comport] is open and that device gets disconnected, comport freezes and Pd crashes. My guess is that comport is waiting and therefore blocking. It seems like the select() call should prevent that, any other guesses on how to prevent comport from locking like this? Many arduino users would be very happy.
Is this on linux? It should be non-blocking on Windows. I suppose it crashes only when you try to send something, not if you just pull the cable out. I would have thought that if hardware handshaking was off, the port will send anyway. I seem to remember sending into an oscilloscope probe with no cable present.
Select is problematic, as we have seen with recent [tcpserver], checking if each byte can be sent before it goes out slows the whole thing down a lot.
i am still in the process of understanding things, that you have to deal with, so forgive any obvious question from my side, but why is it necessary to call select() for each single byte? wouldn't it be sufficient to call it 'from time to time' (whatever that means)?
I guess if you pull the cable out at the exact moment that [tcpserver] is sending a message, every once in a while it might hang because select said it was clear to send, but right after that the connection broke...
just out of curiosity: if there is a solution, that works well for [tcpserver], couldn't it be applied also to [comport]?
Maybe. But I think you should be able to use [comport] with no hardware handshaking enabled and send data even if no cable is attached. Sometimes the absence of one of the two input handshake signals prevents the serial hardware from sending. Also if an error occurred in the reception of serial data it may not be handled properly in [comport]. So I'm not sure what is causing this particular crash, since HC said that it happened when the remote device was disconnected but gave no further detail.
Martin
thanks for the info.
On Fri, 2009-05-08 at 19:27 +0000, martin.peach@sympatico.ca wrote:
just out of curiosity: if there is a solution, that works well for [tcpserver], couldn't it be applied also to [comport]?
Maybe. But I think you should be able to use [comport] with no hardware handshaking enabled and send data even if no cable is attached. Sometimes the absence of one of the two input handshake signals prevents the serial hardware from sending. Also if an error occurred in the reception of serial data it may not be handled properly in [comport]. So I'm not sure what is causing this particular crash, since HC said that it happened when the remote device was disconnected but gave no further detail.
iirc, on linux at least, [comport] makes pd hang, _whenever_ the other end disappears. i.e.:
- pulling out the usb-cable, while the arduino is connected
- turning off an rfcomm device
i should test again, if pd hangs immediately, or if only hangs sending another message/a certain amount of bytes to [comport].
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Roman Haefeli wrote:
thanks for the info.
On Fri, 2009-05-08 at 19:27 +0000, martin.peach@sympatico.ca wrote:
just out of curiosity: if there is a solution, that works well for [tcpserver], couldn't it be applied also to [comport]?
Maybe. But I think you should be able to use [comport] with no hardware handshaking enabled and send data even if no cable is attached. Sometimes the absence of one of the two input handshake signals prevents the serial hardware from sending. Also if an error occurred in the reception of serial data it may not be handled properly in [comport]. So I'm not sure what is causing this particular crash, since HC said that it happened when the remote device was disconnected but gave no further detail.
iirc, on linux at least, [comport] makes pd hang, _whenever_ the other end disappears. i.e.:
- pulling out the usb-cable, while the arduino is connected
- turning off an rfcomm device
This looks like something related to the usb interface. I think pulling out an RS-232 cable has no effect, as the serial driver can only be closed by [comport]. With a usb adapter the usb driver can close the port. I suspect that the comport_tick routine, which is called periodically to check for received characters, tries to access the serial port after the usb driver has closed it. The non-Windows code in comport_tick looks like this:
unsigned char serial_byte; fd_set com_rfds; int count = 0;
FD_ZERO(&com_rfds); FD_SET(fd,&com_rfds);
while((err=select(fd+1,&com_rfds,NULL,NULL,&null_tv)) > 0) { err = read(fd,(char *) &serial_byte,1); outlet_float(x->x_data_outlet, (t_float) serial_byte); ++count; }
As you can see the select call only checks for the presence of received characters with com_rfds, and doesn't check the write or exception status. I suppose the select call should also check the exception fd_set, as the usb driver has no other way of informing [comport] that it has closed the port, it should have flagged it there. (Although if the fd itself is no longer valid I don't know what to do...using non-existent file descriptors is a good way to crash Pd)
ATM I only have 'legacy' RS-232 ports on my hardware so I can't test it, but I can change the code.
Martin
On May 9, 2009, at 2:43 PM, Martin Peach wrote:
Roman Haefeli wrote:
thanks for the info. On Fri, 2009-05-08 at 19:27 +0000, martin.peach@sympatico.ca wrote:
just out of curiosity: if there is a solution, that works well for [tcpserver], couldn't it be applied also to [comport]?
Maybe. But I think you should be able to use [comport] with no hardware handshaking enabled and send data even if no cable is attached. Sometimes the absence of one of the two input handshake signals prevents the serial hardware from sending. Also if an error occurred in the reception of serial data it may not be handled properly in [comport]. So I'm not sure what is causing this
particular crash, since HC said that it happened when the remote device was disconnected but gave no further detail.iirc, on linux at least, [comport] makes pd hang, _whenever_ the
other end disappears. i.e.:
- pulling out the usb-cable, while the arduino is connected
- turning off an rfcomm device
This looks like something related to the usb interface. I think
pulling out an RS-232 cable has no effect, as the serial driver can
only be closed by [comport]. With a usb adapter the usb driver can
close the port. I suspect that the comport_tick routine, which is called
periodically to check for received characters, tries to access the
serial port after the usb driver has closed it. The non-Windows code in comport_tick looks like this:unsigned char serial_byte; fd_set com_rfds; int count = 0;
FD_ZERO(&com_rfds); FD_SET(fd,&com_rfds);
while((err=select(fd+1,&com_rfds,NULL,NULL,&null_tv)) > 0) { err = read(fd,(char *) &serial_byte,1); outlet_float(x->x_data_outlet, (t_float) serial_byte); ++count; }
As you can see the select call only checks for the presence of
received characters with com_rfds, and doesn't check the write or
exception status. I suppose the select call should also check the
exception fd_set, as the usb driver has no other way of informing
[comport] that it has closed the port, it should have flagged it
there. (Although if the fd itself is no longer valid I don't know what to
do...using non-existent file descriptors is a good way to crash Pd)ATM I only have 'legacy' RS-232 ports on my hardware so I can't test
it, but I can change the code.Martin
Ok, quick test shows a couple things:
- just using [comport 1 115200] and then yanking the USB out causes
the crash, so no data needs to be sent to cause this. This is with a
standard Arduino USB.
- in the select() that you highlight, it is just testing before
reading, so I am guessing it would not be so useful to do a write test
if it is only going to read().
.hc
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
Hans-Christoph Steiner wrote:
On May 9, 2009, at 2:43 PM, Martin Peach wrote:
Roman Haefeli wrote:
thanks for the info. On Fri, 2009-05-08 at 19:27 +0000, martin.peach@sympatico.ca wrote:
just out of curiosity: if there is a solution, that works well for [tcpserver], couldn't it be applied also to [comport]?
Maybe. But I think you should be able to use [comport] with no hardware handshaking enabled and send data even if no cable is attached. Sometimes the absence of one of the two input handshake signals prevents the serial hardware from sending. Also if an error occurred in the reception of serial data it may not be handled properly in [comport]. So I'm not sure what is causing this particular crash, since HC said that it happened when the remote device was disconnected but gave no further detail.
iirc, on linux at least, [comport] makes pd hang, _whenever_ the other end disappears. i.e.:
- pulling out the usb-cable, while the arduino is connected
- turning off an rfcomm device
This looks like something related to the usb interface. I think pulling out an RS-232 cable has no effect, as the serial driver can only be closed by [comport]. With a usb adapter the usb driver can close the port. I suspect that the comport_tick routine, which is called periodically to check for received characters, tries to access the serial port after the usb driver has closed it. The non-Windows code in comport_tick looks like this:
unsigned char serial_byte; fd_set com_rfds; int count = 0;
FD_ZERO(&com_rfds); FD_SET(fd,&com_rfds);
while((err=select(fd+1,&com_rfds,NULL,NULL,&null_tv)) > 0) { err = read(fd,(char *) &serial_byte,1); outlet_float(x->x_data_outlet, (t_float) serial_byte); ++count; }
As you can see the select call only checks for the presence of received characters with com_rfds, and doesn't check the write or exception status. I suppose the select call should also check the exception fd_set, as the usb driver has no other way of informing [comport] that it has closed the port, it should have flagged it there. (Although if the fd itself is no longer valid I don't know what to do...using non-existent file descriptors is a good way to crash Pd)
ATM I only have 'legacy' RS-232 ports on my hardware so I can't test it, but I can change the code.
Martin
Ok, quick test shows a couple things:
- just using [comport 1 115200] and then yanking the USB out causes the
crash, so no data needs to be sent to cause this. This is with a standard Arduino USB.
So the crash most likely occurs when comport_tick is called by the timer.
- in the select() that you highlight, it is just testing before reading,
so I am guessing it would not be so useful to do a write test if it is only going to read().
The write test is not needed, but I was thinking that the third possible test, the exception test, might give useful info, unless the file descriptor has already become invalid, in which case I don't know what to do about it, since using a dead file descriptor is usually lethal and probably is what is causing the crash. How does [hid] react to unplugging of the device?
Martin
On May 14, 2009, at 6:56 PM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
On May 9, 2009, at 2:43 PM, Martin Peach wrote:
Roman Haefeli wrote:
thanks for the info. On Fri, 2009-05-08 at 19:27 +0000, martin.peach@sympatico.ca wrote:
just out of curiosity: if there is a solution, that works well
for [tcpserver], couldn't it be applied also to [comport]?Maybe. But I think you should be able to use [comport] with no hardware handshaking enabled and send data even if no cable is attached. Sometimes the absence of one of the two input handshake signals prevents the serial hardware from sending. Also if an
error occurred in the reception of serial data it may not be handled properly in [comport]. So I'm not sure what is causing this
particular crash, since HC said that it happened when the remote device was disconnected but gave no further detail.iirc, on linux at least, [comport] makes pd hang, _whenever_ the
other end disappears. i.e.:
- pulling out the usb-cable, while the arduino is connected
- turning off an rfcomm device
This looks like something related to the usb interface. I think
pulling out an RS-232 cable has no effect, as the serial driver
can only be closed by [comport]. With a usb adapter the usb driver
can close the port. I suspect that the comport_tick routine, which is called
periodically to check for received characters, tries to access the
serial port after the usb driver has closed it. The non-Windows code in comport_tick looks like this:unsigned char serial_byte; fd_set com_rfds; int count = 0;
FD_ZERO(&com_rfds); FD_SET(fd,&com_rfds);
while((err=select(fd+1,&com_rfds,NULL,NULL,&null_tv)) > 0) { err = read(fd,(char *) &serial_byte,1); outlet_float(x->x_data_outlet, (t_float) serial_byte); ++count; }
As you can see the select call only checks for the presence of
received characters with com_rfds, and doesn't check the write or
exception status. I suppose the select call should also check the
exception fd_set, as the usb driver has no other way of informing
[comport] that it has closed the port, it should have flagged it
there. (Although if the fd itself is no longer valid I don't know what to
do...using non-existent file descriptors is a good way to crash Pd)ATM I only have 'legacy' RS-232 ports on my hardware so I can't
test it, but I can change the code.Martin
Ok, quick test shows a couple things:
- just using [comport 1 115200] and then yanking the USB out causes
the crash, so no data needs to be sent to cause this. This is with
a standard Arduino USB.So the crash most likely occurs when comport_tick is called by the
timer.
- in the select() that you highlight, it is just testing before
reading, so I am guessing it would not be so useful to do a write
test if it is only going to read().The write test is not needed, but I was thinking that the third
possible test, the exception test, might give useful info, unless
the file descriptor has already become invalid, in which case I
don't know what to do about it, since using a dead file descriptor
is usually lethal and probably is what is causing the crash. How does [hid] react to unplugging of the device?
In [hid] I don't remember doing anything special, I never even used
select(). I am guessing that serial ports behave differently that USB
HID. Serial was designed to be permanently attached, USB was designed
to be hot-pluggable. Here's the read() for example:
while( read (x->x_fd, &(hid_input_event), sizeof(struct
input_event)) > -1 )
I open it using read-only and non-blocking, maybe that has something
to do with it?
x->x_fd = open(block_device, O_RDONLY | O_NONBLOCK);
I just tried a test with just a USB serial adapter, it didn't actually
crash, it just stopped responding and pegged the CPU.
.hc
There is no way to peace, peace is the way. -A.J. Muste
Hans-Christoph Steiner wrote:
On May 14, 2009, at 6:56 PM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
On May 9, 2009, at 2:43 PM, Martin Peach wrote:
Roman Haefeli wrote:
thanks for the info. On Fri, 2009-05-08 at 19:27 +0000, martin.peach@sympatico.ca wrote:
> just out of curiosity: if there is a solution, that works well for > [tcpserver], couldn't it be applied also to [comport]? > Maybe. But I think you should be able to use [comport] with no hardware handshaking enabled and send data even if no cable is attached. Sometimes the absence of one of the two input handshake signals prevents the serial hardware from sending. Also if an error occurred in the reception of serial data it may not be handled properly in [comport]. So I'm not sure what is causing this particular crash, since HC said that it happened when the remote device was disconnected but gave no further detail.
iirc, on linux at least, [comport] makes pd hang, _whenever_ the other end disappears. i.e.:
- pulling out the usb-cable, while the arduino is connected
- turning off an rfcomm device
This looks like something related to the usb interface. I think pulling out an RS-232 cable has no effect, as the serial driver can only be closed by [comport]. With a usb adapter the usb driver can close the port. I suspect that the comport_tick routine, which is called periodically to check for received characters, tries to access the serial port after the usb driver has closed it. The non-Windows code in comport_tick looks like this:
unsigned char serial_byte; fd_set com_rfds; int count = 0;
FD_ZERO(&com_rfds); FD_SET(fd,&com_rfds);
while((err=select(fd+1,&com_rfds,NULL,NULL,&null_tv)) > 0) { err = read(fd,(char *) &serial_byte,1); outlet_float(x->x_data_outlet, (t_float) serial_byte); ++count; }
As you can see the select call only checks for the presence of received characters with com_rfds, and doesn't check the write or exception status. I suppose the select call should also check the exception fd_set, as the usb driver has no other way of informing [comport] that it has closed the port, it should have flagged it there. (Although if the fd itself is no longer valid I don't know what to do...using non-existent file descriptors is a good way to crash Pd)
ATM I only have 'legacy' RS-232 ports on my hardware so I can't test it, but I can change the code.
Martin
Ok, quick test shows a couple things:
- just using [comport 1 115200] and then yanking the USB out causes
the crash, so no data needs to be sent to cause this. This is with a standard Arduino USB.
So the crash most likely occurs when comport_tick is called by the timer.
- in the select() that you highlight, it is just testing before
reading, so I am guessing it would not be so useful to do a write test if it is only going to read().
The write test is not needed, but I was thinking that the third possible test, the exception test, might give useful info, unless the file descriptor has already become invalid, in which case I don't know what to do about it, since using a dead file descriptor is usually lethal and probably is what is causing the crash. How does [hid] react to unplugging of the device?
In [hid] I don't remember doing anything special, I never even used select(). I am guessing that serial ports behave differently that USB HID. Serial was designed to be permanently attached, USB was designed to be hot-pluggable. Here's the read() for example:
while( read (x->x_fd, &(hid_input_event), sizeof(structinput_event)) > -1 )
I open it using read-only and non-blocking, maybe that has something to do with it?
x->x_fd = open(block_device, O_RDONLY | O_NONBLOCK);I just tried a test with just a USB serial adapter, it didn't actually crash, it just stopped responding and pegged the CPU.
Well I got hold of an Arduino Diecimila and played around with the [comport] code on an up-to-date Debian box but no luck. I tried select() to see if the port is still writeable, as well as to see if any exceptions occurred, but no. Also I tried trapping the SIGHUP that's supposed to be sent but I didn't get any. There seems to be an issue with the FTDI driver for linux, as mentioned in some bug reports and patches (Arduino is using an FTDI USB to serial converter). It seems that it doesn't close properly when it's hot-unplugged; even though /var/log/messages gets written to when the close happens, no SIGHUP is sent. So we probably have to wait for the patches to trickle down into the next kernel.
Martin
Am 14.05.2009 um 22:14 schrieb Hans-Christoph Steiner:
On May 9, 2009, at 2:43 PM, Martin Peach wrote:
Roman Haefeli wrote:
thanks for the info. On Fri, 2009-05-08 at 19:27 +0000, martin.peach@sympatico.ca wrote:
just out of curiosity: if there is a solution, that works well for [tcpserver], couldn't it be applied also to [comport]?
Maybe. But I think you should be able to use [comport] with no hardware handshaking enabled and send data even if no cable is attached. Sometimes the absence of one of the two input handshake signals prevents the serial hardware from sending. Also if an error occurred in the reception of serial data it may not be handled properly in [comport]. So I'm not sure what is causing this
particular crash, since HC said that it happened when the remote device was disconnected but gave no further detail.iirc, on linux at least, [comport] makes pd hang, _whenever_ the
other end disappears. i.e.:
- pulling out the usb-cable, while the arduino is connected
- turning off an rfcomm device
This looks like something related to the usb interface. I think
pulling out an RS-232 cable has no effect, as the serial driver can
only be closed by [comport]. With a usb adapter the usb driver can
close the port. I suspect that the comport_tick routine, which is called
periodically to check for received characters, tries to access the
serial port after the usb driver has closed it. The non-Windows code in comport_tick looks like this:unsigned char serial_byte; fd_set com_rfds; int count = 0;
FD_ZERO(&com_rfds); FD_SET(fd,&com_rfds);
while((err=select(fd+1,&com_rfds,NULL,NULL,&null_tv)) > 0) { err = read(fd,(char *) &serial_byte,1); outlet_float(x->x_data_outlet, (t_float) serial_byte); ++count; }
As you can see the select call only checks for the presence of
received characters with com_rfds, and doesn't check the write or
exception status. I suppose the select call should also check the
exception fd_set, as the usb driver has no other way of informing
[comport] that it has closed the port, it should have flagged it
there. (Although if the fd itself is no longer valid I don't know what to
do...using non-existent file descriptors is a good way to crash Pd)ATM I only have 'legacy' RS-232 ports on my hardware so I can't
test it, but I can change the code.Martin
Ok, quick test shows a couple things:
- just using [comport 1 115200] and then yanking the USB out causes
the crash, so no data needs to be sent to cause this. This is with
a standard Arduino USB.
- in the select() that you highlight, it is just testing before
reading, so I am guessing it would not be so useful to do a write
test if it is only going to read().
i can confirm this. when a [print] is connected to [comport] and after
unplugging the usb cable, [comport] starts sending '0' messages with
maximum rate. so it seems, that it is bogusly receiving data.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On May 15, 2009, at 4:09 AM, Roman Haefeli wrote:
Am 14.05.2009 um 22:14 schrieb Hans-Christoph Steiner:
On May 9, 2009, at 2:43 PM, Martin Peach wrote:
Roman Haefeli wrote:
thanks for the info. On Fri, 2009-05-08 at 19:27 +0000, martin.peach@sympatico.ca wrote:
just out of curiosity: if there is a solution, that works well
for [tcpserver], couldn't it be applied also to [comport]?Maybe. But I think you should be able to use [comport] with no hardware handshaking enabled and send data even if no cable is attached. Sometimes the absence of one of the two input handshake signals prevents the serial hardware from sending. Also if an
error occurred in the reception of serial data it may not be handled properly in [comport]. So I'm not sure what is causing this
particular crash, since HC said that it happened when the remote device was disconnected but gave no further detail.iirc, on linux at least, [comport] makes pd hang, _whenever_ the
other end disappears. i.e.:
- pulling out the usb-cable, while the arduino is connected
- turning off an rfcomm device
This looks like something related to the usb interface. I think
pulling out an RS-232 cable has no effect, as the serial driver
can only be closed by [comport]. With a usb adapter the usb driver
can close the port. I suspect that the comport_tick routine, which is called
periodically to check for received characters, tries to access the
serial port after the usb driver has closed it. The non-Windows code in comport_tick looks like this:unsigned char serial_byte; fd_set com_rfds; int count = 0;
FD_ZERO(&com_rfds); FD_SET(fd,&com_rfds);
while((err=select(fd+1,&com_rfds,NULL,NULL,&null_tv)) > 0) { err = read(fd,(char *) &serial_byte,1); outlet_float(x->x_data_outlet, (t_float) serial_byte); ++count; }
As you can see the select call only checks for the presence of
received characters with com_rfds, and doesn't check the write or
exception status. I suppose the select call should also check the
exception fd_set, as the usb driver has no other way of informing
[comport] that it has closed the port, it should have flagged it
there. (Although if the fd itself is no longer valid I don't know what to
do...using non-existent file descriptors is a good way to crash Pd)ATM I only have 'legacy' RS-232 ports on my hardware so I can't
test it, but I can change the code.Martin
Ok, quick test shows a couple things:
- just using [comport 1 115200] and then yanking the USB out causes
the crash, so no data needs to be sent to cause this. This is with
a standard Arduino USB.
- in the select() that you highlight, it is just testing before
reading, so I am guessing it would not be so useful to do a write
test if it is only going to read().i can confirm this. when a [print] is connected to [comport] and
after unplugging the usb cable, [comport] starts sending '0'
messages with maximum rate. so it seems, that it is bogusly
receiving data.roman
Does it crash? I just hooked up a print to my Arduino Stamp USB-
serial adapter and got nothing, and it doesn't crash either. I find
that when disconnecting using an arduino, Pd usually crashes.
.hc
I spent 33 years and four months in active military service and during
that period I spent most of my time as a high class muscle man for Big
Business, for Wall Street and the bankers. - General Smedley Butler
On Fri, 2009-05-15 at 11:21 -0400, Hans-Christoph Steiner wrote:
On May 15, 2009, at 4:09 AM, Roman Haefeli wrote:
Am 14.05.2009 um 22:14 schrieb Hans-Christoph Steiner:
On May 9, 2009, at 2:43 PM, Martin Peach wrote:
Roman Haefeli wrote:
thanks for the info. On Fri, 2009-05-08 at 19:27 +0000, martin.peach@sympatico.ca wrote:
> just out of curiosity: if there is a solution, that works well
> for > [tcpserver], couldn't it be applied also to [comport]? > Maybe. But I think you should be able to use [comport] with no hardware handshaking enabled and send data even if no cable is attached. Sometimes the absence of one of the two input handshake signals prevents the serial hardware from sending. Also if an
error occurred in the reception of serial data it may not be handled properly in [comport]. So I'm not sure what is causing this
particular crash, since HC said that it happened when the remote device was disconnected but gave no further detail.iirc, on linux at least, [comport] makes pd hang, _whenever_ the
other end disappears. i.e.:
- pulling out the usb-cable, while the arduino is connected
- turning off an rfcomm device
This looks like something related to the usb interface. I think
pulling out an RS-232 cable has no effect, as the serial driver
can only be closed by [comport]. With a usb adapter the usb driver
can close the port. I suspect that the comport_tick routine, which is called
periodically to check for received characters, tries to access the
serial port after the usb driver has closed it. The non-Windows code in comport_tick looks like this:unsigned char serial_byte; fd_set com_rfds; int count = 0;
FD_ZERO(&com_rfds); FD_SET(fd,&com_rfds);
while((err=select(fd+1,&com_rfds,NULL,NULL,&null_tv)) > 0) { err = read(fd,(char *) &serial_byte,1); outlet_float(x->x_data_outlet, (t_float) serial_byte); ++count; }
As you can see the select call only checks for the presence of
received characters with com_rfds, and doesn't check the write or
exception status. I suppose the select call should also check the
exception fd_set, as the usb driver has no other way of informing
[comport] that it has closed the port, it should have flagged it
there. (Although if the fd itself is no longer valid I don't know what to
do...using non-existent file descriptors is a good way to crash Pd)ATM I only have 'legacy' RS-232 ports on my hardware so I can't
test it, but I can change the code.Martin
Ok, quick test shows a couple things:
- just using [comport 1 115200] and then yanking the USB out causes
the crash, so no data needs to be sent to cause this. This is with
a standard Arduino USB.
- in the select() that you highlight, it is just testing before
reading, so I am guessing it would not be so useful to do a write
test if it is only going to read().i can confirm this. when a [print] is connected to [comport] and
after unplugging the usb cable, [comport] starts sending '0'
messages with maximum rate. so it seems, that it is bogusly
receiving data.roman
Does it crash? I just hooked up a print to my Arduino Stamp USB- serial adapter and got nothing, and it doesn't crash either. I find
that when disconnecting using an arduino, Pd usually crashes.
sorry, i wasn't precise. it does not crash, but pd hangs (uses 100% cpu and does not respond anymore). i interprete it as [comport] blocking pd and going into an infinite loop, when the plug is pulled without prior closing the port.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
-
Hans-Christoph Steiner -
Martin Peach -
martin.peach＠sympatico.ca
-
Roman Haefeli