Как спроектировать программу?, В каком виде записать алгоритм Опции

[Slash]

Здравствуйте!

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

Кто нибудь пишет программы по всем правилам - составление алгоритма, а потом просто его кодирование?
Сколько времени занимает разработка алгоритма, в каком виде его делаете?
Есть какой-нибудь критерий сложности программы, когда пора переходить на RTOS?

[dxp]

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

Никакой способ - ни нисходящего проектирования, ни восходящего, не является однозначно лучшим. Эффективность достигается при сбалансированном использовании обоих. В двух словах: все, что ясно представляется на уровне архитектуры программы, можно и нужно сразу обозначить в виде модулей/объектов - наполнение их можно будет сделать потом. Остальное (что ясно не представляется) придется делать "снизу-вверх". По мере заполнения этой части, будет появляться и понимание по недостающим частям на уровне архитектуры. Такой вот итеративный процесс.

Кто нибудь пишет программы по всем правилам - составление алгоритма, а потом просто его кодирование?

Это все зависит от... Все индивидуально. В предельном случае доводилось рисовать структурную схему программы - квадратики (модули) и стрелки (связи). Такая схема очень хорошо потом описывается на С++: квадратики - классы, стрелки - public функции-члены классов.

Есть какой-нибудь критерий сложности программы, когда пора переходить на RTOS?

Если используемая платформа без проблем тянет целевую задачу и RTOS, то применять имеет смысл всегда. ОС дает возможность использовать формализованный подход при описании потока выполнения программы, упрощая этот процесс. И с портабельностью получше получается. Все это, конечно, при наличие определенного background'а в теме RTOS.

[demiurg_spb]

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

[Dog Pawlowa]

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

[_Bill]

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

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