I had left the Ar2.0 running overnight (on Ubuntu 16.04) and noticed 100% CPU use (= 1 core of 4) on the next morning. The only thing going on was the Serial monitor.
Switching it off, and the CPU use dropped to negligible.
Did that cause any problems? The only other task is the idle task which is a do nothing. You can change the priority if that is a problem for you.
Since I can't interact with the IDE anymore, I'd say it has a negative impact!
Reboot and see if that solves it, if not return the settings back to where they were. The IDE lockes once in a while for me, I just kill it and relaunch it.
With a reboot you will have destroyed all info in the monitor, you might be interested in. In particular after a long overnight run.
A reboot does not solve the underlying bug for this behavior!
My CPU usage goes up as well but it is different on different machines. The more cores and the faster it is the less usage there is. Any data coming in to the monitor causes the CPU to increase its usage as well. At this point I think that is normal for your machine. Try it on another machine.
I noticed high CPU, though not 100%, usage as well when logging at high rates. I had a sketch the other day printing to the serial every loop() iteration at 115200 baud and what I noticed was that not only was the CPU usage skyrocketing, but that the serial port seemed to be unable to keep up with the incoming data. I was monitoring the analogRead() values of a joystick and right when the sketch would start up I would see the changes in value immediately, but then after a few seconds it would take several seconds to several minutes for the values to show up. I am unsure if this is just a hardware limitation of my particular machine, or if the IDE is not able to get the serial buffer as quickly as the buffer is getting filled, causing the delays to occur. @ullix did you happen to notice similar behavior when your usage was high? I can reproduce the delayed monitor behavior consistently.
This bug is tracked here:
It would make sense for the excessive CPU usage to somehow be related to having a massive backlog of Serial Monitor data caused by printing at a higher rate than it can consume over a long period of time.
1 Like
I just had this problem again.
With an average rate of perhaps one line of 50 characters printed every second the average data baud rate is under 100 baud.
I really can't see how this could result in a "backlog" of a serial line operating at 115000 baud?
I started in the evening, all running smoothly. In the morning I saw 1 core of the CPU having 100% load. The Serial Monitor could did not respond, nor did any other button or menu item of the IDE 2.0beta7 respond. I could not even close the IDE.
After killing and restarting all was back to normal.
With that configuration, I don't think it would. Even though the throughput of the Serial Monitor is poor, it should easily be able to handle that. So I think my hypothesis of the backlog causing the CPU usage you reported is proven to be incorrect by this information you provided.
Even though it can handle your 100 baud, unfortunately, the throughput of Arduino IDE 2.x's Serial Monitor is far lower than 115200 baud. You can see the bug report in my last reply. If you set up a sketch for continuous output of some sort of data that represents real-time events (e.g., printing an input pin's value), you'll find that what is printed in the Serial Monitor is progressively farther and farther behind what is actually happening on the microcontroller.
Makes sense.
But, I occasionally use an external monitor, which I programmed in Python. No matter what I did put out by the ESP32, I could barely see any CPU usage.
Whatever the Ar2.0beta7 monitor is programmed in, overwhelming it seems almost impossible.
The front end is TypeScript. There is some Go under the hood in Arduino CLI. Communication between the two is done via gRPC. I don't know where the bottleneck is.
Yet possible it is. Give this one a try:
const byte inputPin = 2;
void setup() {
Serial.begin(115200);
pinMode(inputPin, INPUT_PULLUP);
}
void loop() {
Serial.println(digitalRead(inputPin));
}
Don't misunderstand me, I don't deny that even a measly microchip can be programmed to send more through the Serial pipe than even a good desktop can handle. But given typical scenarios, I don't think so.
Two new languages for a complete rewrite? I keep my fingers crossed!
Is Arduino-CLI creating the Serial Monitor? Could I actually use that to monitor a project? Assuming its output would go a regular (Linux-)Terminal?
And the same problem again: Serial Monitor consumed 100% of 1 CPU core with printing ~1 line per sec
This time I was able to shut down only the Serial Monitor, and the CPU consumption dropped to negligible values. So it is definitely the SM, and only it!
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.
Hi @ullix. The IDE developers recently did some work on improving the Arduino IDE 2.x Serial Monitor performance, which might have fixed this issue. Those improvements were released in Arduino IDE 2.0.0--beta.12.
Unfortunately, I was not able to reproduce the original issue with Arduino IDE 2.0.0-beta.7, so I can't say whether the situation has improved with 2.0.0--beta.12. If you give the new IDE version a try, we'd be interested to hear about the results.
Sorry, but I had moved to platformio after I was told in this forum that users who want advanced features are not welcome. Good luck to all.