Interrups for when Serial communication is received

Hi,

I have a large system, with many different functions, and would like to know if there is a way to set an interrupt for serial communication. As a simple example, if my system is busy operating as normal and I send "Stop" through serial communication from my computer, then the system should immediately stop what it is doing and return to a certain starting point in my code.

As far as I understand serial communication is interrupt-based, i.e. as soon as something is sent an interrupt is triggered and the data is stored in the receiving buffer. Now I need a way to immediately analyze this received data no matter where I am in my code. I have looked at the attachInterrupt() function, but am not sure if it will work. What should the first argument of the attachinterrupt() function be for serial communication received from the computer over a USB cable.

I am using an Arduino Uno and as I said the serial communication is via the USB cable.

1 Like

Are there any significant (i.e. > 1ms) delays in your loop() function? If the answer is yes, and that is the reason you want to do this, you are digging yourself into a very deep hole. Serial is already interrupt driven, there is an interrupt generated every time a character is received. But the response is to put it into a buffer. You could tie into that already existing interrupt, but as I say, it is likely to create a huge design mess.

Allow me to give you a general idea of how this could go badly. You want to intercept certain commands. However, you may have code that reads from the existing buffer. Now you have to decode and execute commands in two different places. Not fun. How would you coordinate them?

Just fix the delays in your "many functions" so that normal serial processing can work.

No, but that is because my loop() function is quite empty. I use my loop() function only as a skeleton for the system and then use other functions (called from my loop() function), to implement subsystems of my system. This is my problem since some of my subsystems should run indefinitely until a certain command is received over serial. And depending on what that command is some of the functions might continue as normal or should immediately end and return to my loop() function.

No, your problem is that your design is flawed, and inappropriate for the architecture and environment.

chris_jooste:
This is my problem since some of my subsystems should run indefinitely until a certain command is received over serial. And depending on what that command is some of the functions might continue as normal or should immediately end and return to my loop() function.

The problem almost certainly lies in the way you have implemented the subsystems that should run indefinitely.

Have a look at how the code is organized in Several Things at a Time

Note how each function runs very briefly and returns to loop() so the next one can be called. None of the functions tries to complete a task in one call. And there may be dozens of calls to a function before it is actually time for it to do anything.

When the code returns to loop() it can check if a new message has bee received. Also have a look at Serial Input Basics - simple reliable non-blocking ways to receive data.

...R

Keep loop running freely by not using blocking code in your sketch. That way you can check frequently whether serial data has been received

some of my subsystems should run indefinitely until a certain command is received over serial.

It sounds like a state machine would be a good way to implement your requirements. Use switch/case to run the code for the current state but make it non blocking, then check in loop() for serial data between executing the code for the current state. When a command is received change the state and run that code instead