The HardwareSerial requires to run an interrupt to store received bytes in the buffer. Look at this file from the Arduino Core. If I am now constantly receiving and writing on the Software Serial, the data from the HardwareSerial cannot be buffered, since external interrupts are higher priority.

In my application, I need to constantly listen to the SoftwareSerial and respond immediately to incoming data (actually inside the receive interrupt of the SoftwareSerial, so its modified), so the SoftwareSerial has higher priority. But when I do this, I lose data on the HardwareSerial.

Is there any way to circumvent this limitation, without disabling any interrupts or getting a chip with more UART ports?

EDIT: the actual interrupt vector is here

EDIT2: This is question is not answered by the answers in my previous question. It is clearly a fact that HardwareSerial needs its receive interrupt to store data in a buffer. My question now is how I can still use the SoftwareSerial while it is constantly receiving.

  • 1
    Does this answer your question? SoftwareSerial and HardwareSerial lost data
    – VE7JRO
    Jul 11, 2023 at 19:42
  • This was my question which has clearly been misunderstood. People don't understand that HardwareSerial is using a receive interrupt to store bytes in a buffer. My question is how to use SoftwareSerial together with HardwareSerial, if SoftwareSerial is constantly receiving.
    – RenX
    Jul 11, 2023 at 19:53
  • Duplicate of arduino.stackexchange.com/questions/93772/…
    – Delta_G
    Jul 11, 2023 at 22:02
  • 1
    This is question is not answered by the answers in my previous question ... look again ... that question does not have any answers
    – jsotola
    Jul 11, 2023 at 22:13
  • 1
    You have asked the same question twice, here and here. It is hard to know which one to close because they both have answers. Please don't do that. Don't re-ask the question just because you don't get an answer to the first one.
    – Nick Gammon
    Jul 12, 2023 at 7:56

1 Answer 1


If you are sending something in SoftwareSerial ISR handler that means ISRs are disabled and you are blocking other ISRs being called (if needed).

If you're using some crazy slow baudrate like 9600 then it means over 1 millisecond per character sent and during that time you might be missing other interrupts calls (millis, HW serials). If there is only one character, it's not problem, it'll be handled after interrupts are enabled again, but if there will be second or more character, previous are lost, as the've never been readed out from the UDR register (that should set flag for buffer overrun or how it's called).

If your Hw serial has some nice speed like 115200, you can lose up to 12 characters during sending single characted on software serial with speed 9600

The cli() in software serial library but as you wrote it's called from ISR handler and the ISRs are disabled anyway already during whole ISR handler

  • "If your Hw serial has some nice speed like 115200, you can loose up to 12 characters during sending single characted on software serial with speed 9600" This is exactly the situation I'm in, which is unfortunately required. Thanks for your Info. I'm currently looking into AltSoftSerial, which doesn't block as much.
    – RenX
    Jul 11, 2023 at 20:06
  • Go for something like Nano Every (note that Every), that has several USARTs and one connected to the USB is different from second connected to pins 0 and 1
    – KIIV
    Jul 11, 2023 at 20:11
  • Another solution would probably be to implement some sort of hardware flowcontrol, since the device on the HW serial supports it. This would require a modification to the receive isr of the HW serial AND a new PCB. We'll see
    – RenX
    Jul 11, 2023 at 20:12
  • @LiessJemai Another solution is to swap the interfaces. Use the software serial with the higher speed (it can handle up to 115200 bits per second) and the hardware serial with the lower speed. Or, if you can choose the speeds, adjust them. Jul 12, 2023 at 6:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.