Конечные автоматы, ATmega8 и бочка в теплице

Пока не зафиксированы все возможные состояния, и не выявлена их конечность рано говорить о конечном автомате.

 

Вот здесь всё расписано и даже программная реализация таблицы есть ... в принципе, там же где-то (на том форуме) есть и универсальная реализация для любой таблицы ... but komu eto nahren nuzhno?

 

Тут бочка только наполняется, а я хочу сделать чтоб и форточки открывались, и вентилятор включался, надо учить Ёксель и составлять таблички

 

Самое страшное, что эти задачи по состояниям вапще никак независимы. Например, полив в 20-00, или открывание форточек при 35 гра никак не влияет на наполняемость бочки То есть, суперпозиции состояний нету, перемножать их не нужно, одно множество не пересекает другие, а значить, состояний не должно быть овердохрена. О чем я и сказал во втором посте : "Так как денег на бесконечные автоматы у меня нет, буду использовать конечные".

 

Это что такое? Любые комбинации входных состояний, для которых нет решения, должны вызывать ошибку.

 

вот только почему "ожидаем"? Ожидаем - это встать в этом месте и ждать.

 

Именно так и работает автомат. Становится в этом месте и ждёт символа входного алфавита.

 

Я никогда не был профессиональным программистом, тем более, на этом вашем лжывом С++, и для своих невеликих проектов определил следущую канцепцию.
Есть базовый класс TClass, прародитель всех остальных классов, который только и умеет, что отдавать свой ID (читай - свой адрес в ОЗУ). Так как все экземпляры классов (instance) располагаются по разным адресам, то по ID его можно однозначно идентифицировать.
всё, что можно подключить к контроллеру можно смело разделить на 3 группы, это
1. Сенсоры (Sensor)
2. Исполнительные устройства (Device)
3. Модули (Module)

Так что можно смело отнаследовать от TClass абстрактных бастардов

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

TCustomDevice - класс устройств, которые ничего не читают, и которыми можно только управлять, но, которые так же могут уведомлять основную программу о смене своего состояния, например, на вкл/выкл или ошибка. (Это, например, реле, светлодиодики, активные буззеры и многое другое)

TCustomModule - класс устройств, которые могут только исполнять команды и отдавать результаты. Это, например, всевозможные приемники тип RDA5807, модули памяти AT24XX или внешний АЦП 1115, без разницы.

всё остальное - наследники этих абстракций, например Analog и DigitalSensor, AlarmSensor, который еще следит, чтоб читаемая величина не выходила за рамки заданного диапаноса (тот же термометр для открытия окон в теплице). Сенсоры также могут быть I2CSensor и OneWireSensor, да тысячи их, но благодаря наследованию и виртуальным функциям, мы можем определить общую, базовую функциональность и переопределить, то, что в данном, конкретном сенсоре должно быть исполнено по-другому.

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

Продолжать?

 

Читал, что в МК, особенно в наших мелких дуньковских, виртуалки могут поднасрать с памятью. Это правдиво или я не так чего понял? Профи может подскажите.

 

а если в этом автомате ещё один автомат, как у блохастого? Поэтому правильно будет не "ожидаем", а "опрашиваем".

выдохни.
Зачем С++ в МК? Даже FreeRTos записана безо всяких классов. А у вас простейшие свистоперделки

 

каждая добавленная в классе виртуальная функция это +2 байта к памяти данных класса ( читай - лишняя переменная типа int в каждом экземпляре). Разработчики GCC для AVR грозились сделать хранение VMT во флэше, да чота не торопюца.

 

Затем, что программировать проще.
Вопщем - блохастым подавай С++
Меднолобым - ассемблер, процессоры MSP или, на самый накрайняк, чесный, как скупая слеза железячника, Си.

 

А то! конечно!

Да, у меня немного другие определения, но в общем выходит то же самое.
1. Модули. 1 модуль может содержать несколько сенсоров например BME280, модуль он или есть или нет, при смене состояния в зависимости от заданного уровня логирования должен выдавать информацию куда скажуть. Например был модуль и не стало, молнией убило, надо отправить смс, и отключить сенсоры принадлежащие модулю.
2 Сенсоры, то бишь часть модуля, в отличии от модулей выдают некую динамическую информацию, температура, давление и тд, можно указать количество итераций для усреднения показаний и правила выдачи куда либо, SMS, MQTT... Так же на основании показаний сенсора программировать поведение механизмов.
3 Механизмы Краны, актуаторы, вентиляторы, релюхи и тд и тп. Сюда еще не дошел. Ну самое простое, по таймеру открывать/закрывать лаз в курятник, в совокупности с температурой на улице, ежели температура ниже 5 градусов по цельсию, лаз не открывать.

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

 

точна

 

Суперпозиция состояний А и Б достигается переходом из А в Б.
Если открывать форточку нужно после 20-00 и только при температуре выше 35, то поступаем так:
Фиксируем состояние "жара" - это когда температура перевалила за порог 35 (с учетом запаса антидребезга),
В 20-00 из "жарко" переходим в "проветривание" - т.е. открываем форточку.
Просто так в 20-00 форточка не откроется (зимой, например) - в "проветривание" можно попасть только из "жара" - по таблице в этом можно наглядно убедиться

 

Надо сначала придумать язык описания таблицы переходов (ЯТП), и написать какую-то приблуду для перевода Ё-таблицы на ЯТП.
Потом пошаманить с Лексом-Яком - построить анализатор-интерпретатор ЯТП на Си или Яве.

 

Фактически конечный автомат так и работает:
Попав в состояние он проверяет все возможные (по ТП) условия (входной поток данных) перехода в другое состояние:
В состоянии "жду" проверяются кнопки, датчики, и т.д., и если что-то удовлетворило условию (значение на датчике равно, или попало в "вилку") перехода, то автомат переходит в соотв состояние "сигнал", например.
Никакого останова по факту не происходит! - просто "если ..., то ..." в цикле.

 

На просторах тырнета нашол свой патрет на даче



Только кота не хватает.

 

И стола с лабораторным блоком питания, компа со "студией"…

 

Это в соседней комнате, туда, где дверь