Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

serial.receive() returns true repeatedly with no traffic #1

Open
simm42 opened this issue May 8, 2018 · 3 comments
Open

serial.receive() returns true repeatedly with no traffic #1

simm42 opened this issue May 8, 2018 · 3 comments

Comments

@simm42
Copy link

simm42 commented May 8, 2018

After a successful packet is received and HammingSerial.receive() is called, it will continue to return true for as long as no further traffic is on the underlying Serial device.

I beleive this is undesirable behaviour as the HammingSerial.receive() check is called to determine is there is a packet arrived to process. I think the bug is cuased by the following checks in HammingSerial.receive both being conditional on _serial.available() being true.

  if ((readState == PACKET_READ_STATE_END) && _serial->available()) {
    b = _serial->read();
    if (b == PACKET_START_SYMBOL) {
      readState = PACKET_READ_STATE_START;
    } else {
      readState = PACKET_READ_STATE_UNKNOWN;
      ++errorCount;
      rx_buffer.clear();
    }
  }
  
  while ((readState == PACKET_READ_STATE_UNKNOWN) && _serial->available()) {
    b = _serial->read();
    if (b == PACKET_START_SYMBOL) {
      readState = PACKET_READ_STATE_START;
    } 
  }

I beleive the fix would be to replace the above with:

  if (readState == PACKET_READ_STATE_END) {
    readState = PACKET_READ_STATE_UNKNOWN;
  }
  
  while ((readState == PACKET_READ_STATE_UNKNOWN) && _serial->available()) {
    b = _serial->read();
    if (b == PACKET_START_SYMBOL) {
      readState = PACKET_READ_STATE_START;
    }  else {      
      ++errorCount;
    }
  }

This saves the user from needing to check that both HammingSerial.receive() is true and that rx_buffer.count is non zero before being able to assume a new packet has been received.

@bkeevil
Copy link
Owner

bkeevil commented May 8, 2018

Did you happen to check if the tests in the demo app run with this change?

@simm42
Copy link
Author

simm42 commented May 8, 2018

I’m afraid I don’t have an environment set up to run them currently.

If I get chance to do so in next few days I’ll look at setting it up and adding the test case that this fixes.

@bkeevil
Copy link
Owner

bkeevil commented May 8, 2018

I'll do it tonight.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants