Проблема с использованием Arduino Mega Timer2 с прерыванием PinChange

Есть довольно много проблем с этой программой. Наиболее очевидным является использование вычислений с плавающей точкой в контексте прерывания. Прерывания должны подаваться как можно быстрее, а плавающая точка действительно медленная на AVR.

Некоторые другие вопросы:

• Флаги прерываний должны быть очищены, написав логику 1 для них, как бы глупо это ни звучало.

• Пара операторов if & в ISR(PCINT2_vect), вероятно, должна быть &&.

• Логика обнаружения восходящих и падающих краев ошибочна.

• Нет необходимости хранить так много данных в объектах Pulse.

• ch1.width следует читать с отключенными прерываниями, чтобы избежать гонки данных.

• Существует тонкое состояние гонки при чтении ovfCount и TCNT2: если таймер переполняется прямо при запуске ISR(PCINT2_vect), это переполнение не будет учитываться.

Вот версия программы, которая пытается исправить все эти моменты. Я также изменил его для работы на Uno (с pin 13 = PB5 = PCINT5), чтобы я мог проверить его:

/*
 * Ширина импульса через PCINT.
 *
 * https://arduino.stackexchange.com/questions/81688
 */

volatile uint32_t ovfCount = 0;

struct Pulse {
    uint32_t last_toggle;
    uint32_t width;
    bool stateHigh;
    uint32_t get_width() {
        noInterrupts();
        uint32_t width_copy = width;
        interrupts();
        return width_copy;
    }
};

Pulse ch1, ch2, ch3, ch4, ch5, ch6;

void setup() {
    Serial.begin(115200);
    pinMode(13, OUTPUT);

    /* Настройка прерывания смены контактов для обнаружения импульсов. */
    PCMSK0 = _BV(PCINT5);  // изменение смысла на выводе 13 = PB5 = PCINT5
    PCIFR  = _BV(PCIF0);   // сброс флага прерывания
    PCICR  = _BV(PCIE0);   // enable PCINT0_vect: pins PCINT[7:0]

    /* Настройка таймера 2 для подсчета. */
    TCCR2B = 0;           // стоп
    TCCR2A = 0;           // нормальный режим
    TCNT2  = 0;           // сброс таймера
    TIFR2  = _BV(TOV2);   // сброс флага прерывания
    TIMSK2 = _BV(TOIE2);  // включить прерывание переполнения таймера
    TCCR2B = _BV(CS20);   // count at F_CPU/1
}

ISR(TIMER2_OVF_vect) {
    ovfCount++;
}

ISR(PCINT0_vect) {
    uint8_t tcnt2 = TCNT2;
    uint32_t ovf_count = ovfCount;

    // Было ли переполнение, которое еще не было учтено?
    if (bit_is_set(TIFR2, TOV2) && tcnt2 < 128) {
        ovf_count++;
    }

    uint32_t time = ovf_count << 8 | tcnt2;

    bool input_is_high = bit_is_set(PINB, PB5);
    if (input_is_high && !ch1.stateHigh) {  // low -> high
        ch1.stateHigh = true;
    } else if (!input_is_high && ch1.stateHigh) {  // high -> low
        ch1.width = time - ch1.last_toggle;
        ch1.stateHigh = false;
    }
    ch1.last_toggle = time;
}

void loop() {
    digitalWrite(13, HIGH);
    delay(1000);
    digitalWrite(13, LOW);
    delay(200);
    Serial.println(ch1.get_width() / 16e3, 5);
}

И вот результат:

1000.02349
1000.01959
1000.01916
1000.02496
1000.01959
1000.02032
1000.01947
1000.02795
1000.02642
1000.01855
1000.01916
1000.02105
1000.02490
1000.01782
1000.03033
1000.01898
...

Печатные значения больше 1000 из-за времени, необходимого для выполнения digitalWrite().

Также обратите внимание, что 8-битный таймер, работающий на полной скорости процессора, переполняется каждые 16 мкс. Это довольно большая нагрузка на процессор, и многие операции займут больше времени, чем ожидалось, из-за этих прерываний. Если бы я хотел засечь что-то с разрешением в один цикл, я бы потянулся к 16-битному таймеру. И я бы предпочел использовать захват входного сигнала, хотя, к сожалению, на Мега доступны только два канала захвата входного сигнала (на контактах 48 и 49).

Правка: Отвечаю на вопросы в комментариях.

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

Я не тестировал его, но мне кажется, что этот код должен работать. Однако я бы предпочел иметь разные прерывания для каждого канала. В противном случае последовательные вызовы pinChangeFunction() могут сделать выполнение этого ISR довольно долгим.

Также обратите внимание, что Pulse::input_is_high не служит никакой полезной цели. Хранение этого значения в объекте замедляет ISR, так как он должен обращаться к памяти, в то время как локальная переменная будет храниться в (гораздо быстрее) внутреннем регистре процессора.

что мы будем делать, если у нас есть 8 каналов, как в радиоприемнике?

Вы можете использовать 6 внешних прерываний и 2 прерывания смены контактов.

Почему вы взяли tcnt2 < 128, когда tcnt2 max равен 256?

Это хитрое дело. Я постараюсь объяснить всю логику теста.

Рассмотрим следующую наивную версию ISR:

ISR(PCINT0_vect) {
    // ← A
    uint8_t tcnt2 = TCNT2;
    uint32_t ovf_count = ovfCount;
    uint32_t time = ovf_count << 8 | tcnt2;
    // ...
}

Есть небольшой шанс, что Таймер 2 переполняется в точке А, т. е. в то время как этот ISR выполняет свой пролог и еще не прочитал TCNT2. Если это произойдет, то TIMER2_OVF ISR не будет запущен немедленно, потому что мы уже выполняем ISR, а ISR не гнездятся. Затем ovfCount не обновляется. Если это происходит, мы затем считываем значение TCNT2 , на которое влияет переполнение, и значение ovfCount, которое не учитывает это переполнение. Затем мы объединяем эти несогласованные значения в значение времени, которое пропускает 256 тиков таймера.

Мы можем обнаружить эту ситуацию, прочитав флаг TOV2 в TIFR2. Этот флаг устанавливается только при наличии ожидающего запроса прерывания для TIMER2_OVF, то есть если счетчик переполнен и это переполнение еще не было учтено в ovfCount. Таким образом, “фиксированный” ISR выглядит следующим образом:

ISR(PCINT0_vect) {
    // ← A
    uint8_t tcnt2 = TCNT2;
    // ← B
    uint32_t ovf_count = ovfCount;
    // ← B
    if (bit_is_set(TIFR2, TOV2)) {
        ovf_count++;
    }
    uint32_t time = ovf_count << 8 | tcnt2;
    // ...
}

При этом, если переполнение происходит в точке А, нам удается вычислить нужное время. Но теперь подумайте, что произойдет, если таймер переполнится в любой из точек, отмеченных B, то есть после чтения TCNT2, но до чтения TOV2. Если это происходит, мы считываем значения предварительного прерывания как TCNT2, так и ovfCount. Таким образом, для вычисления последовательного времени не требуется никакой коррекции . Тем не менее, TOV2 повышается, когда мы тестируем его: затем мы применяем ненужную коррекцию, и в итоге получаем время, которое слишком велико на 256 тиков.

Чтобы устранить эту проблему, мы должны убедиться, что коррекция применяется, если переполнение происходит в точке А, но не в точке В. Как мы можем различить эти две ситуации? Ответ таков: взглянув на значение, записанное в tcnt2. В случае А счетчик считывался сразу после переполнения, поэтому при копировании в tcnt2 он имел очень малое значение (близкое к 0). В случае B счетчик считывался, когда он был близок к переполнению, поэтому он имел очень большое значение (близкое к 255). Если TOV2 установлен, когда мы его читаем, это означает, что переполнение произошло в самом начале текущего ISR, очень близко к точке, где мы читаем TCNT2. Таким образом, значение, записанное в tcnt2 должен быть либо очень маленьким, либо очень большим. Он не может быть посередине (близко к 128).

Поэтому мы должны решить, является ли tcnt2 очень маленьким или очень большим. Существует множество возможных значений, которые можно использовать в качестве порога. Наиболее естественным является средний диапазон: 128. Он также является наиболее эффективным для вычисления, так как компилятор может оптимизировать сравнение в простую проверку наиболее значимого бита. Таким образом, окончательный вариант теста:

    if (bit_is_set(TIFR2, TOV2) && tcnt2 < 128) {
        ovf_count++;
    }