[Zeal0t 0]

Добрый день.

Осваиваю scmRTOS.

Пробую простой пример.

 

Исходные данные:

Лишнее убрал.

Оставлена только суть.

 

 struct tagMessageFQ {
   uint16_t Value;
 };

 typedef OS::process<OS::pr0, 200> TProcessFQ;  
 typedef OS::process<OS::pr1, 200> TProcessAPP;

 typedef OS::message<tagMessageFQ> TMessageFQ;

 

namespace OS
{
 template <> OS_PROCESS void TProcessFQ::exec()
 {
   FOREVER {
//    if (MessageFQ.wait(2)) {             // вариант 1
     if (MessageFQ.is_non_empty()) { // вариант 2
       TP2.On();
       {
         MessageFQ.out(msgFQ);
         MessageFQ.reset();
         regFQPWM = msgFQ.Value;
       }
       TP2.Off();
     }
     sleep(1);
   }
 }
} 

 

static tagMessageFQ  msgFQ;

namespace OS
{
 template <> OS_PROCESS void TProcessAPP::exec()
 {
   msgFQ.Value = 0;

   FOREVER {

     TP1.On();
     msgFQ.Value       = msgFQ.Value+1;
     MessageFQ = msgFQ;
     MessageFQ.send();
     TP1.Off();

     sleep(1);
   }
 }
} 

 

TP1, TP2 - просто пины на процессоре, куда зацеплены щупы скопа.

TP1 - желтый

TP2 - синий

 

Процесс APP шлет для FQ новое значение через message.

Если проверку наличия сообщения делать через вариант [1] то получаем вот такую картинку:

 

 

Т.е. процесс увидел сообщение и его прочитал. Все верно. Но т.к. ожидание через wait идет с параметром

то получаем как бы задержку внутри желтого импульса.

 

Если используем вариант [2] то получаем следующее:

 

 

Т.е. сообщение было получено и на следующем витке планировщика процесс FQ "увидел" данные и их забрал.

 

Все работает корректно в обоих случаях.

Но если далее процесс FQ будет расти то и задержка для процесса APP будет расти.

В связи с чем вопрос: я неверно понял принцип использования сообщений или это нормально и можно использовать любой вариант?

 

[AHTOXA 14]

Первый вариант правильнее. Процесс ждёт сообщения, и тут же на него реагирует. Второй вариант - это просто опрос.

Кстати, почитайте про подводные камни сообщений. Возможно, лучше будет использовать каналы.

[Zeal0t 0]

Первый вариант правильнее. Процесс ждёт сообщения, и тут же на него реагирует. Второй вариант - это просто опрос.

Кстати, почитайте про подводные камни сообщений. Возможно, лучше будет использовать каналы.

 

Я пробовал на каналах. Логика, в принципе, у них такая же - передать для другого процесса данные. Но после просмотра листинга от компилятора они мне показались избыточны для передачи одного единственного значения. Слишком там много кода получается.

 

[AHTOXA 14]

Не думаю, что между каналами и сообщением большая разница по коду. И там и там критическая секция, и там и там при записи производится копирование объекта. В канале только добавляется обновление указателя на позицию записи и количества элементов в очереди. На фоне общего объёма действий это мизер. Зато нет возможности гонок, описанных в приведённом мной примере.

Но решать, конечно, вам.