На пол пути к конечному автомату для Arduino. Однопроходные функции и фиксация событий программы с помощью флагов

Предлагаю машину состояний с явным указанием состояний.
И Шалыто А.А. будет рад.

/*-----------------------------------------------------------------------------------------------------
   Автомат состояний выходных сигналов (на основе машины состояний)

  \param tnow  - текущее машинное время в тактах процессора
-----------------------------------------------------------------------------------------------------*/
void Outputs_state_automat(T_sys_timestump *tnow)
{
    for (uint32_t n = 0; n < OUTPUTS_NUM; n++) {
        OutputControlBlock *block = &outs_cbl[n];

        switch (block->state) {
            case OUTPUT_STATE_IDLE:
                if (block->active && block->start_pattern_ptr != NULL) {
                    block->state = OUTPUT_STATE_START;
                }
                break;

            case OUTPUT_STATE_START:
                block->curr_pattern_ptr = block->start_pattern_ptr;
                block->state = OUTPUT_STATE_NEXT;
                break;

            case OUTPUT_STATE_NEXT:
                if (block->curr_pattern_ptr == NULL) {
                    block->state = OUTPUT_STATE_RESET;
                    break;
                }
                block->output_state = *block->curr_pattern_ptr;
                block->curr_pattern_ptr++;
                block->state_duration = *block->curr_pattern_ptr;
                block->curr_pattern_ptr++;
                block->state = OUTPUT_STATE_SET_OUTPUT;
                break;

            case OUTPUT_STATE_SET_OUTPUT:
                Set_output_state(n, block->output_state);
                memcpy(&block->last_timestump, tnow, sizeof(T_sys_timestump));
                if (block->state_duration == 0) {
                    block->state = OUTPUT_STATE_REPEAT;
                } else {
                    block->state = OUTPUT_STATE_WAIT;
                }
                break;

            case OUTPUT_STATE_WAIT:
                {
                    uint32_t dt = Timestump_diff_to_msec(&block->last_timestump, tnow);
                    if (dt >= block->state_duration) {
                        block->state = OUTPUT_STATE_NEXT;
                    }
                }
                break;

            case OUTPUT_STATE_REPEAT:
                block->curr_pattern_ptr = block->start_pattern_ptr;
                block->state = OUTPUT_STATE_NEXT;
                break;

            case OUTPUT_STATE_END:
                if (block->repeat_flag) {
                    block->repeat_flag = 0;
                    block->state = OUTPUT_STATE_REPEAT;
                } else {
                    block->state = OUTPUT_STATE_RESET;
                }
                break;

            case OUTPUT_STATE_RESET:
                block->active = 0;
                block->start_pattern_ptr = NULL;
                block->state = OUTPUT_STATE_IDLE;
                break;

            default:
                block->state = OUTPUT_STATE_IDLE;
                break;
        }
    }
}

На пол пути к конечному автомату для Arduino. Однопроходные функции и фиксация событий программы с помощью флагов

Хороший слог, а какой красивый код!

А если в названии указать и значение?
#define PORT_RED_12 12
#define PORT_YELLOW_11 11
#define PORT_GREEN_10 10

Знакомство с TypeScript: базовая типизация и ключевые возможности

Оценил TypeScript после понимания, что троица:
- присвоение
- ветвление
- цикл
попадая в руки программиста и есть генератор ошибок.
Даже машина управляющих состояний не справляется - её же делает человек.

И типобезопасность отсекла много степеней свободы ошибкам.

Вначале сильно не привычно - прописал тип - насладись ошибками :-) (и зачем связался с этими типами!).
Теперь радуюсь - типозащищённость следит за мной.

Небольшой конкурс хокку на айтишную тематику

Включил компьютер -
Код шепчет непонятные песни ...
Услышу ли хлопок одной ладони.

Открыл VS Code -
Хочу понять код ...
Заварю чай - первый коммит.

Смотрю на код ...
Или код смотрит на меня.
Подойду к окну.

Осенью хокку
удивил нейросеть.
ИИ меня похвалил.
Это вам не прыжок лягушки.

Построение архитектуры с использованием формальных моделей безопасности

Интересует Ваше мнение на такой тезис:

Разработку начать с моделирования поведения , а не структуры (DFD).

1. Машина состояний первична: Она определяет требования к поведению системы, ее отказоустойчивости и безопасности на фундаментальном уровне.

2. DFD вторична: Она разрабатывается для реализации требуемого поведения, описанного в машине состояний.

3. DFD — это частная проекция машины состояний: Это представление системы с точки зрения потоков данных, "вычитанное" из полного описания поведения. Попытка сделать наоборот (вывести поведение из структуры) является неполной и ведет к архитектурным ошибкам, пропуску критических состояний и уязвимостей.

Вайбкодинг мертв. На смену пришло агентное роевое программирование

Если спросите меня подскажу, я не гугл, я добрый.

Вайбкодинг мертв. На смену пришло агентное роевое программирование

Да, вспомнил мастера керамики из Монголии, тарелки которого хотят украсть.

Вайбкодинг мертв. На смену пришло агентное роевое программирование

Жду обсуждения методов проектирования программ ...

От Intel 086 до нейросетей: исповедь охотника за бизнес-процессами

"1. Размер. Схема становится большой."

Не нравятся схемы - повесьте на стену спортзала Ваш код.
Поймут ли Вас стейкхолдеры?

Есть же презентационная техника - по схеме можно перемещаться, масштабировать.

"2. Модификация схемы. Как только возникла нужда вставить элемент, особенно в основание схемы - возникает проблема это все перерисовать, сместить и т.п."

Как раз редакторы ДРАКОН и задуманы для упрощения модификаций схем, причём они и не позволят нарисовать "неправильно" схему ДРАКОН.

"3. Как раз таки достаточность / избыточность и рентабельность."

Это проблема не задействующих визуальное мышление.
Они гоняют в уме код.
И забывают, что есть редакторы ДРАКОН, генерирующие код из схем.
Да, код получается специфичный, но код же для компьютера, он не против.
Постепенно, Вы будете проводить в коде меньше времени.

"5. А главное - "а дальше что". "
Если рисовали схемы не для генерации кода, то всё равно лучше со схемой, чем без схемы.
А если ради код, то теперь у Вас есть код программы.
Который обновится, при изменении программы.
Но придётся запретить редактировать код вне схем ДРАКОН - и это самое сложное, но другого выхода пока не придумал.

Привыкших к дифф - если используете редактор ДРАКОНА Степана Митькина, который хранит схемы в формате drn, то придётся написать преобразователь в текстовый формат.

От Intel 086 до нейросетей: исповедь охотника за бизнес-процессами

Как обычно, восхищён Вашей эрудицией.
Сам то я из деревни - слаще морковки ничаво не едал.

Греет душу Кузнецов Побиск Георгиевич:
"От всей бесконечно разнообразной и бурной деятельности остается для передачи в машинную систему ГРАФИЧЕСКАЯ КОНСТРУКЦИЯ, в которой нет ничего, кроме … «кружков» и «стрелок»".

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

Не сомневаюсь, что Вам известно, что управлять сложным поведением автоматов обучает Шалыто Анатолий Абрамович.

Сомневаюсь, что Вам известно, что силуэт ДРАКОН Паронджанова Владимира Даниловича - изоморфно отображает машины состояний.

Из ДРАКОН схем можно генерировать код.

Похоже остальной зоопарк технологий отвлекает от главного.

Осталось научить редактор ДРАКОНА генерировать разные слои схем и сворачивать/разворачивать участки схемы.

«Мир есть совокупность фактов, а не вещей»: Витгенштейн и операционно-ориентированное программирование

Мир — это не объекты, а факты: события, операции, изменения состояний.
Машина состояний идеально моделирует такие системы — через переходы между состояниями, а не через статические сущности.

1. Пример: "Сотрудники и зарплата"

Состояния:

• UNHIRED → ACTIVE → FIRED

• SALARY_PAID, REDUNDANCY_PAID

События (факты):
HIRE, PAY_SALARY, FIRE, PAY_REDUNDANCY

Переходы:

• UNHIRED + HIRE → ACTIVE

• ACTIVE + PAY_SALARY → SALARY_PAID

• ACTIVE + FIRE → FIRED

• FIRED + PAY_REDUNDANCY → REDUNDANCY_PAID

2. Почему лучше ООП?

В ООП неясно, где должен быть метод:
PaySalary — в Employee, Account, PayrollService?

Проблема: поведение искусственно привязывается к объекту.

Решение:

• Операции = события

• Логика = правила переходов

• Данные = контекст

Нет "войны за методы". Нет привязки к владельцу.

3. Преимущества

• Декларативность: чёткие правила переходов.

• Предсказуемость: только разрешённые переходы.

• Расширяемость: новое событие = новый переход.

• Отслеживаемость: текущее состояние системы всегда известно.

4. Сравнение с операционным подходом

Вместо классов-операций (как в статье) —
операции становятся событиями,
контекст — данными, а не объектами с поведением.

5. Когда использовать?

• Бизнес-процессы: найм, увольнение, оплаты.

• Жизненные циклы: статусы заказов, заявок.

• Взаимодействие с API.

Не для CRUD, но идеально для процессов.

Вывод

"Мир — это факты."
Машина состояний — язык для описания динамики, а не статики.
Она заменяет "где метод?" на "что может произойти?".
Чисто, предсказуемо, масштабируемо.

Представление об однородном пространстве-времени

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

Разум vs Интуиция или как принимать решения

Для себя определил интуицию после такой ситуации:
- молодой, бодрый, трезвый, в обычном состоянии, внезапно понимаешь, не решаешь, не сомневаешься, а понимаешь, что ты можешь вернутся домой, но не вернёшься.
Не смотря на отсутствие препятствий и сильное желание вернуться домой.

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

Никаких сожалений не будет, потому что разум не был допущен к участию в этом событии.

Вот это "интуиция", а остальное, когда есть неуверенность, подсчёты - не интуиция.

Самый загадочный баг в моей работе

Помню. 2:5040/6.30

Самый загадочный баг в моей работе

В уголке задумчивао курит бухгалтер с выдающимся бюстом. ...

Самый загадочный баг в моей работе

Не Австралия, Дальний Восток РФ, г. Хабаровск, Судостроительный техникум, год, примерно 1998.

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

Чем запомнился именно этот случай?
Спец сидит за компом, я прошу разрешения запустить программу - русские буквы нормально.
Запускает тот мужик - кракозябры.
И так пару раз.

Уже не помню нюансов, сделал в config.sys запуск драйвера клавиатуры с более жёсткими опциями и программа перестала баловаться.

Что объединяет историю топикстартера и мою - далеко от Москвы, про символы.

«Отказываться нельзя использовать» — как мы расставили ключевые запятые, исходя из опыта работы с low-code платформой

Приятно встретить использующих визуальное программирование.

Рисунок 1. Схема бизнес-процесса отправки email-сообщений, которая настраивается аналитиком - приемлемая схема управляющей машины состояний начального.

Не вижу в ней обработки ошибок при обращении к внешним системам.
Похоже Ваши схемы не связаны с кодом?

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

ИИ, no-code, блокчейн и софты: тренды во фронтенд- и бэкенд-разработке 2025

Какая-то часть программистов, в каких-то компаниях будет освобождена от процесса написания кода.

Каприз на тему будущего программирования

Как мы учим роботов ходить плавно, или Почему градиент градиента — это не опечатка, а ключ к безопасной робототехнике

Привет!

Вы достигли хорошего прогресса, но попали в ловушку "почти работает, осталось чуть-чуть".
Могу недорого продать направление, которое приведёт Вас к созданию не падающего робота.

Проектирование Информационных систем. Часть 9. Моделирование поведения 9.2. Поведенческие диаграммы UML

Есть два вида обучения:
1 - Обучил и давай, до свиданья ("до свиданья" – разговорная форма, лучше "до свидания").
2 - Обучил, а если обученный не сделает, то делать будешь ты .

Как бы обучал созданию информационных систем ленивый разработчик, создавший не одну информационную систему, если он во второй позиции:

Информационная система – это программа, это код.

Как ни крути, нужен код, хотя заказчик может считать, что ему нужна некая работающая система, но получит код.

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

Чтобы изменять код, нужна документация на код.
Как показывает практика, код без документации выбрасывается, новые разработчики говорят: "Нам проще и лучше переписать всё с начала!".

Большинство создают документацию на код отдельно от кода, документация, отдельная от кода, становится не изоморфной коду, документация выбрасывается вместе с деньгами и временем, затраченными на её создание.

Заказчикам, особенно военным, интересно – как, не понимая код, убедиться, что код делает то, что в ТЗ.

Нужна абстракция между кодом и ТЗ.

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

Заказчикам, пользователям, разработчикам нужно одно место (абстракция), которую все они понимают, могут изменять поведение программы, причём "правильность" изменений будет контролировать само это место.
Заказчики и пользователи, нечаянно, становятся разработчиками, потому что код напрямую исправлять в IDE можно, но зря – он сгенерируется заново при следующем изменении.

Да, это место замешано на математике, информатике, эргономике.