next topic »

[on:]

I am working on a sound installation which contains at least a few dimmable leds, four servos, a motion detector (ePIR) and an eight channel relay board. This is going to be controlled through max/msp. We've tried Maxuino but it's incredible unstable with my Mega 2560, and we've come to realize that it's quite simple to use the serial connection with a simple customized code for the arduino, that's not a problem.

Now the question is how to send the data streams from Max to Arduino. The simplest way for a max-head like me would be to [prepend] a channel number for every unique data stream (that creates a two number list in which the first is the channel number and the second is unique data), and then in a, ehm, perfect word, be able to use an object similar to [route] in the arduino to strip the first number (the channel number) and then send the second to the the assigned variable. I dont know if this is how you do it at all and I'm a bit amazed that I haven't been able to figure it out myself.

I would be very grateful if someone could point me to the right direction. I've tried to understand how one could do this with Switch/Case but I'm not really into C, at all. Someone mentioned to use a msb/lsb bit technique, but I dont know much about that either. The way we have it now is to simply use range of whatever controller we're using and then add a >= 0, <=255 in arduino to pick out the data, but it will be seriously complicated as the patch grows and whenever you need to change something.

By the way does anyone know if there's anythink I should think of when configuring the [serial] object in Max?

Thank you for your time.

Trrg

[Reply #1 on:]

Reading a bit of C syntax tutorials and reading my post again, I come to realize that, ehm, I sound like a spoiled Max-brat.

I guess now the correct answer to my "Where is the object!?"-question is, "There is no object. Do a function for it!". Now the Max-part of my is crying "Miller, please give me an object!", but I think I just have to swallow my pride and take it as a man, and learn C.

Or as my man Adorno would say; "Keep it dialectic."

[Reply #2 on:]

You are on the right track. Prefixing the actual data with a "symbol" that can identify it's destination is the way to do it.

It would probably be  a good idea to define a "packet", consisting of a startymbol, the channel identifier, the data and finally an end Symbol.

Start and end symbols should not be allowd to be present in channel identifiers and data.

That way you can always get on track again if something goes wrong with the serial communication, just by waiting for a start symbol to arrive.

something like:

[  channel identifier,  data ]

Where the square brackets are start and end identifiers (just chosen randomly, use whatever works for you)

Then as you figured out, in your Arduino code you create a function that reads incomming serial data until you have  a complete package, which you can parse and then deal with the data.

This is usually refered to as a protocol, a well defined way for two devices to exchange some data.
If you search the forum for serial protocol, you should find some stuff to get you started.

I hope this makes sense.

[Reply #3 on:]

Start and end symbols should not be allowd to be present in channel identifiers and data.

That way you can always get on track again if something goes wrong with the serial communication, just by waiting for a start symbol to arrive.

I second this.

Serial data delivery follows the USPS rules of engagement, not the UPS rules. UPS guarantees to deliver your package. USPS guarantees to try to deliver your package.

Serial data can get corrupted due to noise or other factors, and not be delivered. While dropped packets sent over a wire are rare, dropped packets sent wirelessly are common.

You do not want to rely on the order of the bytes being sent as the only means of parsing the received data.

Just as serial data transmission relies on start and stop bits for synchronization, so should your code use synchronization of some sort. Start and end of packet markers do this.