En muchos códigos de muestra, las personas en línea agregan la línea Serial.begin(9600)en el bloque de configuración.

Cuando busco lo que Serial.begin()está en la documentación oficial, dice que controla la transferencia de datos de bit por segundo.

Entonces, la pregunta obvia es, ¿por qué no usar 28800, la tasa de transferencia más alta? ¿Por qué la gente se conforma con 9600? ¿Cuál es la limitación aquí?

¿Por qué se conforman las personas?

La gente se conforma porque es más que lo suficientemente rápido. El uso más común es imprimir algunas cosas en un terminal para depurar. 9600 baudios son 960 caracteres por segundo, o 12 x 80 líneas de caracteres por segundo. ¿Qué tan rápido puedes leer? :)

Si su programa está utilizando el puerto serie para la transferencia de datos a granel, elegiría no conformarse.

¿Cuál es la limitación ...

Los límites en serie son altos. Directamente, puede usar 115200 baudios en sus programas y simplemente funcionará. El terminal Arduino permitirá un máximo de 115200, pero otros programas como RealTerm te permitirán correr más alto.

La serie de hardware se ejecutará a 1 M de baudios. Si lee, verá que las personas han usado hasta 1 M controlando directamente el UART. Es posible que se beneficie de altas velocidades en baudios para usos como la transmisión a través de un chip bluetooth. Si está utilizando la interfaz serial de hardware para intercambiar de un chip a otro con una corta distancia, entonces 1 M de baudios es completamente factible. Piense en todos los dispositivos SPI e I2C que funcionan bien a una velocidad de reloj de 1 MHz.

A distancias más grandes, comenzará a tener problemas con el ruido cuando use la señalización de nivel lógico (0 a 5V). Para usar distancias más grandes, agregaría un transceptor para proporcionar una señalización robusta, comúnmente RS-232 y menos comúnmente RS-485. Con RS-232 podrías correr un mega bit a distancias de 10 pies.

La velocidad del reloj del microprocesador será el límite real. Con un UART de hardware, el procesador debe cargar un byte al UART cada 10 bits (para N81). Entonces, cuando llegue a 1 M de baudios, será un desafío para el procesador de 16 MHz mantener el UART suministrado con datos. Se enviará un nuevo byte cada 160 tics de reloj, que son muy pocas líneas de código. Para una breve ráfaga de datos, puede lograr esa tasa. El mensaje es que el procesador se quedará sin velocidad antes de que el UART sea el límite.

Tenga en cuenta que todo esto se aplica a HardwareSerial , la serie de software es muy diferente.

Además de todas las respuestas interesantes, vale la pena mencionar que establecer la velocidad de serie en XXX bits / s no implica necesariamente XXX bits / s en el hardware.

Los relojes, incluso a base de cuarzo, son imperfectos y están sujetos a la deriva. Además, como el reloj en serie generalmente se genera a través de un divisor y un contador (entero) de potencia de dos, no se puede obtener con precisión el valor dado una frecuencia de reloj base. Con la ayuda de los bits de inicio / parada, la comunicación serial asíncrona puede ser tolerante a alguna deriva del reloj. Pero esto tiene límites.

Por ejemplo, si su ATmega328PA está funcionando a 1MHz, puede alcanzar 9600b / sa un 0.2% de error. Pero a 14400b / s el error es -3.5% (en realidad se comunica a 13900b / s). Y a 28800b / s, el error es + 8.5% (en realidad se comunica a 31200b / s). Todas esas cifras provienen de la hoja de datos ATmega48PA-88PA-168PA-328PA, p200 .

Esto no es un problema cuando dos dispositivos idénticos se comunican entre sí (ya que de hecho hay comunicación a la misma velocidad). Se podría ser un problema en la comunicación entre diferentes dispositivos.

El aumento de la frecuencia base no necesariamente mejora significativamente la precisión. Por ejemplo, ejecutar el mismo ATmega328PA que el anterior a 2MHz realmente no da mejores resultados, ya que se deben principalmente a errores de redondeo. Pero ejecutarlo a 1.8432MHz proporciona bps muy precisos desde 2400b / s hasta 57.6kHz.

Creo que es una especie de tradición usar una velocidad de transferencia que no sea la más lenta (300) pero tampoco una que pueda causar problemas en algunas configuraciones (28800 o incluso 115200). El puerto serie de la PC (más a menudo un adaptador USB FTDI232) puede hacer frente a tasas más altas, pero su hardware de bricolaje no. Entonces, 9600 bps se ha establecido como una especie de tasa de transferencia estándar para ejemplos de código.

En las brumas del tiempo, el "estándar de oro" para los teclados remotos (usando un módem telefónico y teletipos, si los recuerda) era de 9600 baudios, inicialmente alcanzables solo a través de una línea telefónica dedicada. El tiempo avanza, lentamente; avances tecnológicos, rápidamente; y la memoria se mueve aún más lentamente que el tiempo (parece). Podemos comunicarnos rutinariamente, al menos durante varios metros, a un par de órdenes de magnitud más rápido que 9600 baudios. Lo que alguna vez se consideró un estándar de oro ya no es oro, pero aún se considera estándar.

TL; DR: es historia, no tecnología.

Creo que la razón principal por la que la gente usa 9600 la mayor parte del tiempo es porque es la velocidad de transmisión predeterminada en el IDE de Arduino. Además, las velocidades de datos más rápidas también podrían ser poco confiables si la señal en serie tiene que recorrer un largo camino, aunque no tengo idea de por qué se seleccionó como una velocidad óptima.

Tiempo de reacción humana

Debido a que los usuarios requieren el poder de detener el monitor en serie cuando su Arduino está golpeando en el puerto el 100% del tiempo, y tener la velocidad de transferencia máxima se requiere menos del 100% del tiempo.

9600 baudios es un compromiso entre "fácil de matar un proceso desbocado" y "molestamente lento".