Перейти к содержанию

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

Добрый день!

 

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

 

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

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

P171207__________.pdf

Поделиться сообщением


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

Ощущение что нет гармонии.

Соседствуют несоразмерные по уровню абстракции блоки. Где-то детализировано до уровня названий сигналов, а где-то сложные блоки типа инвертера без всякой детализации.

Лучше сделать нисходящую иерархию диаграмм по степени детализации.

Причем софт отделить от железа.

 

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

 

Поделиться сообщением


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

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

Так описывается семейство устройств.

 

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

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

 

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

 

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

 

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

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

 

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

 

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

 

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

А дальше печатная плата, наложив свои ограничения, скорее всего, заставит каждый раз перетрассировать все заново.

 

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

Поделиться сообщением


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

Кстати да, хороший вариант.

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

Тогда и диаграммы станут очень компактными и софт будет просто небольшой надстройкой над фреймворком

А новые платы типа такой можно будет шлепать каждые две недели.

post-2050-1528956566_thumb.jpg

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Наподобие таблицы периферии я такое тоже сооружал, по ходу разработки эта таблица перерабатывается, и важно поддерживать ее актуальность.

Поделиться сообщением


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

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

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

 

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

 

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

Поделиться сообщением


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

Вместо MBI5039 и регистра клавиатуры я бы предложил AS1115-BSST

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

 

Общий принцип - модуляризация. Выделить и изолировать отдельные функции дивайса.

Скажем GUI я бы не рисовал на общей диаграмме.

У GUI логичнее рисовать дерево окон и меню, а не какими сигналами оно связано с другими задачами.

GUI не риалтаймная часть системы, зачем его так акцентировать.

 

Стейт машины рисовать в Excel тоже как-то странновато.

Их рисуют в Matlab StateFlow или на худой конец в IAR Visual State. Там хотя бы из них сразу код генерится и симулировать работу можно.

И даже так мне не удавалось долго сохранять эквивалентность этих моделей и их реализации в дивайсах.

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Кстати да, хороший вариант.

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

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

 

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

Поделиться сообщением


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

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

Если разработчик не видит свои разработки дальше чем на год или два, то он и не делает такие модули.

Но модули, конечно, свои должны быть.

Поделиться сообщением


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

Если разработчик не видит свои разработки дальше чем на год или два, то он и не делает такие модули.

Но модули, конечно, свои должны быть.

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

 

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

 

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

 

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

Поделиться сообщением


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

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

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

И опять модули здесь сильно помогают.

 

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

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

 

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

 

Поделиться сообщением


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

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

 

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

Изменено пользователем one_eight_seven

Поделиться сообщением


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

Думаю тем кто пользуется Visio этот yed покажеться сломаными костылями.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Сервера, персональные компьютеры, ноутбуки...

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

Поделиться сообщением


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

Ну, если не понимать, что такое yed, и не осилить чтение - то да, поверить трудно...

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти