The Arduino Compatible Pro Micro and the Arduino Leonardo both use the ATmega32u4, which has built-in USB communications. While this eliminates the need for a secondary processor or UART chip, it allows the Leonardo to appear to a connected computer as a USB device, such as a mouse or keyboard, in addition to the virtual (CDC) serial/COM port.
While this sounds really useful, I was having a weird issue using a Pro Micro as a serial device with my ROV hardware, where, despite explicitly stating the baud rate and being able to turn on and off outputs while manually connected to it via the Arduino IDE Serial Terminal, at any baud rate and not the one set.
I was speaking to Nick Charlton whom I know from TermiSoc. He is trying to communicate between two Arduinos using RS485 on non-standard ports via software serial; it wasn’t until he shared the following image that I realised my issues may not be just related to my poor coding.
One of his Arduinos is a Leonardo that, like the pro-micro, uses the ATmega32u4 as its processor; this showed that I was not alone in having weird issues with serial.
I suspected the issue was related to how the lack of explicitly stating the baud rate allows for it to work; however, the problem is more specific than that. The ATmega32u4 requires that DtrEnable be set when opening the serial connection (on the PC end). The Arduino IDE Serial Monitor does that. However, most applications do not. Including my serial Python code.
A suggested fix for this issue is to edit the file “Arduino\hardware\arduino\cores\arduino\CDC.cpp”, which I would very much like to avoid, as editing core Arduino code is a quick way to break bigger things.
Another possible option is adding the line ”serialPort.DtrEnable = true” just before ”serialPort.Open()” but I have not tested that either.
My fix will be to skip using Arduino Pro Micros and use Arduino Uno R3S, which uses the ATmega328 processor for development. Once I have working code, I will reassess my choices, but chances are I will use an Arduino Mega 2560, which uses the ATmega2560 microcontroller.
7 thoughts on “Serial issues with the Arduino Pro Micro”
The Arduino has a fairly small serial buffer. If you do not “serial.read()” frequently enough, it will fill up. Particularly if you are using very high baud rates.
You must either – Use hardware flow control to prevent buffer overflow (slowing how fast you are filling it) , or Use hardware buffering of sufficient size (by getting a chip with a larger buffer). Or modify your code so that the buffer is emptied more frequently.
I don’t think that is likely to be the issue in this case. I have used serial quite a bit. This issue relates to the specific microcontroller.
The code for the lights is in this file. As you can see, there is nothing that blocks the main loop, nor anything that will cause the loop to take too long to complete.
https://github.com/PhilipMcGaw/ROV/blob/main/Arduino/Light/Light.ino
Yes, the issue is specific to this specific micro-controllers lack of a large serial buffer. Your program is doing exactly what I suspected:
“If you do not serial.read() frequently enough, it will fill up”.
You are calling serial.read() once in a large loop, and also in that loop you have a bunch of other slow stuff:
serial.println() <- sometimes very fast, but if the write buffer is full because you are printing huge blocks of text all at once, this call becomes very slow as the main loop has to wait for the buffer to accept the last characters.
I can think of a few ways to address this:
1 – Use an asynchronous serial reading approach. One option there would be to use something like modbus, where a library would read the input in the background using interrupts and then store the most recent value in a variable for you.
2 – make your strings much shorter. There is no reason to have "output/lights/toggle/status: {some bool}. If you shorten those up, you are less likely to fill up the write buffer and cause serial.print to become very slow.
2. The reason for the strings being that length is due to what happens to them when they are injected into and out of the MQTT server.
I think I will move away from the ATmega32u4, and give the RPi 2040 a go.
This is the code that Nick was having issues with:
There is a post that details how to increase the size of the serial buffer, but like the ‘fix’ for the Pro Micro this involves changing the core Arduino files: https://forum.arduino.cc/t/solved-increase-serial-buffer-size-on-arduino-mega-2560/385108
There is a tutorial that I will also have a look at https://forum.arduino.cc/t/serial-input-basics-updated/382007/3