Parse serial string ... update DO and PWM pins

This is a small function to handle a char string got through Serial from another device, parse it and send the resulting boolean information to four pins of a Mega 2560. Works as expected. Now this has to be expanded to handle the final data structure which will be in this format :

< B0,B1,B2,B3,B4,B5,B6,…B15,INT0,INT1,INT2,INT3…INT7>

< : Start Marker

: End Marker
Bn : Boolean data
INTn : Integer data

The requirement is to parse the above string and update 16 digital pins based on the Boolean data and update 8 Analog pins with the PWM data got as an integer.

Would it be better to split the string into separate Boolean and Integer data strings and create two functions as i have shown below ? Or any other method can be tried ?

// Function to parse the incoming char array data and send to digital pins. 

void showData()
  char *cs = dataFromLVApp;               // data format <Switch01state, ... SwitchNstate>  // Start Marker '<' and End marker '>'
  char pinState[4] = {0, 0, 0, 0};
  byte count = 0;

  for (char *p = strtok(cs, ","); p != NULL; p = strtok(NULL, ","))
    pinState[count] = *p - 0x30;         // Byte via Serial is ASCII, so get back the orginal digit 0 or 1 

  for ( byte index = 0; index < 4 ; index++)
    digitalWrite(ledPin[index], pinState[index]);

Based on your fixed format input record comprising position determined fields, I think I would most likely just have a single function which would split the whole record. Either update the digital pins directly in it as you have done; or perhaps return a struct with the data - so simply a deserialization function.

This may just be demo code you posted, but note that the code you have written has the potential for a buffer overflow if the incoming data is unexpected: count increases unchecked, so pinState[count] could be overwriting something it shouldn’t.
You also need to handle the < and > markers.
I would also explicitly, in pinState[count] = *p - 0x30, set pinState[count] to HIGH or LOW depending on the input value. It will likely work either way but, at least in my mind, seems cleaner.