Errors While Resetting Board During Receiving Data

Forum 2005-2010 (read only) Software Syntax & Programs
1

i've written a small sketch that reads data from a Flash application over the serial port using TinkerProxy. everything works as it should from the software: i can connect the device, disconnected the device and send the appropriate data. the data i'm sending from Flash that is read by the Arduino is a simple byte array of 3 values (3 colors) from 0-255.

here is my sketch:

#define RED 11
#define GREEN 10
#define BLUE 9

struct rgbByteArray
  {
  byte element[3];
  }
  rgb;

void setup()
  {
  Serial.begin(9600);

  pinMode(RED, OUTPUT);
  pinMode(GREEN, OUTPUT);
  pinMode(BLUE, OUTPUT);
  }
  
void loop()
  {
  if (Serial.available() == 3)
     {
     rgb.element[0] = Serial.read();
     analogWrite(RED, rgb.element[0]);
     
     rgb.element[1] = Serial.read();
     analogWrite(GREEN, rgb.element[1]);
     
     rgb.element[2] = Serial.read();
     analogWrite(BLUE, rgb.element[2]);
     }
  }

the bizarre problem i am seeing is that if i press the reset button on the Arduino and it restars WHILE Flash is still quickly sending the data, the byte array will always shift up one position. so instead of the red value going to rgb.element[0], it goes to rgb.element[1]. it's also cyclic, so the last element[3], becomes the first element[0].

why is this happening?

of course, if i wait a few seconds before sending data after it resets, the array is normal. however, i would like the ability to press the reset button during the execution of my Flash program and have the data read appropriately when the board is finished resetting.

2 
if (Serial.available() == 3)

What happens if there are 4 bytes in the buffer before this call is made? It should be >= 3, not == 3.

The way that you are sending data now is just a stream of bytes, not a series of rgb values. You need to include some sort of start and end of packet markers, so the Arduino knows WHICH byte is the r value.

If the sending program send , etc., there would be no ambiguity as to which value was for r, which was for g, and which was for b.

3

i'm sending data from my Flash application like this:

socket.writeByte(redValue);
socket.writeByte(greenValue);
socket.writeByte(blueValue);
socket.flush();

so to my knowledge i'm always sending 3 bytes at a time and i haven't set up any data buffer in my sketch. therefore, i believe my if statement is correct, although i'm not completely convinced and wide open for corrections.

how would you code the data so that it's no ambiguous, and hopefully solve the array shift that is caused by resetting the board?

4

I'm not familiar with flash or it's socket methods, but, you need to write some end of packet marker. Right now, the data stream you are writing looks like

rgbrgbrgbrgbrgb

which you interpret as

rgb rgb rgb rgb rgb

and assume that the values are r, g, and b.

During a reset, some of the data is lost. You end up with

brgbrgbrgb

which you interpret as

brg brg brg b

and assume that the values are r, g, and b.

With some sort of end of packet marker, you could determine if you received 3 bytes prior to the end of packet marker.

If you were sending

rgb;rgb;rgb;rgb;rgb;

and interpreting as rgb rgb rgb, you'd be OK.

If some data got lost, and you read only b;rgb;rgb;rgb;, you'd know that the 1st packet was incomplete, and you'd not use any of the data in the packet.

therefore, i believe my if statement is correct

What triggers you to send more data? What is to prevent sending more data before the previous data has all been read? Does the Arduino tell the flash application that it is ready for more data? If not, there is a possibility for there to be more than 3 bytes in the serial buffer. If that happens, your code will stop working. Once there are more than 3 bytes in the buffer, nothing will ever happen to reduce that count.

5

ok, i understand now, so i'll use >= in my if statement.

still trying to figure out the best way to read/ignore data packets, but in the meantime i've notice that placing a small delay(250) at the end of the setup() method corrects this problem. however, the colors array will still be out of place, but the delay seems to put it back into the correct order.