[nanorobot 3]

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

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

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

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

 

парадигма маршалинга это серьезно... :blink:

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

 

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

 

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

Изменено 9 декабря, 2016 пользователем nanorobot

[AHTOXA 14]

Если отвлечься от вопроса, зачем мастеру знать состояние семафоров ведомого, то тут всё достаточно прозрачно.

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

А для мастера - это просто некие флаги. Которые вполне можно упаковать в uint16_t (и даже в uint32_t), и передать любым имеющимся способом.

 

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

[zltigo 0]

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

Не наводите тень на плетень. То, что Вы собирались делать написано в Вами в первом посте:

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

Это и есть через анус. Безвариантно.

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

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

 

 

 

 

 

 

[AlexandrY 3]

Так что "парадигма" не так уж сильно нарушена...

 

Ну если мы договорились что делаем не 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 3]

Если отвлечься от вопроса, зачем мастеру знать состояние семафоров ведомого, то тут всё достаточно прозрачно.

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

А для мастера - это просто некие флаги. Которые вполне можно упаковать в uint16_t (и даже в uint32_t), и передать любым имеющимся способом.

 

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

 

Все именно так.

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

 

Не наводите тень на плетень. То, что Вы собирались делать написано в Вами в первом посте:

 

Это и есть через анус. Безвариантно.

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

 

 

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

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

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

На этом дискуссию заканчиваю.

С Уважением, Александр.

Изменено 9 декабря, 2016 пользователем nanorobot

[zltigo 0]

Тем более непонятно зачем Вам подобные упражнения.

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

 

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

 

[nanorobot 3]

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

 

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

 

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

 

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

Семафоров на самом деле не так много, они помещаются в uint8_t, применение же uint16_t вызвано лишь желанием иметь резерв, который может оказаться нелишним.

 

[AlexandrY 3]

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

 

Ну допустим SPI работает на 10 МГц. Передача одного байта занимает 0.8 мкс

Передача 8-и байт - 6.4 мкс.

При тике операционки в 5 мс это всего около 0.1 % от пропускной способности SPI на указанной скорости.

При этом имея развитого слэйва байты можно на лету скопировать в соответствующие переменные используя scatter/gather DMA

 

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

 

Такие темы как ваша мало смысла обсуждать абстрактно. Поэтому и получаете от особенно эмоциональных.

[zltigo 0]

Поверьте, упоминание анусов и обвинение в невежестве - не....

Поверьте, что в данном случае все так и есть :(

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

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

[AlexandrY 3]

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

 

Кстати, вчера вышла интересная статья

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

А о более поздних марсоходах была инфа о багах вызванных отсутствием синхронизации где надо было.

 

А эта ChibiOS, как известно, такая быстрая потому что игнорирует некоторые политики, например поднятие приоритетов на простых примитивах синхронизации.

Поэтому семафоры там точно плохая идея.

 

[zltigo 0]

Кстати, вчера вышла интересная статья

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

Ничего нового на белом свете :(. Будут семафоры, будет и борьба с инверсией, и борьба с последствиями этой борьбы :(. Посему и считаю все эти семафоры и иже с ними, заплатками используемыми с осторожностью в крайнем случае.

Но в любом случае в любой программе будет минимум два бага - последний и предпоследний :). Вопрос только в их фатальности.

Понравилось только :) :

Заключение:

Глен Ривз благодарит разработчиков операционки из фирмы Wind River, за то что они разработали систему, позволяющую дебажить даже в таких аварийных ситуациях.

Это и моя реальность. Хотя очень многие потребовали послать человека на марс с компьютером и отладчиком :).

А эта ChibiOS, как известно, такая быстрая потому что игнорирует некоторые политики, например поднятие приоритетов на простых примитивах синхронизации.

Поэтому семафоры там точно плохая идея.

Посмотрел. Мельком, но посмотрел. RTOS, как RTOS. Все даже лучше, чем в, например, uCOS у которой даже задач с одинаковыми приоритетами не существует. Так что уже есть средство в корне обойти ту же проблему инверсии приоритетов :).

[AlexandrY 3]

Посмотрел. Мельком, но посмотрел. RTOS, как RTOS. Все даже лучше, чем в, например, uCOS у которой даже задач с одинаковыми приоритетами не существует. Так что уже есть средство в корне обойти ту же проблему инверсии приоритетов :).

 

Но не лучше MQX, в которой штатно идут средства межпроцессорного взаимодействия именно по каналу SPI :laughing:

[zltigo 0]

Но не лучше MQX, в которой штатно идут средства межпроцессорного взаимодействия именно по каналу SPI :laughing:

Я считаю правильным оценивать возможности операционных систем по их ядру, а не по наличию "штатных" прибуд типа поддержек SPI, прикрученных разных библиотек или возможности запуска Microsoft Word.

[jcxz 184]

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

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

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

Хотя в Вашем случае несомненно использовать надо критические секции aka запрет прерываний.

А фобии надо преодолевать....

 

Все даже лучше, чем в, например, uCOS у которой даже задач с одинаковыми приоритетами не существует.

Вы отстали от жизни. Откройте для себя uCOS-III. :1111493779:

[zltigo 0]

Вы отстали от жизни. Откройте для себя uCOS-III. :1111493779:

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