SciFi (24.04.2024 16:18, просмотров: 41) ответил ar-elec на Изобретение велосипеда с прерываниямиส็็็็็็็็็็็็็็็็็็็็็็็็็༼ ຈل͜ຈ༽ส้้้้้้้้้้้้้้้้้้้้้้้
-
- Есть аппаратный таймер, считающий в пределах uint32. Хочется, чтобы
считал до uint64. Я использую функцию, которая видит, насколько
изменилось значение таймера между вызовами и добавляет эту разницу
в переменную uint64 - ar-elec(24.04.2024 16:25)
- 1) "заворот кишок" не анализируется (переход с 99 на 3) Zoro(142 знак., 24.04.2024 16:34)
- Если я правильно понял, речь в 1 про то, что cnt_old, допустим, уже
близко к максимуму, а cnt уже перебежало через него и стало опять
маленьким? ar-elec(391 знак., 24.04.2024 16:45)
- нафиг int32_t. использование uint32_t сильно упрощает. - Vit(Сегодня, 17:04)
- Возможно, сама хотелка хотелка перейти на 64 бита неуместна. Оно
таки нужно? Намного проще и безопаснее определить переполнение,
если чтение счетчика происходит не реже 4Г тактов. - POV(24.04.2024 16:50)
- ...А 64 бита - да, нужно. - ar-elec(24.04.2024 16:52)
- Да, возможно, я тоже в эту сторону смотрю. Но это не приведёт к тем же проблемам? Только они будут ещё реже возникать, и если там будет косяк, то его вообще хрен отловишь. - ar-elec(24.04.2024 16:51)
- Если я правильно понял, речь в 1 про то, что cnt_old, допустим, уже
близко к максимуму, а cnt уже перебежало через него и стало опять
маленьким? ar-elec(391 знак., 24.04.2024 16:45)
- Как-то так, наверное: SciFi(434 знак., 24.04.2024 16:34)
- А зачем это в разных местах вызывать? Всё рано ж дельта плюсуется. - POV(24.04.2024 16:26)
- Ну ок, неправ я. Не написал явно, что результат этого func'а
возвращается и используется там, откуда его вызвали. Т.е. на самом
деле ar-elec(300 знак., 24.04.2024 16:40)
- Ну вот, уже что-то осмысленное. У задачи повышения разрядности
таймера, и получения правильного значения есть классическое
решение, без запрета прерываний вообще. il-2(489 знак., 24.04.2024 16:54)
- Да, согласен. Единственно, по переполнению таймера тоже прерывание.
Хотя, ему можно поставить приоритет ниже, чем у всех остальных,
чтобы они не блокировались, тогда, действительно, должно идеально
сработать. Спасибо! В эту сторону тоже смотрел, но до конца не
продумал. - ar-elec(24.04.2024 16:59)
- Наоборот - приоритет самый высокий... POV(44 знак., 24.04.2024 17:00)
- 3. Повторить чтение - убедиться, что прочитали оно и то же (что не было в момент чтения переполнения счетчика). - POV(24.04.2024 16:58)
- Да, согласен. Единственно, по переполнению таймера тоже прерывание.
Хотя, ему можно поставить приоритет ниже, чем у всех остальных,
чтобы они не блокировались, тогда, действительно, должно идеально
сработать. Спасибо! В эту сторону тоже смотрел, но до конца не
продумал. - ar-elec(24.04.2024 16:59)
- И в гиперлупе и в прерываниях это нужно? Ну запрети прерывание синк
на пару тактов - чему это может повредить? - POV(24.04.2024 16:44)
- Ну, там не пара тактов, конечно, а пара десятков. Может, и ничего.
Критическое время порядка 10 мкс, частота процессора порядка 30-40
МГц. По идее, да, вроде, можно и запретить. Если ничего не
придумается, так и сделаю, но вдруг чудо? - ar-elec(24.04.2024 16:49)
- У тебя несколько команд. В любой момент исполнение функции
чтения-коррекции счетчика может быть прервано прерыванием с вызовом
той же самой функции. И все вычисления идут лесом. Особенно со
статик переменными, которые уж точно в единственно экземпляре (см.
недавнее обсуждение вопроса mse). - POV(24.04.2024 16:52)
- Вычисления лесом можно, теоретически, продублировать и сравнить, ну, и выполнять до тех пор, пока не совпадут, это будет критерием, что их никто не прерывал. В другом месте программы я так и делаю, только там прерывания не меняют этих переменных, так что прекрасно всё работает. А здесь вот - другая ситуасьён. - ar-elec(24.04.2024 16:55)
- У тебя несколько команд. В любой момент исполнение функции
чтения-коррекции счетчика может быть прервано прерыванием с вызовом
той же самой функции. И все вычисления идут лесом. Особенно со
статик переменными, которые уж точно в единственно экземпляре (см.
недавнее обсуждение вопроса mse). - POV(24.04.2024 16:52)
- Ну, там не пара тактов, конечно, а пара десятков. Может, и ничего.
Критическое время порядка 10 мкс, частота процессора порядка 30-40
МГц. По идее, да, вроде, можно и запретить. Если ничего не
придумается, так и сделаю, но вдруг чудо? - ar-elec(24.04.2024 16:49)
- Ну вот, уже что-то осмысленное. У задачи повышения разрядности
таймера, и получения правильного значения есть классическое
решение, без запрета прерываний вообще. il-2(489 знак., 24.04.2024 16:54)
- Ну ок, неправ я. Не написал явно, что результат этого func'а
возвращается и используется там, откуда его вызвали. Т.е. на самом
деле ar-elec(300 знак., 24.04.2024 16:40)
- 1) "заворот кишок" не анализируется (переход с 99 на 3) Zoro(142 знак., 24.04.2024 16:34)
- Есть аппаратный таймер, считающий в пределах uint32. Хочется, чтобы
считал до uint64. Я использую функцию, которая видит, насколько
изменилось значение таймера между вызовами и добавляет эту разницу
в переменную uint64 - ar-elec(24.04.2024 16:25)