Mahagam 0 20 января, 2015 Опубликовано 20 января, 2015 · Жалоба Aner, фриртос действительно тормознее других переключалок. в некоторых моментах - существенно. после одного из таких сравнений задали вопрос автору. в итоге в лицензии фриртос появился пункт запрещающий её сравнивать с другими ))) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dimonomid 0 20 января, 2015 Опубликовано 20 января, 2015 · Жалоба Ну, и были случаи когда только мьютекс помогал задаче гарантированно выполниться до deadline? Уж конечно я не измерял, т.к. для блокировки ресурсов всегда сразу использую корректный объект синхронизации (мютекс), но назовите мне причину, по которой я должен оставлять потенциальную возможность инверсии приоритетов? Т.е. ваш код не отрабатывает аварийные ситуации, пилит и пилитдальше не смотря ни на что? А у других 90% кода это сплошь обработка аварийных ситуаций знаете-ли, иначе сертификацию не пройдут. Конечно обрабатывает, только называть удаление задачи способом "разблокировать мютекс" и говорить, что, дескать, значит семафор и мютекс это одно и то же - некорректно, т.к. для семафора ожидание и сигнализирование из разных задач - рабочая ситуация, а для мютекса - крайняя и аварийная. И приведите пожалуйста примеры, когда вы используете удаление задачи в качестве разрешения нештатной ситуации? Не будем наделять задачи разумом, а скажем так - при вызове функции уничтожения задачи происходит уничтожение и всех объектов синхронизации которые были привязаны к ней. Уничтожение задачи можно вызвать и из другой задачи. Это стандартный подход в развитых RTOS, в MQX в частности. Единственный объект синхронизации, привязанный к задаче - мютекс. Например, выделенная из TN_FMem или вообще из кучи память никак не привязывается к задаче (т.к. память легко может быть выделена в одной задаче, а освобождена в другой), так что удаление задачи, выделяющей память динамически, может привести к утечке памяти. Хотя, конечно, не удивлюсь, если вы и динамическое выделение памяти не используете. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
becopt 0 20 января, 2015 Опубликовано 20 января, 2015 (изменено) · Жалоба Спасибо! Будем смотреть. А тесты в открытом доступе имеются? Добавлено: Нашел в документации, отдельный репозиторий (: Изменено 20 января, 2015 пользователем Valentine Loginov Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dimonomid 0 20 января, 2015 Опубликовано 20 января, 2015 · Жалоба А тесты в открытом доступе имеются? В доке на странице "Unit tests" в конце указано, где взять тесты: http://dfrank.bitbucket.org/tneokernel_api...unit_tests.html Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aner 3 20 января, 2015 Опубликовано 20 января, 2015 · Жалоба Aner, фриртос действительно тормознее других переключалок. в некоторых моментах - существенно. после одного из таких сравнений задали вопрос автору. в итоге в лицензии фриртос появился пункт запрещающий её сравнивать с другими ))) кроме bla-bla-bla пример тормознутости в студию! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
LightElf 0 20 января, 2015 Опубликовано 20 января, 2015 (изменено) · Жалоба Хотя, конечно, не удивлюсь, если вы и динамическое выделение памяти не используете. Да, многие не используют динамическое распределение памяти в embedded системах. Одна из холиварных тем. :smile3009: Но кучи в системах высокой ответственности - однозначное зло. :maniac: Изменено 20 января, 2015 пользователем LightElf Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dimonomid 0 20 января, 2015 Опубликовано 20 января, 2015 · Жалоба Но кучи в системах высокой ответственности - однозначное зло. :maniac: Куча - согласен, зло, т.к. поведение недетерминировано. Но кроме кучи есть другие инструменты для динамического распределения памяти - например, TN_FMem (и аналоги в других ядрах). Это - не зло Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 20 января, 2015 Опубликовано 20 января, 2015 · Жалоба Уж конечно я не измерял, т.к. для блокировки ресурсов всегда сразу использую корректный объект синхронизации (мютекс), но назовите мне причину, по которой я должен оставлять потенциальную возможность инверсии приоритетов? Если вы не анализируете условия RMA, то не знаете плохо или хорошо вдруг низкоприоритетной задаче поднимать приоритет. А по сути именно это происходит при захвате мьютекса самой низкоприоритетной задачей. Тогда вопрос - почему она была сделана низкоприоритетной? Предположу что мьютексы используете для коротких участков доступа к глобальным данным. Вот это и есть излишество. Получается чтобы защитить доступ длительностью в доли микросекунды применяются сервисы в десять раз более длинные. Для этого в RTOS применяется гораздо более эффективный механизм - изменение уровня разрешенных прерываний. Конечно обрабатывает, только называть удаление задачи способом "разблокировать мютекс" и говорить, что, дескать, значит семафор и мютекс это одно и то же - некорректно, т.к. для семафора ожидание и сигнализирование из разных задач - рабочая ситуация, а для мютекса - крайняя и аварийная. И приведите пожалуйста примеры, когда вы используете удаление задачи в качестве разрешения нештатной ситуации? Во первых половину задач я создаю динамически. Их цель выполнить операцию и прекратить свое существование. Например дали команду с клавиатуры сложному механизму выполнить определенное движение. На запуск движения (еще не на само движение) создается задача. Движение сложного механизма сопряжено с выполнение многих подготовительных действий. Это управление элементами индикации: лампочки, бузера; включение или выключение каких-то соленоидов, активация вспомогательных приводов и проч. и проч. И вот если какая либо из этих мелочей по ходу не сработает или не даст подтверждения происходит аварийная выгрузка задачи. В MQX это будет просто команда return errorcode. И все! Все мьютексы, семафоры, флаги, блоки памяти занятые этой задачей будут освобождены автоматически. Никаких хлопот. Единственный объект синхронизации, привязанный к задаче - мютекс. Например, выделенная из TN_FMem или вообще из кучи память никак не привязывается к задаче (т.к. память легко может быть выделена в одной задаче, а освобождена в другой), так что удаление задачи, выделяющей память динамически, может привести к утечке памяти. Хотя, конечно, не удивлюсь, если вы и динамическое выделение памяти не используете. Не возводите только в ранг стандарта то, что сами себе придумали. Как написал выше в развитых RTOS это не так. Кстати советую подумать зачем мьютексы нужны в Windows если это не система реального времени и на инверсию приоритетов... ну она там точно не важна. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Mahagam 0 20 января, 2015 Опубликовано 20 января, 2015 · Жалоба кроме bla-bla-bla пример тормознутости в студию! померло за давностью лет. нашлась только ссылка на обсуждение http://www.microchip.com/forums/m279201.aspx там есть а пара картинок, где виден слив, и приходит сам автор фриртоса, который заявил что вы неправильно тестите, но "правильных" результатов так и не показал. собственно, на первой же странице обсуждения и видны все графики и табличка, что попали в статью, которая уже и исчезла Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
den_po 0 20 января, 2015 Опубликовано 20 января, 2015 · Жалоба Не возводите только в ранг стандарта то, что сами себе придумали. Как написал выше в развитых RTOS это не так. а потолок "развитости" есть? и потребляемых вместе с этой развитостью ресурсов Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aner 3 20 января, 2015 Опубликовано 20 января, 2015 · Жалоба померло за давностью лет. нашлась только ссылка на обсуждение http://www.microchip.com/forums/m279201.aspx там есть а пара картинок, где виден слив, и приходит сам автор фриртоса, который заявил что вы неправильно тестите, но "правильных" результатов так и не показал. собственно, на первой же странице обсуждения и видны все графики и табличка, что попали в статью, которая уже и исчезла Да блин 2007 год, крутое обсуждения незнамо чего. И по вашему с той поры Free RTOS просто замёрз и не разу не менялся и новых версий никто не видел. Так шта все это бла-бла-бла. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dimonomid 0 20 января, 2015 Опубликовано 20 января, 2015 · Жалоба Предположу что мьютексы используете для коротких участков доступа к глобальным данным. Мда, интересно, из чего вы сделали такой вывод? Я вам приводил примеры использования мютексов для работы с флешкой, вы говорите про глобальные данные. Когда это разумно, конечно я использую критические секции. Все мьютексы, семафоры, флаги, блоки памяти занятые этой задачей будут освобождены автоматически. Никаких хлопот. Подход, когда задача грохается из другой задачи в штатном режиме работы, я не могу назвать хорошим стилем. Пусть оно все работает и ваша ртос за вами приберет, я считаю что это говнокод. Но я наверное слишком идеалист для эмбеддерства и вообще не прав. Не возводите только в ранг стандарта то, что сами себе придумали. Как написал выше в развитых RTOS это не так. Ок, выделения памяти и какие-то другие вещи, действительно, в разных ядрах реализованы по-разному. Но принципы реализации мютексов и семафоров были придуманы очень давно и не мной. Так что это не я "сам себе придумал", но для вас ведь это не аргумент. Как вы сказали, "разработчики потратили на мьютексы уйму времени, а зачем они нужны в жизни не знают". Но те, кто потратили уйму времени, и те, кто не знают зачем они нужны - это все-таки разные люди. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Mahagam 0 20 января, 2015 Опубликовано 20 января, 2015 · Жалоба Да блин 2007 год, крутое обсуждения незнамо чего. И по вашему с той поры Free RTOS просто замёрз и не разу не менялся и новых версий никто не видел. Так шта все это бла-бла-бла. пока в лицензии на фриртос есть строка о запрете сравнения - фриртос можно считать тормознутым. на том форуме можно найти и технологию тестирования, и вопреки лицензии фриртоса таки сравнить его с другими шедулерами, а без сравнения говорить о том что он таки догнал остальных - то самое bla-bla-bla. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aner 3 20 января, 2015 Опубликовано 20 января, 2015 · Жалоба Шизу про догнал развивать не стоит. Я о тормозах и сравнении то о чем писали. Ссылка ни как не убедила. Возможно это еще и от арх проца зависит. Я от Микрочипа отошел давно в сторону Кортексов. Быстрее писать, отлаживать, дешевле стоит, меньше затрат, удобнее. Хотя кто как привык. TNeo возможно востребованее будет на пиках, и арх проца не последнне дело в этой оси. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 21 января, 2015 Опубликовано 21 января, 2015 · Жалоба Мда, интересно, из чего вы сделали такой вывод? Я вам приводил примеры использования мютексов для работы с флешкой, вы говорите про глобальные данные. Когда это разумно, конечно я использую критические секции. Подход, когда задача грохается из другой задачи в штатном режиме работы, я не могу назвать хорошим стилем. Пусть оно все работает и ваша ртос за вами приберет, я считаю что это говнокод. Как вы сказали, "разработчики потратили на мьютексы уйму времени, а зачем они нужны в жизни не знают". Но те, кто потратили уйму времени, и те, кто не знают зачем они нужны - это все-таки разные люди. Ваш пример с SPI тоже не отличается прямизной. Для таких дел специально созданы сервисы очередей. Зачем задачам которые должны абстрагироваться от аппаратуры лазить в SPI, разбираться с адресами , данными? Это означает подкладывание под свой софт мины межплатформенной несовместимости. Если на такую архитектуру софта рассчитана ваша RTOS, то я конечно дальше обсуждать не буду. Но в целом создается впечатление, что некоторые мьютексы реализуют просто ради моды, коньюнктуры. Nucleus Plus стоит на 3-х миллиардах дивайсов и не имеет мьютексов. Это должно кое о чем говорить. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться