Рекомендации по ограничению устаревшего встроенного приложения приложением реального времени
Я беру «устаревшее» встроенное системное приложение, не совсем унаследованное, и первое, на что я обращаю внимание, это то, что я обнаружил, что во время разработки в какой-то момент временное ограничение для приложения потерялось в требовании проекта. Теперь моя задача реорганизовать его и сделать так, чтобы он был в реальном времени, как и предполагалось.
Проект выполнен для ATMEL UC3 на C и C ++. Работает на FreeRTOS, есть 6 задач. 5 для управления внешними устройствами и другое, с самым низким приоритетом и самой тяжелой задачей в качестве основной программы.
Первым делом я измерил время, затраченное на выполнение основной задачи, и неудивительно, что иногда оно выходило за рамки, поэтому вся задача выполнялась в несколько циклов.
Может кто-нибудь предложить мне, какие возможные основные моменты принять в этом случае?
Чтобы ты делал?
Я знаю, что должен следить за потоком всех путей выполнения и считать инструкции, затем выбирать худший путь выполнения и с частотой чипа даст мне выполнение в реальном времени. То есть в теории есть какой-нибудь инструмент, хитрость или процедура, чтобы сделать это немного проще?
ОБНОВЛЕНО:
Я не могу поделиться источником по конфиденциальным причинам. Кроме того, я копал глубже и обнаружил, что основные задержки, по-видимому, генерируются размером очередей. Большинство очередей созданы для хранения 2 или 3 сообщений. Мне нужно будет сделать несколько тестов, чтобы предоставить дополнительную информацию здесь. Теоретически, если очереди заполняются, то остальные процессы больше не могут отправлять, пока снова не будет свободного места для новых сообщений. Затем процессы приостанавливаются, что приводит к последовательному перепланированию. Моя идея состоит в том, чтобы увеличить размер очередей до 10, просто чтобы увидеть, улучшает ли это производительность и время.
ОБНОВЛЕНО 2
Исходя из предложений, которые мне показались очень полезными, когда я был в неведении, я наткнулся на инструмент под названием «Пойми», он не бесплатный, но помогает мне получить анализ и данные. Также вы можете увидеть поток сложных функций, поэтому вы можете увидеть самый длинный путь выполнения потока.
Решение
Приведу ответ здесь, потому что Rock ‘n Roll Racing — одна из лучших игр всех времен. Что, как говорится…
Исходя из вашей формулировки здесь, это звучит так, как будто задача, которую вы измеряете, которая обязательно должна быть выполнена в срок, является самым низким приоритетом. Это право есть назад. Вы хотите, чтобы ваша задача была гарантированно завершена, как задача с наивысшим приоритетом. Это будет первый шаг.
Если я ошибаюсь из-за того, как я читаю ваш вопрос, и ваша ветка, которая должна сделать эти сроки, является наивысшим приоритетом, то есть другие вещи, на которые стоит обратить внимание.
Убедитесь, что прерывания не отключены никакими другими задачами в течение длительных периодов, так как это повлияет на планирование потоков. Если задача с низким приоритетом отключает прерывания, а затем некоторое время вращается в цикле, у планировщика RTOS нет возможности вернуть управление и передать его высокоприоритетному потоку.
Проверьте инверсию приоритета (http://en.wikipedia.org/wiki/Priority_inversion). Если между вашим потоком с низким приоритетом и этим критическим потоком существует совместное использование ресурсов, вы можете столкнуться с ситуацией, когда даже если ваш критический поток имеет высокий приоритет, он может заблокировать ожидание завершения потока с более низким приоритетом для использования ресурса. Не уверен, что у FreeRTOS есть приоритетные мьютексы / семафоры, но это тоже можно проверить.
Другая вещь, которая, вероятно, является самым простым объяснением, — это профилирование потока. Это сложно сделать во встроенных системах, но вы можете создать какой-нибудь легкий буфер регистрации или что-то в этом роде. Узнайте, когда он иногда пропускает свой крайний срок, что отличается от этого пути кода по сравнению с тем временем, когда он делает это нормально. Возможно, вам придется найти способ ускорить некоторые из этого пути. Например, при медленном запуске это может быть запись большего количества данных, чем обычно, поэтому, возможно, измените эти записи данных, чтобы использовать DMA вместо потока, пишущего вручную.
Это не исчерпывающий список, а несколько хороших советов для начала.
Другие решения
Других решений пока нет …