Process bytes and check for start key

Question

I am working with some wireless communication in Arduino. My data will be wirelessly received like so:

97
97
97
...
...

979797 is the address of the transmitter. I have written the following code to check the address first before processing the data. My main concern is speed of computation.

void printBuffer(const uint8_t *serialBuffer)
{
 //print contents of buffer
 for (int i = 0; i<100; i++) 
 Serial.println(serialBuffer[i]); //remove the print in binary option to decode
}
void processBytes(const uint8_t value)
{ 
 static uint8_t serialBuffer[bufferSize]; //buffer to hold values
 static unsigned int startPosition=0;
 if(startPosition < bufferSize)
 {
 serialBuffer[startPosition] = value; 
 startPosition++;
 }
 else
 {
 printBuffer(serialBuffer);
 startPosition = 0;
 }
}//end of processBytes
void loop() { 
 //check if data is available in serial buffer
 while(RX.available())
 {
 //check for start key
 address(RX.read())
 //process data
 processBytes(RX.read());
 } 
}
void address(const uint8_t value)
{
 int counter = 0;
 int newVal = value;
 while(value == 97 && counter < 3)
 {
 counter++;
 newVal = RX.read();
 }
}

EDIT: The data packet just has the following components: start key (979797) and 68 bytes of data. There is no termination key. Also, the transmitter transmits one byte at a time. Thus, each value received is less than 256. Hence why I am saving the data into a uint8_t[] array.

Other than the address() method, most of it was borrowed from Gammon. Here is the reference page for the arduino commands I am using. Are there ways I can optimize this computation?

• Incomputable: consst in address definition. Probably a typo
• JS1: Could you clarify your message protocol? What comes after the 97 97 97? What does a complete message look like?
• user85591: (+1) @OlzhasZhumabek, sorry about that, it was a typo.

Answer 1

Bugs

There are several things wrong with this function:

void address(consst uint8_t value)
{
 int counter = 0;
 int newVal = value;
 while(value == 97 && counter < 3)
 {
 counter++;
 newVal = RX.read();
 }
}

1. You never use the variable newVal, which is a mistake. Most likely you meant the while loop to read:

   while (newVal == 97 && counter < 3)
   

   As it stands, your code will always read 3 extra bytes if the first is 97, even if the second byte is not 97. You can also get rid of the newVal variable and just use value, if you change the type of value to make it non-const.

2. const is misspelled.

3. When you encounter a series of three 97 bytes, you actually read 4 bytes. The first byte is already read and passed into this function. The function then reads 3 extra bytes. This means that the first byte of the "message" will be missing when you call processBytes() later on.
4. Your message protocol is unclear. From your code, it appears that the message protocol must be 97 97 97 byte 97 97 97 byte which is extremely wasteful. If that is not the protocol, there are problems with how you handle the message stream. For example, the address() function strips all 97s out of the message stream, whether or not they are part of a sequence of three. Also, if the address() function does not detect a sequence of three 97s, it always discards one byte out of the message stream. I'd need to see an example of a proper message stream in order to advise on a solution.

• user85591: Those are great points. I completely failed to realize #4. I have fixed the typo and updated the question with more information regarding the message protocol. Please let me know if anything is unclear and if I should provide more information.
• user85591: I have added a fix for #4. Also, I have kept the buffer size as 100 because that seemed to be an optimal time of "listening for data" vs printing that many values.
• user85591: any update on this @JS1
• JS1: @Christian Actually you aren't supposed to edit your question to include fixes to the code. What you should do is submit your new code as a separate followup question, which can include a link back to this question for reference. Once you do that, I or others can review your new code.
• user85591: (+1) Sorry about that, I have rolled back the edits and created a new follow-up question. @JS1