tchinou1:
GoForSmoke, I tested your code, but I with the: & i < (arraySize -1) I receive only 18 variables. If I remove this parameter, I get pretty close to my goal. The first time I receive 70 value, but the second only 68 and the third 66. After that it seems to stay to 66 or 65
The index doesn't seems to reset in my code, in a test code it was working, but not in the main one. However, with the reset line, it's okay.
You are creating problems by not posting the whole code after changing it.
I don't understand HOW you get the above much less WHY.
When I made the example out of your original snippet and then tried to show how the index might be maintained I used a variable name arraySize for what it is for ---
in your case the variable, whatever you call it, should be 71 elements to include a terminating zero because I made the Possibly Stupid Assumption (MY BAD) that the serial data is for a text string and text strings must always end with 0. So if you would collect 70 chars of text, you need a 71 char array.
Did I give you a link to the Arduino Fundamentals page?
The variables received, are use for color and other parameter in a Vu meter,
PS: I just noticed that when I get rid of the fastled.show(), there is no more problem. I am using the fastled library.
I can't begin to guess why without seeing the whole code that will tell me the full story.
Understand please that when looking for bugs, how the person who wrote them understands the code may well be why the bugs are there. The full code and wiring tell the true story including errors the coder has not (yet) detected.
So please! Full code! We can help you faster!
Here is the code that is working the best for me right now:
if ( Serial1.available() )
{
var[a] = Serial1.read();
Serial.print(a);
Serial.print(": ");
Serial.println(var[a]);
a++;
if(a == 71) { a = 0; }
}
RL[0] = var[0];
RL[1] = var[6];
RL[2] = var[12];
RL[3] = var[18];
RL[4] = var[24];
RL[5] = var[30];
RL[6] = var[36];
RL[7] = var[42];
RL[8] = var[48];
RL[9] = var[54];
RR[0] = var[3];
RR[1] = var[9];
RR[2] = var[15];
RR[3] = var[21];
RR[4] = var[27];
RR[5] = var[33];
RR[6] = var[39];
RR[7] = var[45];
RR[8] = var[51];
RR[9] = var[57];
GL[0] = var[1];
GL[1] = var[7];
GL[2] = var[13];
GL[3] = var[19];
GL[4] = var[25];
GL[5] = var[31];
GL[6] = var[37];
GL[7] = var[43];
GL[8] = var[49];
GL[9] = var[55];
GR[0] = var[4];
GR[1] = var[10];
GR[2] = var[16];
GR[3] = var[22];
GR[4] = var[28];
GR[5] = var[34];
GR[6] = var[40];
GR[7] = var[46];
GR[8] = var[52];
GR[9] = var[58];
BL[0] = var[2];
BL[1] = var[8];
BL[2] = var[14];
BL[3] = var[20];
BL[4] = var[26];
BL[5] = var[32];
BL[6] = var[38];
BL[7] = var[44];
BL[8] = var[50];
BL[9] = var[56];
BR[0] = var[5];
BR[1] = var[11];
BR[2] = var[17];
BR[3] = var[23];
BR[4] = var[29];
BR[5] = var[35];
BR[6] = var[41];
BR[7] = var[47];
BR[8] = var[53];
BR[9] = var[59];
ActiveMode = var[60];
power = var[61];
rotation = var[62];
rotation_order = var[63];
rotation_time = var[64];
random_mode = var[65];
mode_time = var[66];
mood = var[67];
mood_type = var[68];
//sensitivity = var[69];
Thanks !
And that is all generated by code you wrote and can change, not just data straight from devices that you can't change?
Because here is one place where you could get errors; serial data has no guarantees. It's generally reliable but good code never treats it so. -----
** That's why we often send data as text. Corrupted text is easy to spot. I think you do this?
** Another thing to do is add identifiers that the receiving code looks for and acts upon. One or two letters is enough especially when the data is all numbers, doesn't have to be for every variable but the more you use, the more sure you can be that your serial data is good or not.
** Another thing to do, industry standard when binary data is used but good with text is to use CRC (cyclic redundancy check) as an error check. CRC can be simple or not so simply done, people have different ways to use the CRC principle. Easy way is to use a byte (unsigned char) that starts as zero and then add every byte in the message, always making a byte result to add the next until the end. That byte must match the CRC byte at the end of the message (or part checked) and if not matched is error.
I interpreted text from electric meters not so long ago and have done for gas pumps and cash registers and industrial machines. They use all the above tricks to make sure their code knows good data from bad.
All because serial transmission has no guarantees (thanks for that term... AWOL or Grumpy Mike?).
So perhaps you may want to change that 70 character message a little?
And if you like, I can show you how to read such a string without buffering any of it.
