Я усложняю вещи?
Я разрабатываю свой код для связи микроконтроллера 8051 с периферийным устройством через UART. Периферийное устройство отвечает на команды хоста и может отвечать только на одну команду за раз. Это простой протокол отправки и получения. (tx1, rx1, tx2, rx2, tx3, rx3) Каждое сообщение TX завершается CR, каждый ответ завершается знаком >. Я не могу отправить новое сообщение, пока не получу ответ на последнее. Ответы также могут эхо-печатать исходное сообщение TX в начале, если я включу эту опцию (но это вызывает больше трафика)
Пример сообщения:
- ТХ: привет
- RX: Мир!>
Или с опцией эха...
- ТХ: привет
- RX: Привет\rМир!>
Вариант A Функция, такая как getHello, будет состоять как из отправки, так и из получения. Параллельная процедура ISR будет собирать входящие байты и выбрасывать флаг при получении символа '>'.
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;
}
Плюсы:
- Все содержится в одной функции.
- Легче отлаживать
Минусы:
- Эта функция блокируется и может зависнуть, если периферийное устройство не отвечает, поэтому необходимо реализовать тайм-аут.
- Сообщения не могут быть получены не по порядку, они должны быть последовательными (например, tx1, rx1, tx2, rx2, tx3, rx3)
Вариант Б Используется параллельный подход. Будут созданы две отдельные функции. один для отправки сообщения, а другой для вершины при получении ответа от 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;
}
Плюсы:
- Может обрабатывать параллельные сообщения, возвращающиеся не по порядку, потому что он полагается на эхо-печать сообщения tx, чтобы выяснить, как его анализировать. (т.е. tx1, tx2, tx3, rx1, rx2, rx3)
Минусы:
- довольно сложно отлаживать
- порождает несколько потоков
- много дополнительного кода
- не стоит, так как сообщения обязательно вернутся по порядку
Прямо сейчас я использую вариант Б, но по мере того, как я продолжаю работу над проектом, я начинаю чувствовать, что он становится слишком сложным. Мне интересно, что вы, ребята, думаете.
Спасибо!
case "Hello":
вы сравниваете указатели с этим, а не строки. - person ouah   schedule 23.11.2012