[PD] preventing comport freezes
Hans-Christoph Steiner
hans at at.or.at
Thu May 14 22:14:23 CEST 2009
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 at 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
More information about the Pd-list
mailing list