I've been working with Arduino Uno and Arduino Nano 33 BLE Sense Rev2, attempting to establish communication between them using UART. I followed a simple example provided in the Arduino documentation (https://docs.arduino.cc/tutorials/nano-33-ble-sense-rev2/uart/). However, I encountered an issue that I'm struggling to resolve.
Here's the setup:
I'm using Arduino Uno's TX pin with a level shifter to convert it to 3.3V suitable for the Arduino Nano 33 BLE Sense Rev2's RX pin. The transmitter code running on the Arduino Uno looks like this:
void setup() {
pinMode(LED_BUILTIN, OUTPUT); // set LED pin as output
digitalWrite(LED_BUILTIN, LOW); // switch off LED pin
Serial.begin(500000); // initialize serial communication at 500000 bits per second
}
void loop() {
if (Serial.read() == '1'){
Serial.println('1');
digitalWrite(LED_BUILTIN, HIGH);
Serial.println("LEDS ON");
}
else if (Serial.read() == '0'){
Serial.println('0');
digitalWrite(LED_BUILTIN, LOW);
Serial.print("LEDS OFF");
}
}
And the receiver code running on the Arduino Nano 33 BLE Sense Rev2 looks like this:
void setup() {
pinMode(LED_BUILTIN, OUTPUT); // set LED pin as output
digitalWrite(LED_BUILTIN, LOW); // switch off LED pin
Serial1.begin(500000); // initialize UART with baud rate of 500000
}
void loop() {
while (Serial1.available() >= 0) {
char receivedData = Serial1.read(); // read one byte from serial buffer and save to receivedData
if (receivedData == '1') {
digitalWrite(LED_BUILTIN, HIGH); // switch LED On
}
else if (receivedData == '0') {
digitalWrite(LED_BUILTIN, LOW); // switch LED Off
}
}
}
The issue I'm facing is that the Arduino Nano 33 BLE Sense Rev2 doesn't seem to be receiving anything or changing the LED state when I set the baud rate to 500000, as specified in the transmitter & receiver code. However, if I set the baud rate to 9600 in both, everything works perfectly fine.
I'm confused about why this discrepancy is occurring and how I can resolve it. Any insights or suggestions would be greatly appreciated.
Thank you for your suggestion. I've integrated Serial.available() into the code as advised. However, despite this modification, the issue persists. Strangely, the code functions flawlessly at a baud rate of 9600, but encounters difficulties at 500000 baud rate.
Level shifters introduce delays, and it may not be possible to have reliable UART communication at 500000 Baud. In addition, on the Uno, the TX and RX pins are connected to the on board USB to serial converter, which is an additional load.
Overall this general approach is unlikely to work well for high speed UART serial communication.
Is the baud rate you are using one of the possible baud rates for you microprocessor? There should be a list in the data sheet for each of the processors.
I've been using a voltage divider with 2K and 3.3K ohm resistors, essentially a crude form of level shifter. While I'm not certain whether these resistors introduce a noticeable delay, it's plausible that this simplistic approach might be contributing to the issue.
Yes, they do. It is the RC time constant of those resistors combined with line and stray board capacitance. Definitely a problem at high serial Baud rates. Also, as pointed out above, there are Baud rate mismatch problems at different clock speeds and UART clock divisors.
Check the processor data sheets carefully for Baud rate errors.
Thank you for your input. Based on my previous experiments, I'm fairly confident that the Nano BLE Sense Rev2 can indeed support the high baud rate, as I've successfully conducted the same experiment between two identical Arduino Nano BLE Sense Rev2 boards at 500000 baud rate without any issues. At this point, I'm beginning to suspect that the problem might indeed lie with the level shifter, as mentioned by @jremington
Thank you for clarifying the delay introduced by the resistors and highlighting potential issues with Baud rate mismatches. I'll carefully review the processor data sheets for any relevant information on Baud rate errors.
But, you do not really know if the processor is using your baud rate or just the fastest one it can handle. An even, large number like that seems improbably since the baud rate must be an even fraction of the processor clock speed.