Прекрасная статья, я как будто вернулся в 2000-е, сам с 90-х занимаюсь промышленной автоматизацией и было приятно видеть, что автор сделал на промышленное ПЛК систему автоматизации дома (я не называю такие системы "умный дом", потому как там простые сценарии, банальная логика и дистанционное управление и для меня это не умная система).
Да, решение на момент 2011 года было несомненно отличным (хотя и сейчас я тоже сделаю так-же на проводах, единственное, сделаю систему распределенной, не люблю километры проводов, поэтому буду использовать надёжный промышленный RS-485 для управления и контроля). И сейчас промышленное решение типа PLC - кажется максимально надёжным и удобным (опять же, это мышление нашего поколения, потому как мы видели становление беспроводных технологий, видели их костыли и палки, поэтому доверяем им меньше).
Хотя, если посмотреть на современные решения для "умных домов", то там мало отличий от решений прошлых десятилетий и они очень похожи на промышленные решения (отчасти). Аналогичные модули ввода-вывода, использование Modbus на rs-485, но используется Linux и программное обеспечение.
Согласен с одним из выводов в комментариях, о том, что если старая система выйдет из строя, то все нужно будет переписывать и это создаёт проблемы. Да, несомненно, отказ системы - это проблема, но там и логика как правило описана простая. Там нет PID регуляторов, нет управления динамически процессом и автор сделал все, для того, что бы отказ системы прошел максимально безболезненно. Хотя я считаю что эти PLC, ещё 30 лет отработают без напряга. Единственное, что для расширения количества каналов управления и модулей DI необходимо иметь в наличии дополнительные модули. Ну или при их отсутствии городить новые методы управления и контроля, добавляя новую подсистему.
Ничего не имею против современных решений, протоколов и модулей, сам их использую и они несомненно имеют место быть и будут всегда развиваться, но ничто не сделает систему максимально надёжной, чем датчики и исполнительные устройства на проводах.
Сейчас как раз разрабатываю такую систему которая сочетает в себе возможности шинной, распределенной и в основном проводной топологии (беспроводные решения, IoT, zeegbee и пр. тоже будут, а так-же модули, которые смогут охватить максимум необходимых задач, как для промышленных решений, так и для дома. И естественно, в основе - классика автоматизации - DI, DO, AI, AO, RS-485 (MODBUS). Посмотрим, что из этого получится, но пока все отлично!
Автору спасибо за классную статью, хотелось бы ещё увидеть логику, схемы и прочие решения вашей системы управления домом.
А с сетевым трафиком I2S не приходилось работать? С широковещательным пакетом, в полном дуплексе и просто передача звука по tcp ip? От 1 к 1 и от 1 к многим.
Сначала вы предлагаете использовать military grade микросхему, где она не нужна по факту, а потом кидаете ссылки на АлиЭкспресс где они стоят в 10 раз дешевле, чем в нормальных магазинах, и говорите про супер-пупер надёжность решения? Логика из чата вышла
А как вы считаете, микросхема 1-я, которая была предложена и последующие с AliExpress, чем они отличаются? Так вот, скажу вам, только объёмом памяти. Потому что работают они все одинаково хорошо.
Я лично в Китае, был на заводе, где делают модули ввода-вывода Siemens, так вот туда ставят китайского производства микросхемы, оптопары, диоды и всп остальное барахло, а все что лежит в "нормальных" магазинах куплено у тех-же китайцев, просто было проверено ОТК от заказчика и отбраковано порядка 40%. Просто не прошло по одному из параметров, известных только ОТК от Siemens.
Логика никуда не выходила, и сколько я беру на АлиЭкспрессе, всего один раз был брак и тот на китайском микроконтроллере Ch32v003j4M6.
Если не делать так как автор - open/append, write, close, то fatfs кеширует данные до переполнения буфера или f_close/f_flush.
А как вы предлагаете делать? Держать файл открытым? Так в этом и проблема, что автор переживает за то, что при потере питания, он потеряет данные.
Даже если делать как в статье - то запись раз минуту должна убить сектора фат-таблицы за полгода-5 лет
Все будет зависеть от объёма записи, если по 30 байт, то возможно, а если по 300,то быстрее, и sd не скажет об этом, но если помрёт один сектор, то и файл можно будет похоронить. Ну или каждый день делать новый файл, что бы не потерять все.
P.s. лет 20 назад,коллега как-то пытался "убить" eeprom на avr. Работало оно месяц без перерыва, значения из даташита превзошло на порядок. Он не победил
Я в 2003 такое делал с atmega8 и её победил, она сдохла за 2 суток. При постоянной перезаписи своих несчастных 512 байт, а в прошлом году из партии китайцев eeprom взял 3 штуки и убивал их. Да, циклов они выдержали больше заявленного, раза в 4, но сдохли!
FRAM висит уже месяцев 8, жив, здоров и не чихает.
Все куплены на AliExpress.
Нужно будет ради прикола nano и pro mini поставить на тесты.
Я fram использую очень давно. С ним нет никаких проблем.
Я расписывал здесь, как даталоггер может хранить 3 месяца в fram памяти. С вот с оперативной - это проблемы. В fram закинул байт, потом ещё, потом ещё и максимум, потерять можно байт, или последнюю запись. С оперативкой сложнее, там нужно выделять память и в этих рамках только оперировать. И потом, куда скидывать из оперативки? На SD карту, тогда постоянно это делать нужно, если не скидывать и ждать наполнения, то есть риск потерять всю оперативку. Много нюансов. И с eeprom (которая адресуется как fram) есть много проблем. Она не любит много циклов перезаписи. Если брать flash, то туда писать можно только блоками, значит эти блоки нужно собрать сначала.
SD - тоже писать секторами, значит наполнение взять нужно, но пишет долго. Есть риск потерять весь файл.
В итоге, оптимально - это fram, с бесконечной перезаписью, побайтной записью и примитивной i2c.
Попробуйте, потом скажете свое мнение. Можно начать с внешней eeprom на i2c, разобраться, как она пишет, а потом воткнуть fram.
Я вас очень понимаю и сам часто визуализирую данные в виде графиков, особенно если система динамичная. А уж все АСУ ТП системы, так там любая информация - это графики. Как менялась температура, давление, расход и многое другое (PiSystem от Osi Soft, один из представителей подобного рода систем)
Здесь же, автор говорил именно про логгирование. Не хочу быть душным, но это немного другое:
Логгирование информации (журналирование) — это автоматическая текстовая запись хронологии событий, происходящих в компьютерной системе, программе или оборудовании.
Сам по себе лог — это строго текст или структурированные данные.
Ну а графическом представление, которое более информативное - это визуализация данных.
И то и другое имеет место быть и они имеют разное назначение.
Ram - это оперативка и в ней хранить как то не безопасно. Суть логгера сохранить данные, ну и забивать эту память в динамике - можно просто повешать МК при переполнении.
Использование внутренней флеш-памяти ESP32 для постоянного побайтового или построчного логирования приведет к быстрому выходу устройств из строя на реальных объектах.
Встроенная память рассчитана на 100 000 циклов записи и не факт что она их отработает. Если много логов, то спустя год - полтора могут начаться проблемы с записью и чтением. А если циклически записывать данные в одну и ту же ячейку (например, каждую секунду в цикле loop), память выйдет из строя всего за ~27 часов.
Поэтому контроллер лучше использовать как управление, а данные гонять грамотно и оптимизировано, учитывая возможности модулей и компонентов.
Они меньший ресурс имеют чем FRAM, но думаю что при нечастой записи их на век хватит.
Я так понял, SD карта требуется в случаях когда логгер куда-то жестко вмонтирован, и есть ситуация когда пропадает связь а данные требуется считать.
По сути да, и логгер всегда стоит в параллель с потоком данных и сам не занимается считыванием, иначе он становится основным датчиком с накоплением, а не логгером.
А самый оптимальный вариант - это накопление данных в EEPROM или FRAM, а потом, при заполнении переписать на SD. В новый файл, не трогая предыдущий, для сохранения. Затем проверить записались ли данные и сравнить их с тем, что лежит в EEPROM или FRAM и если все ок, то очистить EEPROM или FRAM и приготовиться писать туда опять.
Ну вам видимо нужно много попкорна, а мы так обогатительные фабрики автоматизировали и рудники, не говоря уже про банальные комнаты. Вы вообще понимаете, о чем иднт речь или так просто написать решили? Я же написал про шину rs485, а это немного промышленный стандарт, который легко поднимается где угодно, ну а питание для примитивных датчиков в пару миллиампер - не проблема, в том же кабеле вместе с rs485. Если это вам о чем-то говорит.
А где лог? Я вижу только график и он без пояснений, а лог - это обычно текст, с отметкой времени и данными. Возможно с пояснения и, заметками, отметками. Формат любой по желанию. И лог не предназначен для вывода в виде графика, в виде данных и так далее, лог нужен для того, что бы восстановить пропущенные данные в базах, увидеть и понять какие либо ошибки, а график, который представлен здесь нужен для понимания работы процесса, датчика и так далее, для поиска зависимостей, и всего того, что душа пожелает.
Эта версия, да, стоит дорого, но есть дешевле, объёмом немного меньше.
FM24V10-G на 1 мегабит, или MB85RC256V на 256 килобит. Эти стоят менее 100 рублей, но они вечные, ни одна SD карта столько не отработает и запись на них простая, я выше писал преимущества.
Так там же емкостный датчик влажности применяется, он не имеет контакта открытой меди с грунтом, соответственно окисления нет. Его ещё отдельно лаком заливают, что бы герметичность была лучше.
Очень странно, я же спросил автора, а не критиковал, а мне за вопрос кинули - 1, для меня это действительно интересно, потому что хочу сделать просто как на плате у автора, но мне ещё важна безопасность при эксплуатации.
Серьёзно? А вы в норме? Людей оскорбляете, себя ставите выше всех присутствующих, ноги о мнение других вытираете, а не адекватный здесь я?
А рот вам нужно помыть, что бы больше не говорить такой бред! И совет на будущее: если думаете что что-то знаете, перепроверьте и потом уже доказывайте, есть вероятность ошибиться и потом выглядеть по идиотски.
А самое неприятное, вы ни разу не признали ни один факт того, что ошиблись и продолжаете стоять на своём, это признак нарциссизма, эгоцентризма, и догматичности.
Это по вашему адекватность?
Прощайте и удачи вам.
Нет желания более общаться, тем более это и общением то назвать нельзя. Есть вы, есть ваше мнение и есть другое-неправильное.
А зачем такие непонятные действия делать? И потом коммутировать перед началом записи? Типа дополнительная емкость, ну тогда нужно перед ними, на линии питания диод ставить, что бы разряд шёл только с схему, а не на другие конденсаторы и стабилизаторы (если они там будут).
Я что-то похожее делал для бистабильно го реле, что бы отключать его, если пропало питание. Они же без тока не переключаться обратно, поэтому дополнительное микрореле ставил и коммутировать его так, что бы заряженные конденсаторы отрабатывали на отключающие катушки. Вам можно сделать аналогично. Коммутация конденсатора в момент отключения питания. Реле подключено на самом входе без конденсатор в, потом диод, что бы конденсаторы не удерживали катушку реле, за диодом конденсатор базовый и следом подключаемый.
Посмотрите комментарий внизу, решение очень простое.
А ещё, самая большая проблема в том, что ваше устройство никуда данные не передаёт, ни на сервер, ни в систему умного дома, просто хранит их у себя и все. При этом вы ежесекундно считываете данные, а отображает только последние из буфера. Зачем? Почему? Какова цель? Ну хотя тогда сравнивайте текущие с предыдущим и записывайте только те, которые изменились и для корректной метки времени обязательно нужны часы типа DS3231. Потому что после перезагрузки, у вас метка времени будет кривой и она будет повторяться в вашем файле. Логгирование всегда привязано к реальному времени или к порядковому номеру, если время не важно. У вас ни того ни другого, просто таймер millis / 60000. После перезагрузки МК он обнуляется.
В чем смысл тогда логгирования. Это же просто сбор данных без возможности дальнейшего использования. А потом вы что, возьмёте SD карту и с ней пойдёте к ПК переносить инфу? А куда? В Excel? Так сейчас не 2000 год, а 2026, и у вас микроконтроллер с Wi-Fi, Bluetooth, а это такие возможности!
А SD карта, в таком режиме сдохнет через 1-3 месяца, китайская за 1,5 - 2 недели.
Вместо sd карты можно установить FRAM CY15B102J, на 2 МБит (512КБайт), этого вполне достаточно что бы хранить там метку времени на 32 бита и 3 числа типа float в количестве 16384 записи. Даже если метеостанция будет каждые 10 минут снимать показания (а это слишком много), то этого объема в 16 384 записи вам хватит на 113 дней непрерывной автономной работы без перезаписи!
Но я все таки надеюсь, что и опрос будет реже и вы все таки не будете просто хранить данные на метеостанция за весь период, а будете передавать их на хост и очищать память. А запись будет только в том случае, если нет связи с хостом, иначе непонятно, зачем вообще их хранить на метеостанции. Если для прикола только.
А теперь преимуществ FRAM-памяти (CY15B102J) перед SD-картой при записи малых объемов данных (метка времени и три числа float):
В 100 раз выше скорость работы. Запись одной пачки данных во FRAM занимает всего 0,17–0,4 миллисекунды, тогда как на SD-карту текстовая строчка пишется от 10 до 40 миллисекунд из-за долгой инициализации и работы файловой системы FAT32.
В 500 раз ниже потребление тока. В момент физической записи чип FRAM потребляет около 150 микроампер, в то время как SD-карта при перезаписи флеш-массива требует от 50 до 100 миллиампер.
Практически бесконечный ресурс. FRAM выдерживает до 100 триллионов циклов перезаписи. SD-карта при постоянной циклической дозаписи мелких строчек выйдет из строя в сотни раз быстрее из-за ограниченного ресурса ячеек флеш-памяти. А дешёвая карта очень быстро, как это бывало на Raspberry Pi.
Отсутствие лишних операций с памятью. Во FRAM можно записать ровно 16–20 байт данных. На SD-карту невозможно записать блок меньше одного сектора (512 байт), поэтому системе приходится каждый раз считывать, модифицировать и перезаписывать сотни лишних байт.
Высокая надежность при внезапном отключении питания. Во FRAM данные сохраняются физически в момент отправки последнего бита. Если питание пропадет при записи на SD-карту, файловая система FAT32 может полностью разрушиться, что приведет к потере всего текстового файла.
Экономия памяти микроконтроллера. Для работы с FRAM используется простой и легкий код передачи данных по шине I2C. Для SD-карты требуется подключать тяжеловесные библиотеки для работы с файловой системой, которые занимают много оперативной и флеш-памяти контроллера.
Просто были подобные проекты и там этих граблей было так много, и что мы только не использовали. А вот вариант с FRAM стал спасением.
Прекрасная статья, я как будто вернулся в 2000-е, сам с 90-х занимаюсь промышленной автоматизацией и было приятно видеть, что автор сделал на промышленное ПЛК систему автоматизации дома (я не называю такие системы "умный дом", потому как там простые сценарии, банальная логика и дистанционное управление и для меня это не умная система).
Да, решение на момент 2011 года было несомненно отличным (хотя и сейчас я тоже сделаю так-же на проводах, единственное, сделаю систему распределенной, не люблю километры проводов, поэтому буду использовать надёжный промышленный RS-485 для управления и контроля). И сейчас промышленное решение типа PLC - кажется максимально надёжным и удобным (опять же, это мышление нашего поколения, потому как мы видели становление беспроводных технологий, видели их костыли и палки, поэтому доверяем им меньше).
Хотя, если посмотреть на современные решения для "умных домов", то там мало отличий от решений прошлых десятилетий и они очень похожи на промышленные решения (отчасти). Аналогичные модули ввода-вывода, использование Modbus на rs-485, но используется Linux и программное обеспечение.
Согласен с одним из выводов в комментариях, о том, что если старая система выйдет из строя, то все нужно будет переписывать и это создаёт проблемы. Да, несомненно, отказ системы - это проблема, но там и логика как правило описана простая. Там нет PID регуляторов, нет управления динамически процессом и автор сделал все, для того, что бы отказ системы прошел максимально безболезненно. Хотя я считаю что эти PLC, ещё 30 лет отработают без напряга. Единственное, что для расширения количества каналов управления и модулей DI необходимо иметь в наличии дополнительные модули. Ну или при их отсутствии городить новые методы управления и контроля, добавляя новую подсистему.
Ничего не имею против современных решений, протоколов и модулей, сам их использую и они несомненно имеют место быть и будут всегда развиваться, но ничто не сделает систему максимально надёжной, чем датчики и исполнительные устройства на проводах.
Сейчас как раз разрабатываю такую систему которая сочетает в себе возможности шинной, распределенной и в основном проводной топологии (беспроводные решения, IoT, zeegbee и пр. тоже будут, а так-же модули, которые смогут охватить максимум необходимых задач, как для промышленных решений, так и для дома. И естественно, в основе - классика автоматизации - DI, DO, AI, AO, RS-485 (MODBUS). Посмотрим, что из этого получится, но пока все отлично!
Автору спасибо за классную статью, хотелось бы ещё увидеть логику, схемы и прочие решения вашей системы управления домом.
Очень интересное решение!
А с сетевым трафиком I2S не приходилось работать? С широковещательным пакетом, в полном дуплексе и просто передача звука по tcp ip? От 1 к 1 и от 1 к многим.
А как вы считаете, микросхема 1-я, которая была предложена и последующие с AliExpress, чем они отличаются? Так вот, скажу вам, только объёмом памяти. Потому что работают они все одинаково хорошо.
Я лично в Китае, был на заводе, где делают модули ввода-вывода Siemens, так вот туда ставят китайского производства микросхемы, оптопары, диоды и всп остальное барахло, а все что лежит в "нормальных" магазинах куплено у тех-же китайцев, просто было проверено ОТК от заказчика и отбраковано порядка 40%. Просто не прошло по одному из параметров, известных только ОТК от Siemens.
Логика никуда не выходила, и сколько я беру на АлиЭкспрессе, всего один раз был брак и тот на китайском микроконтроллере Ch32v003j4M6.
А как вы предлагаете делать? Держать файл открытым? Так в этом и проблема, что автор переживает за то, что при потере питания, он потеряет данные.
Все будет зависеть от объёма записи, если по 30 байт, то возможно, а если по 300,то быстрее, и sd не скажет об этом, но если помрёт один сектор, то и файл можно будет похоронить. Ну или каждый день делать новый файл, что бы не потерять все.
Я в 2003 такое делал с atmega8 и её победил, она сдохла за 2 суток. При постоянной перезаписи своих несчастных 512 байт, а в прошлом году из партии китайцев eeprom взял 3 штуки и убивал их. Да, циклов они выдержали больше заявленного, раза в 4, но сдохли!
FRAM висит уже месяцев 8, жив, здоров и не чихает.
Все куплены на AliExpress.
Нужно будет ради прикола nano и pro mini поставить на тесты.
Я fram использую очень давно. С ним нет никаких проблем.
Я расписывал здесь, как даталоггер может хранить 3 месяца в fram памяти. С вот с оперативной - это проблемы. В fram закинул байт, потом ещё, потом ещё и максимум, потерять можно байт, или последнюю запись. С оперативкой сложнее, там нужно выделять память и в этих рамках только оперировать. И потом, куда скидывать из оперативки? На SD карту, тогда постоянно это делать нужно, если не скидывать и ждать наполнения, то есть риск потерять всю оперативку. Много нюансов. И с eeprom (которая адресуется как fram) есть много проблем. Она не любит много циклов перезаписи. Если брать flash, то туда писать можно только блоками, значит эти блоки нужно собрать сначала.
SD - тоже писать секторами, значит наполнение взять нужно, но пишет долго. Есть риск потерять весь файл.
В итоге, оптимально - это fram, с бесконечной перезаписью, побайтной записью и примитивной i2c.
Попробуйте, потом скажете свое мнение. Можно начать с внешней eeprom на i2c, разобраться, как она пишет, а потом воткнуть fram.
Я вас очень понимаю и сам часто визуализирую данные в виде графиков, особенно если система динамичная. А уж все АСУ ТП системы, так там любая информация - это графики. Как менялась температура, давление, расход и многое другое (PiSystem от Osi Soft, один из представителей подобного рода систем)
Здесь же, автор говорил именно про логгирование. Не хочу быть душным, но это немного другое:
Логгирование информации (журналирование) — это автоматическая текстовая запись хронологии событий, происходящих в компьютерной системе, программе или оборудовании.
Сам по себе лог — это строго текст или структурированные данные.
Ну а графическом представление, которое более информативное - это визуализация данных.
И то и другое имеет место быть и они имеют разное назначение.
Ram - это оперативка и в ней хранить как то не безопасно. Суть логгера сохранить данные, ну и забивать эту память в динамике - можно просто повешать МК при переполнении.
Использование внутренней флеш-памяти ESP32 для постоянного побайтового или построчного логирования приведет к быстрому выходу устройств из строя на реальных объектах.
Встроенная память рассчитана на 100 000 циклов записи и не факт что она их отработает. Если много логов, то спустя год - полтора могут начаться проблемы с записью и чтением. А если циклически записывать данные в одну и ту же ячейку (например, каждую секунду в цикле loop), память выйдет из строя всего за ~27 часов.
Поэтому контроллер лучше использовать как управление, а данные гонять грамотно и оптимизировано, учитывая возможности модулей и компонентов.
Да, вполне можно и эти использовать.
Они меньший ресурс имеют чем FRAM, но думаю что при нечастой записи их на век хватит.
По сути да, и логгер всегда стоит в параллель с потоком данных и сам не занимается считыванием, иначе он становится основным датчиком с накоплением, а не логгером.
А самый оптимальный вариант - это накопление данных в EEPROM или FRAM, а потом, при заполнении переписать на SD. В новый файл, не трогая предыдущий, для сохранения. Затем проверить записались ли данные и сравнить их с тем, что лежит в EEPROM или FRAM и если все ок, то очистить EEPROM или FRAM и приготовиться писать туда опять.
Да нет, не белорусских. Я правда в тенге смотрю, потому как из Казахстана. Ну вот, посмотрите сами:
Курс рубля: за 1 рубль 6 тенге. Посчитайте.
Я когда нашёл за такую цену, заказал себе 2 десятка. Есть пара проектов, куда их можно будет применить.
От 500 до 5000 Ампер, для тиристора
До 400-500 Ампер симмисторы справляются.
И это все на запуск, на постоянную работу уже идут контакторы, после запуска, но бывают исключения, когда приходится гонять все только на тиристорах.
Ну и ещё IGBT на таких токах работают, очень неплохо. Но сильно дороже.
Ну вам видимо нужно много попкорна, а мы так обогатительные фабрики автоматизировали и рудники, не говоря уже про банальные комнаты. Вы вообще понимаете, о чем иднт речь или так просто написать решили? Я же написал про шину rs485, а это немного промышленный стандарт, который легко поднимается где угодно, ну а питание для примитивных датчиков в пару миллиампер - не проблема, в том же кабеле вместе с rs485. Если это вам о чем-то говорит.
А где лог? Я вижу только график и он без пояснений, а лог - это обычно текст, с отметкой времени и данными. Возможно с пояснения и, заметками, отметками. Формат любой по желанию. И лог не предназначен для вывода в виде графика, в виде данных и так далее, лог нужен для того, что бы восстановить пропущенные данные в базах, увидеть и понять какие либо ошибки, а график, который представлен здесь нужен для понимания работы процесса, датчика и так далее, для поиска зависимостей, и всего того, что душа пожелает.
Эта версия, да, стоит дорого, но есть дешевле, объёмом немного меньше.
FM24V10-G на 1 мегабит, или MB85RC256V на 256 килобит. Эти стоят менее 100 рублей, но они вечные, ни одна SD карта столько не отработает и запись на них простая, я выше писал преимущества.
Так там же емкостный датчик влажности применяется, он не имеет контакта открытой меди с грунтом, соответственно окисления нет. Его ещё отдельно лаком заливают, что бы герметичность была лучше.
Очень странно, я же спросил автора, а не критиковал, а мне за вопрос кинули - 1, для меня это действительно интересно, потому что хочу сделать просто как на плате у автора, но мне ещё важна безопасность при эксплуатации.
А здесь на входе 220В просто делитель стоит? Я просто не вижу ни диодов ни чего-то ещё. И развязки я так понимаю нет, везде есть высокий потенциал?
Серьёзно? А вы в норме? Людей оскорбляете, себя ставите выше всех присутствующих, ноги о мнение других вытираете, а не адекватный здесь я?
А рот вам нужно помыть, что бы больше не говорить такой бред! И совет на будущее: если думаете что что-то знаете, перепроверьте и потом уже доказывайте, есть вероятность ошибиться и потом выглядеть по идиотски.
А самое неприятное, вы ни разу не признали ни один факт того, что ошиблись и продолжаете стоять на своём, это признак нарциссизма, эгоцентризма, и догматичности.
Это по вашему адекватность?
Прощайте и удачи вам.
Нет желания более общаться, тем более это и общением то назвать нельзя. Есть вы, есть ваше мнение и есть другое-неправильное.
А зачем такие непонятные действия делать? И потом коммутировать перед началом записи? Типа дополнительная емкость, ну тогда нужно перед ними, на линии питания диод ставить, что бы разряд шёл только с схему, а не на другие конденсаторы и стабилизаторы (если они там будут).
Я что-то похожее делал для бистабильно го реле, что бы отключать его, если пропало питание. Они же без тока не переключаться обратно, поэтому дополнительное микрореле ставил и коммутировать его так, что бы заряженные конденсаторы отрабатывали на отключающие катушки. Вам можно сделать аналогично. Коммутация конденсатора в момент отключения питания. Реле подключено на самом входе без конденсатор в, потом диод, что бы конденсаторы не удерживали катушку реле, за диодом конденсатор базовый и следом подключаемый.
Посмотрите комментарий внизу, решение очень простое.
А ещё, самая большая проблема в том, что ваше устройство никуда данные не передаёт, ни на сервер, ни в систему умного дома, просто хранит их у себя и все. При этом вы ежесекундно считываете данные, а отображает только последние из буфера. Зачем? Почему? Какова цель? Ну хотя тогда сравнивайте текущие с предыдущим и записывайте только те, которые изменились и для корректной метки времени обязательно нужны часы типа DS3231. Потому что после перезагрузки, у вас метка времени будет кривой и она будет повторяться в вашем файле. Логгирование всегда привязано к реальному времени или к порядковому номеру, если время не важно. У вас ни того ни другого, просто таймер millis / 60000. После перезагрузки МК он обнуляется.
В чем смысл тогда логгирования. Это же просто сбор данных без возможности дальнейшего использования. А потом вы что, возьмёте SD карту и с ней пойдёте к ПК переносить инфу? А куда? В Excel? Так сейчас не 2000 год, а 2026, и у вас микроконтроллер с Wi-Fi, Bluetooth, а это такие возможности!
А SD карта, в таком режиме сдохнет через 1-3 месяца, китайская за 1,5 - 2 недели.
Это тоже проходили и убивали карты.
Вместо sd карты можно установить FRAM CY15B102J, на 2 МБит (512КБайт), этого вполне достаточно что бы хранить там метку времени на 32 бита и 3 числа типа float в количестве 16384 записи. Даже если метеостанция будет каждые 10 минут снимать показания (а это слишком много), то этого объема в 16 384 записи вам хватит на 113 дней непрерывной автономной работы без перезаписи!
Но я все таки надеюсь, что и опрос будет реже и вы все таки не будете просто хранить данные на метеостанция за весь период, а будете передавать их на хост и очищать память. А запись будет только в том случае, если нет связи с хостом, иначе непонятно, зачем вообще их хранить на метеостанции. Если для прикола только.
А теперь преимуществ FRAM-памяти (CY15B102J) перед SD-картой при записи малых объемов данных (метка времени и три числа float):
В 100 раз выше скорость работы. Запись одной пачки данных во FRAM занимает всего 0,17–0,4 миллисекунды, тогда как на SD-карту текстовая строчка пишется от 10 до 40 миллисекунд из-за долгой инициализации и работы файловой системы FAT32.
В 500 раз ниже потребление тока. В момент физической записи чип FRAM потребляет около 150 микроампер, в то время как SD-карта при перезаписи флеш-массива требует от 50 до 100 миллиампер.
Практически бесконечный ресурс. FRAM выдерживает до 100 триллионов циклов перезаписи. SD-карта при постоянной циклической дозаписи мелких строчек выйдет из строя в сотни раз быстрее из-за ограниченного ресурса ячеек флеш-памяти. А дешёвая карта очень быстро, как это бывало на Raspberry Pi.
Отсутствие лишних операций с памятью. Во FRAM можно записать ровно 16–20 байт данных. На SD-карту невозможно записать блок меньше одного сектора (512 байт), поэтому системе приходится каждый раз считывать, модифицировать и перезаписывать сотни лишних байт.
Высокая надежность при внезапном отключении питания. Во FRAM данные сохраняются физически в момент отправки последнего бита. Если питание пропадет при записи на SD-карту, файловая система FAT32 может полностью разрушиться, что приведет к потере всего текстового файла.
Экономия памяти микроконтроллера. Для работы с FRAM используется простой и легкий код передачи данных по шине I2C. Для SD-карты требуется подключать тяжеловесные библиотеки для работы с файловой системой, которые занимают много оперативной и флеш-памяти контроллера.
Просто были подобные проекты и там этих граблей было так много, и что мы только не использовали. А вот вариант с FRAM стал спасением.