First off, I think I have an idea of what's causing the crashes. I
think its because [comport] isn't handling when the serial port
buffer is full. That's my guess. [comport] should probably start
dropping data, with a warning message, in this condition instead of
just going down the suicide path...

On May 22, 2006, at 7:35 PM, Christian Klippel wrote:

hi,

while at the issue of reading stuff from devices in windows ...

there are also weird problems with libusb on windows. seems that
there are some quirks in windows that prevent the hi-speed use of such ports
(usb is serial as well....)

im wondering if there are any special calls in the windows api that
need to be called first, to set certain parameters first, like for buffering?

Have you seen the OVERLAPPED/asynchronous API for Windows? Check out
the code in [comport], Piotr Majdak implemented this for Windows, and
it seems to be a better way to write to the com port. I think that
it makes Windows do some buffering (but maybe not enough ;).

.hc

greets,

chris

Am Montag, 22. Mai 2006 19:23 schrieb Hans-Christoph Steiner:

...

I have incorporated the "OVERLAPPED" asynchronous mode code for Windows from Piotr Majdak in the [comport], and now it crashes pretty regularly. I just committed the comport-stress-test.pd, which makes Pd crash within a couple minutes. It seems to be caused by transferring a lot of data from Pd to the serial port. FYI: I am using an Arduino to test.

I did a little test to see whether its the new code, or whether there were crashes before. So I compiled revision 1.10, which uses the standard synchronous mode for data transfer. This version seems to last a bit longer, but it crashes in a much uglier way: it zombies Pd and doesn't let go of the serial port. So its an improvement, but still, it crashes a lot.

Any of you Windows hackers want to take a stab? I am going to test things on Mac OS X now.

.hc

---

---

---

        "The arc of history bends towards justice."
                                        - Dr. Martin Luther King,

Jr.

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list

Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos
Williams

On May 24, 2006, at 12:02 PM, Piotr Majdak wrote:

Hi Hans,

Hans-Christoph Steiner wrote:

...

I have incorporated the "OVERLAPPED" asynchronous mode code for
Windows from Piotr Majdak in the [comport], and now it crashes
pretty regularly. I just committed the comport-stress-test.pd,
which makes Pd crash within a couple minutes. It seems to be
caused by transferring a lot of data from Pd to the serial port.
FYI: I am using an Arduino to test.

We get a lot of data from serial port to pd and for this direction
[comport] works in the asynchronous mode. In the transmitting mode,
we send a few bytes only, so we did not any tests...

I don't remember if I've changed anything in the transmitting
section of the code - I'll have a look ASAP.

Can you send me your stress-the-comport patch per email? I'll give
it a try...

Its in CVS, in externals/iem/comport/comport/comport-stress-test.pd

It seems that only transmitting data from Pd to the comport causes
the crashes. Receiving at full speed seems to be no problem.

.hc

"Computer science is no more related to the computer than astronomy
is related to the telescope." -Edsger
Dykstra