In gran parte del codice di esempio, le persone online aggiungono la riga Serial.begin(9600)nel blocco di installazione.

Quando cerco cosa Serial.begin()c'è nella documentazione ufficiale, mi dice che controlla il trasferimento dei dati bit per secondo.

Quindi la domanda ovvia è: perché non usare 28800, la velocità di trasferimento più alta? Perché le persone si accontentano di 9600? Qual è la limitazione qui?

Perché le persone si sistemano?

Le persone si accontentano perché è più che abbastanza veloce. L'uso più comune è solo quello di stampare alcune cose su un terminale per debuggin. 9600 baud sono 960 caratteri al secondo o 12 x 80 righe al secondo. Quanto velocemente riesci a leggere? :)

Se il tuo programma utilizza la porta seriale per il trasferimento di dati in blocco, scegli di non accontentarti.

Qual è la limitazione ...

I limiti sul seriale sono alti. Direttamente puoi usare 115200 baud nei tuoi programmi e funzionerà. Il terminale Arduino consentirà un massimo di 115200, ma altri programmi come RealTerm ti permetterebbero di correre più in alto.

L'hardware seriale funzionerà a 1 M baud. Se leggi in giro vedrai che le persone hanno usato fino a 1 M controllando direttamente l'UART. Potresti beneficiare di baud rate elevati per usi come la trasmissione tramite un chip bluetooth. Se si utilizza l'interfaccia seriale hardware per scambiare da chip a chip con una breve distanza, 1 M baud è completamente fattibile. Pensa a tutti i dispositivi SPI e I2C che funzionano perfettamente a una frequenza di clock di 1 MHz.

Su distanze maggiori, inizierai ad avere problemi con il rumore quando usi la segnalazione di livello logico (da 0 a 5 V). Per utilizzare distanze maggiori, aggiungere un ricetrasmettitore per fornire segnali robusti, comunemente RS-232 e meno comunemente RS-485. Con RS-232 potresti correre un mega bit a distanze di 10 piedi.

La velocità di clock del microprocessore sarà il limite reale. Con un UART hardware, il processore deve caricare un byte nell'UART ogni 10 bit (per N81). Quindi, quando si arriva a 1 M baud, sarà una sfida per il processore a 16 MHz mantenere l'UART fornito di dati. Un nuovo byte verrà inviato ogni 160 tick di clock, che sono pochissime righe di codice. Per una breve raffica di dati, potresti raggiungere quel tasso. Il messaggio è che il processore esaurirà la velocità prima che l'UART sia il limite.

Nota, tutto questo vale per HardwareSerial , il seriale del software è molto diverso.

Oltre a tutte le risposte interessanti, vale la pena ricordare che l'impostazione della velocità seriale su XXX bit / s non implica necessariamente XXX bit / s sull'hardware.

Gli orologi - anche al quarzo - sono imperfetti e soggetti a deriva. Inoltre, poiché l'orologio seriale viene generalmente generato attraverso un contatore pre-divisore e (intero) di potenza di due, non è possibile ottenere con precisione tutti i valori data una frequenza di clock di base. Con l'aiuto dei bit di avvio / arresto, la comunicazione seriale asincrona può essere tollerante a qualche deriva dell'orologio. Ma questo ha dei limiti.

Ad esempio, se ATmega328PA funziona a 1 MHz, è possibile ottenere 9600 b / s con 0,2% di errore. Ma a 14400 b / s l'errore è -3,5% (attualmente comunica a 13900 b / s). E a 28800b / s, l'errore è + 8,5% (comunicazione effettiva a 31200b / s). Tutte queste cifre provengono dalla scheda tecnica ATmega48PA-88PA-168PA-328PA, p200 .

Questo non è un problema quando due dispositivi identici comunicano insieme (poiché in effetti stanno comunicando alla stessa velocità). Esso potrebbe essere un problema quando si comunica tra dispositivi differenti.

L'aumento della frequenza di base non è necessario per migliorare significativamente la precisione. Ad esempio, eseguire lo stesso ATmega328PA di cui sopra a 2MHz non dà risultati migliori in quanto quelli sono principalmente dovuti a errori di arrotondamento. Ma eseguendolo 1.8432 MHz offre bps molto precisi da 2400 b / s fino a 57,6 kHz.

Penso che sia una specie di tradizione utilizzare una velocità di trasferimento che non è la più lenta (300) ma anche che non potrebbe causare problemi in alcune configurazioni (28800 o addirittura 115200). La porta seriale del PC (molto spesso un adattatore USB FTDI232) può far fronte a tassi più alti, ma l'hardware fai-da-te potrebbe non esserlo. Quindi 9600 bps si è affermato come una sorta di velocità di trasferimento standard per esempi di codice.

Indietro nella notte dei tempi, lo "standard d'oro" per le tastiere remote (usando un modem telefonico e teletipi, se ricordi quelli) era 9600 baud, inizialmente ottenibile solo su una linea telefonica dedicata. Il tempo passa lentamente; la tecnologia avanza rapidamente; e la memoria si muove ancora più lentamente del tempo (sembra). Siamo in grado di comunicare di routine, almeno per diversi metri, a un paio di ordini di grandezza più veloci di 9600 baud. Quello che una volta era considerato un gold standard non è più l'oro, ma ancora pensato come standard.

tl; dr: è storia, non tecnologia.

Penso che il motivo principale per cui le persone usano 9600 il più delle volte sia che è il baud rate predefinito nell'IDE di Arduino. Inoltre, velocità dei dati più elevate potrebbero essere inaffidabili se il segnale seriale deve viaggiare molto - anche se non ho idea del perché sia ​​stato selezionato come velocità ottimale.

Tempo di reazione umana

Perché essere in grado di arrestare il monitor seriale quando Arduino si rompe sulla porta è richiesto dagli utenti il ​​100% delle volte e avere la massima velocità di trasferimento è richiesta meno del 100% delle volte.

9600 baud è un compromesso tra "facile uccidere un processo in fuga" e "fastidiosamente lento".