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

[Hexel]

Добрый день!

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

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

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

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

 

[a123-flex]

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

Я для себя стал сводить проекты в Excel-е: делаю табличку: сверху вниз тип узла, по горизонтали девайсы, в табличке количество: Spi 2 Adc 3, и тд.
Так описывается семейство устройств.

На строчку ниже удобно в похожем виде описать каждое устройство: сверху вниз тип узла (одинаково с 1), по горизонтали функция каждого конкретного канала.
Так в таблице получается как сводная информация по семейству устройств, так и расшифровка узлов каждого.

Есть проблема с иерархией: вход может быть adc с разными функциями (усилитель, делитель, сух.конт...) но пока у меня это укладывается в плоскую схему: все они подкласс In: InAdcAmp, InDiscrDiv....

При разработке семейства устройств такая схема позволяет хорошо описывать основную функцию каждого отдельного устройства, и продумывать концепцию всей линейки.

Родился этот подход из таблицы для всех девайсов, которые стояли в очереди на разработку (их в какой-то момент стало много).
Когда все потребности сведены в такую таблицу, она хорошо показывает, где можно малой кровью сделать одну универсальную плату на несколько устройств, а где неизбежно придется делать несколько плат, тк требования по ресурсам несовместимые: меняя столбцы местами, можно скомпоновать таблицу так, что она разобьется на явные подгруппы: рядом будет стоять то что хорошо совпадает, и будет несколько сильно разных подгрупп.

Набор узлов, их функции, и алгоритм их работы ИМХО на схеме совмещать бессмысленно: они хоть и связаны, но суть и производные, соотв. складывать их вместе теплое с мягким.

Я описал алгоритм для устройств одноранговых, простых. Как правильно заметил AlexandrY в случае сложных устройств требуется иерархия. К сожалению в связи со спецификой ПП, при переходе к трассировке все иерархии складываются в один уровень.

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

Я имею в виду, что нормальные иерархические блоки: схема+плата я не видел ни в альтиуме ни в менторе, а кэденс мы увы не разумеем(

[AlexandrY]

Когда все потребности сведены в такую таблицу, она хорошо показывает, где можно малой кровью сделать одну универсальную плату на несколько устройств,

Кстати да, хороший вариант.
Сделать универсальный процессорный модуль и сделать в нем базовый программный фреймворк с RTOS, GUI, FS, RF, CAN и проч.
Тогда и диаграммы станут очень компактными и софт будет просто небольшой надстройкой над фреймворком
А новые платы типа такой можно будет шлепать каждые две недели.