Do Events block?

Programming Support
1

Does VexCode place Events in separate threads?

In the example below, would the LongRunningProcess block the ChassisControl?

void LongRunningProcess(void){
  while(results == false){
    //Evaluate sensor
  }
}

void ChassisControl(){
  LeftDriveSmart.setVelocity(
      Controller1.Axis2.position() + Controller1.Axis1.position(), percent);
  RightDriveSmart.setVelocity(
      Controller1.Axis2.position() - Controller1.Axis1.position(), percent);
}

void userControl(void) {
  //Button Event
  Controller1.ButtonX.pressed(LongRunningProcess);

  // place driver control in this while loop
  while (true) {
    ChassisControl();
    wait(20, msec);
  }
}
2

.pressed() places functions in separate threads.

2 Likes
3

I’d recommend placing the event registration in the main function rather than the userControl as main is guaranteed to run only once while userControl could run multiple times when plugged into field control

1 Like
4

Its been answered, but I thought I would add a little more background.

yes, events run in their own thread, they are also not re-entrant so while you are in the thread it will not fire again.

On V5, we have enough resources so that every event has a dedicated thread, however, on IQ and EXP we use what is known as a thread pool. When an event is triggered an available thread is found in the thread pool and assigned to that event to run the callback function. The size of the thread pool varies by platform.

On IQ generation 1 it’s 4 threads (as we have very little memory)
On IQ generation 2 it’s 8 threads.
On EXP it’s 10 threads

This limits the number of simultaneous event handlers that can be running not the number of event handlers that can be registered, on IQ gen 1 you can still have 64 (IIRC) events registered, but only 4 can run at any given time.

Most event handlers should not block, run the required action and then leave the callback. On V5 if an event handler does block, it’s not really a problem, but you can see that on IQ gen 1 it could cause issues.

For simple event handlers I like to use lambda functions, for example.

vex::controller c1;
vex::pneumatic pnu(PORT7);

int main() {
    c1.ButtonRUp.pressed( [](){ 
      pnu.extend( cylinderAll ); 
    } );

    c1.ButtonRUp.released( [](){ 
      pnu.retract( cylinderAll ); 
    } );

    // more code
}

and yes, that’s the API for the IQ pneumatics shown there.

Using Python, you can also pass parameters to an event handler, for example.

def screen_press(name):
    print("Screen pressed " + name)
    brain.screen.clear_screen(vex.Color.GREEN)

def screen_release():
    print("Screen released")
    brain.screen.clear_screen(vex.Color.BLACK)

E1 = brain.screen.pressed(screen_press, ("hello",))
E2 = brain.screen.released(screen_release)

parameters are passed as a tuple

5 Likes
5

Just wondering since this is the first day of Autumn, are the IQ pneumatics supported in an update release somewhere? Shipping?

6

The pneumatics will be supported in IQ Gen2 vexos 1.0.8 and a future update to VEXcode. That release will be coordinated with customers receiving hardware.

2 Likes
7

James, just curious if there is a description somewhere as to how the threads are specifically implemented and managed on the Gen 2 processor. I think I read somewhere that the processor is an ARM, rather like Cortex?

8

All the VEX brains use some for of arm processor, usually contained with other functionality in a SOC.

The product that was marketed as the “cortex” used an SOC with a cortex M3 processor. IQ2 uses an M4, others use M7 and A9 processors. Most of the smart sensors also use arm processors, some (GPS for example) are quite powerful.

I don’t think I ever wrote a detailed white paper or anything on the scheduler that’s used for VEXcode. It’s a cooperative scheduler (V5 being a dual core system can run alternatives, PROS uses FreeRTOS, but IQ gen 1/2 and EXP cannot) that was inspired by the scheduler used in RobotC, although the implementation is quite different. Years ago, before joining Robomatter/VEX, I did write several long posts on the RobotC scheduler, many of the same concepts still apply.

3 Likes
9

Great stuff James. While I actually programmed some of those primitive systems in the '60s, this will take some digesting.

1 Like
10

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.