Как сделать идеологически выдержанно, "в стиле РТОС" Опции

[nanorobot]

Дивайс состоит из двух узлов на STM32 связанных по SPI. Программа как для мастера так и для слейва пишется с использованием RTOS: мастер CortexM4/ChibiOS, слейв - CortexM0/nil(облегченный вариант ChibiOS). Слейв, в частности формирует слово состояния - набор битов, которое передается мастеру, а так же используется самой программой слейва. Причем биты могут использоваться в разных тредах(процессах). С точки зрения парадигмы RTOS они являются об'ектами синхронизации процессов. В этом случае они должны иметь тип BinarySemaphore с другой стороны для передачи слова состояния мастеру они(биты) должны быть упакованы в переменную типа uint16_t. Сейчас у меня используется union одно поле которого битовая структура, другое поле uint16_t. Покамест УМВР, но беспокоят возможные проблемы из за отхода от парадигмы RTOS. Напрашивается вариант: любое бращение к битам состояния защищать от коллизий доступа с помощью мютекса, но nil их не имеет, а использовать для слейва полную ChibiOs - тяжеловато будет, там и требования к скорости обработки повыше и процессор послабее. Что посоветуют знатоки?

Сообщение отредактировал nanorobot - Dec 9 2016, 12:07

[zltigo]

Достаточно обеспечить атомарность доступа. Для этого можно просто запрещать прерывания на время записи переменной.

Именно так, но это если в лоб. А вообще на Corteх кроме заперта прерываний, есть еще два механизма обеспечения атомарного доступа. Не считая комбинированных.
То что тут начали нести про семафоры и иже с ними, есть офигительный бред в стиле через анус, а не в "стиле RTOS".

почему то напрягает лишний раз прерывания запрещать. Такой вот предрассудок...

Невежество . Вы думаете, что в вызовах всяких семафоров с мютексами нет критических секций

[nanorobot]

Именно так, но это если в лоб. А вообще на Corteх кроме заперта прерываний, есть еще два механизма обеспечения атомарного доступа. Не считая комбинированных.
То что тут начали нести про семафоры и иже с ними, есть офигительный бред в стиле через анус, а не в "стиле RTOS".


Невежество . Вы думаете, что в вызовах всяких семафоров с мютексами нет критических секций

Если Вы имели в виду BitBanding и команды LDREX/STREX то выше указано, что речь идет про cortex M0.
Я в курсе про наличие критических секций в обработке мютексов и семафоров, мой "предрассудок" имеет отношение чисто к "ручному" запрету прерываний,
отдавая предпочтение готовым сервисам, то есть в "стиле RTOS" . Кроме того в этом утверждении была некотороя доля (само)иронии.

Касательно бреда про семафоры: С небольшой поправкой, что упаковку значений бинарных семафоров в uint_16_t выполнять в процессе с максимальным приоритетом
это решение перестает быть "бредом".

Спасибо, что уделили внимание моей персоне.

Сообщение отредактировал nanorobot - Dec 9 2016, 15:26

[jcxz]

Касательно бреда про семафоры: С небольшой поправкой, что упаковку значений бинарных семафоров в uint_16_t выполнять в процессе с максимальным приоритетом
это решение перестает быть "бредом".

Добавлю ещё один способ обеспечения атомарности доступа (касательно задач, но не ISR-ов) - временный запрет шедулера. Если такое поддерживает Ваша ОС.
Хотя в Вашем случае несомненно использовать надо критические секции aka запрет прерываний.
А фобии надо преодолевать....

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

Вы отстали от жизни. Откройте для себя uCOS-III.

[AlexandrY]

Хотя в Вашем случае несомненно использовать надо критические секции aka запрет прерываний.

Кто-то еще запрещает прерывания в Cortex-M?

Там давно уже все уважающие себя RTOS не запрещают прерывания, а просто поднимают приоритет.
Кстати в uCOS тоже нет запрета прерываний, а есть подъем приоритета, как и в MQX.

Я считаю правильным оценивать возможности операционных систем по их ядру, а не по наличию "штатных" прибуд типа поддержек SPI, прикрученных разных библиотек или возможности запуска Microsoft Word.

Хотел бы я посмотреть как линукс будут обсуждать отдельно от файловой абстракции, сетевого стека, управления памятью, загрузки ппроцессов и проч.
В MQX межпроцессорное взаимодействие это часть ядра. Там все сервисы (задачи, семафоры, ивенты...) предусматривают расположение на разных ядрах.
Так что...

[zltigo]

Хотел бы я посмотреть как линукс будут обсуждать отдельно....

Естественно, что не обсуждают, по тому, что нынешние виндовсы с массовыми линуксами есть один комок со всеми потрохами включая не только стеки, но уже де-факто и приложения . Только это совершенно не отрицает и нормального модульного построения систем. Тем более для кортексов M0/M3 которыми здесь Автор озаботился.