Переменные объявлены так.

Далее в коде есть такая проверка.

Что человек хотел проверить делением по модулю?

Условие будет истинным, когда delay кратно txDelay, то есть делится на него без остатка.
Такая конструкция может быть использована для исполнения кода каждые txDelay периодов, если delay увеличивается каждый период.
Например, если каждые 1 мс delay увеличивать на 1, а txDelay = 5, то код под условием if будет выполняться каждые 5 мс.

Я ответил на похожий ваш вопрос в соседней ветке:


т.е. PulseOut() вызывается каждый раз, когда меняется третий разряд (сотни) переменной counter, вернее, когда counter кратен 100.

спасибо за объяснение


и действительно

p.s не! не меняется!

ааа... понял в чем тут дело . спасибо.

тут есть проблема.
если счетчик обновляется медленно то это условие присутствует какое то время и я получу несколько пульсов вместо одного.

Логично ставить проверку условия после обновления счётчика.
Если никак, тогда тоже есть варианты:

или даже так:

это неплохое решение хотя PulseDown() тяжеловат у меня и все время молотить его накладно.

интересно, сколько индусов читает эту ветку
Рэбята, ви все под гипнозом? Что это:

?

где вы видели проц в котором посчитать модуль дешевле чем сравнить?
вот так говнокод и получается.

у нас с ae_ была дискусия о другом топике. надо было отследить изменение третьей цифры справа. скажем было 000199 стало 000200. отсюда модули и прочие навороты.

Пахан, не гони -- тут прозрачно обсуждался принцип, хотя мне не нравятся условия типа "if !(counter % 100) ...", а компилятору тем более.
Какой народ двинул во программеры -- такой и [г]кодит, наушники с бурдой не снимая и портя кармы о 9D...
В реальной обстановке можно counter наращивать и сравнивать с верхним пределом 100, и по достижении обнулять.

Gotan Project это не бурда. это самое то для програмера.

Там это относится к преобразованию Bin -> BCD - это не вызывает смущения, ибо доказано, что модулями и делениями эффективнее всего выходит,
а в обсуждаемом примере - таймер или счетчик
Ну тогда конечно, если это сфероконь без предупреждения - не смею вмешиваться.

А интересно, где и кем доказано?

Раньше вроде было доказано, что эффективнее (в случае, если у процессора нет аппаратной поддержки деления) всего алгоритм, который по очереди в цикле вычитает сначала по 10000, потом по 1000, потом по 100, ну и т.д., считая каждый раз, сколько было вычитаний на каждом этапе. Так как, деление (в его двоичном исполнении в стандартной либе) всегда имеет столько итераций вычитания, сколько разрядность числа, для каждой цифры (допустим, 16), а в данном случае - делении сразу в десятичном исполнении - на каждую цифру уходит от 1 до 10 итераций вычитания, что по любому меньше. А объем кода, в пересчете на его размер в машинных кодах, плюс-минус копейки, одинаков.

Да, и плюс тому деление и остаток могут использоваться еще где-то, а вычитание 10 100 1000- вряд ли.