[PD] preventing comport freezes

Martin Peach martin.peach at sympatico.ca
Sat May 9 20:43:03 CEST 2009


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





More information about the Pd-list mailing list