Насколько точны сроки импульсаIn ()?

Я использовал функцию pulseIn() для обработки кодирования двоичных данных на основе PWM. Он хорошо работает для выделения импульсов, которые имеют значительно различную длину, например. 500us против 1500us. Это делает его более чем достаточным для обработки типичных ИК-пультов.

Однако я хочу создать свою собственную ИК-систему, которая может использовать более двух длительностей импульсов, чтобы передача данных происходила быстрее. В идеале я бы хотел использовать 8 различных длин импульсов для восьмеричного кодирования (например, 200us, 400us, 600us и т. Д.).

Я заметил довольно значительные изменения в значениях, возвращаемых pulseIn(), хотя (+/- 10%). Я ожидаю, что хотя бы некоторые из них будут представлены ИК-передатчиком и приемными модулями, но у меня недостаточно оборудования для проверки этого.

Предполагая, что могу уменьшить эту внешнюю ошибку, pulseIn() может быть достаточно точным, чтобы отличать подобные импульсы?

8 голосов | спросил Peter Bloomfield 20 FebruaryEurope/MoscowbThu, 20 Feb 2014 15:03:18 +0400000000pmThu, 20 Feb 2014 15:03:18 +040014 2014, 15:03:18

2 ответа


11

Функция pulsein () очень убыточна, поскольку она представляет собой жесткий цикл и возвращает число * предполагаемые тактовые циклы, которые требуется для каждого цикла

...
// wait for the pulse to stop
while ((*portInputRegister(port) & bit) == stateMask) {
  if (numloops++ == maxloops)
    return 0;
  width++;
}

// convert the reading to microseconds. The loop has been determined
// to be 20 clock cycles long and have about 16 clocks between the edge
// and the start of the loop. There will be some error introduced by
// the interrupt handlers.
return clockCyclesToMicroseconds(width * 21 + 16); 

Самый точный метод для захвата времени ПИН-кода - использовать функцию INPUT CAPTURE FEATURE. Посмотрите на этот пример . Он позволяет захватить входной сигнал в 1x CPU для максимального разрешения, и каждый край входного штыря фиксирует значение таймера для считывания из сгенерированной службы прерывания. Он также позволяет прерывать переполнение таймера, чтобы поддерживать большое абсолютное время, чтобы быть захватом. Так как 1x будет катиться довольно быстро. Захваты хранят время в массиве для чтения по основному циклу.


Где для сигналов через ИК-библиотека используется библиотека shirriff /Arduino-IRremote . Там, где у него есть несколько демоверсий, которые будут считывать и отправлять ИК-сигнал из демодулированного сигнала. Позволить строить эскиз своей собственной конструкции. Этот код изначально создает прерывание таймера, которое опросает входной контакт со скоростью, определяемой

#define USECPERTICK 50  // microseconds per clock interrupt tick

в файле IRremote.h. Для моих целей я изменил его на 25 человек. Там, где я нахожу, что это все еще может быть прерывисто пропавшими импульсными потоками.

Обратите внимание, что демодуляция лучше всего выполняется в ИК-приемнике, который, в свою очередь, выводит этот сигнал, представляющий интерес. Где добавить некоторый фон. Используя типичную 38KHz модуляцию, приравнивается к минимальному разрешению 26.3uS за цикл импульса. Библиотека sherriff показывает, как правило, большинство бод или бит находятся в порядке 10 + импульсов. Кажется, что они соответствуют вашим желаемым срокам.

microtherion /Arduino-IRremote fork of shirriff's work улучшает прием, заменяя опрос прерывания таймера штыря на использование PinChangeInterrupts. Что я объединил в свою собственную mpflaga /Arduino-IRremote , которая добавляет несколько других функций.

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

  1. опроса в событии таймера (например, 50uS)
  2. захватывает микроны () на PinChangeInterrupt
  3. использует прерывания ввода для захвата точного времени
ответил mpflaga 21 FebruaryEurope/MoscowbFri, 21 Feb 2014 07:38:54 +0400000000amFri, 21 Feb 2014 07:38:54 +040014 2014, 07:38:54
2

Вот несколько тестовых данных теста pulseIn. Один Ардуино послал то, что должно было быть импульсом 14us, а другой выплюнул эти данные:

  

18,18,18,12,18,18,18,18,18,18,18,18,18,18,18,18,18,24,19,18,18,18,18,18 , 24,18,18,18,19,18,18,12,18,18,19,18,18,18,18,18,18,18,18,18,18,18,19,18,19 , 24,18,18,18,18,18,18,18,24,18,18,18,18,18,18,18,18,18,18,18,18,18,19,18,18 , 18,18,18,18,18,18,18,18,19,18,18,18,11,18

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

ответил TheDoctor 20 FebruaryEurope/MoscowbThu, 20 Feb 2014 18:22:35 +0400000000pmThu, 20 Feb 2014 18:22:35 +040014 2014, 18:22:35

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132