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

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

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.

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.

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?

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.

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.