nanorobot 5 9 декабря, 2016 Опубликовано 9 декабря, 2016 (изменено) · Жалоба Дивайс состоит из двух узлов на STM32 связанных по SPI. Программа как для мастера так и для слейва пишется с использованием RTOS: мастер CortexM4/ChibiOS, слейв - CortexM0/nil(облегченный вариант ChibiOS). Слейв, в частности формирует слово состояния - набор битов, которое передается мастеру, а так же используется самой программой слейва. Причем биты могут использоваться в разных тредах(процессах). С точки зрения парадигмы RTOS они являются об'ектами синхронизации процессов. В этом случае они должны иметь тип BinarySemaphore с другой стороны для передачи слова состояния мастеру они(биты) должны быть упакованы в переменную типа uint16_t. Сейчас у меня используется union одно поле которого битовая структура, другое поле uint16_t. Покамест УМВР, но беспокоят возможные проблемы из за отхода от парадигмы RTOS. Напрашивается вариант: любое бращение к битам состояния защищать от коллизий доступа с помощью мютекса, но nil их не имеет, а использовать для слейва полную ChibiOs - тяжеловато будет, там и требования к скорости обработки повыше и процессор послабее. Что посоветуют знатоки? Изменено 9 декабря, 2016 пользователем nanorobot Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
novikovfb 18 9 декабря, 2016 Опубликовано 9 декабря, 2016 · Жалоба Напрашивается вариант: любое бращение к битам состояния защищать от коллизий доступа с помощью мютекса, но nil их не имеет а что он имеет? Напрашивается вместо битов признаки разнести по разным байтам и иметь доступ к ним без коллизий, если, конечно, между битами нет взаимосвязей. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 15 9 декабря, 2016 Опубликовано 9 декабря, 2016 · Жалоба Напрашивается вариант: любое бращение к битам состояния защищать от коллизий доступа с помощью мютекса, но nil их не имеет Достаточно обеспечить атомарность доступа. Для этого можно просто запрещать прерывания на время записи переменной. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nanorobot 5 9 декабря, 2016 Опубликовано 9 декабря, 2016 (изменено) · Жалоба а что он имеет? Напрашивается вместо битов признаки разнести по разным байтам и иметь доступ к ним без коллизий, если, конечно, между битами нет взаимосвязей. Это ничего не даст, пмсм.. Кроме того это никак не снимет необходимости упаковывать "байтовые" биты в uint16_t для отсылки мастеру. С такимже успехом можно опросить полтора десятка бинарных семафоров и собрать из них uint16_t и парадигма не нарушится. Это самый очевидный и громоздкий способ. Кроме того байты здесь 32 битовые ;) Видится спооб использовать счетный семафор, написать для него процедуры установки, сброса и считывания бита по его номеру. но тоже как то не элегантно. Изменено 9 декабря, 2016 пользователем nanorobot Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
novikovfb 18 9 декабря, 2016 Опубликовано 9 декабря, 2016 · Жалоба Это ничего не даст, пмсм.. Это позволит изменять разные признаки в разных тредах не боясь при попытке одновременной модификации двух признаков (первый начал менять, прерывание, второй начал и закончил, вернулся в первый закончил и записал в ячейку только свой результат, стерев результат второго треда. Кроме того это никак не снимет необходимости упаковывать "байтовые" биты в uint16_t для отсылки мастеру. да, но при упаковке можно будет тупо пройтись и снять слепок в текущем состоянии. Опять же, если нет взаимозависимостей между битами в упакованном слове для мастера. Насколько я понимаю, запись байта - атомарная операция в микропроцессоре, а модификация бита во многих реализациях идет через временное значение в регистре (и Cortex M0 - в их числе). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nanorobot 5 9 декабря, 2016 Опубликовано 9 декабря, 2016 (изменено) · Жалоба Это позволит изменять разные признаки в разных тредах не боясь при попытке одновременной модификации двух признаков (первый начал менять, прерывание, второй начал и закончил, вернулся в первый закончил и записал в ячейку только свой результат, стерев результат второго треда. ну здраво в общем. Но наверное использовать массив бинарных семафоров будет более корректно... И да интересно, еслипроцессор имеет bit-banding для SRAM - компилятор будет его использовать для изменения отдельных битов в структуре? не думаю... Достаточно обеспечить атомарность доступа. Для этого можно просто запрещать прерывания на время записи переменной. почему то напрягает лишний раз прерывания запрещать. Такой вот предрассудок... Изменено 9 декабря, 2016 пользователем nanorobot Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 9 декабря, 2016 Опубликовано 9 декабря, 2016 · Жалоба Достаточно обеспечить атомарность доступа. Для этого можно просто запрещать прерывания на время записи переменной. Именно так, но это если в лоб. А вообще на Corteх кроме заперта прерываний, есть еще два механизма обеспечения атомарного доступа. Не считая комбинированных. То что тут начали нести про семафоры и иже с ними, есть офигительный бред в стиле через анус, а не в "стиле RTOS". почему то напрягает лишний раз прерывания запрещать. Такой вот предрассудок... Невежество :(. Вы думаете, что в вызовах всяких семафоров с мютексами нет критических секций :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nanorobot 5 9 декабря, 2016 Опубликовано 9 декабря, 2016 (изменено) · Жалоба Именно так, но это если в лоб. А вообще на Corteх кроме заперта прерываний, есть еще два механизма обеспечения атомарного доступа. Не считая комбинированных. То что тут начали нести про семафоры и иже с ними, есть офигительный бред в стиле через анус, а не в "стиле RTOS". Невежество :(. Вы думаете, что в вызовах всяких семафоров с мютексами нет критических секций :) Если Вы имели в виду BitBanding и команды LDREX/STREX то выше указано, что речь идет про cortex M0. Я в курсе про наличие критических секций в обработке мютексов и семафоров, мой "предрассудок" имеет отношение чисто к "ручному" запрету прерываний, отдавая предпочтение готовым сервисам, то есть в "стиле RTOS" . Кроме того в этом утверждении была некотороя доля (само)иронии. Касательно бреда про семафоры: С небольшой поправкой, что упаковку значений бинарных семафоров в uint_16_t выполнять в процессе с максимальным приоритетом это решение перестает быть "бредом". Спасибо, что уделили внимание моей персоне. Изменено 9 декабря, 2016 пользователем nanorobot Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 9 декабря, 2016 Опубликовано 9 декабря, 2016 · Жалоба Напрашивается вариант: любое бращение к битам состояния защищать от коллизий доступа с помощью мютекса, но nil их не имеет, а использовать для слейва полную ChibiOs - тяжеловато будет, там и требования к скорости обработки повыше и процессор послабее. Что посоветуют знатоки? Вообще не понял проблемы. Что такое здесь 'парадигма'? У меня на M0 вполне себе MQX крутится. Может вам на MQX перейти? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 9 декабря, 2016 Опубликовано 9 декабря, 2016 · Жалоба Если Вы имели в виду BitBanding и команды LDREX/STREX то выше указано, что речь идет про cortex M0. Вообще-то не только о нем. Для предельно кастрированных платформ, где даже допотопного SWP нет, остается запрет прерывания. Я в курсе про наличие критических секций в обработке мютексов и семафоров, мой "предрассудок" имеет отношение чисто к "ручному" запрету прерываний, отдавая предпочтение готовым сервисам, то есть в "стиле RTOS" . Кроме того в этом утверждении была некотороя доля (само)иронии. Мне, значит, не дано не понять :) почему вызов вызов десятков-сотен команд содержащих запреты прерывания вместо просто запрета прерывания назван Вами "без предрасудков". О критических секциях - если если в некой операционке нет оформления критических секций, то это надо дописать, либо выкинуть такую "RTOS" нафиг. Касательно бреда про семафоры: С небольшой поправкой, что упаковку значений бинарных семафоров в uint_16_t выполнять в процессе с максимальным приоритетом это решение перестает быть "бредом". Процесс это НЕ семафор. Использование возможностей высокоприоритетного процесса, это нормально. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nanorobot 5 9 декабря, 2016 Опубликовано 9 декабря, 2016 (изменено) · Жалоба Вообще не понял проблемы. Что такое здесь 'парадигма'? У меня на M0 вполне себе MQX крутится. Может вам на MQX перейти? м.б. сформулировал неудачно, но тема себя исчерпала. Вообще-то не только о нем. Для предельно кастрированных платформ, где даже допотопного SWP нет, остается запрет прерывания. Мне, значит, не дано не понять :) почему вызов вызов десятков-сотен команд содержащих запреты прерывания вместо просто запрета прерывания назван Вами "без предрасудков". О критических секциях - если если в некой операционке нет оформления критических секций, то это надо дописать, либо выкинуть такую "RTOS" нафиг. Процесс это НЕ семафор. Использование возможностей высокоприоритетного процесса, это нормально. указано что слейв-M0, далее все про слейв возможно стоит отказаться от всех сервисов РТОС, для синронизации использовать обычные переменные, запрещая , где требуется, прерывания ;) не удалось найти места, где бы я утверждал что процесс это семафор. Изменено 9 декабря, 2016 пользователем nanorobot Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 9 декабря, 2016 Опубликовано 9 декабря, 2016 · Жалоба не удалось найти места, где бы я утверждал что процесс это семафор. Но тем не менее свалили их в одну кучу: Касательно бреда про семафоры: С небольшой поправкой, что упаковку значений бинарных семафоров в uint_16_t выполнять в процессе с максимальным приоритетом возможно стоит отказаться от всех сервисов РТОС, для синронизации использовать обычные переменные, запрещая , где требуется, прерывания ;) Перестаньте противопоставлять средства предоставляемой какой то кастрированой RTOS всему спектру приемов программирования. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 9 декабря, 2016 Опубликовано 9 декабря, 2016 · Жалоба м.б. сформулировал неудачно, но тема себя исчерпала. Не думаю, тема эта долгая и еще плохо раскрытая. Я например в связке M4-M0 по SPI делаю мастером M0. Так легче релизовать риалтайм без блокировок обмена. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nanorobot 5 9 декабря, 2016 Опубликовано 9 декабря, 2016 · Жалоба Но тем не менее свалили их в одну кучу: Что не так? Есть набор бинарных семафоров, значения которых требуется "упаковать" в переменную типа uint16_t. Эту самую упаковку я собираюсь выполнять в процессе(треде, задаче) обладающем наивысшим приоритетом. Ни логических, ни грамматических ошибок не допущено. Ну, возможно, запятую пропустил. Ну так я на Пулитцеровскую премию не претендую. Будьте доброжелательнее, не упоминайте анусы всуе :laughing: Всего доброго. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 9 декабря, 2016 Опубликовано 9 декабря, 2016 · Жалоба Что не так? Есть набор бинарных семафоров, значения которых требуется "упаковать" в переменную типа uint16_t. Так это же нарушение 'парадигмы' если я ее правильно понимаю. Основной принцип RTOS - независимость задач, для того чтобы была возможность оценить их планируемость. Вы же целую кучу задач связываете между собой неким общим маршалингом. Это не RTOS, планируемости нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться