D18B20, Arduino, MODBUS, Master SCADA

Коллеги, собрал действующий макет.

Управляю ШИМ нагрузки через прерывания при помощи библиотеки ticker.h.

Все на аппаратном уровне работает. Т.е. лампа (аналог нагрузки для тестов) послушно загорается и гаснет.

Не очень нравится мне мой алгоритм. Покритикуйте пожалуйста.

Реализовано: на входе параметр – мощность ТЭН, целое число от 0 до 100 (проценты мощности). Прерывание стучит каждые 100 мс. Если мощность, например 1%, то ТЭН включается на 0.1 секунду, а затем пауза 9.9 секунд. Если мощность, например 60%, то ТЭН работает 6 секунд, затем пауза 4 секунды.

Не слишком это долгие паузы? Не могу придумать алгоритм как это изящнее реализовать. Может идеи есть какие, или почитать что?

По прерываниям рекомендуется использовать для выставления флагов, а выполнять непосредственные действия в основном цикле. Веб и прерывания очень не дружат.

Придумывать алгоритм не нужно, есть простой и удобный Брезенхем, который размазывает например в вашем случае 6 секунд равномерно по всему интервалу.

В ЛС кину ссылку на наглядную модель.

@ersivv

Спасибо, изучу.

В основном цикле ничего в идеале быть не должно. Иначе вся система превратится в сплошную кашу, неразрывно связанную и нечитаемую. Я модульно делаю.

Связи между прерываниями и вебом нет никакой. Прерывания бегут на чипе, веб обрабатывается по мере запросов на обновление данных на странице и т.д.

skalinas писал(а):

Тут реализован алгоритм

Спасибо, посмотрю

ers писал(а):

Из основного цикла можно разбить на подмодули

Это понятно. Блин, хочу уже хоть как-то промежуточно финализировать и выпустить уже в шаловливые ручонки сообщества))

Счастливчик писал(а):

Покритикуйте пожалуйста.

Роман писал(а):

3. По Брезенхему. При этом способе в нагрузку всегда подаются [полу]периоды сетевого напряжения целиком, но не все, а только часть. Например, если из каждых 100 [полу]периодов подать в нагрузку только 20, то мощность, поданная в нагрузку, будет 20% от максимальной. Причём эта часть [полу]периодов как бы “размазывается” по времени, чтобы достичь более равномерного распределения “рабочих” и “нерабочих” [полу]периодов. Такой метод позволяет регулировать мощность лишь источников тепла (ТЭНов), так как при подключении в качестве нагрузки лампы она будет мигать. Помех по сети такой метод создаёт мало, так как включение и отключение тока нагрузки всегда происходит в момент перехода сетевого напряжения через ноль.

Дальше там обсуждение, почитай. Два варианта реализации в Экселе было. Алгоритм сводится к десятку строк целочисленной арифметики.

ers писал(а):

По прерываниям рекомендуется использовать для выставления флагов

Беда в том, что http не единственный критичный к задержкам процесс в системе. Та же программная реализация 1-Wire для DS18x20 тоже на временных интервалах построена.

Еще одна беда – прерываний, как правило, бывает больше одного, и чтобы они не прерывали друг друга, на время обработки одного остальные запрещаются. Со всеми вытекающими.

Поэтому стараются в обработке прерываний выполнять минимум простых действий (установка/сброс флагов, старт/рестарт/стоп таймеров и т.п.), а “тяжелый” код выполнять в порядке, тыскыть, очереди.

Вот, кстати, Брезенхем:

dy = !(2*z > xm) ;    // управление на триак; xm=100 – максимально возможная уставка в %; если двойная ошибка z больше xm, триак не открывается на следующей полуволне

z = z – ym;                 // текущая ошибка, вначале =0; ym – текущая уставка в %

If (dy) {z = z + xm}; // Коррекция ошибки для следующего шага

И все!!!

Роман писал(а):

Есть такой стиль программирования, когда прерывания идут довольно часто, и есть счётчик их (прерываний), считающий до некоторого значения, а потом обнуляющийся, и так постоянно.

Вариант – одно прерывание (генератор “тиков”), и программные счетчики-таймеры для каждой задачи. Как таймер сработал – задача выполняется. Грубо говоря, прежде чем что-то делать, задача проверяет состояние таймера.

По-моему, это как раз и называется CASE-программированием 🙂

“Задачи” либо встраиваются в основной цикл, либо делаются функциями. С функциями оно, конечно, читабельнее, но – накладные расходы времени на вызов-возврат, бывает критично.