Cannot use conditions on uint8_t

[anon66076557]

I tried to read bytes from Serial and put it into uint8_t and I tried to print the contents of uint8_t using Serial.print(); and it worked but there was a problem when I wanted to take part of the bytes in uint8_t to compare, but it didn't work even though what was sent by Serial was correct,

void RecvCommand()
{
    uint8_t readBuffer[256]; 
    int indexBuffer = 0;

    while (Serial.available() > 0) {
        if (indexBuffer < sizeof(readBuffer)) {
            readBuffer[indexBuffer] = Serial.read();
            indexBuffer++;
        }
    }

     if (indexBuffer > 0) {
        Serial.print("Received bytes: ");
         for (int i = 0; i < indexBuffer; i++) {
             Serial.print(readBuffer[i], HEX); 
              Serial.print(" ");
         }
         Serial.println();
     }
    if (indexBuffer > 0) {
        if (readBuffer[0] == 0xFF && readBuffer[1] == 0x01) { 
                Serial.write(readBuffer, indexBuffer);
        }
    }
}

output from Serial Terminal

Success Send Command
Received response:  "52656365697665642062797465733a204646200d0a52656365697665642062797465733a2031200d0a"

if changing “52656365697665642062797465733a204646200d0a52656365697665642062797465733a2031200d0a” to ascii then the output is
“
Bytes received: FF

Byte received: 1
”

here only the print loop part works, not the condition part.

So here uint8_t is not used for comparison, I don't or what the real problem is that the way arduino works is different,

Thanks

[UKHeliBob]

@anon66076557

I tried to read bytes from Serial

Are you reading bytes or are you actually reading characters ?

What is sending the data ?

[sterretje]

@anon66076557

if changing “52656365697665642062797465733a204646200d0a52656365697665642062797465733a2031200d0a” to ascii then the output is

Can you explain what you mean by that?

According to your received response there is no 0xFF as the first byte so that (last) Serial.write() will never be executed.

[anon66076557]

that is the hex received from the arduino to the Serial Terminal if you change the hex to ascii it will look String

Bytes received: FF

Bytes received: 1

after this string there should be a return byte that has been sent from the arduino so Serial.write(readBuffer, indexBuffer); but the Serial Terminal does not receive this at all,, I hope you understand

[gilshultz]

@anon66076557

I tried to read bytes from Serial and put it into uint8_t

Which Arduino are you using? In my experience, both are unsigned integers, so they are essentially the same. Are you perhaps thinking of a nibble, which is 4 bits? UARTs typically operate in 8-bit units.

[sterretje]

Your first byte in the output is 0x52 which is an 'R'; so that last if will never evaluate to true.

Your code does not contain a text Received response: but your output does; the code contains the text Received bytes:. What is going on with that?

Your output is also missing all spaces that your code is supposed to print so what is happening there?

[StefanL38]

We only knew what you are writing.
We don't sit next to your computer.

@anon66076557

Bytes received: FF

Byte received: 1

is this really that what you see in the serial monitor?
The code-snippet that you posted has different fixed text.

The code snippet prints

@anon66076557

Received bytes:

Bytes received:
versus
Received bytes:

do you see the difference.

It is unclear if your text

@anon66076557

if changing “52656365697665642062797465733a204646200d0a52656365697665642062797465733a2031200d0a” to ascii then the output is

means that you changed the code posted above to be different.
or do you mean this part of the code

@anon66076557

if (indexBuffer > 0) {
        if (readBuffer[0] == 0xFF && readBuffer[1] == 0x01) { 
                Serial.write(readBuffer, indexBuffer);
        }

does not print?

You should be more careful and spend some more time for write a precise description of what you really did.
You should always post complete sketches. From the very first to the very last line.

If you used different code-versions post each and every code-version that you used
Give each code-version some keywords what this code-version is doing.

As you have only posted a code-snippet I am forced to post a code-snipped too
For debugging I would print the received bytes like this

    while (Serial.available() > 0) {
        if (indexBuffer < sizeof(readBuffer)) {
            readBuffer[indexBuffer] = Serial.read();
            Serial.print("idx:");
            Serial.print(indexBuffer);
            Serial.print(" value:#");
            Serial.print(readBuffer[indexBuffer]);
            Serial.println("#");
            indexBuffer++;
        }
    }

This will it make much easier to see which byte has what value

[bperrybap]

You need to post the code you are actually running.
Until you post that and we can take a look at it, we can't help you.

--- bill

[anon66076557]

okay I will explain
output

Success Send Command
Received response: “52656365697665642062797465733a204646200d0a52656365697665642062797465733a2031200d0a”

is the response received by the Serial Terminal sent from the Arduino, I made a simple terminal from Qt c++ code.

        uint8_t data[] = {0xFF,0x01};
        COMPORT->write(reinterpret_cast<char*>(data), sizeof(data));
        qDebug() << “Success Send Command”;
        QThread::msleep(100);

        if (COMPORT->bytesAvailable() > 0)
        {
            QByteArray response = COMPORT->readAll(); 
            qDebug() << “Received response: ” << response.toHex();
        }
        else
        {
            qDebug() << “No response received”;
        }

that's why what is received is hex not string, sorry I forgot to explain about this,

so I tried to send 0xFF,0x01 from Serial to arduino whether arduino responds to this command.

back to the arduino code
if I make a condition like this, it doesn't work.

 if (readBuffer[0] == 0xFF && readBuffer[1] == 0x01) 

this doesn't work even if given the correct command
but if I create a condition like this

 if (readBuffer[1] == 0x01) 

it works but if I send a byte whose position 0x01 is not at address 01 in uint8_t the condition still works for example I send ,0xCE,0xFE,0x7D,0x01 it still works even though 0x01 is not at address 01 in uint8_t.

[StefanL38]

How many posts long do you want to waste time with quick but too short postings?

@bperrybap

You need to post the code you are actually running.
Until you post that and we can take a look at it, we can't help you.

I second that.

post the complete sktech. From the very first line to the very last line of code
My experience is in 95% of all cases the bug is somehwere else than the user posting the question assumes where the bug is.

This can be done by a few mouse-clicks like described here

Make experienced users help: two ways to quickly post code as a code-section

Hi newcomer, This thread wants to show you how you can speed-up getting helpful answers with small effort. If you manage at least to post this way. You have the sympathy of the experienced users. If you are willing to invest another 20 minutes these 20 minutes extra-time will save you a minimum of 200 minutes to finish your project. always post your full sketch. As a code-section from the very first to the very last line A code-section has a small height => keeps your posting "short" but e…

Additionally it will really help to make visible in the serial monitor each and every byte-value that the arduino received

with a code like this

while (Serial.available() > 0) {
        if (indexBuffer < sizeof(readBuffer)) {
            readBuffer[indexBuffer] = Serial.read();
            Serial.print("idx:");
            Serial.print(indexBuffer);
            Serial.print(" value:#");
            Serial.print(readBuffer[indexBuffer],HEX);
            Serial.println("#");
            indexBuffer++;
        }
    }

[el_supremo]

@StefanL38. The code does print each and every received byte.

@anon66076557:
Your problem lies in the while loop. The received characters arrive at a much slower rate than the Arduino can handle them.
What happens is that the while loop receives the FF, but it hasn't yet received the 01.
So your code just prints that it has received FF and exits the RecvCommand function.
Next time that you call the RecvCommand() function it may not have received anything and so it does nothing.
Eventually, when you call the function it does receive the next character (01). But it is only one character so your code prints that it received the 01 and exits the function again.
Your code is looking for the two character sequence FF 01, but they arrive so slowly (as far as the Arduino is concerned) that it sees one character and then at a later time one more character.

There are various ways to handle this but what we need in order to help you properly is a clear explanation of what you are trying to do.
It would be nice to know what is sending the data to the Arduino and what sort of messages it can send.
Without this information all you can get is guesswork.

Pete

[StefanL38]

@el_supremo

@StefanL38. The code does print each and every received byte.

Which code ? you did not specify which one.

Sure but in a way where all values are glued together which makes it uncomfortable to analyse it.

@neorax

is the response received by the Serial Terminal sent from the Arduino, I made a simple terminal from Qt c++ code.

Is this correct that you user @neorax wrote this code yourself

uint8_t data[] = {0xFF,0x01};
        COMPORT->write(reinterpret_cast<char*>(data), sizeof(data));
        qDebug() << “Success Send Command”;
        QThread::msleep(100);

        if (COMPORT->bytesAvailable() > 0)
        {
            QByteArray response = COMPORT->readAll(); 
            qDebug() << “Received response: ” << response.toHex();
        }
        else
        {
            qDebug() << “No response received”;
        }

Which means you can modify this code to whatever you want.

I recommend that you modify it to send a start-character and an end-character
If you use an end-character as the very last byte you can use this endmarker to set a flag to "command-receiving completed" and then react on the command.

If you use and end-character sending your command can be as slow as you want it.
Even with seconds inbetween each sended character.

[Grumpy_Mike]

@anon66076557

okay I will explain

That is not an answer to the request:-

@bperrybap

You need to post the code you are actually running.

Unless you fully cooperate with us people will stop responding to you. In fact I think it would be a good idea if no one responded until we get a full code listing.

[anon66076557]

I have found the problem, I just move this variable out of the function and give a condition equal or greater than 5 like this, Serial.available() >= 5

uint8_t readBuffer[10];
int indexBuffer = 0;

It's like it's initializing uint8 multiple times and making the stored data problematic.

uint8_t readBuffer[10];
int indexBuffer = 0;

void RecvCommand()
{
  indexBuffer = 0;
  while (Serial.available() > 0) {
      if (indexBuffer < sizeof(readBuffer)) {
          readBuffer[indexBuffer] = Serial.read();
          indexBuffer++;
      }
  }
  if (indexBuffer > 0) {
    
  }
}

void setup() {
  Serial.begin(115200);
}

void loop() {
  if (Serial.available() >= 5)
  {
    RecvCommand();
  }

}

sorry if my question upset you

[el_supremo]

StefanL38:

Which code ? you did not specify which one.

Sorry, I was referring to the code in Msg #1.

neorax:

I have found the problem

No you haven't. You still don't understand the underlying problem. All you've done is change the size of message that can cause problems.

sorry if my question upset you

The question wasn't the problem. It was your non-answers.

Ciao
Pete

[dccontrarian]

That code isn't guaranteed to work. You still run the risk of returning before the entire packet is received.

Do you have a way of knowing how many bytes are supposed to be in the packet? If you do, don't return until that many bytes are received (or a timeout elapses). Or if there's some way of telling the end of a packet, don't return until you get it.

If you don't, you have to set a timeout and wait until either the buffer is full or the timeout elapses. Neither is going to be terribly reliable.

[xfpd]

@StefanL38

Bytes received:
versus
Received bytes:

do you see the difference.

This was a translate.google.com issue of SVO versus SOV language pattern.

[gilshultz]

I will keep my answer secret as is the code. Good Luck!