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

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

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

У меня получается скорее не по вертикали, а по горизонтали.
Инициализация, далее суперлуп, на который сбоку навешиваются задачи и модули.
Для себя пришёл к выводу, что снизу вверх - всё-таки предпочтительнее для единоличного творчества и небольших проектов.
Главное - чёткое деление на максимально независимые модули и поэтапная разработка с обязательным тестированием каждого пункта.
Чтобы вышестоящие конструкции опирались на надёжный фундамент.
Ну и по мере движения вверх находятся какие-то общности, корректируется структура и т.д.
Плюс обязательное документирование! Хотя бы в тексте.

Составление алгоритма - это отнюдь не первый этап работы. Еще есть требования, деление на блоки, планирование тестирования... Почитайте что-нибудь на тему RUP или подобное.
Потом все можно моделировать в том же UML. И т.д.
Только нужно четко представлять себе, зачем все это. Самообразование при этом не самая плохая отговорка, удачи!

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


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


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

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

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

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

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