Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Как сделать идеологически выдержанно, "в стиле РТОС"
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы
nanorobot
Дивайс состоит из двух узлов на STM32 связанных по SPI. Программа как для мастера так и для слейва пишется с использованием RTOS: мастер CortexM4/ChibiOS, слейв - CortexM0/nil(облегченный вариант ChibiOS). Слейв, в частности формирует слово состояния - набор битов, которое передается мастеру, а так же используется самой программой слейва. Причем биты могут использоваться в разных тредах(процессах). С точки зрения парадигмы RTOS они являются об'ектами синхронизации процессов. В этом случае они должны иметь тип BinarySemaphore с другой стороны для передачи слова состояния мастеру они(биты) должны быть упакованы в переменную типа uint16_t. Сейчас у меня используется union одно поле которого битовая структура, другое поле uint16_t. Покамест УМВР, но беспокоят возможные проблемы из за отхода от парадигмы RTOS. Напрашивается вариант: любое бращение к битам состояния защищать от коллизий доступа с помощью мютекса, но nil их не имеет, а использовать для слейва полную ChibiOs - тяжеловато будет, там и требования к скорости обработки повыше и процессор послабее. Что посоветуют знатоки?
novikovfb
Цитата(nanorobot @ Dec 9 2016, 14:08) *
Напрашивается вариант: любое бращение к битам состояния защищать от коллизий доступа с помощью мютекса, но nil их не имеет

а что он имеет?
Напрашивается вместо битов признаки разнести по разным байтам и иметь доступ к ним без коллизий, если, конечно, между битами нет взаимосвязей.
AHTOXA
Цитата(nanorobot @ Dec 9 2016, 16:08) *
Напрашивается вариант: любое бращение к битам состояния защищать от коллизий доступа с помощью мютекса, но nil их не имеет

Достаточно обеспечить атомарность доступа. Для этого можно просто запрещать прерывания на время записи переменной.
nanorobot
Цитата(novikovfb @ Dec 9 2016, 17:33) *
а что он имеет?
Напрашивается вместо битов признаки разнести по разным байтам и иметь доступ к ним без коллизий, если, конечно, между битами нет взаимосвязей.


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

Видится спооб использовать счетный семафор, написать для него процедуры установки, сброса и считывания бита по его номеру. но тоже как то не элегантно.
novikovfb
Цитата(nanorobot @ Dec 9 2016, 14:42) *
Это ничего не даст, пмсм..

Это позволит изменять разные признаки в разных тредах не боясь при попытке одновременной модификации двух признаков (первый начал менять, прерывание, второй начал и закончил, вернулся в первый закончил и записал в ячейку только свой результат, стерев результат второго треда.
Цитата(nanorobot @ Dec 9 2016, 14:42) *
Кроме того это никак не снимет необходимости упаковывать "байтовые" биты в uint16_t для отсылки мастеру.

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

Насколько я понимаю, запись байта - атомарная операция в микропроцессоре, а модификация бита во многих реализациях идет через временное значение в регистре (и Cortex M0 - в их числе).
nanorobot
Цитата(novikovfb @ Dec 9 2016, 17:56) *
Это позволит изменять разные признаки в разных тредах не боясь при попытке одновременной модификации двух признаков (первый начал менять, прерывание, второй начал и закончил, вернулся в первый закончил и записал в ячейку только свой результат, стерев результат второго треда.

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

Цитата(AHTOXA @ Dec 9 2016, 17:40) *
Достаточно обеспечить атомарность доступа. Для этого можно просто запрещать прерывания на время записи переменной.



почему то напрягает лишний раз прерывания запрещать. Такой вот предрассудок...
zltigo
Цитата(AHTOXA @ Dec 9 2016, 13:40) *
Достаточно обеспечить атомарность доступа. Для этого можно просто запрещать прерывания на время записи переменной.

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

Цитата(nanorobot @ Dec 9 2016, 14:18) *
почему то напрягает лишний раз прерывания запрещать. Такой вот предрассудок...

Невежество sad.gif. Вы думаете, что в вызовах всяких семафоров с мютексами нет критических секций sm.gif
nanorobot
Цитата(zltigo @ Dec 9 2016, 19:27) *
Именно так, но это если в лоб. А вообще на Corteх кроме заперта прерываний, есть еще два механизма обеспечения атомарного доступа. Не считая комбинированных.
То что тут начали нести про семафоры и иже с ними, есть офигительный бред в стиле через анус, а не в "стиле RTOS".


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


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

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

Спасибо, что уделили внимание моей персоне.
AlexandrY
Цитата(nanorobot @ Dec 9 2016, 13:08) *
Напрашивается вариант: любое бращение к битам состояния защищать от коллизий доступа с помощью мютекса, но nil их не имеет, а использовать для слейва полную ChibiOs - тяжеловато будет, там и требования к скорости обработки повыше и процессор послабее. Что посоветуют знатоки?


Вообще не понял проблемы. Что такое здесь 'парадигма'?
У меня на M0 вполне себе MQX крутится. Может вам на MQX перейти? biggrin.gif
zltigo
Цитата(nanorobot @ Dec 9 2016, 17:14) *
Если Вы имели в виду BitBanding и команды LDREX/STREX то выше указано, что речь идет про cortex M0.

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

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

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

nanorobot
Цитата(AlexandrY @ Dec 9 2016, 21:55) *
Вообще не понял проблемы. Что такое здесь 'парадигма'?
У меня на M0 вполне себе MQX крутится. Может вам на MQX перейти? biggrin.gif


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


Цитата(zltigo @ Dec 9 2016, 22:00) *
Вообще-то не только о нем. Для предельно кастрированных платформ, где даже допотопного SWP нет, остается запрет прерывания.

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

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



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

не удалось найти места, где бы я утверждал что процесс это семафор.
zltigo
Цитата(nanorobot @ Dec 9 2016, 18:07) *
не удалось найти места, где бы я утверждал что процесс это семафор.

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

Цитата(nanorobot @ Dec 9 2016, 18:07) *
возможно стоит отказаться от всех сервисов РТОС, для синронизации использовать обычные переменные, запрещая , где требуется, прерывания wink.gif

Перестаньте противопоставлять средства предоставляемой какой то кастрированой RTOS всему спектру приемов программирования.
AlexandrY
Цитата(nanorobot @ Dec 9 2016, 18:07) *
м.б. сформулировал неудачно, но тема себя исчерпала.


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

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




nanorobot
Цитата(zltigo @ Dec 9 2016, 23:24) *
Но тем не менее свалили их в одну кучу:


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


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


nanorobot
Цитата(AlexandrY @ Dec 10 2016, 00:07) *
Так это же нарушение 'парадигмы' если я ее правильно понимаю.
Основной принцип RTOS - независимость задач, для того чтобы была возможность оценить их планируемость.
Вы же целую кучу задач связываете между собой неким общим маршалингом.
Это не RTOS, планируемости нет.


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

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

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

Что же касаемо приоритета процесса, который делает эту упаковку, то тут всё зависит от того, насколько срочно надо отправлять статус мастеру. Если при каждом изменении, то приоритет должен быть повыше (хотя всё равно можно пропустить), но скорее всего надо просто передавать с определённой периодичностью. В этом случае приоритет неважен.
zltigo
Цитата(nanorobot @ Dec 9 2016, 19:58) *
Что не так? Есть набор бинарных семафоров, значения которых требуется "упаковать" в переменную типа uint16_t. Эту самую упаковку я собираюсь выполнять в процессе(треде, задаче) обладающем наивысшим приоритетом. Ни логических, ни грамматических ошибок не допущено.

Не наводите тень на плетень. То, что Вы собирались делать написано в Вами в первом посте:
Цитата
Напрашивается вариант: любое бращение к битам состояния защищать от коллизий доступа с помощью мютекса

Это и есть через анус. Безвариантно.
О том, что Вы сейчас повторили, я ранее уже написал:
Цитата
Использование возможностей высокоприоритетного процесса, это нормально.






AlexandrY
Цитата(nanorobot @ Dec 9 2016, 20:14) *
Так что "парадигма" не так уж сильно нарушена...


Ну если мы договорились что делаем не real-time, то у меня вот так реализован канал приема-передачи по SPI:
Код
  for (;;)
  {
    // Принимаем и отправляем данные чипу MKW40 в режиме слэйва
    // Мастер MKW40 посылает пакеты размером MKW_BUF_SZ каждые 2 мс
    // Структура пакета:
    // Номер байта   Назначение
    // в пакете
    // 0     [llid]  - идентификатор логического канала
    // 1     [LEN]   - количество передаваемых данных
    // 2     [data0] - первый байт данных
    // ...
    // LEN+2 [dataN] - последний байт данных



    if (MKW40_SPI_slave_read_write_buf(mkw_tx_buf, mkw_rx_buf, MKW_BUF_SZ) == MQX_OK)
    {
      uint8_t  llid = mkw_rx_buf[0] - 1; // Получаем номер логического канала которому предназначен пакет
      

      // Посылаем приемнику канала если он подписался на прием
      if (llid < MKW_SUBSCR_NAX_CNT)
      {
        if (MKW40_subsribers[llid].receiv_func!= 0)
        {
          MKW40_subsribers[llid].receiv_func(&mkw_rx_buf[2], mkw_rx_buf[1], MKW40_subsribers[llid].pcbl); // Вызов неблокирующей функции приемника логического канала
        }
      }

      // Загрузка новых данных для отправки
      memset(mkw_tx_buf, 0, MKW_BUF_SZ); // Предварительно очищаем буфер отправки от старых данных.
      _mutex_unlock(&mutex);
      // Здесь задачи клиенты  ожидающие мьютекса получают доступ к заполнению буфера на отправку mkw_tx_buf.
      // Получает мьютекс только одна задача в зависимости от настроек политики очереди. Остальные остаются ждать следующей возможности.  
      _mutex_lock(&mutex);
    }

  }


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

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


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

Цитата(zltigo @ Dec 10 2016, 02:33) *
Не наводите тень на плетень. То, что Вы собирались делать написано в Вами в первом посте:

Это и есть через анус. Безвариантно.
О том, что Вы сейчас повторили, я ранее уже написал:



Согласен, что первая фраза как бы не вполне. Тем не менее несколькими постами выше вы процитировали другую мою фразу, в которой якобы смешано все в кучу, собственно за нее я вступился.
Если заходить на форум, имея в качестве цели придраться к неудачной, наскоро составленной формулировке, это почти всегда можно сделать, потешив тем самым свое самолюбие.
Ваша компетентность не вызывает сомнений ни у меня(пусть для Вас это совершенно неважно), ни(я так думаю) у большинства других посетителей форума, да и Вы сами знаете себе цену. Тем более непонятно зачем Вам подобные упражнения.
На этом дискуссию заканчиваю.
С Уважением, Александр.
zltigo
Цитата(nanorobot @ Dec 9 2016, 23:35) *
Тем более непонятно зачем Вам подобные упражнения.

Плохо, что Вы "увидели" какие то "упражнения", а цели - объяснить, что как минимум наличие системных средств формирования критических секций есть принадлежность любой системы, так и не захотели увидеть sad.gif. Хотя и использование системных критических секций тоже уже избыточность для организации атомарного доступа к биту. При отсутствии у Cortex-M0 других механизмов обеспечения атомарности использование запретов прерывания является абсолютно естественным.

Теперь еще о "семафорах" - если эта куча битов которую Вы хотите передавать действительно состояние семафоров, то я могу точно сказать, что наличие сколь-нибудь заметного количества семафоров есть признак дурной реализации алгоритма sad.gif. Лет 10-15? назад с удивлением понял, что семафоры на самом деле есть своеобразные алгоритмические заплатки и можно обходиться без них практически всегда.
nanorobot
Цитата(zltigo @ Dec 10 2016, 14:16) *
Плохо, что Вы "увидели" какие то "упражнения", а цели - объяснить, что как минимум наличие системных средств формирования критических секций есть принадлежность любой системы, так и не захотели увидеть sad.gif. Хотя и использование системных критических секций тоже уже избыточность для организации атомарного доступа к биту. При отсутствии у Cortex-M0 других механизмов обеспечения атомарности использование запретов прерывания является абсолютно естественным.

Теперь еще о "семафорах" - если эта куча битов которую Вы хотите передавать действительно состояние семафоров, то я могу точно сказать, что наличие сколь-нибудь заметного количества семафоров есть признак дурной реализации алгоритма sad.gif. Лет 10-15? назад с удивлением понял, что семафоры на самом деле есть своеобразные алгоритмические заплатки и можно обходиться без них практически всегда.


Вот мы и дошли до текстов, которые можно читать. Поверьте, упоминание анусов и обвинение в невежестве - не лучший способ привлечь внимание собеседника. Обычно это преследует какие то другие цели...

Критические секции и атомарный доступ к битам: Возможно я коряво выразился, но речь шла в том числе и о том, что бы эти самые биты могли одновременно быть использованы и для организации взаимодействия между процессами, и для извещения мастера о состоянии слейва(в данном случае не как слейва SPI, а как об'екта управления).
Семафоров на самом деле не так много, они помещаются в uint8_t, применение же uint16_t вызвано лишь желанием иметь резерв, который может оказаться нелишним.
AlexandrY
Цитата(nanorobot @ Dec 10 2016, 11:30) *
Критические секции и атомарный доступ к битам: Возможно я коряво выразился, но речь шла в том числе и о том, что бы эти самые биты могли одновременно быть использованы и для организации


Ну допустим SPI работает на 10 МГц. Передача одного байта занимает 0.8 мкс
Передача 8-и байт - 6.4 мкс.
При тике операционки в 5 мс это всего около 0.1 % от пропускной способности SPI на указанной скорости.
При этом имея развитого слэйва байты можно на лету скопировать в соответствующие переменные используя scatter/gather DMA

Т.е. я например не вижу тут практической пользы от манипуляций с битами.

Такие темы как ваша мало смысла обсуждать абстрактно. Поэтому и получаете от особенно эмоциональных.
zltigo
Цитата(nanorobot @ Dec 10 2016, 11:30) *
Поверьте, упоминание анусов и обвинение в невежестве - не....

Поверьте, что в данном случае все так и есть sad.gif
Цитата
Критические секции и атомарный доступ к битам: Возможно я коряво выразился, но речь шла в том числе и о том, что бы эти самые биты могли одновременно быть использованы и для организации взаимодействия между процессами, и для извещения мастера о состоянии слейва(в данном случае не как слейва SPI, а как об'екта управления).

Это слишком заморочено по битам семафоров судить о состоянии устройства и добавляет зависимость протокола обмена от модификации алгоритмов слейва. Уже по этой причине неправильно.
AlexandrY
Цитата(zltigo @ Dec 10 2016, 23:03) *
Это слишком заморочено по битам семафоров судить о состоянии устройства и добавляет зависимость протокола обмена от модификации алгоритмов слейва. Уже по этой причине неправильно.


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

А эта ChibiOS, как известно, такая быстрая потому что игнорирует некоторые политики, например поднятие приоритетов на простых примитивах синхронизации.
Поэтому семафоры там точно плохая идея.
zltigo
Цитата(AlexandrY @ Dec 11 2016, 00:32) *
Кстати, вчера вышла интересная статья
где рассказано как на ровном месте ребята чуть не убили марсоход просто инверсией приоритетов.

Ничего нового на белом свете sad.gif. Будут семафоры, будет и борьба с инверсией, и борьба с последствиями этой борьбы sad.gif. Посему и считаю все эти семафоры и иже с ними, заплатками используемыми с осторожностью в крайнем случае.
Но в любом случае в любой программе будет минимум два бага - последний и предпоследний sm.gif. Вопрос только в их фатальности.
Понравилось только sm.gif :
Цитата
Заключение:
Глен Ривз благодарит разработчиков операционки из фирмы Wind River, за то что они разработали систему, позволяющую дебажить даже в таких аварийных ситуациях.

Это и моя реальность. Хотя очень многие потребовали послать человека на марс с компьютером и отладчиком sm.gif.
Цитата
А эта ChibiOS, как известно, такая быстрая потому что игнорирует некоторые политики, например поднятие приоритетов на простых примитивах синхронизации.
Поэтому семафоры там точно плохая идея.

Посмотрел. Мельком, но посмотрел. RTOS, как RTOS. Все даже лучше, чем в, например, uCOS у которой даже задач с одинаковыми приоритетами не существует. Так что уже есть средство в корне обойти ту же проблему инверсии приоритетов sm.gif.
AlexandrY
Цитата(zltigo @ Dec 11 2016, 10:22) *
Посмотрел. Мельком, но посмотрел. RTOS, как RTOS. Все даже лучше, чем в, например, uCOS у которой даже задач с одинаковыми приоритетами не существует. Так что уже есть средство в корне обойти ту же проблему инверсии приоритетов sm.gif.


Но не лучше MQX, в которой штатно идут средства межпроцессорного взаимодействия именно по каналу SPI laughing.gif
zltigo
Цитата(AlexandrY @ Dec 11 2016, 12:02) *
Но не лучше MQX, в которой штатно идут средства межпроцессорного взаимодействия именно по каналу SPI laughing.gif

Я считаю правильным оценивать возможности операционных систем по их ядру, а не по наличию "штатных" прибуд типа поддержек SPI, прикрученных разных библиотек или возможности запуска Microsoft Word.
jcxz
Цитата(nanorobot @ Dec 9 2016, 18:14) *
Касательно бреда про семафоры: С небольшой поправкой, что упаковку значений бинарных семафоров в uint_16_t выполнять в процессе с максимальным приоритетом
это решение перестает быть "бредом".

Добавлю ещё один способ обеспечения атомарности доступа (касательно задач, но не ISR-ов) - временный запрет шедулера. Если такое поддерживает Ваша ОС.
Хотя в Вашем случае несомненно использовать надо критические секции aka запрет прерываний.
А фобии надо преодолевать....

Цитата(zltigo @ Dec 11 2016, 11:22) *
Все даже лучше, чем в, например, uCOS у которой даже задач с одинаковыми приоритетами не существует.

Вы отстали от жизни. Откройте для себя uCOS-III. 1111493779.gif
zltigo
Цитата(jcxz @ Dec 13 2016, 23:52) *
Вы отстали от жизни. Откройте для себя uCOS-III. 1111493779.gif

О чудо! Только это не я отстал от жизни, а они. Их поезд ушел, пока они держались за свой примитивнейший шедулер и порты сделанные через анус sad.gif, появились более разумно сделанные операционки и III стал просто не интересен. Незачем пытаться входить в одну реку дважды.

AlexandrY
Цитата(jcxz @ Dec 13 2016, 23:52) *
Хотя в Вашем случае несомненно использовать надо критические секции aka запрет прерываний.


Кто-то еще запрещает прерывания в Cortex-M?

Там давно уже все уважающие себя RTOS не запрещают прерывания, а просто поднимают приоритет.
Кстати в uCOS тоже нет запрета прерываний, а есть подъем приоритета, как и в MQX.

Цитата(zltigo @ Dec 11 2016, 13:50) *
Я считаю правильным оценивать возможности операционных систем по их ядру, а не по наличию "штатных" прибуд типа поддержек SPI, прикрученных разных библиотек или возможности запуска Microsoft Word.


Хотел бы я посмотреть как линукс будут обсуждать отдельно от файловой абстракции, сетевого стека, управления памятью, загрузки ппроцессов и проч.
В MQX межпроцессорное взаимодействие это часть ядра. Там все сервисы (задачи, семафоры, ивенты...) предусматривают расположение на разных ядрах.
Так что... laughing.gif
zltigo
Цитата(AlexandrY @ Dec 14 2016, 10:35) *
Хотел бы я посмотреть как линукс будут обсуждать отдельно....

Естественно, что не обсуждают, по тому, что нынешние виндовсы с массовыми линуксами есть один комок со всеми потрохами включая не только стеки, но уже де-факто и приложения sad.gif. Только это совершенно не отрицает и нормального модульного построения систем. Тем более для кортексов M0/M3 которыми здесь Автор озаботился.
jcxz
Цитата(AlexandrY @ Dec 14 2016, 11:35) *
Там давно уже все уважающие себя RTOS не запрещают прерывания, а просто поднимают приоритет.

Приоритет чего?

Цитата(AlexandrY @ Dec 14 2016, 11:35) *
Кстати в uCOS тоже нет запрета прерываний, а есть подъем приоритета, как и в MQX.

Приоритета чего???
Кстати - в uCOS нет, но в её портах - имеется. И в порту для Cortex-M:
Код
#if OS_CRITICAL_METHOD == 3u
#define OS_CPU_SR_ALLOCATE() OS_CPU_SR cpu_sr  //Allocate storage for CPU status register
#define OS_ENTER_CRITICAL() {cpu_sr = __get_PRIMASK(); __disable_interrupt();}
#define OS_EXIT_CRITICAL()  {__set_PRIMASK(cpu_sr);}
#endif

А уже в самом ядре интенсивно пользуются эти функции.
sanny444
Цитата(nanorobot @ Dec 9 2016, 21:35) *
Все именно так.
Состояния всех семафоров мастеру знать не нужно. Требуется знать сотояние ограниченного числа именно флагов, которые для слейва играют роль семафоров, использующихся для взаимодействия между процессами. Спасибо. Чтобы осознать проблему, иногда достаточно кому то рассказать о ней.




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

Так всё-таки Вам в конкретно этой задаче над максимально быстро сообщить мастеру об изменени флагов или это периодически опрос?
Имхо, идеологически верно будет "вести"(модифицировать) переменную на самом сервере, а со слэйва присылатьсообщения об изменении состояния критических бит
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.