State machine, Приведите примеры реализации Опции

[sat]

Где можно почитать по теме/посмотреть примеры на С, асме

[Diz]

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

[TMX]

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

сомнительно. все равно потом по указателю функция вызывается,
для таких случаев обычно пишут лог переходов в том или ином виде, ну и список разрешенных переходов (собственно, он у Гомеса есть).

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

[Diz]

сомнительно. все равно потом по указателю функция вызывается,
для таких случаев обычно пишут лог переходов в том или ином виде, ну и список разрешенных переходов (собственно, он у Гомеса есть).

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

[TMX]

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

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

Да все тупо...

то есть, если надо убрать одну функцию из центра списка, придется перенумеровывать все последующие?

с событиями не совсем ясно:
насколько я понял, функции опроса событий возвращают 0, если события нет и номер события, если событие есть. Как происходит нумерация событий?
Получается, что события имеют приоритет, в порядке которого они опрашиваются. Из этого следует, что в любом состоянии приоритет событий одинаков. Более того, каждое состояние должно реагировать на все события.
А если, допустим, первое событие - кнопка нажата, а второе - таймер сработал. Тогда при нажатой кнопке даже в состоянии "ждать таймер" система не будет не него реагировать.

Причина редактирования: Излишнее цитирование.

[Dog Pawlowa]

то есть, если надо убрать одну функцию из центра списка, придется перенумеровывать все последующие?

Вовсе нет. Если это состояние не используется, есть два пути:
1) не делать ничего, разместив указатель на пустую функцию

#define stSelfTest 1 >> #define st1 1
#define f1 fSelfTest >> #define f1 fEmpty

2) или, если два байта в таблице вдруг понадобились, перенести сюда функцию, последнюю в списке.

с событиями не совсем ясно:
насколько я понял, функции опроса событий возвращают 0, если события нет и номер события, если событие есть. Как происходит нумерация событий?
Получается, что события имеют приоритет, в порядке которого они опрашиваются. Из этого следует, что в любом состоянии приоритет событий одинаков. Более того, каждое состояние должно реагировать на все события.
А если, допустим, первое событие - кнопка нажата, а второе - таймер сработал. Тогда при нажатой кнопке даже в состоянии "ждать таймер" система не будет не него реагировать.

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

Состояние не должно реагировать на все события, тут Вы не правы.

[TMX]

Состояние не должно реагировать на все события, тут Вы не правы.

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

Фактически, это модель с монитором однократных событий. Сложно сказать, какие преимущества и недостатки у моделей.
А вот насчет вашей реализации - похоже на реализацию Gomez, но event driven, и те же недостатки.

Простой switch по состояниями имеет меньше источников ошибок, поскольку там нет нумерации и перечисление событий только в одном месте.

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

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

А "много" это сколько? "Плюспицот" - это много? Тестировали атомарность записи в eeprom? А если да, то как?

Я имею дело со всякими девайсами и разными процессорами. В различных средах разработки, кстати. Поэтому молиться на IAR как-то не тянет.
Например, были готовые серийные девайсы с внешней EEPROM на программном SPI. Именно с проблемой восстановления.
Я - за рациональные решения. Объясните, пожалуйста, зачем нужна ранняя диагностика питания и как она сказывается на приличности? Если результата можно добиться программными средствами - это красиво и целесообразно.
Уточняю - это не для всех случаев. Я не против диагностики, я даже за резевный ионистор в НЕОБХОДИМЫХ случаях. А вопросы о приличности оставляю на рассмотрение депутатов.

[Dog Pawlowa]

А вот насчет вашей реализации - похоже на реализацию Gomez, но event driven, и те же недостатки.

Мне важно иметь механизм, а с недостатками можно смириться. Для сведения - в устройстве более 100 состояний.

Простой switch по состояниями имеет меньше источников ошибок, поскольку там нет нумерации и перечисление событий только в одном месте.

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

[TMX]

Мне важно иметь механизм, а с недостатками можно смириться. Для сведения - в устройстве более 100 состояний.

Странно люди относятся к инструментам, которыми пользуются.
К примеру, просто машину (не состояний) они тщательно выбирают, взвешивают все за и против, смотрят на внешний вид и удобство посадки. Тратят на это немало времени, читают журналы, просматривают интернет. Пожалуй, стоит взять на вооружение фразу "мне важно иметь механизм, а с недостатками можно смириться, для сведения - я проезжаю 100 км за раз"
В то же время, с помощью методов и средств программирования мы зарабатываем деньги, в том числе, на автомобили. Почему бы не потратить время на поиск удачных решений?

По поводу списка:
в случае switch все состояния тоже переименовываются с помощью enum. Так что, вот и список (1 шт.).
Кстати, для основных автоматов я использую не switch, а возврат функцией состояния указателя на следующую функцию состояния. Там тоже список прототипов функций (1 шт.).

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