How to handle this interrupt-driven state tracking neatly in C? - c

Question

An external module sends the string "CMD\n" to my program one character at a time through interrupts. It is important to know where in the sequence the module is so that I can troubleshoot. This is the way I'm currently handling tracking of the module:
// Enumeration describing the different states
typedef enum {
BTSTATE_ENTERING_CMD_C, // awaiting "C"
BTSTATE_ENTERING_CMD_M,
BTSTATE_ENTERING_CMD_D,
BTSTATE_ENTERING_CMD_EOL,
BTSTATE_CMD
} btstate_t;
// State variable
btstate_t btstate = BTSTATE_ENTERING_CMD_C;
// function called every time a new character is sent
ISR(USART_RX_vect) {
uint8_t rcv = UDR0; // the received character
if ( btstate == BTSTATE_ENTERING_CMD_C && rcv == 'C') {
btstate = BTSTATE_ENTERING_CMD_M;
} else if ( btstate == BTSTATE_ENTERING_CMD_M && rcv == 'M') {
btstate = BTSTATE_ENTERING_CMD_D;
} else if ( btstate == BTSTATE_ENTERING_CMD_D && rcv == 'D') {
btstate = BTSTATE_ENTERING_CMD_EOL;
} else if ( btstate == BTSTATE_ENTERING_CMD_EOL && rcv == '\n') {
btstate = BTSTATE_CMD;
} else {
// error handling here
}
}
Intuitively, there seems to be a lot of redundancy in the code. Is there a better or more canonical way to achieve the same result?

Answer 1

What about this ? It's pretty readable and easy to modify.
// Enumeration describing the different states
typedef enum {
BTSTATE_ENTERING_CMD_C, // awaiting "C"
BTSTATE_ENTERING_CMD_M,
BTSTATE_ENTERING_CMD_D,
BTSTATE_ENTERING_CMD_EOL,
BTSTATE_CMD
} btstate_t;
// State variable
btstate_t btstate = BTSTATE_ENTERING_CMD_C;
struct cmp
{
btstate_t state;
btstate_t next_state;
uint8_t c;
} t_cmp;
ISR(USART_RX_vect) {
static t_cmp cmp_array[] = {
{BTSTATE_ENTERING_CMD_C, BTSTATE_ENTERING_CMD_M, 'C'},
{BTSTATE_ENTERING_CMD_M, BTSTATE_ENTERING_CMD_D, 'M'},
{BTSTATE_ENTERING_CMD_D, BTSTATE_ENTERING_CMD_EOL, 'D'},
{BTSTATE_ENTERING_CMD_EOL, BTSTATE_CMD, '\n'}
};
static int array_size = sizeof(cmp_array) / sizeof(cmp_array[0]);
uint8_t rcv = UDR0; // the received character
int i;
for (i = 0; i < array_size; ++i)
{
if (btstate == cmp_array[i].state && rcv == cmp_array[i].c)
{
btstate = cmp_array[i].next_state;
break ;
}
}
if (i == array_size)
// error handling here
}

Answer 2

Something like the following will test an incoming stream to confirm that it
matches a string:
static const char leader[] = "CMD\n";
uint8_t btstate = 0;
ISR(USART_RX_vect) {
uint8_t rcv = UDR0;
if (btstate < 4)
{
if (rcv == leader[btstate])
btstate++;
else
{
// error handling here
btstate = 0;
}
}
}
(untested, obviously)
If (btstate == 4) then you've got your leader string and are now receiving
whatever comes after.
An error condition which is not well handled here, which might affect the
design, is where you receive some leading garbage before the correct string.
As things stand, we'll enter into // error handling here and reset btstate,
but if rcv is now equal to the first 'C' that the sender really intended
then we've missed it, and next time around we'll expect 'C' but receive 'M'
and raise yet another error and completely miss the correct string.
Here you have two options. One is to signal the sender to reset itself (which
can be troublesome over high-latency links), and the other is to re-check
(rcv == 'C') in the error handler.
If your command string were "GABBAGABBAHEY", and you were expecting the 'H'
but you instead got 'G', then it's possible that all of the preceeding
characters were sent erroneously, or that some number of characters were sent
deliberately as the prefix of another string (or the current string).
Handling that case, and handling the case of there being multiple possible
strings, requires a structure that can take different paths depending on the
character received. In the case where you do want to tolerate leading garbage,
that structure can loop back on itself -- pointing back to the longest prefix
which matches the current state -- and in that case you don't really want to
build the table by hand.
You've said you know what string you're expecting, so I won't go into all that,
but I thought it worth mentioning for completeness.