[PD] preventing comport freezes
Roman Haefeli
reduzierer at yahoo.de
Fri May 15 10:09:59 CEST 2009
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 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().
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
More information about the Pd-list
mailing list