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