Il y a plusieurs facteurs ici:
- Quel est le débit en bauds atteint par le MCU ATmega328P?
- Quel est le débit en bauds de l'interface USB-série?
- Quelle est la fréquence de l’oscillateur sur l’ATmega328P?
- Quelle est la fréquence de l’oscillateur sur l’interface série USB (s’il en existe une)?
- Quelle est la tolérance de l'interface série USB de la non-concordance des débits en bauds?
Tous ces facteurs sont pertinents pour déterminer le débit en bauds maximum réalisable. L'ATmega328P utilise un diviseur matériel à partir de sa fréquence d'horloge pour générer l'horloge de base de l'interface série. S'il n'y a pas de rapport entier entre l'horloge principale et le temps en bits du débit en bauds souhaité, la MCU ne sera pas en mesure de produire exactement le débit souhaité. Cela peut entraîner des problèmes potentiels, car certains appareils sont beaucoup plus sensibles à l'inadéquation du débit en bauds que d'autres.
Les interfaces basées sur FTDI tolèrent assez bien le décalage entre les débits en bauds, jusqu'à plusieurs pour cent d'erreur. Cependant, j'ai travaillé avec des modules GPS embarqués spécialisés, incapables de gérer une erreur de 0,5% en bauds.
Les interfaces série générales tolèrent une erreur de taux de bauds de ~ 5%. Cependant, étant donné que chaque extrémité peut être désactivée, une spécification plus courante est + -2,5%. De cette façon, si une extrémité est rapide à 2,5% et l'autre à 2,5% lente, votre erreur globale n'est que de 5%.
Quoi qu'il en soit. Uno utilise un ATmega328P en tant que MCU principal et un ATmega16U2 en tant qu'interface USB-série. Nous avons également la chance d’être ici dans la mesure où ces deux MCU utilisent des USART similaires, ainsi que des horloges à 16 MHz.
Étant donné que les deux microcontrôleurs ont le même matériel matériel et la même fréquence d'horloge, ils ont tous deux la même erreur de débit en bauds dans le même sens, ce qui permet d'ignorer fonctionnellement le problème de l'erreur en bauds.
Quoi qu'il en soit, la réponse "appropriée" à cette question impliquerait de rechercher la source de l'ATmega16U2 et de déterminer les débits en bauds possibles à partir de là, mais comme je suis paresseux, je pense qu'il est simple de procéder à des tests empiriques.
Un rapide coup d’œil sur la fiche technique ATmega328P donne le tableau suivant:
Donc, étant donné le débit maximum indiqué de 2 Mbps, j'ai écrit un programme de test rapide:
void setup(){};
void loop()
{
delay(1000);
Serial.begin(57600);
Serial.println("\r\rBaud-rate = 57600");
delay(1000);
Serial.begin(76800);
Serial.println("\r\rBaud-rate = 76800");
delay(1000);
Serial.begin(115200);
Serial.println("\r\rBaud-rate = 115200");
delay(1000);
Serial.begin(230400);
Serial.println("\r\rBaud-rate = 230400");
delay(1000);
Serial.begin(250000);
Serial.println("\r\rBaud-rate = 250000");
delay(1000);
Serial.begin(500000);
Serial.println("\r\rBaud-rate = 500000");
delay(1000);
Serial.begin(1000000);
Serial.println("\r\rBaud-rate = 1000000");
delay(1000);
Serial.begin(2000000);
Serial.println("\r\rBaud-rate = 2000000");
};
Et puis en regardant le port série approprié avec un terminal série:
Il semble donc que le matériel puisse fonctionner à 2 000 000 bauds sans problèmes.
Notez que cette vitesse de transmission ne donne à la MCU 64 que 80 cycles d'horloge par octet. Il serait donc très difficile de garder l'interface série occupée. Bien que les octets individuels puissent être transférés très rapidement, il est probable que l'interface soit simplement inactive.
Edit: Test en cours!
Le 2 Mbps est réel:
chaque bit-time est de 500 ns, ce qui correspond exactement à ce qui est attendu.
Les problèmes de performance! Longueur totale du paquet:
500 Kbauds:
1 Mbaud:
2 Mbauds:
Remarque: le dépassement notable est dû à de mauvaises pratiques de mise à la terre de la sonde de portée et n'est probablement pas réel. J'utilise le fil de terre qui fait partie de ma sonde d'oscilloscope, et l'inductance du fil est probablement à l'origine de la majorité du dépassement.
Comme vous pouvez le constater, la longueur totale de la transmission est la même pour 0,5, 1 et 2 Mbauds. Cela est dû au fait que le code qui place les octets dans le tampon série est mal optimisé. En tant que tel, vous ne réaliserez jamais mieux qu'un 500 Kbaud effectif , à moins d'écrire vos propres bibliothèques de séries. Les bibliothèques Arduino sont très mal optimisées, il ne serait donc probablement pas trop difficile d'obtenir un débit de 2 Mbaud approprié, du moins pour les transmissions en rafales, si vous y consacriez un peu de temps.