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

[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

[wangan]

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

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

"алгоритм должен быть энергоэффективным" это что такое? чтобы не рубил пустые циклы что ли?, там где GSM, спутниковый канал, и ethernet можно не беспокоится за энергоэффективность.

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

"Как планировать, как разбивать? Как прорабатывать концепцию?" - главное чтобы было написано ТЗ, не для кого то а для себя. Каждый пункт в ТЗ это и есть твоя разбивка. А концепция построения программы такая, что если начальник скажит все вывернуть наизнанку - то ты бы смог это выполнить. Т.е универсальность и гибкость. А по поводу "Как планировать" так c утра и до вечера, а читать нужно не книжки, а форум с какими проблемами сталкивались люди при реализации подобного набора ваших датчиков и оконечных устройств (MODBUS, GSM, спутниковый канал, и ethernet)

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

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