Küsimus:
Kui kõrgele saab baudikiirust (ilma vigadeta) minna?
Anonymous Penguin
2014-02-19 09:16:57 UTC
view on stackexchange narkive permalink

Standard on 9600 baud. See on lihtsalt standard . Mis on Arduino Uno SMD R2 abil kõrgeim praktiline edastuskiirus, mida ma saan saavutada?

Boonuspunktid jultunud inimeste jaoks: Kuidas läheksite veakontrolli loomisel edasi? mehhanism ja seejärel suurendada ülekandekiirust naeruväärselt kõrgeks, et saada kõrge ülekandekiirus?

Väärib märkimist, et Arduino plaadid, mis kasutavad FTDI USB-jada IC-sid, võivad tõepoolest kiiresti minna. Tavaline FT232 suudab probleemideta läbida 3 megabaidi (see on 3 000 000 baudi). ATmega16U2 kasutamine on piiravaks teguriks.
Minu kloon Arduino Nano, mille sain eBay-st, oli 1 099 999. Tõsiselt. See tegi. Kui see jõudis 1 100 000-ni, oli toodang segane. `` laqq`na`fca`fga`fga`bcngaah```iin`ha`a`a`bga`fga`bcqpahhqfq `` fh`oopa`bca`fca``. See kasutab USB-koomiksite jaoks CH340 kiipi.
Neli vastused:
#1
+63
Connor Wolf
2014-02-19 12:24:55 UTC
view on stackexchange narkive permalink

Siin on mitu tegurit:

  • kui suure kiiruse saab ATmega328P MCU saavutada?
  • Kui suure kiirusega saab USB- Jaamaliidese saavutamine?
  • Milline on osmillaatori sagedus ATmega328P-l?
  • Milline on USB-jadaliidese ostsillaatori sagedus (kui sellel on)?
  • Kui tolerantne on andmeedastuskiiruse mittevastavuse USB-jadaliides?

Kõik need tegurid on olulised maksimaalse saavutatava baudikiiruse määramiseks. ATmega328P kasutab jadaliidese baaskella loomiseks oma kellamääraga riistvaralist jagajat. Kui põhikellast kuni soovitud baudikiiruse bitiajani pole täisarvu suhet, ei saa MCU soovitud kiirust täpselt toota. See võib põhjustada potentsiaalseid probleeme, kuna mõned seadmed on palju kiiremini tundlikud ülekandekiiruse mittevastavuse suhtes kui teised.

FTDI-põhised liidesed taluvad baudikiiruse mittevastavuse suhtes üsna palju viga. Olen aga töötanud spetsiaalsete sisseehitatud GPS-moodulitega, mis ei suutnud toime tulla isegi 0,5% bittikiiruse veaga.

Üldised jadaliidesed taluvad ~ 5% bittikiiruse viga. Kuid kuna mõlemad otsad võivad olla välja lülitatud, on tavalisem spetsifikatsioon + -2,5%. Sel juhul, kui üks ots on 2,5% kiire ja teine ​​2,5% aeglane, on teie üldine viga endiselt ainult 5%.


Igatahes. Uno kasutab ATmega328P esmase MCU-na ja ATmega16U2 USB-jadaliidesena. Meil on siin ka õnne, et mõlemad MCU-d kasutavad sarnaseid riistvara USART-sid, samuti 16 Mhz kella.

Kuna mõlemal MCU-l on sama riistvara ja taktsagedus, on neil mõlemal ühesugune sama baudikiiruse viga, nii et võime baudi tõrke probleemi funktsionaalselt ignoreerida.

Igatahes tähendaks "õige" vastus sellele küsimusele ATmega16U2 allika üleskaevamist ja sealt võimalike baudikiiruste väljatöötamist, kuid kuna ma olen laisk, siis arvan, et lihtne, empiiriline testimine töötab. / p>

Kiire pilguheit ATmega328P andmelehele annab järgmise tabeli:
enter image description here

Arvestades maksimaalselt määratud 2 Mbps andmeedastuskiirust, kirjutasin kiirtesti programmi:

  void setup () {}; void loop () {delay (1000); Serial.begin (57600); Serial.println ("\ r \ rBaud-rate = 57600"); viivitus (1000); Serial.begin (76800); Serial.println ("\ r \ rBaud-rate = 76800"); viivitus (1000); Serial.begin (115200); Serial.println ("\ r \ rBaud-rate = 115200"); viivitus (1000); Serial.begin (230400); Serial.println ("\ r \ rBaud-rate = 230400"); viivitus (1000); Serial.begin (250000); Serial.println ("\ r \ rBaud-rate = 250000"); viivitus (1000); Serial.begin (500000); Serial.println ("\ r \ rBaud-rate = 500000"); viivitus (1000); Serial.begin (1000000); Serial.println ("\ r \ rBaud-rate = 1000000"); viivitus (1000); Serial.begin (2000000); Serial.println ("\ r \ rBaud-rate = 2000000");};  

Ja seejärel jadaterminaliga asjakohase jadapordi vaatamine:

enter image description here

Seega näib, et riistvara suudab probleemideta töötada 2 000 000 baudiga.

Pange tähele, et see baudikiirus annab MCU-le ainult 64 80 taktsüklit baidi kohta, seega oleks jadaliidese hõivamine väga keeruline. Kuigi üksikud baidid võidakse edastada väga kiiresti, on tõenäoliselt palju aega, kui liides on lihtsalt jõude.


Muuda: tegelik testimine!

2 Mbps on tõeline:
enter image description here
iga bitiaeg on 500 ns, mis sobib täpselt oodatuga.

Toimivuse probleemid! Paketi üldpikkus:
500 Kbaud: enter image description here

1 Mbaud: enter image description here

2 Mbaud: enter image description here
Märkus: märgatav ületamine on tingitud sondi maandamise halbast ulatusest ja tõenäoliselt pole reaalne. Kasutan maapealset klambrit, mis on osa minu ulatusega sondist, ja plii-induktiivsus on tõenäoliselt suurema osa ületamise põhjus.

Nagu näete, on ülekande üldpikkus 0,5, 1 ja 2 Mbaud puhul sama. Seda seetõttu, et baitide jadapuhvrisse paigutav kood on halvasti optimeeritud. Sellisena ei saa te kunagi midagi paremat kui efektiivne 500 Kbaud, kui te ei kirjuta ise oma seeriaraamatukogusid. Arduino teegid on väga halvasti optimeeritud, nii et ilmselt poleks raske korralikku 2 Mbaudi saada, vähemalt purskedastuse jaoks, kui kulutate sellele natuke aega.

Kena illustratsioon läbilaskevõime piiramise kohta!
@jippie - mul oli rakendusala üleval ja käitasin vastuses programmi, mis tsükli kaudu edastab kiirust. See oli väga vähe lisatööd ja illustreerib seda küsimust üsna kenasti. Samuti on minu ulatusega segmenteeritud mälu vinge.
DS2000 seeria? Kas bitikiiruse langetamine 250kb-ni kahekordistab edastamise aega? Ma arvan, et 500kb suurusel pildil suudan ikkagi hõlpsasti tuvastada stardi- / stoppbitid.
@jippie - 4000 seeria. Ma armastan mind umbes 4 kanaliga.
Kui jätate seeriateegi vahele, saate palju kiiremini.
@Cybergibbons - jah. Vaadake optimeerimise kohta märkust lõpus.
Ma arvasin, et 9600 baud oli AVR-seadme jaoks üsna hea, kuid ma ei oodanud kunagi 2 MBPS-i!
@AnnonomusPerson - kui lülitate 20 Mhz kella, saate teha 2,5 Mbps.
@FakeName 20 Mhz peakristall või USB-kiibil?
@AnnonomusPerson - peate vahetama mõlemad või kasutama FTDI usb-jadaliidest koos 20 Mhz ATmega328P ostsillaatoriga. ATmega328P ei saa 2,5 Mbit / s ilma 20 Mhz kristalli / resonaatorita. Sama kehtib kõigi ATmega16U2 liideste kohta.
Suurepärane vastus! Ainult üks väike parandus: kiirusel 2 Mb / s võtab iga baidi edastamine 80 protsessori tsüklit, mitte 64. Seda seetõttu, et aja jooksul on iga bait väärt 10 bitti (1 algus, 8 andmeid, 1 peatus).
@EdgarBonet - teil on üsna korrektne (ja ohhoo). Parandatud.
See on suurepärane vastus ühe erandiga, kuna see ei arvesta füüsilise andmekandja (teise seadmega ühenduse loomiseks kasutatav traat / kaabel) mõjutusi. See on ka peamine kasulike baudikiiruste piirav tegur. Järjestikune suhtlus on üsna igav vaid ühe seadmega (kaasa arvatud loopback). :: muigama ::
@linhartr22 - juhtmed tulevad tõepoolest mängu vaid siis, kui need on * pikad *, nagu 12 "+ puhul. Ma arvan, et on tõenäoliselt ebatõenäoline, et liiga paljud inimesed kasutavad 100 jala pikkuseid kaableid liiga palju. Pealegi oli küsimus, kui kõrge on ** arduino / ATmega ** baudikiirus võib minna, mitte see, kui kõrgele suvaline kaablikomplekt võib tõusta.
@ConnorWolf, Ma ei tea, kas nõustun selle väitega 100%: "Kuna mõlemal MCU-l on sama riistvara ja taktsagedus, siis on neil mõlemal ühesugune sama baudikiiruse viga, nii et võime funktsionaalselt ignoreerida baudi viga. " Ma ei näe, kuidas sama UART-i olemasolu tagaks vea samas suunas, kuna üksikud kiibid võivad ikkagi juhuslikult erineda? - ja kuigi mõlemad kiibid on sama sagedusega, mis tähendab, et seeriasageduse arvutamise viga on samas suunas , Tean, et kiibid ei kasuta sama kella allikat (16U2 kasutab kristalli, 328 eraldi keraamilist ostsillaatorit).
@GabrielStaples - teil on puudu viga, millest räägin. Põhimõtteliselt kasutavad ATmega UART-id nii, et nad kasutavad jada ajastuse genereerimiseks täisarvujaoturit MCU kellast. Sellisena ei saa mõnda baudikiirust otseselt saavutada, kuna edastuskiiruse ja süsteemi kella suhe ei ole täisarv. Üldiselt valitakse selles olukorras * lähim variant *, mille tulemuseks on viga, millest ma siin räägin (`abs (lähim variant - target baud) = viga`). ** See ** viga sobitub kahe erineva osa vahel.
While chips can vary, the operation of the UART is deterministic, so if you drive two parts with the same clock source, you'll get the same outputs (minus some small potential jitter).
@ConnorWolf, Ma näen, nii et see tähendab, et kui soovite maksimeerida kahe seadme võimalust rääkida väga suure baudikiirusega, kuna tegemist on asünkroonse suhtlusega, peaksite laskma neil mõlemal kasutada sama sageduskella, et nende tegelik tegelik arv baudikiirused kalduvad samas suunas, ühtlustades seeläbi nende bitiajastust paremini? On see õige? st: 16MHz Arduino 16MHz USB to UART seadmega on parem kui 20MHz USB to UART seadmega 16Mhz Arduino?
Põhimõtteliselt on küsimus selles, et teil on 20 MHz kellaga MCU, võite saada baudikiiruse jagurilt -1,5% vea ja * ostsillaatori dispersioon võib olla -1%. Kui räägite 16 MHz osc-ga MCU-ga, mis annab + 2% jagaja vea ja + 1,5% ostsillaatori vea, on kõik teie vead kokku 5%. Kui jagate sama ostsillaatori võrdlussagedust, ühilduvad baudikiiruse jagaja vead, mistõttu need tühistatakse ja ainsaks asjakohaseks teguriks saab ostsillaatori viga.
Edit: Yeah, you've got it. However, the baud-rate generation logic is specific to a device/line-of-devices,so comparing between different manufacturers can be complicated.
Ma näen nüüd. Kontrollisin just ATmega328 andmelehte. Siin on [veel üks tabel] (http://i.stack.imgur.com/muABX.png) (alates lk 175), võiksite esimese vastuse sisse visata. See aitab arvutada baudikiiruseid, et kontrollida nende vigu tabelis, ja teeb mulle selgeks, kuidas nad oma vead said. Näiteks näitab 115,2 k asünkroonse tavarežiimi viga -3,5% (U2Xn = 0). Valem kõlab: "16e6 / (16 * (8 + 1)) = 111111.11bps". See on lähim variant. Niisiis, viga on 111111,11 / 115200 = 0,9645 = -3,5%.
Naljakas, et 1MBPS ja 2MBPS baudi edastamiseks kulub sama aeg. Selle põhjuseks on asjaolu, et baite ei kopeerita piisavalt kiiresti? See võib tähendada ka seda, et te ei saa selle kiirusega baite vastu võtta. Muidugi saate 1 baidi 2Mbaud-ga, kuid mitme baidi vastuvõtmiseks sõltub see, kui kiiresti Arduino jadapuhvri tühjendab (ja seega saab veel ühe baidi).
@Paul - Arduino ei tee midagi. ** ATMega328p ** aga teeb palju asju. Igatahes on läbilaskevõime probleemid ülekande katkestuse käitleja kiiruse efektiivsusest. Reeglina on arduino vaikekogudes olev kood tõepoolest halva kvaliteediga. Peaks olema täiesti võimalik jadalinki küllastada vähemalt lühikeste pursketena.
Kas arvate, et põrkumist vähendavate mütside (~ 10-2pf) lisamine maapinnale võib stabiilsust suurendada?
@tuskiomi - mida? Ei, küsimus on maandusklambri juhtme induktiivsuses, mis on osa minu ulatusega sondist. Õige lahendus on kasutada [sondi otsas asuvat maad] (https://electronics.stackexchange.com/a/40421/1374), kuid kui te ei ürita spetsiaalselt mõõta selliseid asju nagu tööaeg, kui teate helisemist pole tõeline, see pole märkimisväärne teema.
@ConnorWolf ma pole kindel. näiteks [minu küsimus] üle (https://arduino.stackexchange.com/questions/41661/arduino-due-not-properly-detecting-sd-card), kondensaatorid eitasid enamikku spikerdamist, mis ei juhtuks, kui see oleks sondi asi.
@tuskiomi - see on ootuspärane, kuna kondensaatorid aeglustavad servasagedust, mis tähendab, et maandusklambri induktiivsusel on väiksem mõju. Asi on selles, et spikerdamine ei ole 1. mitte kahjulik, 2. enamikul juhtudel mitte tegelikult reaalne, vaid pigem mõõteartefakt. Lisaks on kondensaatorid vooluahela jaoks * halvemad *, kuna need koormavad otse bussi juhtiva IC väljunddraivereid. Üldiselt on ** väga ** üksikuid juhtumeid, kus soovite kunagi andmesiinile * mahtuvust * lisada.
Põhimõtteliselt, enne kui hakkate kondensaatoreid kõikjale kleepima, [õppige oma maapinda kasutama] (https://electronics.stackexchange.com/questions/40420/what-is-the-name-of-this-springy-type-oscilloscope- probe-accessory / 40421 # 40421) ja kontrollige seda. [Siin] (http://teledynelecroy.com/doc/passive-probe-ground-lead-effects) on Teledyne LeCroy valge raamat selle teema kohta. [Siin] (http://web.mit.edu/6.101/www/reference/ABCprobes_s.pdf) on teine ​​Tektronix.
Pidage meeles, et isegi kui teie andmeedastuskiirus on suhteliselt aeglane, määrab maapinna induktiivsuse mõju pigem * servasagedus * kui servasagedus. Isegi väikesed aeglased seadmed, nagu ATMega IC-d, suudavad üsna kiireid servi toota.
#2
+8
sachleen
2014-02-19 11:27:36 UTC
view on stackexchange narkive permalink

Arduino seeriamonitori aken piirdub 115200-ga, kuid see pole kõrgeim võimalik baudikiirus. Maksimaalsuse väljaselgitamiseks võite lugeda Atmeli ja FT232 (või mida iganes te kasutate) andmelehti, kuid olen võimeline probleemideta kasutama 230400 (kaks korda kiiremini kui Arduino seeriamonitori suurim).

Kui soovite tulemusi oma arvutis näha, vajate teist seerianäidikut, mis toetab muid baudikiiruse valikuid. Mulle meeldivad CoolTerm ja Termite.

Pange tähele, et see sõltub suuresti ka teie kella kiirusest.

Siin on kalkulaator, mis aitab teil arvutada võimalikke.

Kui hakkate üha kiiremini liikuma, muutub piirang seeriateegiks - selle rakendamine pole eriti tõhus.
lingi veebisait on surnud
"Arduino seeriamonitori aken piirdub 115200-ga," - See pole enam tõsi. See tõuseb kuni 2Mbps
#3
+3
jippie
2014-02-19 12:39:32 UTC
view on stackexchange narkive permalink

See on ilmselt üks väheseid aspekte, kus el-Cheapo lauad erinevad originaalplaatidest. Maksimaalset seeriaedastuskiirust piirab üsna palju ainult tahvli kvaliteet ja selle paigutus. Kui seeriandmed sisestatakse kas AVR-i või USB-liidese kiibi, töödeldakse andmeid jadapõhisest UART-protokollist erinevalt.

Pidage siiski meeles, et mikrokontrolleril on põhiline riistvara, et seeriandmeid IO-nööpnõeltesse sisestada / välja viia, kuid absoluutne maksimaalne kiirus on piiratud 16MHz kellaga (AVR-de puhul). Kui bait on jadapuhvrisse viidud, võtab UART riistvara üle ja surub bitid ise välja / tõmbab sisse. Parimal juhul jõuab AVR 16M-ni sekundis ja jadapuhvri täitmiseks kasutatavatel katkestustel on üldkulud (katkestuste käsitlemiseks vähemalt 8 kellapulka + juhised praeguse oleku salvestamiseks + mitu juhist puhvri tegelikuks täitmiseks). Teatud bitikiirusel töötab protokoll tohutult n bitti sekundis, kuid teie kontroller vajab jadapuhvri täitmiseks rohkem aega kui andmete reaalseks väljastamiseks, mille tulemuseks on oodatust madalam keskmine läbilaskevõime ja UART tühikäigul suhteliselt pikka aega. Puuduseks on bitivigade suurenenud tõenäosus.

Teine efekt, mida tuleb meeles pidada, on see, et kõiki andmeid, mis on vajalikud andmete UART-i välja tõrjumiseks (või nende sisestamiseks), ei saa teie tegelikus programmis kulutada, mõjutades jällegi keskmist praktiline läbilaskevõime. Igat käsitsüklit saab puhvri täitmiseks või peatsükli arvutamiseks kasutada ainult üks kord.

Maksimaalne läbilaskevõime sõltub seetõttu kasutatavast rakendusest (kui kiiresti andmeid genereeritakse / arvutatakse / valmis on liikuda jadapuhvrisse / tagasi) ja tegelik "füüsiline" bitikiirus on ainult väike osa kujundusotsusest.

Ma tõesti, tõesti kahtlen, et ühelgi seal oleval tahvlil on piisavalt tõsiseid paigutusprobleeme, et takistada 2 MHz signaali head töötamist. 2 Mhz pole just kõrge sagedus.
@FakeName Vähemalt üks minu siin laual olev plaat on suurendanud BER-i, kui surun jadakiirust. Ma kasutan tavaliselt 9600, mis on enamiku rakenduste jaoks enam kui piisav ja vastupidav.
Ilma naljata! Ah. Huvitav, kui halb peab paigutus olema, et see juhtuks? Ma kahtlustaksin, et see pole siiski nii paigutus kui halvasti talutavad resonaatorid / kristallid.
Kõrge ülekandekiirus, eriti kui USART-is on "U2Xn = 1", kipub mittevastavuse osas üsna hulluks minema.
@FakeName Olen dinosaurus. Mulle meeldib "9600 8N1" kõigil valedel põhjustel, mida võite mõelda; o)
Pagan, ma kasutan 9600 ise kõige silumisjama jaoks. See pole ainult sina. Mul on lihtsalt aeg-ajalt vaja * palju * andmeid ümber lükata ja piiride tundmine on oluline.
Ma ei imestaks, kui suurenenud BER on tingitud odavast võltsitud jadakiibist. (FTDI võlts) @ConnorWolf
#4
+2
80HD
2014-02-19 21:31:57 UTC
view on stackexchange narkive permalink

Vigade kontrollimine on tegelikult väga lihtne ja on olemas AVR lib, mis teeb seda ühes liinis.

Lugege lehelt util / crc16.h ja peaksite olema hea, kui kaasatud näidetega viivitamatult minna. > CRC on lihtsate rakenduste jaoks üsna vastupidav ja kiire.



See küsimus ja vastus tõlgiti automaatselt inglise keelest.Algne sisu on saadaval stackexchange-is, mida täname cc by-sa 3.0-litsentsi eest, mille all seda levitatakse.
Loading...