Serial data in interrupt.

For some code I am writing I need to be constantly polling a serial port for data to see if an emergency stop button has been pressed on the wireless transmitter.

I was reading about the possibility of sticking this in an interrupt to make the code easier but I understand this is not possible.

Is the best solution to just run:

if(XBee.available()){
XBee.read();
}

etc. (XBee being the newsoftserial port name)
at the end of the loop. The loop will be fast enough so that this should be ok.

From fiddling with my XBee, I also have to use XBee.flush(); after each receive to get rid of the old characters. Why is it that you have to do this when using an XBee?

Mowcius

From fiddling with my XBee, I also have to use XBee.flush(); after each receive to get rid of the old characters. Why is it that you have to do this when using an XBee?

I've never had to do that.

It's either a NewSoftSerial issue or something in your code. My guess is that it's in your code. Can you post all of your code?

Wel I don't have the code on me but if I do:

if(XBee.available() > -1){
digitalWrite(ledpin, HIGH);
}
else{
digitalWrite(ledpin, LOW);
}

Then as far as I can remember, it would then keep lighting up the LED after I have sent data via the xbee to the arduino.
I have to add:

 Xbee.flush();

at the end to make it work...

Anyway that's not the main concern :smiley:

Mowcius

if(XBee.available() > -1){

NewSoftSerial::available() returns the number of bytes available to be read. If there are none, it returns 0. Since 0 is greater than -1, your LED will be turned on.

Sorry I meant 0 not -1...

It still does it on 0.

Mowcius

if(XBee.available() > -1){
digitalWrite(ledpin, HIGH);
}
else{
digitalWrite(ledpin, LOW);
}

In this example at least, you're not consuming the data that has been received, so it remains available because it is still in the buffer. Flushing the buffer has the desired effect as it consumes all the available data.

In terms of the serial polling, I don't know what your "emergency button transmitter" consists of, but you may be able to use the XBee's line passing feature to trigger the interrupt on the receiving device.

Yeah what he said above.
You are checking if there is any data availabe in the buffer by using if(XBee.available() > 0), however you are not actually reading the data itself which means the data remains in the buffer.
So next time your code checks if there is data in the buffer, then of course it will still return true as its still the old data + any new data that has arrived.

You need to read in the data if you want it to be removed from the buffer, otherwise your flush command does the same function.

You are currently only checking if something has been sent, but you dont appear to care what was sent, only that something was sent.

Yeah what he said above.
You are checking if there is any data availabe in the buffer by using if(XBee.available() > 0), however you are not actually reading the data itself which means the data remains in the buffer.
So next time your code checks if there is data in the buffer, then of course it will still return true as its still the old data + any new data that has arrived.

You need to read in the data if you want it to be removed from the buffer, otherwise your flush command does the same function.

You are currently only checking if something has been sent, but you dont appear to care what was sent, only that something was sent.

Ahh, that makes it clearer :slight_smile:
Thanks. In the final application I will be reading what the character is but thanks for the explanation of why it does this currently :slight_smile:

Mowcius