Но мы тут люди "от сохи" - поэтому покажите пожалуйста код - как на вашем автоматном подходе можно одновременно общаться с дисплеем и датчиком температуры по I2C шине ?
опрос устройств по шине это естественный КА, даже если вы это так не воспринимаете)
отправка запроса, получение ответа либо таймаут, отправка запроса на следующее устройство
А вот дальше можно найти отличия - либо цикл опроса отдельный от алгоритма работы с этими данными, как в типичных ПЛК, либо же смешан с процедурой опроса, что часто наблюдается в эмбеде, и на мой взгляд плохой подход.
не скажу за автора, но для меня интересно запустить каждый КА в своём треде и пусть уже библиотека раскидывает между ядрами и ожиданиями на не самом мощном эмбед железе
Это конечно все хорошо, но по факту надо ещё учитывать градиент. т. е уровень понизился и в диапазоне 60..30 (ближе к 60) или повышался и в диапазоне 30..60 (ех 32)
состояние датчиков при этом одинаковое, но объёмы сильно разные
я собственно про то, что теория КА не противоречит параллельности в любом виде.
Но как всегда, КА лучше привязывать к экземпляру устройства. У нас общая шина на 10 приборов, значит КА на шину, а приборы пойдут подчиненными КА или просто параметрами.
сихронизация зависимых КА дело муторное, надо думать над удобным разбиением и минимизацией количества
Прекрасное, что я видел в таких конфигурациях на АМД - при работе видеоядра (2500U) перегрев и перегрузка системы по температуре. Еще жестко откушенные 2Гб для видео.
Подождем результата проверки апгрейда. Это всего лишь Zen+ с минимально пофикшенными проблемами с памятью.
был вполне прекрасный turbo debugger, зачем командная строка
опрос устройств по шине это естественный КА, даже если вы это так не воспринимаете)
отправка запроса, получение ответа либо таймаут, отправка запроса на следующее устройство
А вот дальше можно найти отличия - либо цикл опроса отдельный от алгоритма работы с этими данными, как в типичных ПЛК, либо же смешан с процедурой опроса, что часто наблюдается в эмбеде, и на мой взгляд плохой подход.
в реальности абсолютная синхронность состояния и связанных данных непринципиальна. чаще нужно знать только шаг КА (имя)
хочется атомарности - делаем
тут поискать есть
может это и не чистое мпп, но близкая категория
ну да
я не упомянул очевидной вещи, что доступ на смену состояния КА только через интерфейс? ну извините
читать состояние кстати, обычно можно без ограничения
мпп я в этой области я читал только про мультиклет. реализация под него выглядит очень сложно
любая.
реализуется алгоритм КА.
А как он будет исполняться, мне собственно все равно.
Если может библиотека в треды, корутины или в мпп, тем лучше
не скажу за автора, но для меня интересно запустить каждый КА в своём треде и пусть уже библиотека раскидывает между ядрами и ожиданиями на не самом мощном эмбед железе
КА надо делать на ресурс. в данном случае ресурс это таблица.
Да, неудобный выбор КА приводит только к усложнению логики.
Проблема очереди изменений типичная для СУБД.
Все таки этот пример далековато от темы статьи - контроллеры и устройства, где КА уместнее
КА инкапсулируют разледеляемый ресурс - свое состояние.
Это множество текущих состояний всех КА.
В общем, сама идея интересная, но статья увы и ах. Параллелить КА можно как yield на состоянии ожидания, так и удобнее между потоками.
Как при этом у автора набегают мегабайты объектного кода, большая загадка
Это конечно все хорошо, но по факту надо ещё учитывать градиент. т. е уровень понизился и в диапазоне 60..30 (ближе к 60) или повышался и в диапазоне 30..60 (ех 32)
состояние датчиков при этом одинаковое, но объёмы сильно разные
в Википедии есть история языка. с каждой новой версией добавляют сахара, которые предыдущими компиляторами ессно не собирается
семафор это и есть атомарное состояние
я собственно про то, что теория КА не противоречит параллельности в любом виде.
Но как всегда, КА лучше привязывать к экземпляру устройства. У нас общая шина на 10 приборов, значит КА на шину, а приборы пойдут подчиненными КА или просто параметрами.
сихронизация зависимых КА дело муторное, надо думать над удобным разбиением и минимизацией количества
Картинка выглядит достаточно подходящей для КА. На каждое устройство свой КА.
Параллельное исполнение и машина состояний понятия ортогональные.
Конечно, на конкурентую запись появятся семафоры, зато и точки распараллеливания удобны в точках ожидания изменения состояний.
дело не в супер производительности.
запускаешь игру, 20 минут и перезагрузка ос с диагностикой биоса "перегрев"
Прекрасное, что я видел в таких конфигурациях на АМД - при работе видеоядра (2500U) перегрев и перегрузка системы по температуре. Еще жестко откушенные 2Гб для видео.
Подождем результата проверки апгрейда. Это всего лишь Zen+ с минимально пофикшенными проблемами с памятью.
М-да. 11.1.0.7 выходила лет 15 назад.
железного доктора