Разработка концепции программы для микроконтроллера Опции

[yanvasiij]

Дошёл до такого уровня, когда программа пишется не за день-два и все необходимое держишь в голове, а когда проект большой и сложный на несколько месяцев. Мне нужно средство, которое позволило бы грамотно проработать концепцию программы, спланировать работу, разбить ее на куски и т.д. То есть здесь не обойтись просто алгоритмами, нужно нечто более глобальное такое как UML. Но как применить UML к embedded на простом Си. Как составлять диаграммы классов, если у тебя их в явном виде нет как таковых, какие диаграммы из стандарта мне вообще нужны и в каком порядке мне их применять? Посоветуйте, что знаете и что сами применяете. Вообщем поделитесь опытом, буду признателен.

[yanvasiij]

А Вы поделитесь информацией о своем проекте, как что собираетесь реализовывать, и Вам посоветуют.
Иначе все будет слишком оторвано от жизни.

Ну вот, например, сейчас нужно реализовать телеметрию: передавать данные с датчиков по GSM либо по спутниковому каналу (должен уметь работать и так и так) по протоколу МЭК-104 на скаду. Датчики выполнены в виде отдельных модулей с протоколом MODBUS. Устройство автономное, на аккумуляторе, поэтому алгоритм должен быть энергоэффективным (измерил, заснул и много не кушаешь). В добавок в перспективе должны быть подключено дополнительные модули через ethernet по UDP, данные тоже должны отправляться по запросу. Конфигурирование устройства должно осуществляться по telnetу. Ну вот для начала. По отдельности пустяк, а в комплексе можно набыдлокодить за недельку, а потом никто кроме тебя поддержать это не сможет. Вот и хочется, что все было продуманно, лаконично. А как это сделать? Как планировать, как разбивать? Как прорабатывать концепцию?

Это 2-я глава, что ли? Где про блочные диаграммы, иерархию управления, интерфейс драйверов и схему модель-представление-контроллер (Model-View-Controller)?

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

Интерфейсы драйверов в стиле open-close-read-write_IOcontrol на дух не переношу. Они маскируют физику. А физику в real-time системах не замаскируешь.
Она даст о себе знать, а унифицированный интерфейс только увеличит вероятность ошибок.

Вещь под название Model-View-Controller представляет собой какой-то чистый поток разума, высшую абстракцию. Никакой практической нагрузки. Просто чтобы занять объем книги.

Ну, что же. Положим Вы меня убедили в неэффективности всего этого творчества. Тогда, что же Вы используете?

Сообщение отредактировал yanvasiij - Nov 15 2013, 04:16

[Dog Pawlowa]

А как это сделать? Как планировать, как разбивать? Как прорабатывать концепцию?

Посмотрел город. Около-"мега" строение? Но неважно.

На задачи то красиво бьется. Мастер опроса датчиков, монитор питания и заряда, конфигуратор, связь и проч.
Делаете простыми и лаконичными задачи, складывающие/берущие/конвертирующие данные из памяти, тогда будут понятны и связи между ними.

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