Issues with Serial Comm roboRio to RioDuino

[seg9585]

All,
I have been trying to configure our RioDuino (plugged into the MXP port on the roboRio) for serial transfer, but the Java Serial class seems to be giving me quite a few problems.

On the arduino side, for purposes of troubleshooting I simplified the code to just listen for an ASCII character, store in a variable, then echo that character back to the serial port to be heard on the roboRio. This uses the Serial.read(); and Serial.write(); functions
I verified this works without issue when I transmit this character through the Arduino serial monitor

On the roboRio side, I use the SerialPort.writeString(myString); command to transmit that value, and the SerialPort.readString(1); command to listen to just 1 byte. I then print this value to the SmartDashboard

However I'm having problems on both sides of the transaction. On the roboRio readString(1); side, there appears to be buffering issues -- the data isn't getting cleared from the buffer so the resulting character is very delayed. I am aware there's a known bug and a patch out there which I haven't tried yet, so not too worried about that, but...

On the writeString(), I am getting very strange results read by the Arduino. For example, if I repeatedly send SerialPort.writeString("1"), I don't get the number 49 (ASCII 1) or "1" echoed in the Arduino Serial Monitor, but I get numbers like 204, 17, or some other random numbers. Sending multiple times produces different numbers every time, although some tend to repeat.

I'm not sure what to make of this. Is the Serial port malfunctioning, or maybe there's a bug in the WPI code? Do I need to "interpret" the incoming values a different way?
I realize I can use I2C for communication. I'm already using I2C for a different sensor so I can make use of it for this as well, but I would really like to figure out why I'm having so many problems with Serial.

FYI, yes I verified both roboRio and Arduino are using the same bitrate (9600)

[Katie_UPS]

I haven't used this set up before, but I've done a serial thing or two before. I found the WPI Library so I'm just going off that and what I know.

readString takes in the number of characters to read, not bytes, which is probably a non-issue, but I recommend using it without any parameters to see if there is more in the buffer for some reason. For troubleshooting, the writeString function returns the number of bytes written. I recommend printing that out.

[seg9585]

I haven't used this set up before, but I've done a serial thing or two before. I found the WPI Library so I'm just going off that and what I know.

readString takes in the number of characters to read, not bytes, which is probably a non-issue, but I recommend using it without any parameters to see if there is more in the buffer for some reason. For troubleshooting, the writeString function returns the number of bytes written. I recommend printing that out.

I use the defaults on both sides. I know the arduino is no parity, 1 stop bit. I don't know what the default is on the roboRio. If it's different I could definitely envision some issues. Any idea what the roboRio defaults are?

The characters are ASCII characters, which is in itself a single byte per character. For readString, if I removed the numBytes param, I get the same value repeating many times (as expected -- I output the variable to serial on the arduino at 10Hz with no newline and no spaces).

Will look at the writeString function return, but not sure what it would tell me -- if more than 1 byte written, *why*? If exactly 1 byte written, what I expect but still no solution to this issue. All the values I see are between 0 and 255 so I know I'm pretty sure they're 1 byte in length

[Katie_UPS]

I use the defaults on both sides. I know the arduino is no parity, 1 stop bit. I don't know what the default is on the roboRio. If it's different I could definitely envision some issues. Any idea what the roboRio defaults are?


The WPI Library here (http://first.wpi.edu/FRC/roborio/stable/docs/java/classedu_1_1wpi_1_1first_1_1wpilibj_1_1SerialPort. html#a6dbe8d9ef188835106b8079bc690137d) says that it defaults at no parity and 1 stop bit, so that can't be it.

You eliminated all of my initial hunches, so I'm out of ideas. I guess post more information if you have any, and hopefully someone else will be able to help.

[Alan Anderson]

If you remove the Arduino and tie the MXP TX and RX pins together, do you get back what you send on the roboRIO?

Do both devices agree on the voltages being used for 1s and 0s?

[seg9585]

If you remove the Arduino and tie the MXP TX and RX pins together, do you get back what you send on the roboRIO?

Do both devices agree on the voltages being used for 1s and 0s?

Alan --
Good tips so far, I tied the TX and RX pins together and got the data I was expecting on the roboRio, so that's a good sign. Regarding voltages, the roboRio and Arduino are both running off the battery. When I plugged my laptop in to view Serial output data, I grounded the rioDuino to the roboRio grounds to ensure consistency

Still no luck on reading serial data on the rioDuino though -- using the same roboRio code above (works correctly when shorting the Tx/Rx), I get gibberish from the Serial.read() in the arduino code, mostly values of "255" or "204", etc. Serial.ParseInt(); returns nothing as well if I send a single integer