Experienced strange output in a complex motor controller sketch. So I wrote the following sketch to see what happens. Same garbled output.
#include "Arduino_RouterBridge.h"
int a = 0;
int b = 1;
void setup() {
// put your setup code here, to run once:
Monitor.begin();
}
void loop() {
// put your main code here, to run repeatedly:
Monitor.print("a = ");
Monitor.println(a);
Monitor.print("b = ");
Monitor.println(b);
Monitor.print("a + b = ");
Monitor.println(a+b);
a += 1;
b += 1;
delay(1000);
}
Screenshot Output in AppLab:
Screenshot Output in Arduino IDE:
Any idea, what's wrong
If you upload your sketch by Arduino IDE, output will be perfect
Unfortunately not, see screenshot above. Did you use Serial.println()?
Why not Bridge.begin(); code?
Message/data from MCU goes to MPU through router bridge and then goes to Console>>python over the USB-C/USB-A connector.
I wanted to port a more complex sketch for motor controller from Uno to Uno Q.
This is only a test for calculations and output in the Serial Monitor.
Bridge.begin() alone did not change the situation with wrong end of line commands.
I will try data relay to Python and output in the shell later.
Follow SSS (start with Small Step) Strategy to see success!
Hi @legoexpert2011 . I think you are encountering this bug:
opened 10:25AM - 29 Jan 26 UTC
bug
### Describe the problem
When a sketch transmits data via the `Monitor` object,… the messages arrive out of order and with incorrectly placed line breaks.
### To reproduce
1. Create the following sketch:
```cpp
#include <Arduino_RouterBridge.h>
void setup() {
Monitor.begin();
}
void loop() {
Monitor.print("Reading 1: ");
Monitor.println(1234);
Monitor.print("Reading 2: ");
Monitor.println(4567);
delay(500);
}
```
1. Upload the sketch to an UNO Q board.
1. Open Serial Monitor.
🐛 The output from the sketch is not as expected:
```text
Reading 1: 1234Reading 2: 4567
1234Reading 2: 4567
Reading 1:
Reading 2: 4567Reading 1: 1234
Reading 2: 4567Reading 1: 1234
Reading 2: 45671234Reading 1:
Reading 2: 4567
1234Reading 1: 1234Reading 2:
Reading 1: 4567
Reading 1:
1234Reading 2: 4567
Reading 2: 4567Reading 1: 1234
Reading 1:
1234Reading 2: 4567
[...]
```
### Expected behavior
Output is received in order:
```text
Reading 1: 1234
Reading 2: 4567
Reading 1: 1234
Reading 2: 4567
Reading 1: 1234
Reading 2: 4567
Reading 1: 1234
Reading 2: 4567
[...]
```
### Arduino_RouterBridge version
0.3.0
### Additional context
We are seeing a spike of reports over the course of last few days. This seems to correlate with recent releases
- "**Arduino UNO Q Board**" platform (`arduino:zephyr`) version 0.53.0
- Arduino App Bricks version 0.6.4
---
Originally reported at:
https://forum.arduino.cc/t/why-an-update-messed-up-monitor-print/1427515
Note this:
> I had my first simple sketch working then updated with a new patch for the MCU. Now the print formatting using Monitor is all over the place
#### Additional reports
- https://forum.arduino.cc/t/zephyr-wish-there-was-standard-way-to-speed-up-spi-operations/1426772/3
- https://forum.arduino.cc/t/arduino-uno-q-serial-monitor-broken/1427596
- They reported the following result from rolling back their `arduino:zephyr` installation to 0.52.0:
> Working fine in Arduino App Lab
- https://forum.arduino.cc/t/uno-q-monitor-garbled/1427874
> I uploaded extensive code, monitor worked GREAT. Flawless!!
> Then I downloaded app lab, set up the linux side.
> No apps are running. Yet, monitor is now completely garbled
- https://github.com/arduino/ArduinoCore-zephyr/issues/322#issuecomment-3816480239
- https://forum.arduino.cc/t/stable-multiprocessing-readme/1427828/53
The developers are working on a fix:
main ← serialize-handler-per-name
opened 03:22PM - 03 Feb 26 UTC
### Motivation
We were exploiting too much parallelism; every RPC command was… concurrently executed, which led to out of order message for the same rpc call.
Instead, we should serialize all the requests for the same rpc call. Concurrent requests by multiple parties will not guarantee an ordering, but at least all the requests from the same party will be locally ordered.
### Change description
The proposed implementation uses a fixed number of concurrent worker and the requests will be distributed enforcing that the same RPC request is always sent to the same worker. The change also permits customizing the distribution by a key, that allow to handler tcp request for different sockets in parallel.
### Additional Notes
- https://github.com/arduino-libraries/Arduino_RouterBridge/issues/52
### Reviewer checklist
- [ ] PR addresses a single concern.
- [ ] PR title and description are properly filled.
- [ ] Changes will be merged in `main`.
- [ ] Changes are covered by tests.
- [ ] Logging is meaningful in case of troubleshooting.
If you have a GitHub account, you can subscribe to that thread to get notifications of any new developments related to this subject:
I also had lots of issues with printing out results. Here is what worked for me:
void setup() {
Monitor.begin();
delay(1000);
}
Give Monitor a chance to get its act together.
Get rid of the println’s since they don’t appear to work.
Use this instead:
Monitor.print("******************\n");
Monitor.flush();
Get rid of all ambiguity to avoid shuffling outputs as follows: Compose your string, then print it out.
String tm_out = "Elapsed time = " + tm_elt + "\n end loop\n";
Monitor.print(tm_out);
instead of something like:
Monitor.print("Elapsed time = ")
Monitor.println(tm_elt)
Monitor.println(" end loop")
Good luck.