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

[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

[novikovfb]

Напрашивается вариант: любое бращение к битам состояния защищать от коллизий доступа с помощью мютекса, но nil их не имеет

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

[AHTOXA]

Напрашивается вариант: любое бращение к битам состояния защищать от коллизий доступа с помощью мютекса, но nil их не имеет

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

[nanorobot]

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

Это ничего не даст, пмсм.. Кроме того это никак не снимет необходимости упаковывать "байтовые" биты в uint16_t для отсылки мастеру. С такимже успехом можно опросить полтора десятка бинарных семафоров и собрать из них uint16_t и парадигма не нарушится. Это самый очевидный и громоздкий способ. Кроме того байты здесь 32 битовые

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

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

[novikovfb]

Это ничего не даст, пмсм..

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

Кроме того это никак не снимет необходимости упаковывать "байтовые" биты в uint16_t для отсылки мастеру.

да, но при упаковке можно будет тупо пройтись и снять слепок в текущем состоянии. Опять же, если нет взаимозависимостей между битами в упакованном слове для мастера.

Насколько я понимаю, запись байта - атомарная операция в микропроцессоре, а модификация бита во многих реализациях идет через временное значение в регистре (и Cortex M0 - в их числе).

[nanorobot]

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

ну здраво в общем. Но наверное использовать массив бинарных семафоров будет более корректно...
И да интересно, еслипроцессор имеет bit-banding для SRAM - компилятор будет его использовать для изменения отдельных битов в структуре? не думаю...

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

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


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

[zltigo]

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

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

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

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

[nanorobot]

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


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

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

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

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

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

[AlexandrY]

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

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

[zltigo]

Если Вы имели в виду BitBanding и команды LDREX/STREX то выше указано, что речь идет про cortex M0.

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

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

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

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

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

[nanorobot]

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

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

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

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

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

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

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

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

[zltigo]

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

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

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

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

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

[AlexandrY]

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

Не думаю, тема эта долгая и еще плохо раскрытая.

Я например в связке M4-M0 по SPI делаю мастером M0.
Так легче релизовать риалтайм без блокировок обмена.

[nanorobot]

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

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

[AlexandrY]

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

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