<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
> > Hi Ricardo,<br>> > Well I didn't have chance to try it with [comport], but I suspect you need<br>> > to make the output of [comport] into lists using the slip packet delimiter<br>> > 192 and [list append] and [list prepend] as in the [list] examples.<br>> > It should not crash Pd though, that's bad...<br>> > Martin<br>> <br>> Hi Martin, I used [list preped] and [list append] as you said and now<br>> it works, thanks.<br>> <br><br>Yes, but I think it should work with individual input bytes, I noticed that it's not checking the buffer for overflow in that case, so I will fix that today. I was getting crashes by feeding [slipdec] with random bytes.<br><br><br>> However, I am still getting crashes with the stream from comport (if I<br>> program the microcontroller to send messages every ~200ms, it works<br>> fine), I read a recent mail about unpackOSC, then I tested using just<br>> slipdec (still crashes)<br>> <br>> Crashes occur if I send messages too fast, just putting a [metro 50]<br>> to a valid message in slipenc-help.pd or sending microcontroller<br>> messages every 10 - 50 ms, freezes pd, and eventually make it crash.<br>> <br><br>Maybe it's a [print] object overloading? Trying to print thousands of numbers usually hangs Pd.<br><br>> I don't know what should be the minimun time that slipdec needs to<br>> process a packet, I use the same settings that I use in Linux with<br>> serialIO, OpenSoundControl and OSCruote [1], in Linux it works pretty<br>> well even with shortes times.<br>> <br><br>It should be able to hold on to a partial message indefinitely, but at the moment if the message list isn't a complete SLIP packet it might not work properly.<br><br>Martin<br> </body>
</html>