Arduino Leonardo Serial1.availble = 0

I have a Leonardo with a zigbee device connected to the serial Rx an Tx ports. The code below seems to work at random at times. Particularly, if I remove the Rx Tx connections first. When I print the value of Serial1.available it is 0; I read somewhere that the Rx Tx pin must be disconnected before uploading the code. If this is true my question is why? How can I make a reliable system if I constantly have to remove the pins to get my code to run? There has to be a workaround.

#include <SoftwareSerial.h>

int led = 13;

void setup() {
  Serial1.begin(9600);
  Serial.begin(9600);
  delay(500);
  Serial1.print('H');
  delay(500);
}

void loop() {
  while(Serial1.available()){
    digitalWrite(led, HIGH);
    Serial1.print('H');
    delay(500);
    digitalWrite(led, LOW);
    delay(500);
  }
}

You have a mix of different advice, which doesn't apply to your board. There's no need to disconnect Rx on the Leonardo.

You have #included software serial, but you never use it anywhere. You can remove that #include.

Often it's a good idea to have the board stop and wait for the USB serial monitor to connect. Here's one way to do it, which allows it to continue after 5 seconds if you don't open the serial monitor:

void setup() {
  Serial.begin(9600); //baud rate is ignored, but you must put some number here
  while(!Serial && millis()<5000) {
    //wait for serial monitor to connect
  }
  ...
}

Your example code will send 'H' on the hardware serial. You won't see that on the serial monitor.

MorganS:
You have a mix of different advice, which doesn't apply to your board. There's no need to disconnect Rx on the Leonardo.

You have #included software serial, but you never use it anywhere. You can remove that #include.

Often it's a good idea to have the board stop and wait for the USB serial monitor to connect. Here's one way to do it, which allows it to continue after 5 seconds if you don't open the serial monitor:

void setup() {

Serial.begin(9600); //baud rate is ignored, but you must put some number here
  while(!Serial && millis()<5000) {
    //wait for serial monitor to connect
  }
  ...
}




Your example code will send 'H' on the hardware serial. You won't see that on the serial monitor.

Ok, I've edited the code to be as below, I still get the same result. To my understanding Serial1 read and writes to Rx and Tx, so I use that instead

int led = 13;

void setup() {
  Serial1.begin(9600);
  Serial.begin(9600);
  while(!Serial1 && millis()<5000) {
    //wait for serial monitor to connect
  }
  
}

void loop() {
  Serial.print(Serial1.available()); // Equals 0 all the time

  while(Serial1.available()){
    digitalWrite(led, HIGH);
    Serial1.print('H');
    delay(500);
    digitalWrite(led, LOW);
    delay(500);
  }
}

while(!Serial1 && millis()<5000)

No, this doesn't work on hardware serial ports. Only on the USB native port.

The Zigbee isn't sending you anything. Were you expecting something? Don't you need to address it or configure it first?

MorganS:
No, this doesn't work on hardware serial ports. Only on the USB native port.

The Zigbee isn't sending you anything. Were you expecting something? Don't you need to address it or configure it first?

The Zigbee sends when it get data, the issue is the Arduino ports are not available unless the pins are removed before uploading the code. When the ports are open it send data to the Zigbee and the Zigbee transmits. I will try seeing if there is some initialization signal needed to be sent to the Zigbee, Thus far I havent come across any mention of it.

I couldn't figure out anything. Still have the same issue. Anyone have any insight ?

I'm having a similar problem. I am trying to build a MIDI Show Control to PC keyboard converter so that I can use MSC to control a laptop running MS PowerPoint.

I am using a Leonardo so that I can interface to MIDI on the hardware serial (Serial1 on pins 0 and 1).

The MIDI rx hardware is the standard 6N138 circuit, assembled on a soldered stripboard.

The problem is that it works sometimes and then stops working. Resetting the Leonardo doesn't help. The hardware construction is robust and anyway, the same thing happens when I recreate the circuit on breadboard.

For the moment, I'm just trying to get this sketch to work reliably.

#define PIN_LED 13

void setup() {

// long blink LED to confirm sketch is running
pinMode(PIN_LED, OUTPUT);
digitalWrite(PIN_LED, HIGH);
delay(1000);
digitalWrite(PIN_LED, LOW);
Serial1.begin(31250);

}

void loop() {
if (Serial1.available()) {
// short blink LED to show byte recieved
digitalWrite(PIN_LED, HIGH);
delay(250);
digitalWrite(PIN_LED, LOW);
// read byte to empty buffer
int inByte = Serial1.read();
}
}

When I send MIDI data, I don't get the short blinks. I'm sure it's something simple but I can't see what.

Thanks for any help.

    int inByte = Serial1.read();

Do NOT use a type in a variable name when the type in the name is not the type of the variable. It makes you look stupid.

How does PaulS look?

PaulS:

    int inByte = Serial1.read();

Do NOT use a type in a variable name when the type in the name is not the type of the variable. It makes you look stupid.

Now I really am being stupid but I can't decipher the help that you're giving here. Are you suggesting that is the reason Serial1.available is always 0?

barneyd:
Now I really am being stupid but I can't decipher the help that you're giving here.

What type are you using in the name? What type is the variable with that name? Are the types the same? NO, THEY ARE NOT.

Would you expect to see
float myInt;

or
char myFloat;

or
int myFloat;
?

Of course not. You'd think that the person that named those variables was a few cards short of a full deck.

MorganS:
No, this doesn't work on hardware serial ports. Only on the USB native port.

The boolean operator works as defined on h/w serial ports.
Here is the code:

    operator bool() { return true; }

The boolean operator in the "serial" class returns whether or not the h/w is ready to transmit/receive data.
On a h/w uart port, it is ready all the time, and as you can see in the code, it always returns true.

--- bill

PaulS:

    int inByte = Serial1.read();

Do NOT use a type in a variable name when the type in the name is not the type of the variable. It makes you look stupid.

In this specific case, IMO, you are being overly aggressive and potentially missing a very valid reason to define the variable to hold the incoming character/byte as an int but yet have "byte" in the name.

due to the way the Arduino API for reading data works, you have to define the return value variable as an int because the return value from read() is overloaded with the integer return status.
If you ever want to look at the return value to check for read() errors, it requires that you define the variable receiving the return value from read() as an int and only use the lower 8 bits if the read was successful.

Granted, the code shown so far was not yet checking the return value for any errors, but if it did, the return value type for read() variables must be an int.

So in this type of usage, it can make sense to have the name of variable include a type that does not match its true type.
This is because from an API perspective the type must be an int but from a code readability perspective it really holds just a byte that was read from the serial port.

--- bill

This is because from an API perspective the type must be an int but from a code readability perspective it really holds just a byte that was read from the serial port.

There really is no reason to use a type in a name that is not the type of the variable. If available() has been used to determine that there is data to read, then the data will fit in a char/byte, so that type can be used.

  if(Serial.available() > 0)
  {
     char inChar = Serial.read();
     // or
     byte inByte = Serial.read();

     // use the data
  }

There is nothing to be gained, though, from using a type in the name. If the data is ASCII, then letter makes a perfectly good name. If the data is binary, then inData makes a perfectly good name.

lars,
In terms of you issue. It is not clear what you are trying to do.
In the code you are talking about and attempting to use 3 different types of serial ports.

  • USB virtual serial port (uses the object Serial)
  • h/w serial serial port (uses the object Serial1)
  • Software serial (header file included, but you have not defined any object to use)

The bit about not having anything connected to the h/w serial pins is generally related to something like an UNO where the h/w serial pins are used for the upload.
This is not the case on Leonardo which uses the USB virtual serial port for uploading.

In your code you initialize both the USB virtual serial port (Serial) and the h/w serial port (Serial1)
Then you wait for Serial1 to be "ready" which is a NOP since h/w serial ports are always ready.
Then you fall in to a loop looking for data on the h/w serial port (Serial1) and do some things and in some cases spit out characters on the h/w serial port (Serial1).
It could be that the serial connections from your zigbee feeding into your h/w serial pins are incorrect or have issues.
Some potential issues:

  • using incorrect leonardo pins
  • zigbee tx/rx pins might be backwards
  • baud rate might be wrong
  • wires might not be making proper connection

--- bill

PaulS:

    int inByte = Serial1.read();

Do NOT use a type in a variable name when the type in the name is not the type of the variable. It makes you look stupid.

Not cool to be a code fascist, its a name describing the variables function, and its not unknown to use
ints for character I/O so that -1 can be used to represent end-of-stream. Unix I/O has been like this for decades,
Java is the same.

PaulS:
What type are you using in the name? What type is the variable with that name? Are the types the same? NO, THEY ARE NOT.

Would you expect to see
float myInt;

or
char myFloat;

or
int myFloat;
?

Of course not. You'd think that the person that named those variables was a few cards short of a full deck.

Calling other people stupid might make you feel superior but it's pretty obvious that you don't actually know the answer to the question. I asked the question knowing that I didn't know the answer, all you've done is to not answer it and exposed that you don't.

Having not done programming for about 20 years clearly are a few cards buried in the mists of memory; however from a social skills perspective, you're playing a pretty weak hand and what's more, you've shown it.

Declaring types is pretty early on in the book. Perhaps you'd care to come back when you've read a few more pages and can actually help.

Declaring types is pretty early on in the book. Perhaps you'd care to come back when you've read a few more pages and can actually help.

I've been a programmer for 37 years. I can recognize a stupid (as in misleading) name when I see one.

Yep - we've established that. Still not been able to answer the question though.

barneyd:
Yep - we've established that. Still not been able to answer the question though.

Your assumption that it is not a hardware problem is one that I find difficult to accept. If the hardware connected to the Arduino was sending data to the serial port, then the Arduino would be able to read it.