[Alex32 0]

Чем ее правильнее закрывать, бинарным семафором или мьютексом?

 

Как альтернатива для функции потокобезопасного вывода - блокировка планировщика(на примере FreeRTOS):

void vPrintString( const char *pcString )
{
    /* Print the string, suspending the scheduler as method of mutual
    exclusion. */
    vTaskSuspendAll();
    {
        sprintf( cBuffer, "%s", pcString );
        consoleprint( cBuffer );
    }
    xTaskResumeAll();
}

[jcxz 184]

Как альтернатива для функции потокобезопасного вывода - блокировка планировщика(на примере FreeRTOS):

...

consoleprint( cBuffer );

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

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

Если так пишете - значит Вы не поняли зачем вообще нужна многозадачная ОС.

[Alex32 0]

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

 

Я понимаю, конечно на время вывода сообщения система "стопорится". Я использую это только для отладки чего-либо, в местах под макросом #ifdef _DEBUG_ANYTHING.

В рабочем приложении такого конечно нет.

Функция взята из учебника "FreeRTOS на Cortex-M3". Не такой уж и бред, если понимать, в каком контексте её можно использовать.

[jcxz 184]

Я понимаю, конечно на время вывода сообщения система "стопорится". Я использую это только для отладки чего-либо, в местах под макросом #ifdef _DEBUG_ANYTHING.

В рабочем приложении такого конечно нет.

Функция взята из учебника "FreeRTOS на Cortex-M3". Не такой уж и бред, если понимать, в каком контексте её можно использовать.

Один из главных плюсов использования ОС это: полезное использование времени процессора во время выполнения операций ввода/вывода.

Т.е. - например когда одна задача, как у вас, ждёт готовности FIFO UART-а принять очередной передаваемый байт, другая в этой время получает время CPU и выполняет полезную работу.

В суперцикле это невозможно, аналогично как и в приведённом Вами куске кода.

Плюс также - время реакции критичных по времени сервисов существенно меньше суперцикла. А у Вас, при выводе чего-то существенного в порт таким способом, все такие сервисы будут в пролёте.

Использовать такое для отладки тоже не имеет смысла, так как, при включении такой отладки, поведение программы сильно меняется (работа перестаёт быть многозадачной) и соответственно результаты отладки бессмысленны (отлаживается совсем не то ПО, которое нужно).

Если нужно корректное разделение ресурса (буфера вывода UART), то самое правильное - использовать семафор.

Можно использовать и запрет прерываний или запрет шедулера, но только на время вывода в программный буфер UART, а не на время вывода в IO-порт UART.

[Alex32 0]

jcxz, спасибо за разъяснение. Я все это понимаю, и полностью согласен.

Но если 1 тик шедулера = 1 мс, то на 115200бод/с можно успеть передать 11 символов. Если это будут сообщения типа "PING:ok" или "timeout", то ничего ведь страшного не случится?

Т.е. 1-2 тика не такой уж и криминал в этом случае? Все зависит от требований к времени реакции, конечно.

К тому же прерывания не запрещаются при блокировке шедулера и в некотором смысле многозадачность сохраняется.

По поводу защиты буфера - тогда нужно гарантировать, что все операции через UART для всех задач будут организованы только через него.

Ладно, это всё - скорее мои нелепые попытки оправдаться, знаю :laughing:

Изменено 3 марта, 2017 пользователем MoskWin32

[zltigo 0]

Но если 1 тик шедулера = 1 мс, то на 115200бод/с можно успеть передать 11 символов.

Много больше, если для передачи используется буфер, то сброс вывода в буфер просходит на порядки быстрее, чем вывод в нефифофированный порт.

Ну а за такой вывод через промежуточный буфер:

sprintf( cBuffer, "%s", pcString );
        consoleprint( cBuffer );

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