Printing hangs when toggling pin

Hello all,

I made my own gcode to toggle the LED lighting of my printer.
I am working with Marlin V2.0 (newest).
I added the new gcode (777) function to gcode/gcode.cpp (inside the switch case of "GcodeSuite::process_parsed_command") and also to gcode/gcode.h to the class "GcodeSuite".
For the actual code I added a new file called 777.cpp with the following content:

#include "../../inc/MarlinConfig.h"
#include "../gcode.h"
#include "../../MarlinCore.h"

/**
 * M777: Switch printer lighting on/off
 *
 *  P(pin)      - Pin number
 *  T(bool)     - Toggl lighting on/off
 *  S(state)    - Switch lighting on if 1 and off if 0
 */
void GcodeSuite::M777()
{

  const int pin_index = PARSED_PIN_INDEX ('P', GET_PIN_MAP_INDEX (LED_PIN));
  //SERIAL_ECHO_MSG("pin_index: ", pin_index);
  if (pin_index < 0) return;

  const pin_t pin = GET_PIN_MAP_PIN(pin_index);

  if(parser.seenval('S'))
  {
    const byte status = parser.value_byte();

    if(status == 1)
    {
     pinMode(pin, OUTPUT);
     extDigitalWrite(pin, 1);
    }else if(status == 0)
    {
     pinMode(pin, OUTPUT);
     extDigitalWrite(pin, 0);
    }else
    {
     return;
    }
  }

  if(parser.seenval('T'))
  {
    pinMode(pin, OUTPUT);
    extDigitalWrite(pin, !extDigitalRead(pin));
  }
}

This is working fine, but when I am printing an then toggle the LEDs the printing pauses for about 2s and continues then. This only happens when switching off (S=0)... This happens with the T command and the S command.
To send the gcode and control the printer I use a MKS TFT32 V3.0. My Mainboard is Bigtreetech SKR V1.3.

Does anyone have an idea what can cause this behaviour?
Or does anyone knw where to post that? (Github as bug?)

Thank you in advance

I don't thinks its causing your delay but if's are slow, use a switch statement

eg

if (parser.seenval('S')) {
    switch (parser.value_byte()) {
      case 0: pinMode(pin, OUTPUT); extDigitalWrite(pin, 0); break;
      case 1: pinMode(pin, OUTPUT); extDigitalWrite(pin, 1); break;;
      default: return
    }
  }

Thank you for your suggestion!

But a if statement can't cause such delays. A if statement only needs a few assembly instuctions and with a clock frequency of over 70MHz therefore some 100ns... This has to be a firmware bug

I solved the problem myself.
See: [github.com]