Есть прерывание с периодом 1 мс, где инкрементируется 32-разрядный счетчик:



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



Истек ли интервал, проверяется так:



Всё хорошо, но примерно через 50 дней счетчик TSysTimer::Counter переполнится и всё сломается. Как красиво это обойти? При этом можно наложить ограничение, что формируемый интервал никогда не превышает половины (или даже четверти) периода счетчика, а проверка переполнения тоже делается часто, много раз за период счетчика.

Нужно не сравнивать числа, а вычитать. Тогда отрицательная разность из-за ограничения разрядности превратится в положительную.

+1. Кстати, стандарт Си гарантирует, что при вычитании (unsigned int) - (unsigned int) результат будет корректным, пока разница во времени не превышает те самые 50 дней (для 32 бит), несмотря на переполнение первой или второй переменной.

+1 Всегда так делаю.

не знаю, как на ARM, а для x64 вычитание не прокатывает (gcc 4.7.2):

Вы невнимательно читали. Типы должны быть unsigned int.
А в вашем примере перед вычитанием значения приводятся к типу int (он же int64_t) со всеми вытекающими...

О, спасибо, точно! А я было зациклился на сравнениях и чуть не погряз в условиях.

Важное замечание:
Вычитать нужно беззнаковые величины иначе результат будет неверный.


О! scifi уже написал

а в NT x86 таймер 64 бита... и процедура получения значения для сравнения не используется ничего похожего на запрещение прерываний. Вам такое ней подойдёт? кроме того, можно ещё получить точный часов с "некруглой" частотой прерываний.

А я вечно горожу проверку что типа если текущее меньше начального, то сложить хвост и начала... вот я балда)))

хотя последний раз я дошел до того что просто в таймере сделал
if(Delay >0)
Delay --;

и если надо выждать 10 тиков, то
Delay = 10; и проверяю что он не 0....

у вас все равно переменная Start задействована, так чего ей значение хранить, когда она может просто считаться назад?

Возможно, и для знаковых будет все нормально.

Да, возможно. Но это может зависеть от процессора и/или компилятора. А для типа unsigned int это гарантируется стандартом языка Си.

для без знакового все просто, пусть 8 бит

250 - старт

0 - 250 == -250 = 0x06 (остальные биты улетают из за переполнения) == 6.
то есть 0 - 250 == 256 - 250 = 6

а если знаковое, то переполнение на 127.
и после 127 идет -128
120 - старт
-128 - 120 == -248 == 8 как должно было бы быть.

Все по битам верно, думаете компилятор может вмешаться?

Дак 64 бита никогда не переполнятся за всю жизнь

да ну бросьте.
это всего навсего
584 942.41735507203247082699137494 года
ничто по сравнению с жизнью вселенной...

если тик микросекунда..., а если пико?

НА примере XP дискретность 100 наносекунд. Инкрементируется на время периода системного тика.

если 100 нан, то переполнение через 58.5 тыс лет.

Лично я рассчитываю что мои устройства спокойно преодолеют этот рубеж)

Во-первых, покажите в моём примере, где "значения приводятся к типу int (он же int64_t)"
Во-вторых, смотрите на вариант с unsigned int (правда, уже gcc 4.8.1), на всякий случай - 64-битные регистры те, что на букву r:

но конечно, это кривой пример, так как разность двух беззнаковых больше 0 и компилятор прав, что использует здесь проверку на равенство.
а вот при сравнении беззнакового числа с результатом вычитания двух беззнаковых чисел (как в итоге сделал ТС) компилятор использует кондишн "больше или равно" в беззнаковом варианте и всё работает

Чего там показывать? Это неявное приведение. Почитайте какую-нибудь книжку про язык Си. Ищите "integer promotion".

НО в данном способе (с вычитанием) мы должны гарантировать это вычитание каждую миллисекунду. А иначе есть шанс прошляпить равенство таймера и счётчика и тогда всё посыпется. Ведь так?

Надо проверять не равенство, "а больше или равно" или "меньше или равно" - что подходит по контексту.

В этом и заключается мой вопрос. В приведённом примере вычитания - нет сравнения. Там только вычитание. И срабатывает оно только тогда когда именно равенство между счётчиком и таймером. А если использовать сравнение, то опять же упираемся в переполнение счётчика. Так как красиво то сделать?

Есть. Нужно разницу сравнить с нулем (не на равенство...).

На практике получается что если от меньшего беззнакового отнять большее беззнаковое то результат получается больше нуля, что собственно не удивительно. И данная конструкция не работает. Конечно если гарантировать программе что проверку она будет совершать точно каждую миллисекунду, то всё будет нормально. Но я бы не стал оставлять это на авось. На данный момент пришёл к такому решению: приводить разность перед сравнением к знаковому типу. И тогда всё нормально - обмануть таймер не получается какие бы значения счётчика не брать за начальные. Что об этом думаете?

вы про какой из примеров то?

return(TSysTimer::Counter - StartCount >= Interval); - возвращается не разница, а результат сравнения.

У вас есть время начала и текущее время, их разность всегда есть интервал прошедшего времени. Проблемы только рассчитать интервал больше либо равный максимальному значению счетчика, потому что в этом случае после Максимум - 1, будет следовать 0, из-за переполнения. Но с этим ничего не сделаешь, кроме моего варианта
в прерывании таймера считать назад...


думаем что вы не правы

допустим у нас беззнаковое число 4 бита, для удобства

все его значения
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15

берем любое начало, допустим 7.
все значения от 8 до 15, не вызывают вопросов 8-7 = 1,... 15-7 = 8, честно получаем время прошедшие от 7 до текущего значения.

идем дальше, счетчик переполнился и получилось
0, 0 - 7 == -7, как это представлено в битах? 1001, а что это в беззнаковом числе? О чудо это 9

15-7 = 8, 0 - 7 = 9, 1 - 7 == - 6 (1010) == 10 и так далее, до

6 - 7 = -1 (1111) = 15;

то есть до полного цикла счетчика все переполнения отрабатываются правильно)

Вот взяли мы это 7, и хотим что бы таймер сработал когда счётчик дойдёт до 12. И вы предлагаете вычитать 12 - 7 и сравнивать это с нулём, но так случилось что итерация 12 - 12 не случилась 12 - 11, а за ней уже 12 - 13, и та и другая даёт результат большей нуля в битовом выражении. И получается таймер не сработал тогда когда нужно. Разве нет?

Не так (я неправильно написал выше). Вам нужен интервал 5 (12 - 7). Текущее (стартовое) значение 7, запоминаете его. Дальше читаете значение таймера, отнимаете запомненное стартовое, и сравниваете разность с нужным интервалом.

Но таким образом на каждый случай приходится по 2 переменных: стартовое время и интервал. Если же использовать приведение разности (значение срабатывания - счётчик) к знаковому типу и сравнения получившегося с нулём, то одна переменная.

Тогда потеряете половину диапазона.

Да я как-то не рассчитываю использовать интервал более 25 дней

Кстати, стандарт языка Си говорит, что переполнение знаковых целых - это "undefined behaviour", в отличие от беззнаковых, где всё хорошо в этом плане.


Ну тогда вставьте в код assert(days <= 25). Когда наступите на эти грабли, хотя бы табличка перед носом будет :-)

да тут не вопрос диапазона, а вопрос постановки задачи....

ожидание конкретного времени == выдерживанию интервала. А интервал вычисляется без потери диапазона, но требует доп. переменной, то есть вам приходиться хранить Interval == (NeedTime - Start) и Start. Вроде как 4 байта при современных объемах памяти не большая беда...

Вычисляя разность между текущим значением таймера и начальным, мы сдвигаем точку отсчета в положение Start. И уже относительно нее определяем текущее значение таймера, и сравниваем с требуемым. Аналогичного эффекта можно добиться, если сбрасывать таймер перед запуском. Но так, как предложено, можно на одном таймере задавать сразу несколько задержек.

Да, цель именно выжать максимальную оптимизацию как по времени так и по памяти. В нынешних железах это конечно не принципиально. Но просто хочет это мой внутренний перфекционист. А использовать таймер на 25 дней - это как-то странно по моему. Для таких масштабов есть RTC.
P.S. Да и топик стартер вопрашал именно про юзанье одного счётчика для неограниченного кол-ва таймаутов, задержек и т.п.

Пипец! Не ожидал такого мусоленья здесь совершенно очевидных вещей...

Получается, что это чисто теоретическое упражнение. И правильное решение одно: ассемблер.
А на практике за такие потуги надо очень больно бить по рукам, ибо, как известно, "преждевременная оптимизация - корень всех зол".


Не спешите. В очень многих кортексах есть счётчик циклов DWT_CYCCNT, и он очень удобен для этих самых задержек. Причём в МК из серии LPC43xx с частотой 204 МГц он переполняется каждые 21 сек.

jcxz, вы предложили то же самое: использовать 2 переменных. scifi, почему же она преждевременная? я оптимизировал конкретный конечный функционал, разобрался в вопросе до конца и тщательно вдоль и поперёк оттестировал решение. Побейте тогда по рукам ещё и создателей библиотек которые оптимизируют свои творения до применения в реальных проектах. Какая-то странная логика. Счётчик циклов использую для измерений требуемых максимальную точность (единицы или десятки микросекунд, в зависимости от частоты). Но при чём тут он, не понятно?

Где Вы углядели 2-ю? Вроде всего одна: t.


scifi Вам дело говорит.
1. Кто занимается оптимизацией инкремента переменной , не пишут реальных проектов.
2. Кто пишет реальные проекты, не занимаются оптимизацией инкремента.

Считайте по пальцам из вашего примера: переменная "t" - РАЗ, переменная "TOUT" - ДВА. Про второй пункт вашего поста я промолчу.

Давайте поглядим
Плюсы минусы вашей оптимизации

Минусы
1. Меньший диапазон возможных значений в 2 раза
2. Строго говоря есть необходимость отметить это в документации, и возможные ошибки при использовании функции тем кто не в курсе.
3. Поскольку потери случаются на длинном конце использования, то еще долгий процесс выявления ошибки
4. Необходимость кучи объяснений почему вы сделали так а не иначе в коде

Плюсы
1. Вы выиграли 4 байта памяти. Даже если взять древний проц с каким нибудь 2 КБайтами памяти, то вы выиграли ~0.2% ресурса с каждого таймера. Для обычных кортексов с 48 Кбайтами 0.008%

В целом неплохо потрудились

1. Вы реально использовали миллисекундный таймер для замера интервала времени больше 25 дней?! О_о
2. Относится к первому пункту.
3. Потери НЕ СЛУЧАЮТСЯ ни в теории, ни на практике - провёл огромное кол-во тестов. Если вы считаете что возможны потери - приведите пример (буду искренне рад если вы поможете избежать этих потерь. если они возможны).
4. Кому и что нужно объяснять? По этой логике нужно объяснять и любой другой вариант.

1. Я писал что практическая ценность никакая от этого. Но именно это решение является решением для задачи поставленной топикстартером.

С чего вы взяли что TOUT это обязательно переменная???
Под TOUT имелось в виду выражение. Откройте любой учебник по си чтобы узнать значение термина expression.

1. Почему нет, я участвовал в разработке системы которая работала автономно несколько лет без сбоев, повисаний, перезагрузок. При этом у нее был миллисекундный таймер для внутреннего времени (по ряду причин РТС использовать было нельзя), и почему бы раз в месяц этой системе не синхронизировать с центром время, данные и прочее?
1.1. Вы пишите что-то только один раз? На реюзинг не рассчитываете? Почему вы уверены что ваш код не запустят для микросекундного или наносекундного таймера?

2. Вы не застали замечательную ошибку паскаля который для delay в начале работы программы делал калибровку. Он брал цикл в сколько-то тактов и считал сколько милсекунд ушло на него, потом делил одно на другое и получал калиброванное значение чтобы точнее делать delay. Где то в районе 90 годов, все программы сделанные на этом паскале хором перестали работать. Потому что частота процов так возросла, что отведенный цикл стал выполнятся за 0 мСек, и деление на 0 давало ошибку. Уверен что те кто писал библиотечную функцию тоже заложились что процы же не станут в 1000 раз быстрее)

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

3. Сделайте вашим методом паузу больше половины интервала. Там можно так исхитриться что при заданной частоте проверок и интервале, оно будет так переполнятся что в 90% случаев все будет ок, а в 10% будет второй круг. И его ловить - это задача с подвохом...

4. странные и не очевидные ходы требует больше слов для их оправдания...


решение для ТС приведено сразу же в начальных постах, оно его устроило и оно является очевидно правильным.

У меня тут тоже с коллегами разгорелся спор, можно ссылку на стандарт с упоминанием этой гарантии, не могу найти.

В стандарте С (6.2.5.9) есть такой текст:

А стандарт С++ в (3.9.1) содержит такой текст:

и ниже примечание, совпадающее по смыслу с текстом из стандарта С, про арифметику по модулю 2ⁿ.

Впрочем всё это фигня и словесная эквилибристика.
А правда жизни состоит в том, что все эти свойства и поведение знаковых и беззнаковых типов диктуются устройством АЛУ и принятым в подавляющем большинстве современных машин представлением знаковых целых в так называемом "двоичном коде с дополнением до 2".
Преимущество такого представления - то что АЛУ работает совершенно одинаково, а разница signed/unsigned учитывается только при интерпретации признаков переполнения и переноса ( C и V ), и при многоразрядной арифметике, для правильно учёта переноса из младшего слова в старшее.
Изначально С неявно предполагал именно такое представление целых (как и сделано в PDP-11, на которых он изначально появился). Альтернативные представления уже тогда были редкостью.
Все более поздние изменения стандартов в части целочисленной арифметики и сдвигов просто витиевато выражают простую мысль: "делайте что хотите, но результат должен быть такой же как на "нормальных" процессорах использующих код с дополнением до двойки".

То есть сначала было придумано АЛУ, работающее с неотрицательными целыми числами, потом придумано как представлять отрицательные числа так, чтобы не переделывать АЛУ, а уж потом сочинители стандартов попытались описать что получилось так как они умеют это делать.

Спасибо за ответ, я уже так же нашел пару сносок на буржуйских форумах.

Почитал ради интереса библиотеки stm32cubef4.
Там есть замечательная функция void HAL_Delay(__IO uint32_t Delay) и куча мест где таймауты проверяются прямо в коде аналогичным образом.
Тех кто рискнёт пользоваться этим "программным продуктом" ждёт жестокий облом через 49 дней, 17часов, 2 минуты и 47 секунд.
Повбивав би ...

Моя версия таймера:

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

Да! Только хардкор, только реверс-инжиниринг языка Си!
Мануалы придумал трус!

Причем тут это?
Покажите мне место в стандарте где написано что 2+4=6?
или место где написано 2+4=4+2

есть вещи которые описаны не стандартом а здравым смыслом и физикой природы...
так вот на пальцах

если у нас есть без знаковое от 0 до 15
2 - 12 = -10
а -10 имеет представление 0x6, что в без знаковом представлении просто 6, а теперь считаем сколько прошло с 12 до 2..
13 14 15 0 1 2 - вот и ответ... 6.
Так факт того что без знаковые не переполняются это свойства представления числа и принципов работы арифметики в компутере, а не стандарт языка...