Receive hexa on serial then compare it

Hello all of you.
First of all, I'd like to wish you an great new year.

I'm working on a personal project for which I need to send some hexa message through the serial port, which is working on line 16 & 17.
Then I need to grab data received on the serial to catch the answer form the external object. Which is on line 20 to 23.
And make a comparison between the message received and the theoretical answer (known).
[EDIT] I'm working with a Lolin D1 mini, not sure it have a big impact.

Here is the code I'm currently using

#include "ESP_MICRO.h" 

const byte numChars = 72;
char receivedChars[numChars];
String MyVariable;

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

void loop(){
  MyVariable= "";

  //Send hexa message on Tx pin
  byte message[] = {0x21, 0x00, 0x02, 0x00, 0x53, 0x11, 0xC4, 0x3C};
  Serial.write(message, sizeof(message));
  
  //Read data on Rx pin
  for(int i = 0; i < numChars; i++) {
    receivedChars[i] = Serial.read();
    MyVariable.concat(receivedChars[i]);
  }

  //Send back data from Rx pin
  SendToDisplay(MyVariable);
}

The function "SendToDisplay" send the string to my display.

Currently when I run this code, here is the the return on my display :

b'!\x00\x02\x00S\x11\xc4<\x11\x00\x02\x00S\x11\xeb\xb0\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff'

While in theory the answer is :

0x11 0x00 0x02 0x00 0x53 0x11 0xEB 0xB0

I can see that my variable approximately contain the message I sent and approximately the message that should be received. It might be possible that the error is due to the transmission of the message to my display (I'm not able to check this)
As I don't need to display the hexa code, I only want to have a message like "OK" or "NOK", I'd like to make the comparison directly on the arduino code.
That's why I'm requesting your support.

You have not told us what Arduinos you are using.

Have a look at the examples in Serial Input Basics - simple reliable non-blocking ways to receive data. There is also a parse example to illustrate how to extract numbers from the received text.

The technique in the 3rd example will be the most reliable. It is what I use for Arduino to Arduino and Arduino to PC communication.

You can send data in a compatible format with code like this (or the equivalent in any other programming language)

Serial.print('<'); // start marker
Serial.print(value1);
Serial.print(','); // comma separator
Serial.print(value2);
Serial.println('>'); // end marker

...R

Thanks Robin2 for your reply and for your tips-topics (I already saw some of them and they are really interesting).

Infact I'm sending and receiving data to a third party object. So I'm not able to format the code I receive on the serial pin.
I'm working on the update to get it works, and looks like promissing. I will update the topic when it will be working.
I'm using an Esp8266 and more precisely a Lolin D1 mini.

Also I have a question regarding your statement :

If you need to ensure the Serial input buffer is empty you can do so like this
Code: [Select]

while (Serial.available() > 0) {

Serial.read();
}

Where should I put this to purge the serial input buffer ? Before sending my message, or between sending my message and receiving first data ?
Also, should I combine with a Serial.flush() ?

un26uxx:
Infact I'm sending and receiving data to a third party object. So I'm not able to format the code I receive on the serial pin.

Put us out of our misery and tell us what the third party object is.

Post an example of the data that this mysterious object sends.

Also I have a question regarding your statement :Where should I put this to purge the serial input buffer ? Before sending my message, or between sending my message and receiving first data ?

That depends on where YOU want to ensure that the buffer is empty. Don't bother about it unless you have a problem with unwanted data in the Serial Input Buffer.

Also, should I combine with a Serial.flush() ?

As Serial.flush() is intended to halt your program until the Serial Output Buffer is empty I don't understand why you are considering this.

...R

The mysterious object is a stove ;D

I almost find my way to perform what I was looking for.

int Compteur;

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

void loop(){
  Compteur = 0;

  //Send hexa message on Tx pin
  byte message[] = {0x21, 0x00, 0x02, 0x00, 0x53, 0x11, 0xC4, 0x3C};
  byte answer[] = {0x11, 0x00, 0x02, 0x00, 0x53, 0x11, 0xEB, 0xB0};
  
  //Send data to stove
  Serial.write(message, sizeof(message));
  Serial.flush();
 
  //Read data on Rx pin
  for(int i = 0; i < sizeof(reponse); i++) {
	if(Serial.read() == reponse[i]) Compteur++;
  }
  
  //Check if the answer from the stove was conform
  if(Compteur == sizeof(answer)) {
    SendToDisplay("ok");
  }
  else {
    SendToDisplay("nok");
  }
  
  //Purge remaining data on buffer
  while (Serial.available() > 0) {
    Serial.read();
  }
}

The remaining issue is that during first launch it's always "nok" as there is unwanted data on serial buffer. I tried to had a purge (same as at the end of loop() ) before the Serial.write(), but doing this I was not anymore able to catch the answer from the stove.

I'm considering using the Serial.flush() function because it's a serial TTL half-duplex communication (so input see the output). On my program, adding the Serial.flush had help me to have the answer directly on first values of the Serial Input Buffer.

un26uxx:
The remaining issue is that during first launch it's always "nok" as there is unwanted data on serial buffer.

That suggests to me that you should empty the Serial Input Buffer at the end of setup() and not anywhere else.

...R

I've try this method without success. The results is still the same.
As it's appear only once when the board is plug-in/switch-on to the stove, it's not a big deal. I will manage to have a non-vital command first (like asking for status) and repeat it.

Anyhow, thanks for your support and suggestions.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.