Ну-ка, ну-ка... Флагами у вас автоматы информацию не передают, переменную состояния друг друга не трогают (для тех, кто замучен моделью OSI - не записывают) .
Так каким же святым духом они взаимодействуют?

Не передергивайте, я протестовал против придуманного Вами понятия " напрямую меняет" неведомо что для Вас означающего. Посему уже третий раз повторяю:

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

Для тех, для кого в мире нет ничего, кроме нескольких моторчиков, ссылка на один (первый попавшийся) из нижних уровней - LAPВ :https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.25-199610-I!!PDF-E&type=items
В стандарт уже описан с терминах конечного автомата.

Интересно что вы курите.
В этом стандарте нет ни одного! упоминания таких терминов как finite-state machine (FSM) или finite-state automaton (FSA), finite automaton, или просто state machine

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

Какой ужас! А то, что в нем разрисованы "state diagrams" и соответственно состояния конечного автомата переходы между состояниями, это уже не доступно пониманию чукчи-писателя .

Это Вы у себя в голове, возможно чего-то взводите.

Себя поздравьте с уже третьей безуспешной попыткой приписать свои глупости c какой то "прямой записью" мне.

Я за свои 55 лет написал и сопровождаю, достаточно много конечных автоматов, причем и весьма сложных (не по тому, что они дурно написано, а по тому, что объекты сложные), а не для запустить остановить пару моторчиков. Так что методика программирования конечных автоматов у меня обработана. Мозг на месте. То, что Вам с бухты-барахты удалось даже для моторчика родить уродливый конечный автомат - верю. Конечные автоматы должны быть изначально спроектированы тщательно, после чего, как не удивительно , достаточно легко пишутся и очень четко работают. Нежели же попытаться наскоком чего то там начать писать и латать рассматривая результат не работы под отладчиком, то лепя заплатки, ничего хорошего не получится.

Вау, 32К. Шутка ли! Это ж целая тыща строк! Сложно! </sarcasm>
Серьезно, однако, если вам это сложно надо учиться. Это не то что не сложно, это просто ни о чем. 1000 строк это на неделю работы.

Не нужно вам на 8ми битнике ни OOП ни С++. То что вы описали, это примитивные программы с простейшей логикой. Если вы не можете это эффективно на С выразить, промочки вам будут только усложнять жизнь. С должно быть вполне достаточно. Универсальных советов тут быть не может. Может с опытом придет )) Может надо поработать с кем-то и поучиться

Почитал ваши посты дальше. В принципе, наверное, вы на правильном пути, раз уже сами пришли к тем же выводам.
Я бы посоветовал вам почитать "Clean code <...>" by Martin. Ничего такого, но много правильных советов по поводу того, как делать программу более понятной и читаемой. В остальном вам поможет только "опыт, сын ошибок трудных"

Я нахожусь в соответствующем разделе и задаю вопросы не для того чтоб услышать что мол мало знаю! Это и так ясно, по-крайней мере для меня. Но справедливости ради тысяча строк это в моем проекте один "с" файл из 30ти! И это если не считать USB драйвера (LUFA библиотека. Там наверное как минимум дясять-15 тыс строк).
Таким образом, Вы "дыманули" ориентировочно на два порядка. Мне было бы стыдно за такие оценки и отношение к вопросу.
И снова оговорюсь: речь идет о сложности для меня, для вас это может быть и легко, но судя по всему с некоторыми исключениями

Гы, ну так я же исхожу из того, что вы написали. Написали бы 30 тыщ чтобы не надо было додумывать. К слову, библиотеку-то вы не считайте. Она же для вас только black box.

Вот я бы на Вашем месте извинился. Так принято поступать если ошибся. Посмотрим на что Вы годны

Дык, комментарии и пустые строки тоже не считаются. А то можно в подобной фигне насчитать

☺

P.S. А 1000 строк — это все-таки не неделя. Зависит от сложности. Я вот сегодня за 4 часа написал сотню строк. Теперь уже второй час сижу, не понимаю, чего оно сегфолтится (простая комповая утилитка с кучей malloc/free).

Сообщение отредактировал Эдди - Jan 10 2017, 14:38

Комменты как раз считаются. Это важная часть программы.
Раз на раз не приходится, и да, зависит от сложности. У меня за последние две недели вышло по тыще за неделю, и это я еще и другой работой занимался ).

Буратино, у меня ошибки не было.

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

Пример: сравните варианты:



Если следить за этим, такое преобразование очень часто возможно.
Код получается более линейным и понятным

Сори, а зачем int TimeCountУ ? А зачем его определять ноликом? А зачем скобки в первом случае!? И мне кажется можно и нужно проще записать все это. Или я ошибаюсь!?

Сообщение отредактировал Herz - Jan 10 2017, 18:39

На месте do some stuff подразумевается код, который исполняется раз в 10 вызовов. В первом случае скобки нужны чтобы этот код был внутри if.

Перепишите проще, даже интересно.

А зачем тогда точка с запятой нужна? Я плохо ориентируюсь в таких моментах.

Это я к тому, что разнообразные функции таймеров:

это тоже общая унифицированная часть и рожать на каждое использование таймера чего то заново неразумно

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