caxapa.ru :: Первая версия: где-то забыли поставить volatile.

SciFi (25.01.2023 12:53, просмотров: 58) ответил Dingo на NUC970 BSP. Непонятная ситуация с переменной структуры, которая обновляется в прерывании. Обрабатываю пакеты сети, которым надо отметку времени. Столкнулся с ситуацией, когда время "улетает в прошлое". Раскопки привели к тому, что в прерывании, которое считает время, не обновляется значение регистра сравнения. Основное предположение сейчас - прерывание таймера имеет меньший приоритет, чем обработка сетевого пакета. Работа с сетью взята из примера, в нижний уровень сам не лез

Первая версия: где-то забыли поставить volatile.

ส็็็็็็็็็็็็็็็็็็็็็็็็็༼ ຈل͜ຈ༽ส้้้้้้้้้้้้้้้้้้้้้้้

Ответить

- Структура объявлена как volatile (поля в ней - нет). Это как-то объясняет поломку работы сети при смене приоритета? - Dingo(25.01.2023 12:59)
  - Я вообще ничего не понял из описания проблемы, извините. То ли туплю, то ли описание расплывчатое, то ли линейная комбинация того и другого... - SciFi(25.01.2023 13:06)
    - Думаю, комбо. Я ещё и на кэши грешил, но потом отбросил эту ветку, когда прочитал в память для логов значения регистров таймера. То есть ситуация: мы в обработчике сети читаем через взятие времени регистры таймера, и там по сочетанию регистров вижу, что прерывание "вот только что" было, но регистр сравнения ещё не скорректирован. В обработчиках пишу в память, а когда вижу ситуацию - прошу выплюнуть на консоль всё накопленное: 64 Мб позволяют. - Dingo(25.01.2023 13:16)
      - Яснее не стало. "Взятие времени"? "Регистр сравнения"? Что? Где? Когда? Зачем? Почему? - SciFi(25.01.2023 13:19)
        
        Таймер считает без остановки, от нуля до 2^24, при совпадении с регистром сравнения вырабатывается запрос на прерывание. Приоритет таймера ниже, чем прерываний сетевого интерфейса. В обработчике сети есть "взять время" - получаем точное набортное время, вычисляется с использованием регистров таймера. Но возникает ситуация, когда регистр счёта перешагнул значение регистра сравнения, но само значение регистра сравнения ещё не обновилось (запрос на прерывание есть, но мы в Dingo(46 знак., 25.01.2023 13:26)
        
        Ну это да, такая ситуация возможна. Я повсеместно применяю аппаратный таймер для меток времени, и он переполняется довольно часто. Только прерывание не использую, гораздо проще делать так: SciFi(430 знак., 25.01.2023 13:36)
        
        Спасибо каждому ответившему. Решил тем, что в функции чтения времени предусмотрел ситуацию не только возникновения прерывания ^{из пользовательского кода}, но и из более приоритетного опросом флага контроллера. Примерно так. Dingo(451 знак., 26.01.2023 06:17)
        
        Если запрос на прерывание таймера висит необработанным, значит текущее время нужно скорректировать на единичку, обычно так. - =AlexD=(25.01.2023 13:33)
        
        +1 Видимо в коде количество переполнений суммируется с текущим значением таймера. Получается что таймер уже сбросился, а количество переполнений еще не увеличилось, сумма улетает в прошлое. AlexBi(166 знак., 25.01.2023 15:20)
        
        Да, именно так. Прошу извинить, если невнятно написал. Только не переполнений, а совпадений, таймер продолжает счёт. (ну вот такой таймер! :-/ ) - Dingo(26.01.2023 05:46)
        
        А автоматического сброса таймера по совпадению с регистром сравнения нет? Если в битах порыться. По логике должно быть, иначе оно всё время будет глючить. - =AlexD=(25.01.2023 13:31)
        
        Весь Timer Control and Status Register (TMR_CSR) Но может выйти ещё хуже: событие произошло, а мы его пропустили. Dingo(1 знак., 25.01.2023 13:44, картинка)
        
        Вы Periodic mode, надеюсь, используете? - LightElf(25.01.2023 19:19)
        
        Конечно, нет. Все режимы кроме continous сбрасывают счёт таймера при записи регистра сравнения. ETMR не смотрел в этом отношении. Dingo(439 знак., 26.01.2023 05:52)
        
        Чёт я не пойму изыска. Зачем обновлять регистр сравнения? Делаете переменные задержки на том же таймер или что? - LightElf(26.01.2023 10:07)
        
        Период счёта не кратен секунде, да и нет двух одинаковых кварцев. Например, у меня по результату вместо 12`000`000Гц оказался 12`000`126Гц. И это не точно: может в референсном устройстве тоже не ровно, а подстраиваться к нему надо. Ну и опять же - ошибка всё равно накопится, даже если разница будет в единицы Гц или даже доли. Поэтому - постоянно подводить локальные часы. - Dingo(26.01.2023 10:13)
        
        Ну если вам нужна такая точность, что начинает существенную роль играть разброс кварцев, то вам прямая дорога в IEEE1588. Там и 64-битный таймер на 150МГц, и поправки дробные и синхронизация с мастером. - LightElf(26.01.2023 13:09)
        
        Я бы их в другом месте подводил. Зафиксировал бы таймер с периодом 12000000, чтобы в этом месте геморроя не было, а поправки вносил бы потом при помощи нехитрой арифметики. - SciFi(26.01.2023 10:17)

ARM, RISC-V контроллеры