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

[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. Эту самую упаковку я собираюсь выполнять в процессе(треде, задаче) обладающем наивысшим приоритетом. Ни логических, ни грамматических ошибок не допущено. Ну, возможно, запятую пропустил. Ну так я на Пулитцеровскую премию не претендую. Будьте доброжелательнее, не упоминайте анусы всуе Всего доброго.

[AlexandrY]

Что не так? Есть набор бинарных семафоров, значения которых требуется "упаковать" в переменную типа uint16_t.

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

[nanorobot]

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

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

Смутно припоминаю в TNKernel был сервис EventFlags вот это очень близко к тому, что требуется. Но не бросать же ChibiOs(в данном случае nil) с которой сроднился

Еще: решение, бесспорно, далеко от изящества но насчет планируемости и независимости задач: Каждый битик состояния существует в виде бинарного семафора, и "маршалингу" подвергается исключительно для цели передачи его мастеру. Так что "парадигма" не так уж сильно нарушена...

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

[AHTOXA]

Если отвлечься от вопроса, зачем мастеру знать состояние семафоров ведомого, то тут всё достаточно прозрачно.
Это для ведомого они - семафоры, потому что он их использует как семафоры. То есть, для взаимодействия между процессами (ведь он их для этого использует, да?).
А для мастера - это просто некие флаги. Которые вполне можно упаковать в uint16_t (и даже в uint32_t), и передать любым имеющимся способом.

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