Em grande parte do código de exemplo online, as pessoas adicionam a linha Serial.begin(9600)no bloco de configuração.

Quando procuro o que Serial.begin()está na documentação oficial, ele diz que controla a transferência de dados bit por segundo.

Portanto, a pergunta óbvia é: por que não usar 28800, a maior taxa de transferência? Por que as pessoas se contentam com 9600? Qual é a limitação aqui?

Por que as pessoas se acomodam?

As pessoas se acomodam porque é mais do que rápido o suficiente. O uso mais comum é apenas imprimir algumas coisas em um terminal para depuração. 9600 baud são 960 caracteres por segundo ou 12 x 80 linhas de caracteres por segundo. Quão rápido você consegue ler? :)

Se o seu programa estiver usando a porta serial para transferência de dados em massa, você escolheria não fazer a instalação.

Qual é a limitação ...

Os limites em série são altos. Diretamente, você pode usar 115200 baud em seus programas e ele simplesmente funcionará. O terminal do Arduino permitirá no máximo 115200, mas outros programas, como o RealTerm, permitem que você execute mais alto.

A série do hardware será executada em 1 M. baud. Se você ler ao redor, verá que as pessoas usaram até 1 M controlando diretamente o UART. Você pode se beneficiar de altas taxas de transmissão para usos como transmissão via chip bluetooth. Se você estiver usando a interface serial de hardware para trocar de chip em chip a uma curta distância, a transmissão de 1 M é completamente viável. Pense em todos os dispositivos SPI e I2C que operam perfeitamente na taxa de clock de 1 MHz.

Em distâncias maiores, você começará a ter problemas com ruído ao usar a sinalização de nível lógico (simples de 0 a 5V). Para usar distâncias maiores, você adicionaria um transceptor para fornecer sinalização robusta, geralmente RS-232 e menos RS-485. Com o RS-232, você pode rodar um mega bit a distâncias de 10 pés de pé.

A velocidade do clock do microprocessador será o limite real. Com um UART de hardware, o processador deve carregar um byte no UART a cada 10 bits (para N81). Portanto, quando você chegar a 1 M de baud, será um desafio para o processador de 16 MHz manter o UART fornecido com dados. Um novo byte será enviado a cada 160 marcações, que são muito poucas linhas de código. Para uma pequena explosão de dados, você pode atingir essa taxa. A mensagem é que o processador ficará sem velocidade antes que o UART seja o limite.

Observe que tudo isso se aplica ao HardwareSerial , a série de software é muito diferente.

Além de todas as respostas interessantes, vale ressaltar que definir a velocidade serial para XXX bits / s não implica necessariamente XXX bits / s no hardware.

Relógios - mesmo baseados em quartzo - são imperfeitos e sujeitos a deriva. Além disso, como o relógio serial geralmente é gerado por meio de um pré-divisor de potência e dois (número inteiro), todo valor não pode ser obtido com precisão, dada a frequência do relógio base. Com a ajuda dos bits de partida / parada, a comunicação serial assíncrona pode ser tolerante a algum desvio do relógio. Mas isso tem limites.

Por exemplo, se o seu ATmega328PA estiver em execução em 1 MHz, você poderá atingir 9600b / s com 0,2% de erro. Mas a 14400b / s o erro é de -3,5% (na verdade, comunicando-se em 13900b / s). E a 28800b / s, o erro é de + 8,5% (na verdade, comunicando-se a 31200b / s). Todas essas figuras são da folha de dados do ATmega48PA-88PA-168PA-328PA, p200 .

Isso não é um problema quando dois dispositivos idênticos se comunicam juntos (pois, na verdade, eles estão se comunicando na mesma velocidade). Ele pode ser um problema quando se comunicar entre dispositivos diferentes.

O aumento da frequência base não melhora significativamente a precisão. Por exemplo, executar o mesmo ATmega328PA acima de 2MHz realmente não fornece melhores resultados, pois esses são principalmente devido a erros de arredondamento. Mas rodar com 1,8432MHz fornece bps muito precisos, de 2400b / s a ​​57,6kk.

Eu acho que é um tipo de tradição usar uma taxa de transferência que não seja a mais lenta (300), mas também que não possa eventualmente causar problemas em algumas configurações (28800 ou até 115200). A porta serial do PC (geralmente um adaptador USB FTDI232) pode lidar com taxas mais altas, mas o hardware de bricolage não. Então, 9600 bps se estabeleceu como algum tipo de taxa de transferência padrão para exemplos de código.

Na bruma do tempo, o "padrão ouro" para teclados remotos (usando um modem telefônico e teletipos, se você se lembrar deles) era de 9600 baud, inicialmente atingível apenas por uma linha telefônica dedicada. O tempo passa devagar; a tecnologia avança rapidamente; e a memória se move ainda mais lentamente que o tempo (ao que parece). Podemos nos comunicar rotineiramente, pelo menos por vários metros, em duas ordens de magnitude mais rápidas que 9600 baud. O que antes era considerado um padrão-ouro não é mais ouro, mas ainda é considerado padrão.

tl; dr: É história, não tecnologia.

Eu acho que a principal razão pela qual as pessoas usam 9600 na maioria das vezes é que é a taxa de transmissão padrão no IDE do Arduino. Além disso, taxas de dados mais rápidas também podem não ser confiáveis ​​se o sinal serial precisar percorrer um longo caminho - embora eu não tenha idéia de por que isso foi selecionado como uma velocidade ideal.

Tempo de reação humana

Porque ser capaz de parar o monitor serial quando o Arduino está debatendo na porta é exigido pelos usuários 100% do tempo, e ter a velocidade máxima de transferência necessária em menos de 100% do tempo.

9600 baud é um compromisso entre "fácil de matar um processo descontrolado" e "irritantemente lento".