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

[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

[AlexandrY]

Напрашивается вариант: любое бращение к битам состояния защищать от коллизий доступа с помощью мютекса, но nil их не имеет, а использовать для слейва полную ChibiOs - тяжеловато будет, там и требования к скорости обработки повыше и процессор послабее. Что посоветуют знатоки?

Вообще не понял проблемы. Что такое здесь 'парадигма'?
У меня на M0 вполне себе MQX крутится. Может вам на MQX перейти?

[nanorobot]

Вообще не понял проблемы. Что такое здесь 'парадигма'?
У меня на M0 вполне себе MQX крутится. Может вам на MQX перейти?

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

Вообще-то не только о нем. Для предельно кастрированных платформ, где даже допотопного SWP нет, остается запрет прерывания.

Мне, значит, не дано не понять почему вызов вызов десятков-сотен команд содержащих запреты прерывания вместо просто запрета прерывания назван Вами "без предрасудков". О критических секциях - если если в некой операционке нет оформления критических секций, то это надо дописать, либо выкинуть такую "RTOS" нафиг.

Процесс это НЕ семафор. Использование возможностей высокоприоритетного процесса, это нормально.

указано что слейв-M0, далее все про слейв
возможно стоит отказаться от всех сервисов РТОС, для синронизации использовать обычные переменные, запрещая , где требуется, прерывания

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

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

[zltigo]

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

Но тем не менее свалили их в одну кучу:

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

возможно стоит отказаться от всех сервисов РТОС, для синронизации использовать обычные переменные, запрещая , где требуется, прерывания

Перестаньте противопоставлять средства предоставляемой какой то кастрированой RTOS всему спектру приемов программирования.

[nanorobot]

Но тем не менее свалили их в одну кучу:

Что не так? Есть набор бинарных семафоров, значения которых требуется "упаковать" в переменную типа uint16_t. Эту самую упаковку я собираюсь выполнять в процессе(треде, задаче) обладающем наивысшим приоритетом. Ни логических, ни грамматических ошибок не допущено. Ну, возможно, запятую пропустил. Ну так я на Пулитцеровскую премию не претендую. Будьте доброжелательнее, не упоминайте анусы всуе Всего доброго.