Перейти к содержанию
    

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

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

Изменено пользователем nanorobot

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

а что он имеет?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

а что он имеет?

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

 

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

 

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

Изменено пользователем nanorobot

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

ну здраво в общем. Но наверное использовать массив бинарных семафоров будет более корректно...

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

 

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

 

 

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

 

Изменено пользователем nanorobot

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

То что тут начали нести про семафоры и иже с ними, есть офигительный бред в стиле через анус, а не в "стиле RTOS".

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

То что тут начали нести про семафоры и иже с ними, есть офигительный бред в стиле через анус, а не в "стиле RTOS".

 

 

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

 

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

Я в курсе про наличие критических секций в обработке мютексов и семафоров, мой "предрассудок" имеет отношение чисто к "ручному" запрету прерываний,

отдавая предпочтение готовым сервисам, то есть в "стиле RTOS" . Кроме того в этом утверждении была некотороя доля (само)иронии.

 

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

это решение перестает быть "бредом".

 

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

Изменено пользователем nanorobot

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Вообще не понял проблемы. Что такое здесь 'парадигма'?

У меня на M0 вполне себе MQX крутится. Может вам на MQX перейти? :biggrin:

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Я в курсе про наличие критических секций в обработке мютексов и семафоров, мой "предрассудок" имеет отношение чисто к "ручному" запрету прерываний,

отдавая предпочтение готовым сервисам, то есть в "стиле RTOS" . Кроме того в этом утверждении была некотороя доля (само)иронии.

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

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

это решение перестает быть "бредом".

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вообще не понял проблемы. Что такое здесь 'парадигма'?

У меня на M0 вполне себе MQX крутится. Может вам на MQX перейти? :biggrin:

 

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

 

 

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

 

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

 

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

 

 

указано что слейв-M0, далее все про слейв

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

 

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

Изменено пользователем nanorobot

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

Я например в связке M4-M0 по SPI делаю мастером M0.

Так легче релизовать риалтайм без блокировок обмена.

 

 

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Так это же нарушение 'парадигмы' если я ее правильно понимаю.

Основной принцип RTOS - независимость задач, для того чтобы была возможность оценить их планируемость.

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

Это не RTOS, планируемости нет.

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...