#embedded #uml #microcontroller #diagram
#встроенный #uml #микроконтроллер #диаграмма
Вопрос:
Этот вопрос связан с диаграммой программного процесса. Как инженер-электрик, большая часть программного обеспечения, которое я делаю, предназначена для встроенных микроконтроллеров. В школе мы научились иллюстрировать наш алгоритм с помощью блок-схемы. Однако в настоящее время многие из моих встроенных проектов в значительной степени управляются прерываниями, где основной процесс выполняет некоторый базовый алгоритм, стимулом для которого служат различные источники прерываний. Итак, мой вопрос в том, какие методы построения диаграмм я могу использовать для иллюстрации своего процесса, чтобы будущие разработчики могли легко понять, что я делаю, и включиться в разработку?
Вот несколько ключевых функций, которые я ищу:
- Показывает структуры данных и то, как данные передаются между процессами и прерываниями
- Показывает условия, которые вызывают каждое прерывание
- Показывает, как данные собираются и передаются по нисходящей ссылке
- Показывает, как принимаются, анализируются и выполняются командные сообщения
- В идеале хорошо подходит для иерархической разбивки на более мелкие процессы с более высоким уровнем детализации
Ответ №1:
Я всегда видел, что время прерывания отображается следующим образом:
Или встроенная строка, чтобы:
Но я предпочитаю первый, поскольку он дает больше места для аннотаций.
В ответ на ваш комментарий, возможно, диаграмма конечного автомата UML (с некоторой адаптацией) может быть более подходящей для вашей цели:
Комментарии:
1. Хотя это и полезно, я больше искал способ проиллюстрировать общую концепцию верхнего уровня того, что делает микроконтроллер. Этот тип диаграммы больше ориентирован на иллюстрацию времени выполнения отдельных прерываний, когда в моей системе есть несколько разных процедур прерывания.
2. @user2635036 Не могли бы вы, возможно, немного подробнее объяснить, что вы ищете? На верхней диаграмме показано несколько процессов, которые могут быть или не быть у вас в микроконтроллере. Но если вы забыли процессы B и C, то процесс A — это ваш
mainцикл, который прерывается IRQx, который прерывается прерыванием с более высоким приоритетом, IRQy, перед возвращением к основному циклу. Для меня это звучит как концепция верхнего уровня программы микроконтроллера, прерываемой несколькими уровнями прерывания с приоритетом.3. Что ж, эта диаграмма хорошо объясняет уровни приоритета и временную взаимосвязь между прерываниями и другими процессами. Чего это не объясняет, так это какова цель прерывания, какова цель основной функции, какие обстоятельства вызовут прерывание, какие типы входов и выходов ожидаются от uC в целом и какие интерфейсы существуют между uC и другими системами. На этой диаграмме также не показаны структуры данных и то, как данные передаются между процессами.
4. @user2635036 Теперь я понимаю. Вероятно, вам следует отредактировать свой вопрос, включив в него эту информацию, поскольку она была мне неясна и поможет вам получить более точные ответы. Я также добавил к своему ответу другой возможный тип диаграммы, который может быть полезен.
5. Это больше похоже на это. Знаете ли вы какие-нибудь хорошие (желательно бесплатные) программы для рисования диаграмм такого типа?
Ответ №2:
Есть много интересных подходов, которые вы можете найти на рисунке диаграммы. Я опубликую несколько здесь. Вы найдете там множество имен, специфичных для операционной системы и архитектуры, таких как регистр, событие, имена функций и т.д. Пока это больше для представления, верно? Итак, он и есть мы.
Ответ №3:
Используйте диаграммы классов UML для отображения структур данных. Используйте диаграммы последовательности, чтобы показать взаимодействия между классами и процедурами обслуживания прерываний (показывая только вызовы функций). Используйте диаграммы действий, чтобы показать, как прерывания взаимодействуют с процессами (сигналы хороши для этого). Диаграмма действий также может быть использована для демонстрации процесса получения данных, их анализа и отправки. Это также может быть представлено в статическом представлении диаграммой пакета, где обработчик команд находится в одном пакете, а анализатор команд — в другом, соединенные линией зависимости. Варианты использования хороши для высокоуровневого представления функциональности.
Главное, что UML поддерживает множество различных представлений (статическое, динамическое, логическое, развертывание) в вашей системе. Не пытайтесь выразить все сразу.
На схеме ниже показан пример прерывания процесса.
