Dans la plupart des exemples de code en ligne, les utilisateurs ajoutent la ligne Serial.begin(9600)dans le bloc d'installation.

Quand je regarde ce qui Serial.begin()est sur la documentation officielle, ça dit que ça contrôle le transfert de données bit par seconde.

La question évidente est donc: pourquoi ne pas utiliser 28800, le taux de transfert le plus élevé? Pourquoi les gens se contentent-ils de 9600? Quelle est la limitation ici?

Pourquoi les gens s'installent-ils?

Les gens s'installent parce que c'est plus que rapide. L’utilisation la plus courante consiste simplement à imprimer des éléments sur un terminal à des fins de débogage. 9600 bauds correspondent à 960 caractères par seconde, soit 12 x 80 lignes de caractères par seconde. À quelle vitesse pouvez-vous lire? :)

Si votre programme utilise le port série pour le transfert de données en masse, vous choisirez de ne pas régler.

Quelle est la limitation ...

Les limites en série sont élevées. Vous pouvez utiliser directement 115200 bauds dans vos programmes et cela fonctionnera simplement. Le terminal Arduino autorisera un maximum de 115200, mais d’autres programmes tels que RealTerm vous permettraient de fonctionner plus rapidement.

La série matérielle fonctionnera à 1 M bauds. Si vous lisez autour, vous verrez que les gens ont utilisé jusqu'à 1 M en contrôlant directement l'UART. Vous pouvez tirer parti des débits en bauds élevés pour des utilisations telles que la transmission via une puce Bluetooth. Si vous utilisez l'interface série matérielle pour échanger d'une puce à l'autre avec une courte distance, 1 M de bauds est tout à fait réalisable. Pensez à tous les périphériques SPI et I2C qui fonctionnent parfaitement à une fréquence d'horloge de 1 MHz.

Sur de plus grandes distances, vous commencerez à avoir des problèmes de bruit lorsque vous utiliserez une signalisation de niveau logique (0 à 5V en clair). Pour utiliser de plus grandes distances, vous devez ajouter un émetteur-récepteur offrant une signalisation robuste, généralement RS-232 et moins communément RS-485. Avec RS-232, vous pouvez exécuter un méga bit à des distances de 10 pieds.

La vitesse d'horloge du microprocesseur sera la limite réelle. Avec un UART matériel, le processeur doit charger un octet dans l'UART tous les 10 bits (pour N81). Ainsi, lorsque vous atteignez 1 M bauds, le processeur 16 MHz aura du mal à garder l'UART alimenté en données. Un nouvel octet sera envoyé toutes les 160 ticks d'horloge, ce qui représente très peu de lignes de code. Pour une courte rafale de données, vous pouvez atteindre ce taux. Le message est, le processeur va manquer de vitesse avant que l'UART est la limite.

Notez que tout cela s’applique à HardwareSerial , le logiciel en série est très différent.

En plus de toutes les réponses intéressantes, il convient de mentionner que le réglage de la vitesse série sur XXX bits / s n'implique pas nécessairement XXX bits / s sur le matériel.

Les horloges - même à base de quartz - sont imparfaites et sujettes à la dérive. De plus, comme l’horloge série est généralement générée par l’intermédiaire d’un prédiviseur diviseur et d’un compteur (entier), toute valeur ne peut pas être obtenue avec précision à partir d’une fréquence d’horloge de base. À l’aide des bits de démarrage / arrêt, une communication série asynchrone peut être tolérante à une certaine dérive de l’horloge. Mais cela a des limites.

Par exemple, si votre ATmega328PA fonctionne à 1 MHz, vous pouvez atteindre 9 600 b / s avec une erreur de 0,2%. Mais à 14400b / s, l’erreur est de -3,5% (en réalité, elle communique à 13900b / s). Et à 28800b / s, l’erreur est de + 8,5% (en réalité, elle communique à 31200b / s). Tous ces chiffres sont tirés de la fiche technique ATmega48PA-88PA-168PA-328PA, p200 .

Ce n'est pas un problème lorsque deux appareils identiques communiquent ensemble (car ils communiquent en fait à la même vitesse). Cela peut poser un problème lors de la communication entre différents appareils.

L'augmentation de la fréquence de base n'améliore pas nécessairement la précision. Par exemple, exécuter le même ATmega328PA que ci-dessus à 2 MHz ne donne pas vraiment de meilleurs résultats car ceux-ci sont principalement dus à des erreurs d'arrondi. Mais son utilisation à 1,8432 MHz donne des bps très précis de 2400b / s à 57,6kHz.

Je pense que l’utilisation d’un taux de transfert qui n’est pas le plus lent (300), mais qui pourrait éventuellement poser problème dans certaines configurations (28800 ou même 115200) est une tradition. Le port série du PC (le plus souvent un adaptateur USB FTDI232) peut supporter des débits plus élevés, mais votre matériel de bricolage peut ne pas le faire. 9600 bps s’est donc imposé comme une sorte de taux de transfert standard pour les exemples de code.

De retour dans la nuit des temps, le «standard de référence» pour les claviers distants (avec un modem téléphonique et les télétypes, si vous vous en souvenez) était de 9600 bauds, réalisable au départ uniquement sur une ligne téléphonique dédiée. Le temps passe lentement. la technologie avance rapidement; et la mémoire se déplace encore plus lentement que le temps (semble-t-il). Nous pouvons communiquer régulièrement, au moins sur plusieurs mètres, à quelques ordres de grandeur plus rapidement que 9600 bauds. Ce qui était autrefois considéré comme un étalon-or n’est plus d’or, mais reste considéré comme un étalon.

tl; dr: C'est l'histoire, pas la technologie.

Je pense que la principale raison pour laquelle les utilisateurs utilisent 9600 la plupart du temps est qu’il s’agit du débit en bauds par défaut dans l’IDE ​​Arduino. En outre, des débits de données plus rapides pourraient également ne pas être fiables si le signal série doit parcourir un long chemin - bien que je ne sache pas pourquoi cela a été choisi comme vitesse optimale.

Temps de réaction humaine

Parce que les utilisateurs exigent 100% du temps nécessaire pour arrêter le moniteur série lorsque votre Arduino se débat sur le port , et que la vitesse de transfert maximale est requise moins de 100% du temps.

9600 bauds est un compromis entre "un processus facile à mettre en échec" et "d'une lenteur agaçante".