In veel van de voorbeeldcode online voegen mensen de regel Serial.begin(9600)
toe aan het setup-blok.
Als ik opzoek wat Serial.begin()
in de officiële documentatie staat, staat er dat het de gegevensoverdracht per seconde regelt.
Dus de voor de hand liggende vraag is waarom niet 28800 gebruiken, de hoogste overdrachtssnelheid? Waarom nemen mensen genoegen met 9600? Wat is hier de beperking?
Opmerkingen
- Ter info: de hoogste arduino die is aangesloten op USB-steunen is eigenlijk 115200, en 57600 is vaak de tweede meest voorkomende baud zie je.
Answer
Waarom settelen?
Mensen nemen genoegen omdat het meer dan snel genoeg is. Het meest gebruikelijke gebruik is om wat dingen op een terminal af te drukken voor foutopsporing. 9600 baud is 960 tekens per seconde, of 12 x 80 tekenregels per seconde. Hoe snel kun je lezen? 🙂
Als je programma de seriële poort gebruikt voor gegevensoverdracht in bulk, zou je ervoor kiezen om niet te settelen.
Wat is de beperking …
De limieten voor serieel zijn hoog. U kunt direct 115200 baud gebruiken in uw programmas en het zal gewoon werken. De Arduino-terminal staat maximaal 115200 toe, maar met andere programmas zoals RealTerm zou je hoger kunnen draaien.
Hardware-serieel loopt naar 1 M baud. Als je rondleest, zul je zien dat mensen tot 1 M hebben gebruikt door de UART rechtstreeks te besturen. U kunt profiteren van hoge baudrates voor toepassingen zoals verzending via een bluetooth-chip. Als je de hardware seriële interface gebruikt om met een korte afstand van chip naar chip te wisselen, dan is 1 M baud volkomen haalbaar. Denk aan alle SPI- en I2C-apparaten die prima werken op 1 MHz kloksnelheid.
Over grotere afstanden zul je problemen krijgen met ruis bij het gebruik van logisch niveau (gewoon 0 tot 5V) signalering. Om grotere afstanden te gebruiken, zou u een zendontvanger moeten toevoegen voor robuuste signalering, meestal RS-232 en minder vaak RS-485. Met RS-232 zou je een megabit kunnen uitvoeren op afstanden van 10 “voet.
De kloksnelheid van de microprocessor zal de echte limiet zijn. Met een hardware UART moet de processor één byte in de UART laden. elke 10 bits (voor N81). Dus als je op 1 M baud komt, zal het een uitdaging zijn voor de 16 MHz processor om de UART van data te voorzien. Elke 160 kloktikken zal een nieuwe byte worden verzonden, wat heel weinig regels zijn van code. Voor een korte burst van gegevens zou u die snelheid kunnen behalen. Het bericht is dat de processor geen snelheid meer heeft voordat de UART de limiet is.
Let op, dit is allemaal van toepassing op HardwareSerial , software serienummer is heel anders.
Opmerkingen
- Let op: 2M is archiveerbaar met hw serial, maar de implementatie van arduino ‘ lijkt te traag en stuurt veel rotzooi. Zie atmega328p ds om het magische bit te vinden om je snelheid te verdubbelen. Voeg ook toe dat 9800 baud een zeer oude standaard is, en veel van de sensoren gebruiken die waarde standaard, zelfs als ze voor meer kunnen worden geconfigureerd, zoals xbee, gps en meer. Gebruik ook serieel over usb automatische baudrate-onderhandeling die de geselecteerde baudate kan overschrijven, maar ik denk dat het niet wordt gebruikt door arduino (maar het kan op leonardo zijn)
- 9600 8N1 is ook een de-facto standaardinstelling. Veel apparaten met een seriële interface worden geleverd met deze instelling en moeten worden geconfigureerd als een andere snelheid (of databits, pariteitsbit, stopbit) vereist is.
- ” het is meer dan snel genoeg ” – Goed antwoord, maar ik ben het enigszins oneens met dit punt. De meeste implementaties van debug-uitvoer blokkeren, dus het is zeer wenselijk om de debug-uitvoer zo snel mogelijk te maken om buitensporige wijzigingen in de uitvoeringstijd van de code te voorkomen.
- Als u ‘ als u gegevensoverdracht in bulk uitvoert, idealiter ‘ zou u SPI gebruiken, toch?
Antwoord
Naast alle interessante antwoorden is het vermeldenswaard dat het instellen van de seriële snelheid op XXX bits / s niet noodzakelijk XXX bits impliceert / s op de hardware.
Klokken – zelfs op basis van kwarts – zijn onvolmaakt en onderhevig aan drift. Bovendien, aangezien de seriële klok gewoonlijk wordt gegenereerd door een macht van twee pre-deler en (integer) teller, kan niet alle waarde nauwkeurig worden verkregen gegeven een basisklokfrequentie. Met behulp van de start / stop-bits kan asynchrone seriële communicatie tolerant zijn voor enige klokafwijking. Maar dit heeft grenzen.
Als uw ATmega328PA bijvoorbeeld op 1 MHz draait, kunt u 9600 b / s halen met 0,2% fout. Maar bij 14400 b / s is de fout -3,5% (eigenlijk communiceert met 13900 b / s). En met 28800 b / s is de fout + 8,5% (eigenlijk communiceert met 31200 b / s).Al deze cijfers zijn afkomstig van ATmega48PA-88PA-168PA-328PA datasheet, p200 .
Dit is niet een probleem wanneer twee identieke apparaten met elkaar communiceren (aangezien ze in feite met dezelfde snelheid communiceren). Het kan een probleem zijn bij de communicatie tussen verschillende apparaten.
Het verhogen van de basisfrequentie verbetert niet noodzakelijk de nauwkeurigheid significant. Als u bijvoorbeeld dezelfde ATmega328PA als hierboven gebruikt op 2 MHz, levert dit niet echt betere resultaten op, aangezien deze meestal te wijten zijn aan afrondingsfouten. Maar als je het 1,8432 MHz gebruikt, krijg je een zeer nauwkeurige bps van 2400 b / s tot 57,6 kHz.
Antwoord
Ik denk dat het een een soort traditie om een overdrachtssnelheid te gebruiken die niet de laagste is (300), maar ook niet een die uiteindelijk problemen zou kunnen veroorzaken in sommige opstellingen (28800 of zelfs 115200). De seriële poort van de pc (meestal een FTDI232 USB-adapter) kan hogere snelheden aan, maar uw doe-het-zelfhardware misschien niet. Dus 9600 bps heeft zichzelf bewezen als een soort standaard overdrachtssnelheid voor codevoorbeelden.
Antwoord
Terug in de mist der tijden , de “gouden standaard” voor toetsenborden op afstand (met behulp van een telefoonmodem en teletypes, als je je die herinnert) was 9600 baud, aanvankelijk alleen haalbaar via een speciale telefoonlijn. De tijd gaat langzaam voort; technologie ontwikkelt zich snel; en het geheugen beweegt zelfs nog langzamer dan de tijd (zo lijkt het). We kunnen routinematig communiceren, tenminste over een paar meter, met een paar ordes van grootte sneller dan 9600 baud. Wat ooit als een gouden standaard werd beschouwd, is niet langer goud, maar wordt nog steeds als standaard beschouwd.
tl; dr: Het is geschiedenis, geen technologie.
Antwoord
Ik denk dat de belangrijkste reden waarom mensen 9600 meestal gebruiken, is dat dit de standaard baudrate is in de Arduino IDE. Bovendien kunnen hogere gegevenssnelheden ook onbetrouwbaar zijn als het seriële signaal een lange weg moet afleggen – hoewel ik geen idee heb waarom dit als optimale snelheid is geselecteerd.
Antwoord
Menselijke reactietijd
Omdat de seriële monitor kan stoppen wanneer uw Arduino op de poort klopt is 100% van de tijd vereist door gebruikers en de maximale overdrachtssnelheid is vereist minder dan 100% van de tijd.
9600 baud is een compromis tussen “gemakkelijk om een op hol geslagen proces te beëindigen” en “irritant traag”.
Opmerkingen
- 100% hey … interessant;)