Hereby an example implementation to control FastLED with 11 byte commands. A lightweight protocol, so it should be also easy to use with something like Bluetooth.
It’s not an attempt from me to make a standard, because I think everyone makes their own effects. I hope this is a good starting point for people to experiment with controllable parameters over the Serial port. Suggestions and improvements are welcome of course.
This is sort of motivating me to share the simple param passing protocol that I sometimes use for debugging and config changes! I’ll add that to the queue… but what you have here looks pretty solid and ‘industrial strength’.
@Kasper_Kamperman What micro controller are you using? I just tried compiling the Arduino code (tried Arduino 1.0.6 and also 1.6.5) for a Teensy 3.0 and it’s giving this error for code line 32:
invalid conversion from ‘uint8_t* {aka unsigned char*}’ to ‘char*’ [-fpermissive]
@marmil I tested with an Arduino Uno on 1.6.5. I added the uint8_t cast because otherwise I got this error: conversion for argument 1 from ‘cmd*’ to ‘uint8_t* {aka unsigned char*}’
Does (byte*) work? That seems better (since the function is readBytes):
I found an UNO and that worked. Changing Serial.readBytes((uint8_t*) to Serial.readBytes((byte*) didn’t work on the Teensy 3.0. Anyone know the format needed to make it compile on the Teensy?
I like the idea of a check, give it a try. Your summation comparison check is an interesting idea. That’s getting into coding ideas/practices I’ve never looked into. Is there any benefit to doing something like that vs just checking for a specific character you send at end (like a # sign for example, byte value 35)?
I think the benefit is that you check also the first byte indirectly. I think some protocols use the inverse of a specific byte, thats how I got that idea. But I’m not an expert in this field either. I did a quick search for some best practises, but I couldn’t really find something.
If read something more on CRC, checksums and packing messages in an envelope. However that makes things more complicated, although the message size is fixed. I think protocols like Bluetooth already have error checking build in, so no need to do this on this level.
I’ve updated the protocol with an extra padding byte. Explanation from @Daniel_Garcia : The reason is because compilers on 32 bit systems like to align data - so 16 bit items like to be on 2 byte boundaries, 4 byte items on 4 bytes, etc…
So it will be 12 bytes now, urls mentioned in the original post stay the same.
Hi Kasper, What kind of performance are you able to get with this implementation? I’ve been trying to get something working with Pure Data and Arduino/FastLED but as soon as I get three faders moving simultaneously the flickering starts. I’ve tried OSC and am now using raw slip packages… but I’m still getting the flickering when I change 3+ commands at the same time. I’m happy to share the code with anyone interested.
I didn’t test with sending multiple values at the same time. In order to test if values are received well, I would check if you receive them with the serial command window. Or you could use a dummy command. For example connected the three faders directly to three different leds.
It’s difficult to say where the problem is. Keep in mind that Arduino is single thread. So receiving and processing the commands takes time… So you have to be smart with timing (I’ve posted an interpolation example somewhere, that’s how I deal with this).
When I Serial.println(); for a particular variable stream I will frequently get things like this when trying to “fade” from 0-100:
0
1
2
3
4
5
67
8
9
10
11
1213
14
15
16
etc…
I would be very interested to see your interpolation example!
I use a pd patch which is sending 2 part messages (tag# value) encoded using the [slipenc] object from the mrpeach library. When printing from within PD everything looks perfect. It is only when printing from the arduino IDE that I get what seem to be the glitches described above.
The problem is that this blocks your code. So you might get glitches. Serial.println also takes time. If you send a lot of packages, the while loop keeps running (and takes longer).
In my method I just read one command from the buffer. Nothing more. The next command will be read the next time (since the buffer can hold some data). For my it doesn’t matter if one packet is one frame later (you won’t notice it).