Почему? Под управлением RTOS вполне можно иметь множество задач с такими циклами. Это даже не считая того, что PIO в RP2040 почти всегда работает именно по такому циклу. Так же, как нередко, DMA в кольцевой буфер, например, с ADC.
Зря не упомянули River Logic, предлагающий весьма дружелюбный к пользователю подход, при этом позволяя погрузиться глубже для более эффективного использования его (и Gurobi) возможностей
Я имею дело, преимущественно, с СУБД, где соотношение чисто вычислительной нагрузки и работы с памятью явно смещены в сторону последнего. Более того, на некоторых профилях нагрузки выключение гиперпоточности увеличивает производительность, а включение, соответственно, её снижает..
По моим наблюдениям, можно легко упереться не в производительность ядер, а в скорость доступа к DRAM. Применение CPU с бОльшим размером кеша помогает, но радикально проблему не решает.
Я же дал ссылку на репозиторий! Изучите код. Откуда я знаю о какой кривой Вы речь ведете: температуры воздуха, зёрен, нагревателей или влажности, кислотности, насыщенности одного из контрольных цветов, скорости одного из приводов или вентиляторов?
В src/test/data/profile1.json лежит пример простого тестового профиля. Вот и изучите его для начала.
Но раз вам не хватило 6 Мб, значит вы хранили что то другое.
Даже в пределах одной партии зерен технологу нужно больше десятка программ. Не говоря уже о разных программах для разных сортов, разного географического происхождения и разных годов урожая кофе.
Для недорогих ростеров стоимостью до миллиона рублей обычно используются opensource Artisan. Там репозиторий не больше гигабайта, так что вполне можете склонировать и изучить.
Для чего-то более серьёзного используется уже проприетарный софт и ПЛК.
программа на lua
Lua плохо подходит даже для ПИД-регулирования, не говоря уже о более сложных моделях прогнозирования. Из простого, тут скорее Python с numpy и прочими библиотеками на C/C++.
Точно ошиблись. Коллеги как то делали на ПЛК110 Овен только обжарку кофе. Ну так не хватило 6МБ энергонезависимой памяти на борту для всех рецептур, которые хотел заказчик. Пришлось делать загрузку рецептур из CODESYS по Ethernet.
Только если найдется идиот, который в кофемашину установит SSD. Это даже не считая усложнения схемотехники и снижения надёжности устройства при использовании внешней памяти для МК.
Можно на Ваш github взглянуть? На мой то я не раз уже ссылки давал. И насколько сложно использовать внешнюю память, там хорошо видно.
Мои заказчики почти всегда такое исключают, так как всё предусмотреть невозможно. Но при 500 градусах и 350 атмосферах последствия могут быть куда хуже, чем при заливе соседей водой )
паранойя зашкаливает
Так у меня тоже самое. С "Невинномысским азотом" проект закончили, так теперь бразильские заводы начались )
Сложно - придумать как это сделать на языке пользователя, чтобы было понятно, не мешало работать и не приводило к неожиданным проблемам.
Ничего сложного. Я же уже давно писал решение: "внятно информировать пользователя, какие из заданных им параметров можно изменить и в какую сторону, чтобы программа могла продолжить работу.
На ESP32 я прямо в веб-интерфейсе такие параметры подсвечивал, что даже домохозяйке должно быть понятно."
достаточно будет резервуара приподнятого на пару метров и самотека
Так это и есть один из видов гидроаккумуляции. Причем весьма популярный до сих пор в странах с мягким климатом. И, насколько я знаю, единственный используемый в гидроаккумулирующих электростанциях.
В общую магистраль импульсный счетчик воды.
Я бы не усложнял аппаратную часть, так как ПИД регулирование даст куда более точный результат, позволяя поддерживать влажность в заданных пределах. Да это и проще, чем анализировать дебет воды и испарение, в зависимости от температуры, влажности воздуха и попадания солнечных лучей на почву.
Аварийные ситуации
Тут огромный простор для деятельности. Например, в Невинномысске у нас почти везде тройное резервирование плюс автоматические чисто аппаратные аварийные системы. Так что всё зависит от паранойи создателя системы )
Для дома я бы в аварийной ситуации просто обесточивал систему. Слишком мокро - возможно будет выливаться из горшка. Слишком сухо - возможно трубка полива вывалилась из горшка и льет на пол. Лучше цветочки засохнут, чем залить соседей. Но это моё субъективное мнение.
Ваше предложение выглядит как сообщение на смартфоне: Можете включить запись видео, 7 видеозаписей осталось )))
Рецепты могут занимать разный объем памяти. Теоретически, можно такой рецепт наворотить из смеси зерен разного помола и жарки, что он вообще всю память займёт.
Для устройства, которое используется еще кем-то кроме его создателя, это плохой дизайн.
Ну так отберите у жены и тёщи смартфоны, ведь там тоже памяти может не хватить )))
А то ведь такой ужас! Снимает пользователь видео, а ему вдруг смартфон заявляет, что память закончилась. Очень интересно, какой же дизайн собрались предложить для этого Вы? )))
То есть, кофемашина знающая только восемь рецептов приготовления кофе, заложенных производителем - это хорошо. А кофемашина, поддерживающая множество задаваемых пользователем рецептов, количество которых ограничено лишь доступной памятью - уже говнокод? )))
Почему? Под управлением RTOS вполне можно иметь множество задач с такими циклами. Это даже не считая того, что PIO в RP2040 почти всегда работает именно по такому циклу. Так же, как нередко, DMA в кольцевой буфер, например, с ADC.
До сих пор храню честно купленный JA2 от Буки. Могу сделать копии дисков.
Зря не упомянули River Logic, предлагающий весьма дружелюбный к пользователю подход, при этом позволяя погрузиться глубже для более эффективного использования его (и Gurobi) возможностей
Я имею дело, преимущественно, с СУБД, где соотношение чисто вычислительной нагрузки и работы с памятью явно смещены в сторону последнего. Более того, на некоторых профилях нагрузки выключение гиперпоточности увеличивает производительность, а включение, соответственно, её снижает..
По моим наблюдениям, можно легко упереться не в производительность ядер, а в скорость доступа к DRAM. Применение CPU с бОльшим размером кеша помогает, но радикально проблему не решает.
В описании профиля, само собой.
Вот нашел очень упрощенно, но зато понятным для "чайников" языком.
Я же дал ссылку на репозиторий! Изучите код. Откуда я знаю о какой кривой Вы речь ведете: температуры воздуха, зёрен, нагревателей или влажности, кислотности, насыщенности одного из контрольных цветов, скорости одного из приводов или вентиляторов?
В src/test/data/profile1.json лежит пример простого тестового профиля. Вот и изучите его для начала.
Даже в пределах одной партии зерен технологу нужно больше десятка программ. Не говоря уже о разных программах для разных сортов, разного географического происхождения и разных годов урожая кофе.
Для недорогих ростеров стоимостью до миллиона рублей обычно используются opensource Artisan. Там репозиторий не больше гигабайта, так что вполне можете склонировать и изучить.
Для чего-то более серьёзного используется уже проприетарный софт и ПЛК.
Lua плохо подходит даже для ПИД-регулирования, не говоря уже о более сложных моделях прогнозирования. Из простого, тут скорее Python с numpy и прочими библиотеками на C/C++.
Точно ошиблись. Коллеги как то делали на ПЛК110 Овен только обжарку кофе. Ну так не хватило 6МБ энергонезависимой памяти на борту для всех рецептур, которые хотел заказчик. Пришлось делать загрузку рецептур из CODESYS по Ethernet.
Вот это я и называю идиотизмом. Вы бы еще программы лифта предложили на SD-карте держать )))
Сначала дайте ссылку на Ваш github, а потом я буду отвечать на подобные вопросы.
Только если найдется идиот, который в кофемашину установит SSD. Это даже не считая усложнения схемотехники и снижения надёжности устройства при использовании внешней памяти для МК.
Можно на Ваш github взглянуть? На мой то я не раз уже ссылки давал. И насколько сложно использовать внешнюю память, там хорошо видно.
Мои заказчики почти всегда такое исключают, так как всё предусмотреть невозможно. Но при 500 градусах и 350 атмосферах последствия могут быть куда хуже, чем при заливе соседей водой )
Так у меня тоже самое. С "Невинномысским азотом" проект закончили, так теперь бразильские заводы начались )
Ничего сложного. Я же уже давно писал решение:
"внятно информировать пользователя, какие из заданных им параметров можно изменить и в какую сторону, чтобы программа могла продолжить работу.
На ESP32 я прямо в веб-интерфейсе такие параметры подсвечивал, что даже домохозяйке должно быть понятно."
Так это и есть один из видов гидроаккумуляции. Причем весьма популярный до сих пор в странах с мягким климатом. И, насколько я знаю, единственный используемый в гидроаккумулирующих электростанциях.
Я бы не усложнял аппаратную часть, так как ПИД регулирование даст куда более точный результат, позволяя поддерживать влажность в заданных пределах. Да это и проще, чем анализировать дебет воды и испарение, в зависимости от температуры, влажности воздуха и попадания солнечных лучей на почву.
Тут огромный простор для деятельности. Например, в Невинномысске у нас почти везде тройное резервирование плюс автоматические чисто аппаратные аварийные системы. Так что всё зависит от паранойи создателя системы )
Для дома я бы в аварийной ситуации просто обесточивал систему. Слишком мокро - возможно будет выливаться из горшка. Слишком сухо - возможно трубка полива вывалилась из горшка и льет на пол. Лучше цветочки засохнут, чем залить соседей. Но это моё субъективное мнение.
Ваше предложение выглядит как сообщение на смартфоне: Можете включить запись видео, 7 видеозаписей осталось )))
Рецепты могут занимать разный объем памяти. Теоретически, можно такой рецепт наворотить из смеси зерен разного помола и жарки, что он вообще всю память займёт.
То есть пользователю нельзя даже кинокамеру давать, так как там плёнка заканчивается? )))
Ну так отберите у жены и тёщи смартфоны, ведь там тоже памяти может не хватить )))
А то ведь такой ужас! Снимает пользователь видео, а ему вдруг смартфон заявляет, что память закончилась. Очень интересно, какой же дизайн собрались предложить для этого Вы? )))
Вы действительно не понимаете, что количество рецептов ограничено их сложностью и объёмом памяти? Или просто включили дурака?
То есть, кофемашина знающая только восемь рецептов приготовления кофе, заложенных производителем - это хорошо. А кофемашина, поддерживающая множество задаваемых пользователем рецептов, количество которых ограничено лишь доступной памятью - уже говнокод? )))