Какой правильный способ запроса устройства I2C из процедуры обслуживания прерывания?

"Как правильно запросить устройство I2C из процедуры обслуживания прерывания?"

Правильно НЕ запрашивать устройство I2C из ISR. Подпрограммы обслуживания прерываний должны очень выполняться быстро. (люди советуют избегать вызовов функций digitalWrite() и digitalRead() и напрямую использовать регистры портов, поскольку эти функции немного медленные. Все, что делается на последовательном линия по определению не быстрая. Чтение или запись нескольких символов из последовательного порта занимает несколько миллисекунд, а это целая вечность.)

Когда Arduino обслуживает прерывание, он прекращает все остальные действия, включая обработку других прерываний. Ваши таймеры остановятся, данные других датчиков будут потеряны, любая другая последовательная связь, которая выполняется, когда триггеры прерывания будут получать ошибки и т. д.

ПРОСТО НЕ ДЕЛАЙТЕ ЭТОГО.

Ответ Маженко полезен — вы можете просто отказаться от использования прерываний для этого и опросить вывод непосредственно в своем основном цикле. Особенно на AVR, где внешние выводы выставлены как регистры, которые могут считываться так же быстро, как основная память, это разумный подход. Но что, если вы действительно хотите, чтобы код был «быстрым к прерываниям» без написания кода, который мог бы заблокировать обработчик ISR? Учитывая случай с датчиком падения или удара, задержка может быть реальной проблемой. Что ж, вы можете кое-что сделать.

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

start = micros();
while (micros() - start < howLong) {
  // опрашиваем прерывание ADXL
}

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

Во-вторых, рассмотрите возможность использования прямого доступа к порту для опроса. Проверка наподобие if (PORTB & (1<<3)) компилируется в пару инструкций и стоит 2 цикла, если прерывание на самом деле не установлено (что будет обычным случай). Выполнение if (digitalRead(port)) вызывает функцию, которая занимает примерно в 25 раз больше времени. Это по-прежнему всего несколько микросекунд, но если вы воспользовались советом предыдущего шага опрашивать как можно чаще, чтобы свести к минимуму задержку, то вы не хотите, чтобы все эти микросекунды складывались и влияли на производительность другого кода.

Наконец, метод, который не имеет особого смысла для этого сценария, но может быть применим, если вы работаете в системе, отличной от Arduino на основе AVR, или если вы хотите чтобы реагировать на какое-то прерывание, отличное, чем прерывание от контакта, запускаемое по уровню: у вас есть ISR, который не выполняет никакой реальной работы, а вместо этого устанавливает глобальную переменную volatile в значение true а потом сразу возвращается. Затем в вашем основном коде вместо прямого опроса порта вы проверяете значение этой переменной. Если это правда, вы устанавливаете его в false, а затем запускаете свой код «обработчика прерываний». Обработчик запускается вскоре после срабатывания прерывания, но он запускается в контексте прерывания, когда безопасно выполнять более медленные операции или операции, для работы которых требуются прерывания по таймеру. Это эквивалентно старой концепции Linux о «нижних половинах».