Відповідь:
Ми перевірили і розповідаємо.
Існує дві проблеми:
- Обробка подій за порогами не працює так, як це очікується.
- Немає зручного, на рівні користувача, способу задавати значення порогових регістрів.
Проблема обробки подій за порогами
У класичному вигляді, режим обробки за порогами, а точніше Window Comparator Mode, має працювати так:
- Встановлюємо пороги
- Вмикаємо обробку переривань
- Якщо поточне значення виходить за межі порогів, то на виході INT з’являється логічна одиниця, що вказує на подію.
- Якщо поточне значення повертається в межі порогів, то прапорець події очищується на виході INT і це вказує на стан “НОРМА”.
- Контролер отримує сигнал з INT на своєму GPIO і далі запускається обробник переривання: логічна одиниця – стан “НЕ НОРМА”, логічний нуль – стан “НОРМА”.
Приблизно так працює будь-який з відомих нам сенсорів з виходом переривання. Але не MAX44009.
Ні у режимі “One Shot” ні у режимі Continuous, немає можливості нормально працювати з подіями типу “Норма/Не норма”, тому що сенсор падає у подію і там залишається поки головний контролер не прочитає регістр прапорця стану. Тобто, для того, щоб вивести сенсор із стану “спрацьовано”, потрібно окремою дією через шину I2C прочитати відповідний регістр.
Таким механізмом обробки події не зручно (читай безглуздо) користуватися, адже немає різниці:
- щоразу очищати внутрішню подію сенсора через I2C;
- періодично опитувати сенсор самостійно через I2C і генерувати потрібні події.
На наш погляд, у другому варіанті є кілька ключових переваг. Рухаємося далі.
Проблема встановлення значень порогових регістрів
Сенсор MAX44009 (супутня документація докладно розповідає як), надає нам можливість зчитувати сирі дані з регістрів і перетворювати їх у люкси.
Але документація не описує, як встановлювати значення порогових регістрів так, щоб це було зручно користувачеві, а саме у люксах.
Звичайно, є стандартна для всіх пристроїв можливість встановити регістр двійковим восьми-бітовим значенням. Але цим неможливо користуватися, бо потрібно знати, скільки люксів відповідає певному двійковому значенню регістра. А формули, нагадаємо, у документації немає.
Отже маємо, що для того, щоб задати певний поріг у люксах, користувач має подивитися у таблицю (її можливо отримати) і вказати відповідний люксам сирий байт у якості порогу.
Але і це не всі проблеми. Оскільки у MAX44009 регістр верхнього і нижнього порогу мають різну розрядність, то і таблиці треба мати дві. Одна таблиця на 255 значень, друга на 135. Просто повірте, це не зручно. До того ж, кожна таблиця має розриви діапазонів значень у люксах.
Одним словом, ми дуже здивовані, про що тільки думали інженери, коли проектували цей сенсор.
Всі наведені проблеми чітко показують, чому немає прикладів застосування даного сенсора на повну – розробники просто не використовують наявні у сенсора можливості, бо вони дуже не зручні і їх можливо обійти і інший спосіб.
З іншого боку, це дуже і дуже якісний сенсор з широчезною шкалою вимірювання і динамічною авто-калібровкою під дуже темні і дуже яскраві умови експлуатації.
Замість висновків
Ми вирішили йти по сценарію №2, тобто періодично, засобами контролера опитувати по шині I2C сенсор і генерувати віртуальні події.
Переваги, які ми отримуємо за цим сценарієм:
- користувач задає пороги в люксах.
- немає розривів діапазонів, як у випадку з таблицями
- не треба зберігати в пам’яті таблиці для переведення люксів у байти;
- вивільняється GPIO контролера, який був потрібен для обробки INT.
Ось так непросто. 🙂