Am I complicating things?
I'm architecting my code to talk from a 8051 micro to a peripheral device over UART. The peripheral responds to commands from the host and can only respond to one command at a time. It's a simple send and receive protocol. (tx1, rx1, tx2, rx2, tx3, rx3) Each TX message is terminated with a CR, each response is terminated with a >. I can't send a new message until I receive the response to the last one. Responses can also echo print the original TX message in the beginning if I enable that option (but this causes more traffic)
An example message would be:
- TX: Hello
- RX: World!>
Or with echo option...
- TX: Hello
- RX: Hello\rWorld!>
Option A A function such as getHello would consist of both the send and receive. A parallel ISR routine would gather the incoming bytes and throw a flag when the '>' character is received.
char* getHello(char * buf){
sendMsg("Hello\r");
delay(10ms); //wait a little bit
//wait for receive to come in or timeout to occur
while(!receiveFlag || !timeoutFlag); //thrown by ISR
receiveMsg(buf);
//parse the message and do some other stuff
return buf;
}
Pros:
- Everything is contained within one function.
- Easier to debug
Cons:
- This function is blocking and could hang if the peripheral never responds so a timeout must be implemented.
- Messages can't be received out of order, must be in series (ie, tx1, rx1, tx2, rx2, tx3, rx3)
Option B A parallel approach is taken. Two separate functions would created. one to send the message, and one that would vertexed upon receiving a response from the ISR.
void sendHello(){
sendMsg("Hello\r");
//do some other stuff if needed
}
char* receiveMsg(char * buf){
//figure out from echo print what the tx message was
//use a switch statement to decide which response parser to call
switch(txMessage){ //pseudo code
case "Hello":
receiveMsg(buf);
//parse the message and do some other stuff
break;
}
return buf;
}
Pros:
- Can handle parallel messages coming back out of order because it relies on the echo printing of the tx message to figure out how to parse it. (ie, tx1, tx2, tx3, rx1,rx2,rx3)
Cons:
- quite difficult to debug
- spawns multiple threads
- lots of extra code
- not worth it since messages will definitely come back in order
Right now, I'm doing Option B, but as I continue on with the project, I begin to feel like this is getting overly complex. I'm curious what you guys think.
Thanks!