Осваиваю scmRTOS.
Пробую простой пример.
Исходные данные:
Лишнее убрал.
Оставлена только суть.
CODE
struct tagMessageFQ {
uint16_t Value;
};
typedef OS::process<OS::pr0, 200> TProcessFQ;
typedef OS::process<OS::pr1, 200> TProcessAPP;
typedef OS::message<tagMessageFQ> TMessageFQ;
CODE
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);
}
}
}
CODE
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 будет расти.
В связи с чем вопрос: я неверно понял принцип использования сообщений или это нормально и можно использовать любой вариант?
