Я начинаю с выбора основного вопроса из блока вопросов:
Есть ли причины использовать ОСРВ, а не один бесконечный l oop, когда все операции выполняются быстрее, чем крайний срок самый срочный?
Да, есть. Самое главное: ОСРВ - это способ разбить сложное программное обеспечение на части, которые легко (или даже тривиально!) Поддерживать. Это разделение учитывает время, которое процессор тратит на текущую часть программного обеспечения. Вы можете применять его тривиально, когда ваше программное обеспечение выполняет несколько несвязанных действий на одном процессоре / контроллере. Я хотел бы сравнить это с разделением большого монолитного исходного кода c на небольшие модули и функции, которые заботятся о небольшой части памяти и программного кода. Напротив, каждая задача RTOS заботится об одном, что должно быть сделано микропрограммой контроллера.
Это была тривиальная часть причины, и я взял на себя смелость ответить немного неточно, чтобы выделить основной момент. Теперь по менее тривиальным причинам:
Используя ОСРВ, вы также можете разделить части программного обеспечения, которые не работают независимо, но представляют различные этапы обработки от входных данных (измерений) до выходных данных (заданных значений) , В реалистичной c встроенной системе вам часто приходится заботиться о стольких требованиях, что реализация всего в одном главном l oop в конечном итоге (или по пути sh) в некотором программном коде, который вы можете запишите один раз, но вы вряд ли сможете это исправить (исправляя все меньшие и большие ошибки, распространяя программное обеспечение на некоторые новые идеи и требования), если вы вернетесь к коду более чем через неделю.
Для меня, основная мотивация использовать некоторые ОСРВ (это не обязательно должно быть freertos, но это совсем не плохо) для того, чтобы разложить монолитное программное обеспечение c на части, которые может обрабатывать моя голова.
Ваш вопрос изначально указывает на другой аспект:
Я начинаю проект, который использует [...] GUI [...]
I ' м с использованием STM32H743, работающего на 480 МГц. (Скорее, он перегружен, но всего на 1/15% дороже, чем вдвое быстрее, с меньшим объемом оперативной памяти и fla sh, что само по себе потребует внешнего fla sh за дополнительную плату.) в худшем случае - 10 мс. [...] Ни одна из [...] операций не пострадает при задержке до 20 мс.
Если отрисовка экрана была медленнее и ее нужно было прервать из-за более срочной операции, необходимость в RTOS была бы очевидна.
Вы правы, другая причина использовать RTOS - это чередование различных процессов в системе более или менее динамичным c способом, чтобы каждая задача была завершена до его срок. Я не расследовал все обстоятельства вашего конкретного случая (см. Мои слова в цитате), но я убежден, что этот аргумент не применим в вашей нынешней ситуации. Вот лишь несколько предостережений относительно этой перспективы:
Вы сравниваете конечные цены для отдельных единиц оборудования µ C, возможно, припаянных к какой-либо готовой плате eval. Это хорошая идея, я делаю то же самое для частных проектов. Но как только вы создадите профессиональное встраиваемое программное обеспечение для коммерческих продуктов, вам придется учитывать цену на несколько контроллеров (в зависимости от отрасли, от нескольких десятков до нескольких миллиардов) и цену самого µ C, поскольку он припаян. на печатную плату, которая просто соответствует продукту, который вы программируете. Тогда может случиться так, что никто не предоставит вам STM32H7-что-то, если вы действительно не докажете, что это тот класс контроллеров, который необходим для реализации всех требований к программному обеспечению.
Вы только описали нам screen / GUI, управляемый STM32, но не предназначенный для экрана. Обычно назначение устройства подразумевает некоторые требования в реальном времени к периферийным устройствам, связанным с вводом / выводом контроллера. Затем вы можете быть вынуждены обработать некоторые части вашей программы с меньшей задержкой, чем 10-20 мс. Это приводит вас сначала к использованию прерываний, затем (если вы не хотите обрабатывать каждую передачу данных между контекстами с большим количеством ручных подавлений прерываний) к использованию ОСРВ.
Возможно, я ошибаюсь, и у вас нет никаких ограничений для выполнения какой-либо реакции быстрее, чем 20 мс, или когда-нибудь заменить STM32H7 на более дешевый STM32. Тогда единственный аргумент, который остается, это обработка сложности. Конечно, вы можете попробовать go с основным l oop. Вы будете успешны, если требования достаточно просты, чтобы вы могли справиться со всеми с помощью своего рода архитектуры «все в моей голове».
Кредиты тем, кто предоставил части этого ответа в предыдущих комментариях: @Lundin, @ Clifford