Quelle est la précision du timing de pulseIn ()?

J'utilise la pulseIn()fonction pour traiter l'encodage de données binaires basé sur PWM. Il fonctionne bien pour distinguer les impulsions de longueurs significativement différentes, par exemple 500us contre 1500us. Cela le rend plus que suffisant pour gérer des télécommandes IR typiques.

Cependant, je veux créer mon propre système IR qui peut utiliser plus de 2 longueurs d'impulsion, afin que le transfert de données puisse se produire plus rapidement. Idéalement, j'aimerais utiliser 8 longueurs d'impulsion différentes pour le codage octal (par exemple 200us, 400us, 600us, etc.).

J'ai cependant remarqué des variations assez importantes dans les valeurs renvoyées pulseIn()(+/- 10%). Je m'attends à ce qu'au moins une partie soit introduite par les modules émetteur et récepteur IR, mais je n'ai pas assez de matériel pour le vérifier.

En supposant que je puisse atténuer cette erreur externe, est-il pulseIn()susceptible d'être suffisamment précis pour distinguer de telles impulsions similaires?

La fonction pulsein () est très avec perte, en ce sens qu'il s'agit d'une boucle dure et renvoie un nombre * les cycles d'horloge supposés qu'il faut pour chaque boucle

...
// 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); 

La méthode la plus précise pour capturer la synchronisation d'un code PIN est d'utiliser la FONCTION DE CAPTURE D'ENTRÉE. Regardez cet exemple . Il permet la capture d'entrée à 1 x du processeur pour une résolution maximale et chaque bord de la broche d'entrée capture la valeur d'horloge du temporisateur pour la lecture à partir du service d'interruption généré. Il permet également à l'interruption de dépassement de temporisation de maintenir une grande durée absolue, d'être capturée. Puisque le 1x roulera assez rapidement. Les captures stockent l'heure dans un tableau pour la lecture par la boucle principale.

Où pour les signaux sur IR, la bibliothèque typique à utiliser est la bibliothèque shirriff / Arduino-IRremote . Où il a plusieurs démos qui liront et enverront l'IR à partir d'un signal démodulé. Pour permettre à quelqu'un de construire un croquis de sa propre conception. Ce code crée à l'origine une interruption de minuterie qui interroge la broche d'entrée à un taux déterminé par

#define USECPERTICK 50  // microseconds per clock interrupt tick

dans le fichier IRremote.h. Pour mes besoins, je l'ai changé pour 25 nous. Là où je trouve que cela peut encore manquer par intermittence des flux d'impulsions.

Notez que la démodulation est mieux effectuée dans le récepteur IR, qui à son tour émet ce signal d'intérêt. Où ajouter un peu de fond. L'utilisation de la modulation typique de 38 kHz équivaut à une résolution minimale de 26,3 µS par cycle d'impulsion. La bibliothèque de sherriff montre généralement que la plupart des bauds ou bits sont de l'ordre de 10+ impulsions. Qui semblent correspondre à vos horaires souhaités.

microtherion / Arduino-IRremote fork du travail de shirriff améliore la réception en remplaçant l'interrogation d'interruption de la minuterie de la broche par l'utilisation de PinChangeInterrupts. Ce que j'ai fusionné dans mon propre fork mpflaga / Arduino-IRremote , qui ajoute plusieurs autres fonctionnalités.

Vous pouvez donc utiliser n'importe laquelle des bibliothèques ci-dessus. Ou créez votre propre application qui utilise l'une des méthodes ci-dessous pour capturer les bords.

1. sondages sur un événement Timer (par exemple 50uS)
2. capture les micros () sur un PinChangeInterrupt
3. utilise les interruptions de capture d'entrée pour saisir l'heure exacte

Voici quelques données de pulseIntest d' un test. Un Arduino a envoyé ce qui était censé être des impulsions de 14us, et l'autre a craché ces données:

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

Comme vous pouvez le voir, les impulsions ne sont en aucun cas précises. Le temps serait plus précis si les fins d'envoi et de réception étaient écrites en assemblage, ou même déchargées sur leurs propres processeurs.