Как описывать архитектуру девайса Опции

[Hexel]

Добрый день!

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

Если конкретно, вот полная структурная схема девайса, нарисованная в визио. Компоненты в синем ящике - периферия проца, пакаджи - софтовые модули. Компоненты на свободном поле - участки схемы, в белых ящичках - коннекторы и соответствующие им входные цепи. Входа компонентов обозначены как интерфейсы (кружками), я старался размещать их слева. Например, модуль OutExt имеет процедуру SetOut, которая вызывается из модулей UserIF и Evt, и выдает наружу сигналы через выводы Ch1 и Ch2 и через периферию SPI. Местами путаница, но это промежуточный вариант, т. к. визио показался мне не самым удобным инструментом для даной задачи. Вот я и хочу спросить, кто в каком редакторе составляет такие диаграммы? Может быть, хотя бы для чисто софтовых проектов?
На мой взгляд это должен быть UML, пока что только для структуры. За описание процессов я может потом спрошу

Прикрепленные файлы

 P171207__________.pdf ( 21.75 килобайт ) Кол-во скачиваний: 105

 

[p_v]

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

Я пытаюсь объяснить довольно непростые вещи по методологии. Упрощать их до выбора редактора и тем более сталкивать в УГ лозунгами про визио не очень конструктивно. Если что-то вызывает трудности - ну переспросите, постараюсь детализировать. Это будет новая информация, от которой толку намного больше, чем от развлечений с "доказыванием правоты".

[AlexandrY]

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

Я пытаюсь объяснить довольно непростые вещи по методологии. Упрощать их до выбора редактора и тем более сталкивать в УГ лозунгами про визио не очень конструктивно. Если что-то вызывает трудности - ну переспросите, постараюсь детализировать. Это будет новая информация, от которой толку намного больше, чем от развлечений с "доказыванием правоты".

Просто я здесь не согласен категорически.

Редактор решает все!
То насколько удобно он позволяет делать то или другое определяет то, что вы в нем будете или не будете рисовать.

Это как язык программирования. Я его выбираю не из-за каких-то синтаксических возможностей, а из-за библиотек, фреймворков и IDE под него.

Показанный там вами по ссылке автомат состояний только доказывает это.
Он примитивен, он не симулируется, не параметризуется, он не обложен тестами, он не интегрирован в большую систему, никто его не прочитает, он не презентабелен и т.д.
Это по сути снипет, а не проект.
Только не надо сейчас вываливать уязвленное самолюбие, я верю что где-то там в вашей тусовке и на вас самого это производит впечатление, но попробуйте хотя бы сравнить с Simulink-ом.