Can I achieve concurrency on Udp/Tcp with software Timers?

General
1

I just wrote a simple program to test software timer with TCP/UDP.But when I upload the code in my electron it crashes (it flashes red).See the code below.

Basically, I want to achieve concurrency, I want UDP code to continuously run on the main thread and TCP connection to run periodically on a timer without blocking each other(Or vice-versa,TCP on main thread,UDP on a timer). Is it possible to achieve this with Software timers, if not how can I alternatively solve this issue?

   #include "Particle.h"

   TCPClient client;
   #define HOST "example.com"
   int port = 80;

   Timer testTimer(2000, test);

   void setup() {
     Serial.begin(4800);
     testTimer.start();
   }

  void loop() {
    // Ideally this would be my Udp code
     Serial.println("main thread 1");
     delay(3000);
     Serial.println("main thread 2");
  }
   void test(){
      if (client.connect(HOST,port)) {
          Serial.println("conected to the server");
          delay(2000);
          client.stop();
      }
   }
2

When saying that it's always best to state what kind for ref flashing you see (e.g. SOS+x) to give a hint of what the cause is.
I'd suspect an SOS+13 Stack Overflow
https://docs.particle.io/tutorials/device-os/led/photon/#red-blink-basic-errors

BTW, when you have a timer period of 2000ms and have a delay of 2000ms (+x µs for code execution) in that timer callback you will inevitably run into issues as the timer will be called more frequently than the timer callback routing will end in the same amount of time.

3

Thank you for the response, and my apologies I should have mentioned, it is SOS+13 Stack Overflow.The code I have shared is more simplified version trying to dig what causes the problem, in my actual code the timer period is set to be called every 1 min and in my callback function the code takes less than 20 seconds to execute but still I was experiencing the same issue.

Because initially, I thought maybe it has something to do with using UDP/TCP API on software timer callback function. So in other words, are you saying theoretically I should be able to use UDP on main thread loop and TCP on timer callback function with no issues if implemented correctly?

4

@sparkz19, not quite. The stack size for timers is small and the most likely cause of your SOS. You need to keep the UDP/TCP stuff out of the timer. To do what you are looking for, you could consider creating another FreeRTOS thread but that will bring other challenges. Stick with dong the UDP/TCP processing in loop() and prevent blocking by using one or more FSM (finite state machines) to handle these.

1 Like
5

Thanks @peekay123 So it sounds like it is impossible to do what I am looking for without consequences..is that correct?

But a bit more information if this would help, on UDP I am looking to send a very small packet(one character or integer) to the server and have it respond with another small packet(every one minute). That is it.

6

@sparkz19, it’s not the size of the packet but the depth of calls that occurs when you call UDP client/server functions. The depth of calls affects the stack depth and thus the error you get when call from the Timer callback. When you create another FreeRTOS thread, you can specify the stack allocation size (at the cost of less free RAM). However, if you don’t have experience with RTOS threads, I would suggest you stick to keeping the code in loop() and using FSMs to create non-blocking conditions so loop() runs efficiently.

7

@peekay123 Oh ok I see. I don’t have any experience with FreeRTOS, but I don’t mind learning it .In that case other than implementing another FreeRTOS thread, I can conclude that is not possible to achieve what I wanted to achieve.

But I am trying to understand what is the benefit of using FSM in this case , because I have had both TCP and UDP run sequentially in the main loop with no issues(the only downside is having to wait for each other to complete execute for another to start, which I don’t want)

8

Although you could do that without FMS, having two FSMs (one for UDP one for TCP) would allow to interleave the two concurrent communication tasks.

1 Like