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

[Hexel]

Добрый день!

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

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

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

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

 

[AlexandrY]

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

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

А рисовать в Altium-е.

[a123-flex]

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

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

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

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

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

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

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

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

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

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

[AlexandrY]

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

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

[Hexel]

Ексель - хороший вариант, но на данный момент я составляю в нем спецификацию модулей - перечень стеков, процедур, т. п. и так называемую карту переходов - по вертикали состояния устройства (вкл, работает, ошибка), а по горизонтали приходящие сигналы. На пересечении получается состояние, в которое переходит девайс (узел) в ответ на сигнал. Еще отдельно колонкой условия перехода. Потом таблица соответствий состояний узлов к состояниям верхнего уровня.
Что касается полной картины, чтоб заранее увидеть грабли, которые обычно вылазят уже на стадии кодирования/капчи (схемы)/трассировки/использования =) , то я не смог такую диаграмму придумать в екселе. Как говорится, картинка стоит тысячи слов. Мешанина теплого и мягкого вытекает из того, что девайс и есть суть такой мешанины, и в голове она как раз не помещается. Диаграмма дает возможность анализа косяков, как например, в очередной раз взглянув на представленную мной картинку, заметил кольцевание между модулями, и теперь думаю дальше, как его избежать.
Наподобие таблицы периферии я такое тоже сооружал, по ходу разработки эта таблица перерабатывается, и важно поддерживать ее актуальность.

[a123-flex]

Что касается полной картины, чтоб заранее увидеть грабли, которые обычно вылазят уже на стадии кодирования/капчи (схемы)/трассировки/использования =) , то я не смог такую диаграмму придумать в екселе. Как говорится, картинка стоит тысячи слов. Мешанина теплого и мягкого вытекает из того, что девайс и есть суть такой мешанины, и в голове она как раз не помещается.

Если Вам нужна предельно сжатая структура для облегчения восприятия, то имхо ничего лучше иерархии в природе на эту тему нет.
Желательно иметь динамическую иерархию со сворачиваемыми ветвями - например, notepad++ для кода такое делает прекрасно. И непонятно, что мешает все - и структуру и алгоритм описать текстом.

Также project libre умеет подузлы сворачивать разворачивать.

ActiveHdl ещё в своих блочных диаграммах такое умеет вроде - там и иерархию и алгоритм в картинки впихнуть можно, и они динамические - по ним ходить можно. Ну и да - альтиум.

[AlexandrY]

Что касается полной картины, чтоб заранее увидеть грабли, которые обычно вылазят уже на стадии кодирования/капчи (схемы)/трассировки/использования =) ,

Вместо MBI5039 и регистра клавиатуры я бы предложил AS1115-BSST
Все что можно перевести на локальные шины типа I2C и SPI. Подумать о сопроцессоре и расширяемости.

Общий принцип - модуляризация. Выделить и изолировать отдельные функции дивайса.
Скажем GUI я бы не рисовал на общей диаграмме.
У GUI логичнее рисовать дерево окон и меню, а не какими сигналами оно связано с другими задачами.
GUI не риалтаймная часть системы, зачем его так акцентировать.

Стейт машины рисовать в Excel тоже как-то странновато.
Их рисуют в Matlab StateFlow или на худой конец в IAR Visual State. Там хотя бы из них сразу код генерится и симулировать работу можно.
И даже так мне не удавалось долго сохранять эквивалентность этих моделей и их реализации в дивайсах.
Поскольку потом софт в дивайсе сверху донизу наполняется отладочными хуками, логами, ответвлениями, адаптерами к нижнему API и проч. оснасткой которая никак не лезет в чистые модели.

[a123-flex]

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

Это не обязательно относится к процессорному мезонину. Мне это пригодилось в управляющих платах. Да и вообще, концепция мезонина, такая прекрасная на первый взгляд, имеет недостатки: цена, габарит, теплоотвод, разьемная ёмкость, надёжность итд.

Кстати посмотрел ещё раз схему ТС - она очень даже неплоха, сильно ее не сократить.

[AlexandrY]

Это не обязательно относится к процессорному мезонину. Мне это пригодилось в управляющих платах. Да и вообще, концепция мезонина, такая прекрасная на первый взгляд, имеет недостатки: цена, габарит, теплоотвод, разьемная ёмкость, надёжность итд.

Не, главный "недостаток" здесь - это отсутствие видения горизонта разработчиком.
Если разработчик не видит свои разработки дальше чем на год или два, то он и не делает такие модули.
Но модули, конечно, свои должны быть.

[a123-flex]

Не, главный "недостаток" здесь - это отсутствие видения горизонта разработчиком.
Если разработчик не видит свои разработки дальше чем на год или два, то он и не делает такие модули.
Но модули, конечно, свои должны быть.

Вам никогда не приходит в голову, что ваши детсадовские походы уже много раз пройдены ?

Если нет, подскажу: попробуйте впихнуть в ваш разъем 900 пинов, мультигигабитную линию без ущерба длине, горячий камень, или просто процессор с бОльшим количеством выводов....

Идите в школу.

Консультировать нужно в чем хорошо разбираетесь - по крутилкам, шевелилкам и ble. А про ваши достоинства как разработчика тяжелых плат EvilWreker уже всё написал.

[AlexandrY]

Если нет, подскажу: попробуйте впихнуть в ваш разъем 900 пинов, интерфейс ddr3, мультигигабитную линию без ущерба длине, горячий камень, или просто процессор с бОльшим количеством выводов....

900 пинов эт когда вы DDR хотите сделать на одной плате, а процессор на другой, т.е. полный дурдом.
Когда дело идет к разрастанию сигналов, то делают мультипроцессорные решения.
И опять модули здесь сильно помогают.

Человек так устроен, что ему надо все редуцировать, чтобы он мог себе позволить о чем-то забывать.
Вот вы, например, забыли показать свои разработки прежде чем огрызаться.

Согласен, что модули требуют дополнительных усилий и опыта. Сам стал их применять только спустя 10 лет после начала профессиональной деятельности.

[one_eight_seven]

900 пинов эт когда вы DDR хотите сделать на одной плате, а процессор на другой, т.е. полный дурдом.

Сервера, персональные компьютеры, ноутбуки...

P.S. Топикстартеру: попробуйте yed. Прекрасен тем, что порог входа практически нулевой. Можно отдавать части работ разным специалистам в предметных областях, которые могут и не знать ничего про альтиумы и т.п. Поддерживает иерархию. В отличие от убогих визиоподобных програм имеет неограниченное рабочее поле, но при этом не требует 32 ядра и 256 гигов оперативы, чтобы программа не тормозила.

Сообщение отредактировал one_eight_seven - Jun 14 2018, 11:03

[AlexandrY]

P.S. Топикстартеру: попробуйте yed. Прекрасен тем, что порог входа практически нулевой. Можно отдавать части работ разным специалистам в предметных областях, которые могут и не знать ничего про альтиумы и т.п. Поддерживает иерархию. В отличие от убогих визиоподобных програм имеет неограниченное рабочее поле, но при этом не требует 32 ядра и 256 гигов оперативы, чтобы программа не тормозила.

Думаю тем кто пользуется Visio этот yed покажеться сломаными костылями.
В это трудно поверить, но в yed нельзя даже запастить картинку из буфера обмена.

[a123-flex]

Сервера, персональные компьютеры, ноутбуки...

Плис, коммутаторы, ацп, цап... И такие вещи тоже делают люди. И даже в России)

[one_eight_seven]

В это трудно поверить, но в yed нельзя даже запастить картинку из буфера обмена.

Ну, если не понимать, что такое yed, и не осилить чтение - то да, поверить трудно...
Ну и самое великолепное - что вставлять картинки и разрабатывать архитектуру - это совсем разные задачи.