Hvorfor gjør folk bosette seg?

Folk bosetter seg fordi det er mer enn raskt nok. Den vanligste bruken er bare å skrive ut noen ting på en terminal for debuggin. 9600 baud er 960 tegn per sekund, eller 12 x 80 tegnlinjer per sekund. Hvor raskt kan du lese? 🙂

Hvis programmet bruker serieporten for massedataoverføring, velger du å ikke gjøre noe.

Hva er begrensningen …

Grensene for seriell er høye. Direkte kan du bruke 115200 baud i programmene dine, og det vil bare fungere. Arduino-terminalen tillater maksimalt 115200, men andre programmer som RealTerm vil la deg løpe høyere.

Maskinvareserien kjører til 1 M baud. Hvis du leser rundt, vil du se at folk har brukt opptil 1 M ved å kontrollere UART direkte. Du kan dra nytte av høye overføringshastigheter for bruk som overføring via en Bluetooth-brikke. Hvis du bruker maskinvarens serielle grensesnitt for å bytte fra chip til chip med bare en kort avstand, er 1 M baud fullstendig mulig. Tenk på alle SPI- og I2C-enhetene som fungerer helt fint med 1 MHz klokkehastighet.

Over større avstander vil du begynne å få problemer med støy når du bruker logisk nivå (vanlig 0 til 5V) signalering. For å bruke større avstander vil du legge til en sender / mottaker for å gi robust signalering, ofte RS-232 og mindre vanlig RS-485. Med RS-232 kan du kjøre megabit på avstander på 10 «fot.

Mikroprosessorens klokkehastighet vil være den virkelige grensen. Med en UART-maskinvare må prosessoren laste en byte til UART hver 10. bit (for N81). Så når du kommer til 1 M baud, vil det være en utfordring for 16 MHz-prosessoren å holde UART forsynt med data. En ny byte vil bli sendt hver 160 klokke, det er veldig få linjer kode. For en kort serie data kan du oppnå den hastigheten. Meldingen er at prosessoren vil gå tom for hastighet før UART er grensen.

Merk, alt gjelder HardwareSerial , programvareserien er veldig annerledes.

Kommentarer

• Vær oppmerksom på at 2M kan arkiveres med hw seriell, men arduino ‘ s implementering virker for treg og sender mye søppel. Se atmega328p ds for å finne den magiske biten til å doble hastigheten. Legg også til at 9800 baud er en veldig gammel standard, og mye av sensorer bruker den verdien som standard, selv om den kan konfigureres for mer, som xbee, gps og mer. Også seriell over usb-bruk auto-baudrate forhandlingsheks kan overstyre valgt baudat, men jeg tror ikke det brukes av arduino (men det kan være på leonardo)
• 9600 8N1 er også en de facto standardinnstilling. Mange enheter med et serielt grensesnitt leveres med denne innstillingen og må konfigureres hvis det kreves en annen hastighet (eller databaser, paritetsbit, stoppbit).
• » det er mer enn raskt nok » – Godt svar, men jeg er noe uenig i dette punktet. De fleste implementeringer av feilsøkingsutdata blokkerer, så det er veldig ønskelig å gjøre feilsøkingsutdataene så raskt som mulig for å forhindre for store endringer i kodeutførelsestiden.
• Hvis du ‘ Gjør masseoverføring av data, ideelt sett bruker du ‘, ikke sant?

I tillegg til alle interessante svar, er det verdt å nevne at å sette seriell hastighet til XXX bits / s ikke nødvendigvis innebærer XXX bits / s på maskinvaren.

Klokker – til og med kvartsbaserte – er ufullkomne og utsettes for drift. I tillegg, ettersom den serielle klokken vanligvis genereres gjennom en power-of-two pre-divisor og (heltall) teller, kan ikke alle verdier oppnås nøyaktig gitt en baseklokkefrekvens. Ved hjelp av start / stopp-bitene kan asynkron seriell kommunikasjon være tolerant for noe klokkedrift. Men dette har grenser.

Hvis ATmega328PA for eksempel kjører på 1MHz, kan du oppnå 9600b / s med 0,2% feil. Men ved 14400b / s er feilen -3,5% (kommuniserer faktisk ved 13900b / s). Og ved 28800b / s er feilen + 8,5% (faktisk kommuniserer ved 31200b / s).Alle disse tallene er fra ATmega48PA-88PA-168PA-328PA datablad, p200 .

Dette er ikke et problem når to identiske enheter kommuniserer sammen (ettersom det faktisk er kommunikasjon med samme hastighet). Det kan være et problem når du kommuniserer mellom forskjellige enheter.

Å øke basefrekvensen trenger ikke å forbedre nøyaktigheten. For eksempel å kjøre den samme ATmega328PA som ovenfor ved 2MHz gir egentlig ikke bedre resultater, da de hovedsakelig skyldes avrundingsfeil. Men å kjøre den 1,8432 MHz gir veldig nøyaktige bps fra 2400b / s opp til 57,6 kHz.

Jeg tror det er en slags tradisjon for å bruke en overføringshastighet som ikke er den tregeste (300), men heller ikke en som til slutt kan forårsake problemer i noen oppsett (28800 eller til og med 115200). PC-serieporten (som oftest en FTDI232 USB-adapter) kan takle høyere priser, men DIY-maskinvaren din kanskje ikke. Så 9600 bps har etablert seg som en slags standard overføringshastighet for kodeeksempler.

Tilbake i tidenes tåke , «gullstandarden» for eksterne tastaturer (ved hjelp av et telefonmodem og teletyper, hvis du husker disse) var 9600 baud, som i utgangspunktet bare kan oppnås via en dedikert telefonlinje. Tiden går sakte; teknologien går raskt; og hukommelse beveger seg enda saktere enn tid (ser det ut til). Vi kan rutinemessig kommunisere, i det minste over flere meter, med et par størrelsesordener raskere enn 9600 baud. Det som en gang ble ansett som en gullstandard, er ikke lenger gull, men fremdeles tenkt på som standard.

tl; dr: Det er historie, ikke teknologi.

Jeg tror hovedårsaken til at folk bruker 9600 mesteparten av tiden er at det er standard baudrate i Arduino IDE. Også raskere datahastigheter kan også være upålitelige hvis det serielle signalet må reise langt – selv om jeg ikke aner hvorfor dette ble valgt som en optimal hastighet.

Human Reaction Time

Fordi å være i stand til å stoppe seriell skjerm når Arduino stryker på porten kreves av brukere 100% av tiden, og å ha maksimal overføringshastighet kreves mindre enn 100% av tiden.

9600 baud er et kompromiss mellom «lett å drepe en løpsk prosess» og «irriterende sakte».

Kommentarer

• 100% hei … interessant;)