Пользователь: меняет настройки. Программа: падает, настройки несовместимы с количеством памяти.
Вы просто не умеете программировать, поэтому и не можете представить, что программа при ошибке выделения памяти может не падать, а внятно информировать пользователя, какие из заданных им параметров можно изменить и в какую сторону, чтобы программа могла продолжить работу.
На ESP32 я прямо в веб-интерфейсе такие параметры подсвечивал, что даже домохозяйке должно быть понятно.
такие шедевры , слава Б-у, не попадались
Если Вы ни разу не сталкивались с нехваткой памяти на принтерах, коммутаторах, роутерах и т.п., то это говорит лишь о недостатке Вашего опыта.
Можно использовать BlueTooth/ZigBee влагозащищенные датчики, что автоматически решает первые две проблемы и последнюю.
Для стабильности измерений лучше медиана, чем среднее.
При большом количестве датчиков я бы предпочёл насосам гидроаккумулятор и электромагнитные клапаны, что позволило бы подключать цепочкой, а не звездой. Но это уже дело вкуса.
Если у меня две не пересекающиеся задачи, например, показать меню и сохранить настройки, которые требуют по 1Кб памяти, то разумно размещать их временные данные в структурах размещенных по одному и тому же адресу в статически выделенном буфере.
С точки зрения безопасности при работе с памятью - это совершенно не разумно. Намного надежней выделять динамически память для буферов страницы флеша, сектора FAT на SD-карте или MQTT сообщения, корректно обрабатывая ошибки выделения памяти, чем писать свою реализацию динамической работы с памятью в пуле.
И сюрпризов не возникнет, что в очередной запрос у меня почему-то окажется свободными только 900 байт.
Откуда уверенность в безошибочности своего кода? )))
Просто проверяйте успешность выделения памяти, а память, необходимую для аварийного завершения, выделяйте заранее. Зато сможете адекватно сообщить пользователю, что, для примера, либо ему надо уменьшить количество насосов, либо сократить глубину хранения истории температур и влажности с датчиков.
А вот если Вы напишете работоспособный аналог lwip без динамического выделения памяти - я сильно удивлюсь. И да, поливалка тоже вполне может работать с использованием MQTT. А в случае интеграции этой поливалки в HA, MQTT становится обязательным требованием.
Конкретно, если рассматривать поливалку, если ей не хватит памяти при статической инициализации, то никакая динамика ее не спасет.
Почему не спасёт? Например, если не хватает памяти для 10 датчиков и 512-байтного буфера для SD-карты, она просто об этом сообщит и пользователь будет вынужден или ограничиться 9 датчиками, или отказаться от протоколирования на SD-карту.
Неприятность динамического выделения в двух местах. Первое - это сегментирование. Второе - это привычка им пользоваться забывая про первое.
С этим никто не спорит. Но для решения этой проблемы известны пути решения.
Если на маленьком МК динамическая память используется только при инициализации, то значит динамическая память не нужна.
Докажите, что не нужны МК с конфигурацией задаваемой пользователем и от которой может зависеть потребность в оперативной памяти.
Динамического распределения памяти там быть не должно
Докажите, для примера, что буфер размером в страницу флеш-памяти, необходимый исключительно в момент сохранения изменений конфигурации, должен быть выделен статически. Даже если он занимает до четверти всей RAM.
А потому уже перейдем к обсуждению того, можно ли вообще, например, в ESP32 c RTOS обойтись без динамического распределения памяти. И насколько разумно для встроенного веб-сервера статически выделять память.
Аргументация потрясающая. Ну вперед, докажите для начала ложность моего утверждения: "Если хватает памяти на одновременную работу интерфейса конфигурации и на обслуживание датчиков и насосов - хорошо. Но это совсем не всегда так."
А потом уже вернемся к тому, насколько инертно изменение влажности земли.
Ну и задавайте. Контроллеры насосов и датчиков аллоцированы сразу
Вы вообще читаете на что отвечаете? Я же писал: "Если нужно динамическое распределение памяти, то выделять её надо ещё при инициализации".
Другая проблема, как тоже я писал, "в тех случаях, когда это невозможно".
Если хватает памяти на одновременную работу интерфейса конфигурации и на обслуживание датчиков и насосов - хорошо. Но это совсем не всегда так.
Даже во время работы, если параметры регулирования подбираются автоматически, то памяти может не хватать на одновременную калибровку всех датчиков и насосов.
Так то если памяти много можно писать на питоне и не заморачиваться с плюсами.
Можно. Но можно упереться в производительность. Например, ПИД регулирование с автоподстройкой методом многомерного сканирования Вишняковой нескольких одновременно включенных насосов, на Python может оказаться слишком ресурсоемкой задачей для МК из-за издержек динамической типизации. Впрочем, ТС обошелся вообще без ПИД регулирования, опытным путем подбирая параметры, исходя из размера горшков и мощности насосов, на удивление обеспечивающих одинаковый расход воды при разном его уровне в накопительном баке )))
Если насосов всего пара, то даже PMS171B-S08 за 10 рублей подойдет. Вот только Arduino IDE Padauk не поддерживает и через USB его без дополнительного оборудования, причем совсем не дешевого, не прошить. Я всё же пытаюсь держаться рамок DIY уровня Arduino )
Какой смысл в динамическом выделении памяти, когда мы заранее знаем, что подключено к контроллеру?
А если не знаем на момент прошивки, позволяя пользователю задавать всё в динамике, сохраняя конфигурацию в EEPROM или флеш? Не предлагать же своей жене или бабушке перепрошивать МК, если захотелось добавить цветок или датчик из фиалок переставить в алоэ?
Возвращаешься из отпуска- соседи залиты, цветы засохли, на контроллере бодро мигает лампочка ;)
Или МК уже обругался электронными письмами или сообщениями в Telegram через HA. В любом случае, ошибку надо обрабатывать так, чтобы последствия были минимальны. Это как раз при уходе в перезагрузку можно соседей залить, а не при аварийном завершении работы с отключением всех насосов.
Если поменять МК на более современный, то памяти будет намного больше. Например, RP2040-Zero сейчас можно купить дешевле, чем Arduino UNO. А там SRAM на два порядка больше, чем в ATMega328.
Если нужно динамическое распределение памяти, то выделять её надо ещё при инициализации, а в тех случаях, когда это невозможно - обрабатывать ошибку нехватки памяти с индикацией этого события каким-то способом. Хоть светодиодом.
Тоже самое можно сказать и про SRAM против DRAM. Причем в этом случае выигрыш будет очень существенным. Причем не раз в месяц после перезагрузки, а всё время. Но цена...
Для современных МК, работающих на сотнях мегагерц, такая persistent memory в некоторых случаях представляет интерес, так как почти не требует кеширования кода. Вот только RAM и NVRAM тогда должны находится на одном уровне для CPU. Чтобы именно программа решала, что необходимо хранить в RAM, а что в памяти с ограниченным количеством циклов чтения/записи. Но на практике, не часто встречается код, при выполнении которого действительно возникают задержки при обращении к флеш-памяти. Даже в случае SPI доступа к флеш-памяти, как в ESP32.
Для вычислительных систем общего назначения, где размер оперативных данных на порядок-другой превышает размер редко изменяемых данных, такой подход вряд ли будет востребован.
Ну и цена играет немалую роль. Та же SRAM намного быстрее DRAM и требует для хранения информации микроамперы. Но дорого.
Например, счетчик транзакций в PostgreSQL на некоторых высоконагруженных серверах упирается, в ограничение в 32 бит (4 миллиарда) в течении часа-двух. То есть, в 10 миллионов он упрется меньше, чем через минуту.
Так что энергозависимая память используется не только из-за её скорости, но также потому, что позволяет практически неограниченное количество циклов чтения/записи.
Я специально взял низкую частоту, чтобы начинающие могли это повторить не трогая параметры симуляции. Но, в принципе, задача решаема и для более высоких частот. Просто требует при этом более глубокого понимания ограничений SPICE и конкретной реализации симулятора.
Я же говорю, недостаток опыта )))
Вы просто не умеете программировать, поэтому и не можете представить, что программа при ошибке выделения памяти может не падать, а внятно информировать пользователя, какие из заданных им параметров можно изменить и в какую сторону, чтобы программа могла продолжить работу.
На ESP32 я прямо в веб-интерфейсе такие параметры подсвечивал, что даже домохозяйке должно быть понятно.
Если Вы ни разу не сталкивались с нехваткой памяти на принтерах, коммутаторах, роутерах и т.п., то это говорит лишь о недостатке Вашего опыта.
Можно использовать BlueTooth/ZigBee влагозащищенные датчики, что автоматически решает первые две проблемы и последнюю.
Для стабильности измерений лучше медиана, чем среднее.
При большом количестве датчиков я бы предпочёл насосам гидроаккумулятор и электромагнитные клапаны, что позволило бы подключать цепочкой, а не звездой. Но это уже дело вкуса.
Не предлагать же своей жене или тёще перепрошивать МК, если захотелось добавить цветок или датчик из фиалок переставить в алоэ?
А то, что количество поддерживаемых датчиков может зависеть от параметров задаваемых пользователем Вы так и не смогли представить?
Потому что пользователь добавил датчик или включил протоколирование на SD-карту и ушел не посмотрев на результат? )))
С точки зрения безопасности при работе с памятью - это совершенно не разумно. Намного надежней выделять динамически память для буферов страницы флеша, сектора FAT на SD-карте или MQTT сообщения, корректно обрабатывая ошибки выделения памяти, чем писать свою реализацию динамической работы с памятью в пуле.
Откуда уверенность в безошибочности своего кода? )))
Просто проверяйте успешность выделения памяти, а память, необходимую для аварийного завершения, выделяйте заранее. Зато сможете адекватно сообщить пользователю, что, для примера, либо ему надо уменьшить количество насосов, либо сократить глубину хранения истории температур и влажности с датчиков.
А вот если Вы напишете работоспособный аналог lwip без динамического выделения памяти - я сильно удивлюсь. И да, поливалка тоже вполне может работать с использованием MQTT. А в случае интеграции этой поливалки в HA, MQTT становится обязательным требованием.
Почему не спасёт? Например, если не хватает памяти для 10 датчиков и 512-байтного буфера для SD-карты, она просто об этом сообщит и пользователь будет вынужден или ограничиться 9 датчиками, или отказаться от протоколирования на SD-карту.
С этим никто не спорит. Но для решения этой проблемы известны пути решения.
Употребление слова "всегда" - уже признак демагогии. Так что возвращайтесь к доказательству того, что утверждали Вы.
Докажите, что не нужны МК с конфигурацией задаваемой пользователем и от которой может зависеть потребность в оперативной памяти.
Докажите, для примера, что буфер размером в страницу флеш-памяти, необходимый исключительно в момент сохранения изменений конфигурации, должен быть выделен статически. Даже если он занимает до четверти всей RAM.
А потому уже перейдем к обсуждению того, можно ли вообще, например, в ESP32 c RTOS обойтись без динамического распределения памяти. И насколько разумно для встроенного веб-сервера статически выделять память.
Аргументация потрясающая. Ну вперед, докажите для начала ложность моего утверждения: "Если хватает памяти на одновременную работу интерфейса конфигурации и на обслуживание датчиков и насосов - хорошо. Но это совсем не всегда так."
А потом уже вернемся к тому, насколько инертно изменение влажности земли.
И где ссылка на это правило? У меня почему-то намного чаще динамическое распределение памяти требуется.
Для Вас? )))
Вы вообще читаете на что отвечаете? Я же писал: "Если нужно динамическое распределение памяти, то выделять её надо ещё при инициализации".
Другая проблема, как тоже я писал, "в тех случаях, когда это невозможно".
Если хватает памяти на одновременную работу интерфейса конфигурации и на обслуживание датчиков и насосов - хорошо. Но это совсем не всегда так.
Даже во время работы, если параметры регулирования подбираются автоматически, то памяти может не хватать на одновременную калибровку всех датчиков и насосов.
Можно. Но можно упереться в производительность. Например, ПИД регулирование с автоподстройкой методом многомерного сканирования Вишняковой нескольких одновременно включенных насосов, на Python может оказаться слишком ресурсоемкой задачей для МК из-за издержек динамической типизации. Впрочем, ТС обошелся вообще без ПИД регулирования, опытным путем подбирая параметры, исходя из размера горшков и мощности насосов, на удивление обеспечивающих одинаковый расход воды при разном его уровне в накопительном баке )))
Если насосов всего пара, то даже PMS171B-S08 за 10 рублей подойдет. Вот только Arduino IDE Padauk не поддерживает и через USB его без дополнительного оборудования, причем совсем не дешевого, не прошить. Я всё же пытаюсь держаться рамок DIY уровня Arduino )
А если не знаем на момент прошивки, позволяя пользователю задавать всё в динамике, сохраняя конфигурацию в EEPROM или флеш? Не предлагать же своей жене или бабушке перепрошивать МК, если захотелось добавить цветок или датчик из фиалок переставить в алоэ?
Или МК уже обругался электронными письмами или сообщениями в Telegram через HA. В любом случае, ошибку надо обрабатывать так, чтобы последствия были минимальны. Это как раз при уходе в перезагрузку можно соседей залить, а не при аварийном завершении работы с отключением всех насосов.
Если поменять МК на более современный, то памяти будет намного больше. Например, RP2040-Zero сейчас можно купить дешевле, чем Arduino UNO. А там SRAM на два порядка больше, чем в ATMega328.
Если нужно динамическое распределение памяти, то выделять её надо ещё при инициализации, а в тех случаях, когда это невозможно - обрабатывать ошибку нехватки памяти с индикацией этого события каким-то способом. Хоть светодиодом.
Тоже самое можно сказать и про SRAM против DRAM. Причем в этом случае выигрыш будет очень существенным. Причем не раз в месяц после перезагрузки, а всё время. Но цена...
Для современных МК, работающих на сотнях мегагерц, такая persistent memory в некоторых случаях представляет интерес, так как почти не требует кеширования кода. Вот только RAM и NVRAM тогда должны находится на одном уровне для CPU. Чтобы именно программа решала, что необходимо хранить в RAM, а что в памяти с ограниченным количеством циклов чтения/записи. Но на практике, не часто встречается код, при выполнении которого действительно возникают задержки при обращении к флеш-памяти. Даже в случае SPI доступа к флеш-памяти, как в ESP32.
Для вычислительных систем общего назначения, где размер оперативных данных на порядок-другой превышает размер редко изменяемых данных, такой подход вряд ли будет востребован.
Ну и цена играет немалую роль. Та же SRAM намного быстрее DRAM и требует для хранения информации микроамперы. Но дорого.
В таком виде UltraRAM заменяет SSD, но не DRAM
Например, счетчик транзакций в PostgreSQL на некоторых высоконагруженных серверах упирается, в ограничение в 32 бит (4 миллиарда) в течении часа-двух. То есть, в 10 миллионов он упрется меньше, чем через минуту.
Так что энергозависимая память используется не только из-за её скорости, но также потому, что позволяет практически неограниченное количество циклов чтения/записи.
Обыкновенная копроэкономика
Я специально взял низкую частоту, чтобы начинающие могли это повторить не трогая параметры симуляции. Но, в принципе, задача решаема и для более высоких частот. Просто требует при этом более глубокого понимания ограничений SPICE и конкретной реализации симулятора.
Ну я бы не сказал, что всё настолько плохо. Кое-как мультивибратор симулируется.