Thanks, I'll try that.
There is a formal report of the double Serial Monitor content here:
I think the hypothesis presented by @sterretje in post #17 seems most likely.
The alternative "double reset" hypothesis presented by @gilshultz in post #21 could be tested by using a board that uses the Optiboot bootloader, such as the modern official Nano or UNO R3. Optiboot blinks the on-board LED multiple times quickly after a reset. If you only see one set of those blinks, then you will know that there was only a single reset, disproving the "double reset" hypothesis. Conversely, if you see two sets of blinks, then this would support the "double reset" hypothesis.
Note that the board is also reset at the start of the upload. So it is expected that there will also be a set of blinks when Arduino IDE starts the upload (after completing the sketch compilation). Since the upload operation takes some time, it should be easy to differentiate the set of blinks triggered by starting the upload from those that occur after the completion of the upload. We can eliminate the possibility of the first set of output coming from prior to the upload by changing the sketch to print something different before performing the upload. If both sets of output shown in Serial Monitor are from the uploaded code, then this proves that they are coming from the board post-upload.
Unfortunately the cheap derivative Nano boards often use the old "ATmegaBOOT" bootloader, which does not do the blink sequence. So it would be more difficult to test with one of those boards.
I am able to reproduce the double content behavior on my Ubuntu 24.04 machine with a derivative Nano board that has the WCH CH340 USB chip. I have burned the Optiboot bootloader to that board. I only see a single set of blinks.
I am not able to reproduce the double content behavior using an official Nano Board (which has the FTDI FT232R USB chip).
Don't think so since I get a double reset if the serial monitor is already open.
Are you saying you see two sets of blinks?
Same difference. Arduino IDE automatically disconnects Serial Monitor from the serial port when the upload operation starts, then connects Serial Monitor back to the serial port after the upload completes. So it is expected that the auto-reset circuit on the board will reset it once after an upload when the upload is performed while Serial Monitor is running, just the same as the board is expected to reset when you open Serial Monitor.
No I see the text printed twice. See post #22
That is not conclusive evidence of a double reset. @sterretje hypothesis is based on this sequence of events:
- A sketch upload operation is triggered.
- Serial Monitor is disconnected from the serial port.
- The upload process starts.
- The upload process completes.
- The bootloader exits and the sketch program starts, transmitting data to the serial port.
- Serial Monitor connects to the serial port.
- The auto reset circuit on the board resets it.
- The sketch program starts, transmitting the same data to the serial port once again.
It is somewhat unexpected that we would see the data transmitted by the board at step 5 in that sequence in Serial Monitor. However, as @sterretje wrote, it seems the operating system buffers the received data.
Maybe not but it should not happen so to me it's a bug in the IDE.
Well, you're moving the goalposts now. My previous posts were about identifying the cause of the doubled content.
As for whether this can be considered a bug in Arduino IDE, I'm not convinced. Serial Monitor just displays whatever it receives from the serial port. If it receives two copies of the content from the serial port, then how is it the fault of Arduino IDE that Serial Monitor displays this?
What specific fix do you propose should be implemented for this in the software maintained by Arduino?
The obvious measure would be for Serial Monitor to not assert the DTR and RTS serial control signals when it connects to the port after an upload, thus not resetting the board. That would indeed avoid the double content problem. However, keep in mind that the double content only occurs under certain conditions (e.g., CH340 board, Linux machine), and not under other conditions (e.g., FT232R board, Windows machine). So if the board is not reset, then you will only have traded the slight annoyance of doubled content under certain conditions for the far more serious problem of missing content under more common conditions (keep in mind that the great majority of Arduino users have Windows machines). So this is not an acceptable solution.
I don't think so. All I did was confirm @pommie problem as stated in post #1.
If you say it's not a bug, I won't argue.
I would consider it a bug if it was found to be one of the following:
- Serial Monitor is buffering the content, not the operating system.
- Serial Monitor is asserting the DTR and RTS control signals twice.
My experiment seems to disprove the latter, since I don't see evidence of a double reset, but perhaps I'm misinterpreting my observations.
As for the former, this could be tested by checking whether the buffered content is present if you read from the serial port without using Serial Monitor.
If the operating system is buffering the serial port data, maybe there is some way for Serial Monitor to instruct it to clear the buffered data when opening the port?
I personally really don't care that it happens. As I said, over the years I've learned to ignore it and always close the serial monitor or do a hard reset but I think @pommie need an explanation of what is going on
#include <EEPROM.h>
void setup() {
Serial.begin(115200);
int resetNumber = EEPROM.read(0);
resetNumber++;
EEPROM.write(0, resetNumber);
Serial.println(resetNumber);
}
void loop() {}
I started by uploading a sketch that sets the EEPROM cell to a known starting value:
#include <EEPROM.h>
void setup() {
EEPROM.write(0, 0);
}
void loop() {}
I then uploaded the sketch provided by @ZX80 to the board with Serial Monitor was open. It produced the following output:
1
2
I just did the same (as ptillisch) thing and got the same result.
I tried following the link in post #40 but the result was the same, I still cant install the latest IDE.
Are you referring to lack of a menu item you mentioned previously?:
I think the best path forward will be to use Arduino IDE 2.x. A community member has created a nice littlefs filesystem uploader extension for Arduino IDE 2.x:
I would but I can't figure out how to install it.
Please answer the question I asked:
Yes.
I think it is a bit misleading to describe this as "I can't install". The menu item is merely a convenience feature. As you already stated, you are perfectly well able to use Arduino IDE by simply executing the .AppImage file directly, even if it is perhaps a bit annoying to have to launch the application in that manner.
If you want to add Arduino IDE to the desktop menu, you can do that via a "desktop entry file". You can find various guides for doing that. Here is one: