Strange problem with Arduino Uno communicating over SPI

Projects Networking, Protocols, and Devices
1

Hello,

I am programming an Arduino to control a LED Strip using the Fast_SPI.lib (Although this problem has nothing to do with the Fast_SPI.lib I guess)

Right now I am controlling a strip with 32 LEDs, I get an input in my Arduino of 96 decimal values (R,G,B for each LED) coming from my Terminal software (HTerm on Win 7). I store the values each in an unsigned char Array, one after the other.

I kind of created my own protocol standard, which means, that the input has to start with 1 then 3 and then followed by the actual input. The end of the communication is indicated by the value 251. So in the following you see the relevant part of my code:

if(Serial.available()>0)
  { 
    int a=0, b=0;
    int Check=0;
    Serial.println("begin"); //just for debug reasons
    delay(1);
   
     if(Header[0]==Serial.read() && Header[1]==Serial.read()) //Header[0] contains 1, Header [1] contains 3
     {
       Serial.println("ok");  //just for debug reasons
       Endstr=1; //set to 1 to continue with the next loop
     }
     else Serial.println("not");  //just for debug reasons
     
       
     while (Endstr==1)
     {
       
       incomingByte[a]=Serial.read();
       //delay(15);

                              /*I am referring to the following two Serial.println functions
                              //Serial.println(incomingByte[a],DEC); 
                              //Serial.println(a,DEC);
                              */


       if(incomingByte[a]==251)
       ...

Supposed, I have a correct input (beginning with 1 3) I have following strange problem:

If I use either one of the two centered serial.println functions (doesn"t matter which one), the check whether the input begins with 1 3 will succeed.
If I don't use any of the two print functions, the check will fail.

The strange thing now, as you may already have realized, is that the Serial.print function is in the while loop, after the check. So actually any code written in this while loop should not affect the check, especially as the succeeded check will grant the while loop to begin.

So, hopefully someone of you has an idea where the problem is, or maybe it is even a bug of the arduino platform??

Thanks in advance for your help!

Kai

2 
if(Serial.available()>0)

Means there is one or more bytes waiting. Yet you...

     if(Header[0]==Serial.read() && Header[1]==Serial.read()) //Header[0] contains 1, Header [1] contains 3

...always try to extract two bytes from the queue.

What happens if there is only one byte waiting?

3

You are right, this could cause some problems during the real operation, yet it is not the reason for my specific problem. But thanks for that advice

(As I am still experimenting I didn't implement all the necessary functions to filter possbile errors, yet)

4

blahnik:
...yet it is not the reason for my specific problem...

Wanna bet?

5

As I am entering the input manually right now I am sure that I have an input >1 char.

A temporary "fix", setting serial.available to >2 to wait for the buffer to be filled with the first several chars (what I was already aiming with the delay) didn't help.

Also from my point of view I can't see the correlation between your tip and the reason why a serial.println function in a loop AFTER the check influences it. But maybe you can be more specific? :wink:

6

blahnik:
As I am entering the input manually right now I am sure that I have an input >1 char.

You are manually sending a single byte at a time with a delay between bytes? How long is the delay?

A temporary "fix", setting serial.available to >2 to wait for the buffer to be filled with the first several chars (what I was already aiming with the delay) didn't help.

Which indicates that you failed to post enough code to diagnose the problem.

Also from my point of view I can't see the correlation between your tip and the reason why a serial.println function in a loop AFTER the check influences it. But maybe you can be more specific? :wink:

The Serial.print calls add enough delay that an entire frame arrives.