Bonjour,
Désolé pour la réponse tardive, je n'ai pas eu accès à Internet depuis un ordinateur depuis mon dernier message.
trimarco232:
un petit dessin, même brouillon, les impulsions A, les impulsions B, quelques annotations ...
J'ai fait un petit schéma en pièce-jointe.
pepe:
L'affichage dans le moniteur de l'IDE des valeurs décimales des mesures représente un volume de données conséquent, qui impose un débit de transmission de 2 Mbit/s (16MHz/8), le débit immédiatement inférieur de 1Mbit/s étant insuffisant. Or, un débit aussi élevé est difficilement envisageable, compte tenu notamment du taux élevé d'erreurs de transmission attendu (désynchronisation entre l'ATmega328P et l'ATmega16U2, entre autres).
En comparaison, une transmission purement binaire vers un logiciel spécifique pourrait se contenter d'un débit de 166,6 kbit/s (16MHz/8/12).
La capture est effectuée sur un front de polarité déterminée (front montant ou front descendant). Après chaque front capturé, il faut préparer le système de capture pour réagir au front suivant, car il est nécessairement de polarité opposée.
Justement, j'ai avancé dans mon projet, et je me suis rendu compte que même si mon programme arrive à tout compter, l'affichage dans la console n'est pas régulier, et mes lignes s'affichent de 10 en 10.
16 MHz pour l'horloge de l'Arduino, 8 pour un octet j'imagine, mais à quoi correspond le 12 ? Edit : les 12 MHz du contrôleur USB ?
Ok, je comprends mieux cette histoire de polarité, et c'est ce que j'avais fait dans mon programme sans mettre de nom dessus alors 
J'ai modifié mon code et obtenu un résultat fonctionnel, mais comme l'indique pepe dans son message, c'est l'affichage dans la console de l'IDE avec Serial.print() qui est à la ramasse... J'envisage désormais d'utiliser une liaison SPI pour envoyer toutes ces données à un Raspberry Pi qui s'occuperait de leur affichage, toujours en console avec du C ou en graphique avec du Python. Qu'en pensez-vous ?
Sachant qu'à la base je comptais faire le traitement sur Raspberry Pi avant de me rendre compte que l'OS n'étant pas temps réel, certaines données passaient régulièrement à la trappe. Du coup, est-ce que le Raspberry Pi "n'oublierait" pas également certaines de ces valeurs même en utilisant une liaison SPI ?
Mon code Arduino si vous souhaitez y jeter un œil. J'utilise la bibliothèque dont je parle dans mon premier post, qui offre une alternative à la fonction micros() précise à 1 µs. N'hésitez pas à me faire part de vos remarques et conseils ! 
(Je dois déjà virer quelques unsigned long pour des types plus adaptés...)
#include <eRCaGuy_Timer2_Counter.h>
#define pinA 2
#define pinB 3
volatile unsigned long ACount = 0UL;
volatile unsigned long BCount = 0UL;
unsigned long ACountCopy = 0UL;
unsigned long BCountCopy = 0UL;
unsigned long AStartUs = 0UL;
unsigned long BStartUs = 0UL;
unsigned long AStopUs = 0UL;
unsigned long BStopUs = 0UL;
void setup()
{
timer2.setup();
pinMode(pinA, INPUT_PULLUP);
pinMode(pinB, INPUT_PULLUP);
attachInterrupt(digitalPinToInterrupt(pinA), ARising, RISING);
attachInterrupt(digitalPinToInterrupt(pinB), BRising, RISING);
Serial.begin(230400);
}
void loop()
{
noInterrupts();
ACountCopy = ACount;
BCountCopy = BCount;
interrupts();
Serial.print(F("B n°"));
Serial.print(BCountCopy);
Serial.print(F(" : "));
Serial.print(BStopUs - BStartUs);
Serial.print(F(" µs | A n°"));
Serial.print(ACountCopy);
Serial.print(F(" : "));
Serial.print(AStopUs - AStartUs);
Serial.println(F(" µs."));
}
void ARising()
{
AStartUs = timer2.get_count() / 2UL;
attachInterrupt(digitalPinToInterrupt(pinA), AFalling, FALLING);
}
void AFalling()
{
AStopUs = timer2.get_count() / 2UL;
ACount++;
timer2.reset();
attachInterrupt(digitalPinToInterrupt(pinA), ARising, RISING);
}
void BRising()
{
BCount++;
BStartUs = timer2.get_count() / 2UL;
attachInterrupt(digitalPinToInterrupt(pinB), BFalling, FALLING);
}
void BFalling()
{
BStopUs = timer2.get_count() / 2UL;
timer2.reset();
ACount = 0UL;
attachInterrupt(digitalPinToInterrupt(pinB), BRising, RISING);
}
