Comments 11
Вроде бы и "+". Вроде бы и популяризация, но несколько бросившихся в глаза ляпов - тянут на жирный "-". Так что ограничусь замечаниями. Каюсь, половину пролистал невнимательно, ибо см. замечания :).
За WB (ради него и затевалось же, правда?) - спасибо. В свете нынешней доступности контроллеров, всё более актуально.
1. Указание типа значений uint16_t как бы намекает на 16 бит или 2 байта (а не 4) - из записи EEPROM (то, как оно хранится внутри - другая история)
2. У ESP8266 нет EEPROM. Она эмулируется через FLASH
3. Аналогично с файловой системой - она тоже живёт во FLASH. И "насиловать" её ещё и лишней записью всякого JSON - ну, такое себе... Кстати, а зачем вообще хранить локальные настройки в человеко-читаемом виде? Их же никто, кроме контроллера не видит
4. Не помню, в какой части ардуины, но где-то там есть встроенная функция yield(), отдающая остатки времени внутреннему планировщику. Переопределять её как-то неаккуратненько ©. Мало ли, что потребуется
5. Если сенсор измеряет раз в секунду, зачем дёргать его раз в 10мс? Мало того, что лишний разогрев датчика, так ещё и будем мешать работать тому же modbus-у. На 9600-то, может и успеет, а быстрее - возможны сюрпризы
За WB (ради него и затевалось же, правда?) — спасибо.
Нет, это личный блог и просто делюсь опытом. Я долго искал пример Modbus-устройства с изменяемыми настройками связи и не нашёл, подумал, что будет полезно.
1. Указание типа значений uint16_t как бы намекает на 16 бит или 2 байта (а не 4) — из записи EEPROM (то, как оно хранится внутри — другая история)
2. У ESP8266 нет EEPROM. Она эмулируется через FLASH
3. Аналогично с файловой системой — она тоже живёт во FLASH. И «насиловать» её ещё и лишней записью всякого JSON — ну, такое себе… Кстати, а зачем вообще хранить локальные настройки в человеко-читаемом виде? Их же никто, кроме контроллера не видит
Подскажите, пожалуйста, как лучше сделать — я дополню статью и скетчи.
4. Не помню, в какой части ардуины, но где-то там есть встроенная функция yield(), отдающая остатки времени внутреннему планировщику. Переопределять её как-то неаккуратненько ©. Мало ли, что потребуется
Взял из примера автора библиотеки modbus-esp8266: modbus-esp8266/examples/RTU/slave/slave.ino.
5. Если сенсор измеряет раз в секунду, зачем дёргать его раз в 10мс? Мало того, что лишний разогрев датчика, так ещё и будем мешать работать тому же modbus-у. На 9600-то, может и успеет, а быстрее — возможны сюрпризы
А почему он должен лишнего греться? Мы же просто спрашиваем у него — есть новые значения или нет или я не прав?
Датчик больше греется, потому что больше работают все узлы :))) Ну и смысла спрашивать датчик чаще времени измерения смысла нет. Постоянная времени изменения TVOC - секунды...
Пробую ответить.
Про хранение В ДАННОМ СЛУЧАЕ (!) - нет EEPROM, FRAM, etc... ЕМНИП, EEPROM в esp8266 эмулировалась через 2 страницы FLASH с контролем корректности предыдущего сохранения, но могу ошибаться. И размер страницы, как бы не 1024 байт. Т.е. минимум 2048 байт "отъедается" на хранение 3-5 переменных. Про FS вообще молчу :) как хранилище web страниц для WiFi с возможностью закачки новых извне - да, а хранить настройки - бешеный overkill (там хранить-то 2-5-10 параметров), ну да - место-то пока есть...
делаем структуру с тем, что храним (для текстовых данных - фиксированная длина строки) чтобы не мудрить с логикой считывания
инициализируем её в коде значениями по-умолчанию
сохраняем её в, пусть, "EEPROM" (в данном случае - всё равно - FLASH), только если что-то поменялось. И, возможно, с задержкой в 5-60сек после последнего изменения - если юзер что-то меняет много где (но это уже изыски). Сохранение через write(... sizeof(struct config_struct)). Не знаю, может и .put подойдёт - ардуину в чистом виде уже лет 10 не пользовал, не помню. Максимум - PlatformIO + почти-С...
при старте также читаем блоком всю структуру (есс-но не напрямую в текущий конфиг). По-хорошему, в конце структуры хранить какой-то вид CRC - если не совпало, игнорим прочитанное
при старте в SafeMode - НЕ читаем конфиг и пользуемся значениями по-умолчанию
Если требуется хранить показания счётчиков - отдельная тема с циклическим буфером или внешней FRAM памятью - компромисс между умиранием памяти, ценой, наличием доп. модулей FRAM и частотой сохранения данных
Про опрос датчиков уже ответил @Winnie_The_Pooh , но добавлю - даже в мануалах к упоминаемым BMP180/280/DS18B20/etc указано, что частый опрос приводит к разогреву датчика вплоть до 1-2°С. Ибо опрос (тут, обычно...) запускает вычисление. Тем более с готовыми ардуиновскими библиотеками, которые не спрашивают по-готовности, а, как правило, принудительно опрашивают датчик и ждут ответа (кстати, ещё одно место косяка с модбасом - пока I²C не ответит - будет "висеть", учитывая как подвисает I²C именно в esp8266, это тоже может стать сюрпризом). Правильный подход:
а) спрашивать не чаще, чем это действительно надо
б) можно спрашивать чаще и хранить локально среднее, но без фанатизма
в) максимально использовать данные на датчик - настраивать частоту измерения в самом датчике и не спрашивать его чаще, чем это время
г) время измерения выбирать максимальное в пределах задачи. Например, температура помещения вряд ли нужна чаще раза в 1-5-10 минут - так и не надо его дёргать чаще 0.5-2.5-5 минут с усреднением. Или даже в 1-5-10 - в зависимости от задачи..
д) в модбас отдавать сохраненное значение, не привязывая чтение датчика к запросу от модбас-а (наверно, эта библиотека так и делает, не пользовался - не знаю)
Как -то так. Без претензий на абсолютную истину, но на основе собственных поделок для дома и автоматизации "больших" зданий.
ЗЫ: Любые рацпредложения выслушаю с удовольствием. Хоть и почти "забил" на esp8266 в угоду STM32 для домашних поделок, но идеология никуда не девается ))
Спасибо. Я поправил основные огрехи в статье, в частности, про файловую систему и оставил старый вариант под спойлером. Так же призвал в конце читать комменты.
Считаю, что статья вместе с комментами уже кому-то принесёт пользу, поэтому удалять её не буду.
А по вашим комментариям, пожалуй, надо мне написать новую статью с разбором этой.
:) так в это и главный плюс статей - вдруг, кто ответит, что всё ващще фигня и надо по-другому. А у людей - мысль!©
Тут вопрос, в какую тему копать - автоматика в терминах "контроллеров" - WB в данном случае (полноценный linux), или МИКРО-контроллеров - две большие разницы. Хотя и к "большим" контроллерам, точнее софту, есть те же претензии...
Что не (на самом деле - тоже "да") надо экономить в "большом" контроллере через его конфигуратор, требует вдумчивого чтения мануалов на "железо" - в т.ч. чипы, - на "полевых" устройствах.
Для данной статьи хватило бы микроконтроллера из "базовых" ардуин - ATmega168/238 (Pro mini etc). Esp8266 избыточен совсем (wifi же тут не используется, а в ATmega168, и правда, есть настоящий EEPROM). Ну, пришлось бы рассказать про FreeModbus и её настройку под ардуину, но это отдельная увлекательная тема...
А вы про WB только узнали, или давно наблюдаете? В апреле будет выставка у нас на производстве в Москве, приходите, пообщаемся. Ребята в блоге компании незадолго до события отчёт с прошлогодней опубликуют и позовут на новую.
Дык, и у меня микроконтроллерная часть в качестве хобби. Хоть и с самопальными платами и прошивками. Но, как-то, "для себя" требуются оба направления, а они слегка разные по подходу в реализации.
Узнал давно. Фирма заинтересовалась где-то весной, когда стало понятно, что Шнайдер - таки всё, а делать что-то надо %) С тех пор и стенд сделали, и (думали что) спалили модуль-другой, и проекты начинаем считать потихоньку. Весна придёт - поглядим.
Обновление прошивки с сохранением конфигурации я бы ещё добавил, например длину config_struct до неё записать или версию. Вряд ли удастся предусмотреть всё с самого начала, такие config_srtuct имеют привычку расти.
Согласен. Но это уже детали реализации, навроде кольцевого буфера в EEPROM для экономии ресурса ячеек.
Тут или версию конфига+совместимость в парсинге оного (множим-копим старый код), или делить конфиг на части - сеть отдельно, остальное отдельно, или просто плевать и конфигурить заново после перепрошивки - зависит от задач.
Мои датчики на ESP живут с SPIFFS, на которой веб страницы, бинарный конфиг ESP и отдельно датчиков - но там всё равно веб+mqtt+wifi+файловый менеджер - оправдано. И да, при прошивке есс-но настройки не теряются (а давно ли я менял структуру конфига? лет 5 назад кое-где...)
Делаем датчик качества воздуха с Modbus RTU на ESP8266 и Arduino