Сова — система комплексної безпеки дистиляції та ректифікації

[Serhiy]

Друге важливе впровадження — реалізація вище згадуваного автономного Watchdog (WDT) на апаратному рівні.Оскільки, як виявилось, всі ми тут цінуємо концепцію архітектури останньої надії, було критично важливо захистити систему від зависання самої esp32. Для цього я задіяв апаратний таймер. Логіка проста, але безвідмовна - якщо основний цикл програми через збій чи помилку не обнуляє таймер вчасно, контролер автоматично перезавантажується.
Завдяки цьому Сова миттєво повертається до робочого стану і, як ні в чому не бувало, продовжує моніторинг периметру. Це гарантує, що в випадку коли безпосередньо на Сову не впав метеорит, система безпеки ніколи не залишиться у заціпенінні навіть якщо виникне непередбачувана програмна помилка.

[Serhiy]

Третє вдосконалення, менш масштабне технічно, але приємне для очей — оновлення розділу Макет.
Тепер фон кожного чекбокса забарвлений у колір того датчика, до якого він належить. Це повністю відповідає кольорному кодуванню наших маркерів (адже кожному типу сенсора у нас призначено свій колір). Тобто кожен елемент керування тепер розташований у кольоровому прямокутнику, що відповідає типу датчика.
Це саме той випадок, коли продуманий UIдизайн робить інтерфейс не лише естетичним, а й інтуытивно зрозумілим. Прямий візуальний звязок між чекбоксом у налаштуваннях та маркером на макеті дозволяє зчитувати стан системи за долі секунди. Жодних зайвих роздумів — колір підказує все сам.
Guests are not allowed to view images in posts, please Register or Login

[ДимаС]

За останній час у Сові було реалізовано декілька критично важливих рішень.
Перше і найголовніше — ми «повністю» нейтралізували проблему зависання температурних датчиків DS18B20...[\quote]
Може ще є які критичні чи не критичні баги роботи Сови?

[Serhiy]

ДимаС, дякую! Твоє запитання виявилося найцікавішим із півсотні інших, тому відповідаю на нього з особливим задоволенням.
Говорити про "критичні баги" Сови — справа критично незручна. Якби я написав, що їх у принципі не могло бути, то мої ж слова про нещодавні "критично важливі рішення" втратили б свою вагу. А якби зізнався, що вони ще недавно існували, то виглядав би смішно, презентуючи систему безпеки з дирками.
Тепер по суті. Связка OneWire + DallasTemprerature — це абсолютний монополіст і стандарт дефакто у світі мікроконтролерів. 99,9% всіх статей, відео на ютюбі, відповідей на StackOverflow та прикладів коду для датчиків DS18B20 написані саме під неї. Підозрюю, що і в твоїй коллекції обладнання є зразки, які працюють саме на цих бібліотеках. Іншими словами, назвати використання цього стандарту "критичним багом" — це дуже сильно натягнути сову на глобус (особливо, якщо це наша Сова).
АЛЕ! Коли йдеться про глобальну систему безпеки, де зупинка процесора навіть на пів секунди може призвести до збою, відвалу мережі чи реальної аварії, твої слова про критичність стають цілком адекватними.
У таких випадках потрібно шукати ультимативні рішення. Саме тому OneWireNg є обовязковою для динамічних систем реального часу. Вона вміє використовувати апаратні драйвери (наприклад, RMT всердині esp32), перекладаючи важку роботу на залізо. Це складно реалізувати кросплатформенно, тому OneWireNg значно складніша під капотом. Тут потрібно розуміти шістьнадцатирічні команди, працювати з масивами байтів і вручну перевіряти контрольну суму (CRC). Це нішевий продукт для просунутих інженерів — тобто саме для нас і нашої системи безпеки.
Тому, відповідаючи на твоє пряме запитання про наявність критичних багів зараз, скажу так - теоретично вони можуть виплисти під час експлуатації. Але практично їх немає і бути не може. Бо якби я про них знав, я б не писав цей текст, а вже сидів би і викорінював їх у коді.

[Serhiy]

Електронні листи про нові відповіді не отримую лише я, чи це критичний баг для всього форуму?

[ДимаС]

Не в курсі, я цим давно перестав користуватись, бо просто заходжу пару-трійку раз на добу подивитись як тут справи)

[Serhiy]

На це твоє повідомлення вже отримав і оповіщення і електронного листа.