Serial.begin (): Por que não usar sempre 28800?

Em muitos dos exemplos de código 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, vejo que controla a transferência de dados bit por segundo.

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

Comentários

  • Para sua informação, o mais alto que um Arduino conectado a suportes USB é 115200, e 57600 é frequentemente o segundo mais comum baud que você vê.

Resposta

Por que as pessoas resolver?

As pessoas se acomodam porque é mais do que rápido. O uso mais comum é apenas imprimir algumas coisas em um terminal para depuração. 9600 baud é 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ê deve optar por não se conformar.

O que é a limitação …

Os limites do serial são altos. Diretamente, você pode usar 115200 baud em seus programas e tudo funcionará. O terminal Arduino permite um máximo de 115200, mas outros programas como o RealTerm permitem que você execute mais.

O serial do hardware rodará a 1 M baud. Se você ler ao redor, verá que as pessoas usaram até 1 M controlando diretamente o UART. Você pode obter o benefício de altas taxas de transmissão para usos como transmissão por meio de um chip bluetooth. Se você estiver usando a interface serial de hardware para trocar de chip para chip com apenas uma curta distância, então 1 M baud é completamente viável. Pense em todos os dispositivos SPI e I2C que operam bem a uma taxa de clock de 1 MHz.

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

A velocidade de clock do microprocessador será o limite real. Com um UART de hardware, o processador deve carregar um byte para o UART a cada 10 bits (para N81). Então, quando você chegar a 1 M baud, será um desafio para o processador de 16 MHz manter o UART abastecido com dados. Um novo byte será enviado a cada 160 tiques de relógio, o que é muito poucas linhas de código. Para um pequeno burst de dados, você pode atingir essa taxa. A mensagem é que o processador ficará sem velocidade antes que o UART seja o limite.

Observe, tudo isso se aplica a HardwareSerial , o serial do software é muito diferente.

Comentários

  • Observe que o 2M pode ser arquivado com hw serial, mas a implementação do arduino ‘ s parece muito lenta e envia muito lixo. Veja atmega328p ds para encontrar o bit mágico para dobrar sua velocidade. Além disso, adicione que 9800 baud é um padrão muito antigo, e muito de sensores usam esse valor como padrão, mesmo se puderem ser configurados para mais, como xbee, gps e muito mais. Também serial sobre usb usa negociação auto-baudrate que pode sobrescrever baudate selecionado, mas eu acho que não é usado pelo arduino (mas pode ser no leonardo)
  • 9600 8N1 também é uma configuração padrão de fato. Muitos dispositivos com interface serial são fornecidos com essa configuração e precisam ser configurados se outra velocidade (ou bits de dados, bit de paridade, bit de parada) for necessária.
  • ” é mais do que rápido o suficiente ” – Boa resposta, mas discordo um pouco desse ponto. A maioria das implementações de saída de depuração está bloqueando, então é muito desejável fazer a saída de depuração o mais rápido possível para evitar mudanças excessivas no tempo de execução do código.
  • Se você ‘ está fazendo transferência de dados em massa, idealmente você ‘ estaria usando SPI, certo?

Resposta

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

Relógios – mesmo baseados em quartzo – são imperfeitos e sujeitos a variações. Além disso, como o relógio serial geralmente é gerado por meio de um pré-divisor de potência de dois e contador (inteiro), todos os valores não podem ser obtidos com precisão dada uma frequência de relógio base. Com a ajuda dos bits de início / parada, a comunicação serial assíncrona pode ser tolerante a algum desvio do relógio. Mas isso tem limites.

Por exemplo, se seu ATmega328PA estiver funcionando a 1 MHz, você pode atingir 9600b / s com 0,2% de erro. Mas em 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).Todos esses números são da folha de dados ATmega48PA-88PA-168PA-328PA, p200 .

Isso não um problema quando dois dispositivos idênticos se comunicam entre si (já que, de fato, estão se comunicando na mesma velocidade). Isso pode ser um problema durante a comunicação entre dispositivos diferentes.

O aumento da frequência base não melhora significativamente a precisão. Por exemplo, rodar o mesmo ATmega328PA acima a 2 MHz não dá realmente melhores resultados, pois isso se deve principalmente a erros de arredondamento. Mas executá-lo em 1,8432 MHz oferece bps muito precisos de 2400b / s até 57,6 kHz.

Resposta

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

Resposta

De volta à névoa do tempo , o “padrão ouro” para teclados remotos (usando um modem de telefone e teletipos, se você se lembrar deles) era 9600 baud, inicialmente alcançável apenas por uma linha telefônica dedicada. O tempo passa, lentamente; avanços da tecnologia, rapidamente; e a memória se move ainda mais devagar do que o tempo (parece). Podemos nos comunicar rotineiramente, pelo menos por vários metros, em algumas ordens de magnitude mais rápido do que 9600 baud. O que antes era considerado padrão ouro não é mais ouro, mas ainda é considerado padrão.

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

Resposta

Acho que o principal motivo pelo qual as pessoas usam 9600 na maioria das vezes é que essa é 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 tiver que percorrer um longo caminho – embora eu não tenha ideia de por que isso foi selecionado como uma velocidade ideal.

Resposta

Tempo de reação humana

Porque ser capaz de parar o monitor serial quando seu Arduino está batendo na porta é exigido pelos usuários 100% do tempo, e ter a velocidade de transferência máxima é menor que 100% do tempo.

9600 baud é um meio-termo entre “fácil de matar um processo descontrolado” e “irritantemente lento”.

Comentários

  • 100% hey … interessante;)

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *