Uint_16 Overflow?

Troubleshooting
1

I have some test code running with a counter that is held in a uint_16 variable. That was copied from a Arduino Uno example sketch.

My code stopped running but the Electron didn’t throw any RED error LED’s and my first guess is that the uint_16 variable overflowed but I’m not sure, it would have eventually I know that.

I changed it to a uint_32 to see what happens but I wanted to ask what I should expect with a Photon if the uint-16 variable overflows :confused:

2

@RWB, you know the drill… code please😉

3

“Overflows” of that kind don’t usually caus an exception.

You can safely have uint16_t (I think this is what you mean) do this

uint16_t x = 65534;
x++;
x++;
x++;
x++;

The value will just go 65535, 0, 1, 2, …

4

@peekay123 Here is the code, it’s for testing the RFM95 radio modules:


//PHOTON
// this the client running on photon
#include <RHReliableDatagram.h>
#include <RH_RF95.h>
//#include <SPI.h>
SYSTEM_MODE(SEMI_AUTOMATIC);

#define CLIENT_ADDRESS 1
#define SERVER_ADDRESS 2

const int ledPin = D7;     // D7 has an LED

// Singleton instance of the radio driver
RH_RF95 driver;  //(A2,D2)-->you don't nee set this
//RH_RF95 rf95(5, 2); // Rocket Scream Mini Ultra Pro with the RFM95W

// Class to manage message delivery and receipt, using the driver declared above
RHReliableDatagram manager(driver, CLIENT_ADDRESS);

// Need this on Arduino Zero with SerialUSB port (eg RocketScream Mini Ultra Pro)
//#define Serial SerialUSB

void setup()
{
  pinMode(ledPin, OUTPUT);
  digitalWrite(ledPin, LOW);


  Serial.begin(9600);

  if (!manager.init())
  Serial.println("init failed");
  driver.setTxPower(23, false);
  driver.setFrequency(915.0);  // hay que setear frecuencia para los rfm96 915
  delay(5000);
  Serial.println("..this is the Photon as Client Radio");
}

//uint8_t data[] = "Hello World #      ";
// Dont put this on the stack:
uint8_t buf[RH_RF95_MAX_MESSAGE_LEN];

int32_t packetnum = 0;  // packet counter, we increment per xmission

void loop()
{

  Serial.println("Sending to Server Base Station");
  // Send a message to manager_server basestation.

  char radiopacket[20] = "Hello World #      ";
  itoa(packetnum++, radiopacket+13, 10);
  Serial.print("Transmitting > "); Serial.println(radiopacket);
  radiopacket[19] = 0;
  Serial.println("");

  if (manager.sendtoWait((uint8_t *)radiopacket, sizeof(radiopacket), SERVER_ADDRESS))
  {
    // Now wait for a reply from the server base station.
    uint8_t len = sizeof(buf);
    uint8_t from;

    Serial.println("Waiting for reply..."); delay(10);

    if (manager.recvfromAckTimeout(buf, &len, 2000, &from))
    {
      //Flash D7 LED on Photon if Received Reply
      digitalWrite(ledPin, HIGH);
      delay(500);
      digitalWrite(ledPin, LOW);

      Serial.print("Got reply from Server Base Station 0x");
      Serial.print(from, HEX);
      Serial.print(": ");
      Serial.println((char*)buf);
      Serial.print("RSSI: ");
      Serial.println(driver.lastRssi(), DEC);

      Serial.println();
      Serial.println();

    }
    else
    {

      Serial.println("No reply from Server Base Station?");

      //Flash D7 LED on Photon if No Reply From Server Base Station.
      digitalWrite(ledPin, HIGH);
      delay(200);
      digitalWrite(ledPin, LOW);
      delay(200);
      digitalWrite(ledPin, HIGH);
      delay(200);
      digitalWrite(ledPin, LOW);
    }
  }
  else{
    Serial.println("sendtoWait failed");
    digitalWrite(ledPin, HIGH); //Flash D7 LED on Photon if SendtoWait Failed
    delay(150);
    digitalWrite(ledPin, LOW);
    delay(150);
    digitalWrite(ledPin, HIGH);
    delay(150);
    digitalWrite(ledPin, LOW);
    delay(150);
    digitalWrite(ledPin, HIGH);
    delay(150);
    digitalWrite(ledPin, LOW);
    delay(150);
    digitalWrite(ledPin, HIGH);
    delay(150);
    digitalWrite(ledPin, LOW);
    }

  delay(5000);
}

I’m specifically talking about this variable that was int16_t:

int32_t packetnum = 0; // packet counter, we increment per xmission

@ScruffR I was wrong about it being a uint16_t , its a int16_t instead :blush:

Does the int16_t just roll over also?

If it goes negative then that may be the cause of the lock up.

Haven’t looked to far into this yet.

5

It rolls over just as safe, it’ll just be

int16_t x = 32766;
x++; //  32767
x++; // -32768
x++; // -32767
x++; // -32766
...

But if you use that as an index, you’ll be doomed :wink:

1 Like
6

To confirm I change it to int8_t and it didn’t do anything but roll over to -127 when we hit 127.

So I don’t think that is what caused the lock up.

I’ll keep testing and thanks for the info.

I did just learn something about rollover behaviors.

1 Like
7

Hmm, it should have rolled over to -128 :wink:

8

That’s what I thought.

I was watching it closely and I’m almost 100% positive it rolled over to -127.