Hvorfor gør folk bosætte sig?

Folk bosætter sig, fordi det er mere end hurtigt nok. Den mest almindelige anvendelse er bare at udskrive nogle ting på en terminal til debuggin. 9600 baud er 960 tegn pr. Sekund eller 12 x 80 tegnlinjer pr. Sekund. Hvor hurtigt kan du læse? 🙂

Hvis dit program bruger den serielle port til massedataoverførsel, vælger du ikke at afregne.

Hvad er begrænsningen …

Grænserne for seriel er høje. Direkte kan du bruge 115200 baud i dine programmer, og det fungerer bare. Arduino-terminalen tillader maksimalt 115200, men andre programmer som RealTerm vil lade dig køre højere.

Hardwareserie kører til 1 M baud. Hvis du læser rundt, vil du se, at folk har brugt op til 1 M ved direkte at kontrollere UART. Du kan muligvis få fordel af høje baudhastigheder til anvendelser såsom transmission via en bluetooth-chip. Hvis du bruger hardwarens serielle interface til at udveksle fra chip til chip med kun en kort afstand, så er 1 M baud fuldstændig mulig. Tænk på alle SPI- og I2C-enheder, der fungerer fint ved 1 MHz urfrekvens.

Over større afstande begynder du at få problemer med støj, når du bruger logisk niveau (almindelig 0 til 5V) signalering. For at bruge større afstande vil du tilføje en transceiver for at give robust signalering, almindeligvis RS-232 og mindre almindelig RS-485. Med RS-232 kan du køre en mega bit i en afstand på 10 “fod.

Mikroprocessorens urhastighed vil være den reelle grænse. Med en hardware-UART skal processoren indlæse en byte til UART hver 10 bit (til N81). Så når du kommer til 1 M baud, vil det være en udfordring for 16 MHz-processoren at holde UART forsynet med data. En ny byte sendes for hver 160 urtegninger, hvilket er meget få linjer kode. For en kort burst af data opnår du muligvis den hastighed. Beskeden er, at processoren løber tør for hastighed, før UART er grænsen.

Bemærk, alt dette gælder for HardwareSerial , softwareserien er meget anderledes.

Kommentarer

• Bemærk, at 2M kan arkiveres med hw seriel, men arduino ‘ s implementering virker for langsom og sender en masse affald. Se atmega328p ds for at finde den magiske bit til at fordoble din hastighed. Tilføj også, at 9800 baud er en meget gammel standard og meget af sensorer bruger denne værdi som standard, selvom den kan konfigureres til mere, som xbee, gps og meget mere. Også seriel over usb-brug auto-baudrate forhandling heks kan tilsidesætte valgt baudat, men jeg tror ikke bruges af arduino (men det kan være på Leonardo)
• 9600 8N1 er også en de facto standardindstilling. Mange enheder med en seriel grænseflade leveres med denne indstilling og skal konfigureres, hvis der kræves en anden hastighed (eller databaser, paritetsbit, stopbit).
• ” det er mere end hurtigt nok ” – Godt svar, men jeg er uenig i dette punkt. De fleste implementeringer af debug-output blokerer, så det er meget ønskeligt at gøre debug-output så hurtigt som muligt for at forhindre for store ændringer i kodeudførelsestid.
• Hvis du ‘ laver overførsel af bulkdata, ideelt set bruger du ‘ SPI, ikke?

Ud over alle de interessante svar, er det værd at nævne, at indstilling af seriel hastighed til XXX bits / s ikke nødvendigvis betyder, at XXX bits / s på hardwaren.

Ure – endda kvartsbaserede – er ufuldkomne og udsættes for drift. Derudover, da det serielle ur normalt genereres gennem en power-of-pre-divisor og (heltal) tæller, kan al værdi ikke nøjagtigt opnås med en basisurfrekvens. Ved hjælp af start / stop-bitene kan asynkron seriel kommunikation være tolerant over for noget urdrift. Men dette har begrænsninger.

For eksempel, hvis din ATmega328PA kører ved 1MHz, kan du opnå 9600b / s ved 0,2% af fejlen. Men ved 14400b / s er fejlen -3,5% (kommunikerer faktisk ved 13900b / s). Og ved 28800b / s er fejlen + 8,5% (kommunikerer faktisk ved 31200b / s).Alle disse tal er fra ATmega48PA-88PA-168PA-328PA datablad, p200 .

Dette er ikke et problem, når to identiske enheder kommunikerer sammen (da der faktisk er kommunikation med samme hastighed). Det kan være et problem, når du kommunikerer mellem forskellige enheder.

At øge basisfrekvensen forbedrer ikke nøjagtigheden væsentligt. For eksempel giver det at køre den samme ATmega328PA som ovenfor ved 2MHz ikke rigtig bedre resultater, da disse for det meste skyldes afrundingsfejl. Men at køre det 1,8432 MHz giver meget nøjagtige bps fra 2400b / s op til 57,6 kHz.

Jeg synes det er en slags tradition for at bruge en overførselshastighed, der ikke er den langsomste (300), men heller ikke en, der i sidste ende kan forårsage problemer i nogle opsætninger (28800 eller endda 115200). PC-serielporten (ofte en FTDI232 USB-adapter) kan klare højere priser, men din DIY-hardware muligvis ikke. Så 9600 bps har etableret sig som en slags standardoverførselshastighed for kodeeksempler.

Tilbage i tidenes tåge , “guldstandarden” til fjerntastaturer (ved hjælp af et telefonmodem og teletyper, hvis du husker dem) var 9600 baud, oprindeligt kun opnåelig via en dedikeret telefonlinje. Tiden bevæger sig langsomt; teknologien udvikler sig hurtigt; og hukommelsen bevæger sig endnu langsommere end tiden (det ser ud til). Vi kan rutinemæssigt kommunikere, i det mindste over flere meter, ved et par størrelsesordener hurtigere end 9600 baud. Hvad der engang blev betragtet som en guldstandard, er ikke længere guld, men betragtes stadig som standard.

tl; dr: Det er historie, ikke teknologi.

Jeg tror, at hovedårsagen til, at folk bruger 9600 det meste af tiden, er at det er standard baudrate i Arduino IDE. Også hurtigere datahastigheder kan også være upålidelige, hvis det serielle signal skal rejse langt – selvom jeg ikke har nogen idé om, hvorfor dette blev valgt som en optimal hastighed.

Human Reaction Time

Fordi er i stand til at stoppe den serielle skærm, når din Arduino kaster sig over porten kræves af brugerne 100% af tiden, og det er nødvendigt at have den maksimale overførselshastighed mindre end 100% af tiden.

9600 baud er et kompromis mellem “let at dræbe en løbsproces” og “irriterende langsom”.

Kommentarer

• 100% hej … interessant;)