Hello.

I have a pd patch running on a raspberry pi which uses [comport] to send messages to a teensy which displays an interface on a screen. This is all working well.

However, after a variable amount of time I always eventually get a comport error: "[comport]: Write failed for -1 bytes, error is 11". After this, every message produces this error and I need to unplug and plug the teensy back in to get things working again.

I've searched around and have seen some posts elsewhere with the same issue but no solutions. I don't think the patch is particularly taxing - the CPU is running at about 20% and the RAM about 25%.

If anyone has any suggestions or insight into the issue I'd be very grateful. Thanks.

Can you share your code and patch? Is the communication duplex? I don't know if that could lead to your issue, but I had a Teensy freezing in the past with duplex communication without setting the order of data transmission. The project was headless, so I didn't see the output error, so I don't know if it was the same.

droninator.zip

Hi, thanks for your response. I've added my source files here. The entry point is main.pd. I've only included the first preset that loads with its wavs to keep the filesize down.

The communication is one way, from the pi to the teensy. The patch loads some wavs which then loop. I'm using an external MIDI controller to switch presets and control the volumes and some automation and effects. The comport is being used to send updates on the current volume, etc for each track which then get displayed on a small screen by the teensy.

My only guesses so far are that it could be the frequency of the messages or perhaps trying to send more than one message at the exact same time. In this latest version I've tried to reduce the frequency of the messages but I'm still getting the comport error.

I'm using the blokas patchbox OS on the pi, which seems to all be working ok.

your patch is pretty complex to sink in it and really grasp it. I checked the Arduino code, and I could suggest to either use a series of else if statements instead of lots of single if, or a switch-case structure, with included breaks, so that your code doesn't have to check every single case whenever something arrives in the serial buffer. There could be something in some other part of the code though that I can't spot because it is hardware specific. Try increasing the baud rate to 115200, and probably slowing down the rate of messages from Pd, as you say.

Thanks for taking the time to look into this. The patch has got quite complicated - it probably makes sense to try and reproduce this error with the most simple patch possible.

That's a good point on the else if or switch case - I'll update that and take a look into updating the baud rate.

I've tried running the patch from my laptop connected to the teensy and the error doesn't occur, even with sending as many messages as possible. But the pi doesn't seem to be that taxed. Is there something about the way the pi uses serial communication which could be causing the problem?

One thing that comes to mind is that sometimes, certain hardware combinations cannot print or write the byte 13 from the serial line to Pd. In such cases, Serial.println() sends the number 10 twice to Pd instead of sending 13 and 10. Serial.write(13) sends 10 to Pd. Maybe there's something similar happening the other way round. You could try and echo what you send to the Teensy back to Pd, maybe manually, so you don't clog the serial line. If you see something suspicious, it could be causing the error.

I've managed to reproduce this error with a much simpler patch: test.zip

This works ok until the metros are set to 4 and 2 or below and then I get the same comport error. It works ok on my laptop but gets the error at faster metro speeds on the pi.

I'm assuming it's not just the message rate but perhaps how close together two messages are. So it could cause the error at slower speeds if several messages end up getting sent at the same time.

I'm trying to think how to make some kind of buffer which ensures the message rate is steady but doesn't miss the current state of any particular setting it's trying to send. In regular coding I suppose this could be an array with the current state of each element which it can then loop through at a steady speed to send any updates to the teensy but I'm not sure of a pd approach to doing something like that. If anyone has any suggestions or has seen anything similar I'd be grateful for the help.

You can use a growing list with your messages if they have a character indicating the beginning and another indicating the end of a message. You can calculate how many bytes you can store, depending on the buffer size of Teensy's serial. Make sure you send batches of messages that fit this size. Send a sort of "done" message from the Teensy to Pd, so that Pd can send the next batch. This is useful in case you're sending too many messages. Perhaps you can make a mechanism that can drop messages in case the list grows exponentially.
You can use [list-extend] from the list-abs library, which is a library of vanilla abstractions for list manipulation.

Thanks, I'll check out [list-extend]. I think this seems like a good strategy but may take me a little time to implement. I think the tricky part will be to make sure key state information is sent if there are a lot of messages - it will be fine to discard some volume messages if there are lots of changes in quick succession, but if a button is pressed once that state really needs to be communicated or the UI will get out of sync. I'm glad to have something to try - I was really running out of ideas on this.

Just wanted to report back on this in case it helps anyone else. It does seem like either the rate of messages or perhaps receiving more than one at the same time was causing problems between the Pi and the Teensy. In the end I used [text] to store the messages in and then a metro to remove them as they were sent to the comport. Any messages of the same type that are already in the list get their values updates (e.g. volume). The full project is more complex but this test example shows how it works: test4.pd

@orgk For [comport] you have other tools to play with.
The baud rate (default 9600 which is low nowadays....... see the [pd bauds] sub-patch in the help file).
You will need to check what the teensy is capable of.
And pollintervall (default 10ms).....
David.

Thanks David. That's a good point, I think the teensy can handle higher baud rates so that looks worth trying.