Seberapa tinggi tingkat baud yang dapat saya gunakan (tanpa kesalahan)?


40

Standarnya adalah 9600 baud. Itu hanya standar . Menggunakan Arduino Uno SMD R2, berapakah baud rate praktis tertinggi yang dapat saya capai?

Poin bonus untuk yang berani: Bagaimana Anda membuat mekanisme pengecekan kesalahan dan kemudian meningkatkan baud rate yang konyol untuk mendapatkan tingkat transfer yang tinggi?


2
Perlu dicatat bahwa papan Arduino yang menggunakan FTDI USB-serial IC dapat benar-benar cepat. FT232 umum dapat pergi 3 Megabaud (itu 3.000.000 baud) tanpa masalah. Penggunaan ATmega16U2 adalah faktor pembatas.
Connor Wolf

1
Klon saya, Arduino Nano, yang saya dapat dari eBay mencapai 1.099.999. Serius. Itu benar. Begitu mencapai 1.100.000, hasilnya kacau. laqq`na`fca`fga`fga`bcngaah````iin`ha`a`a`bga`fga`bcqpahhqfq```fh`oopa`bca`fca. Menggunakan chip CH340 untuk komunikasi USB.
PNDA

Jawaban:


59

Ada beberapa faktor di sini:

  • Seberapa tinggi tingkat baud yang dapat dicapai oleh ATmega328P MCU?
  • Seberapa tinggi baud-rate yang dapat dicapai oleh antarmuka USB-Serial?
  • Berapa frekuensi osilator pada ATmega328P?
  • Berapa frekuensi osilator pada antarmuka serial-USB (jika ada)?
  • Seberapa toleran antarmuka USB serial dari ketidakcocokan baud-rate?

Semua faktor ini relevan untuk menentukan tingkat baud maksimum yang dapat dicapai. ATmega328P menggunakan pembagi perangkat keras dari clock-rate-nya untuk menghasilkan clock-dasar untuk antarmuka serial. Jika tidak ada rasio integer dari jam utama ke bit-time dari laju baud yang diinginkan, MCU tidak akan dapat secara tepat menghasilkan laju yang diinginkan. Ini dapat menyebabkan masalah potensial, karena beberapa perangkat jauh lebih sensitif terhadap ketidakcocokan baud-rate daripada yang lain.

Antarmuka berbasis FTDI cukup toleran terhadap ketidakcocokan baud-rate, hingga beberapa persen kesalahan. Namun, saya telah bekerja dengan modul GPS tertanam khusus yang tidak mampu menangani bahkan tingkat kesalahan baud 0,5%.

Antarmuka serial umum toleran ~ 5% kesalahan baud-rate. Namun, karena masing-masing ujung dapat dimatikan, spesifikasi yang lebih umum adalah + -2,5%. Dengan cara ini, jika salah satu ujungnya 2,5% cepat, dan yang lainnya lambat 2,5%, kesalahan keseluruhan Anda masih hanya 5%.


Bagaimanapun. Uno menggunakan ATmega328P sebagai MCU utama, dan ATmega16U2 sebagai antarmuka serial-USB. Kami juga beruntung di sini karena kedua MCU ini menggunakan USART harware serupa, serta 16 jam Mhz.

Karena kedua MCU memiliki harware dan clock-rate yang sama, keduanya akan memiliki kesalahan baud-rate yang sama dalam arah yang sama, sehingga kita dapat secara fungsional mengabaikan masalah kesalahan baud.

Bagaimanapun, jawaban yang "tepat" untuk pertanyaan ini akan melibatkan penggalian sumber untuk ATmega16U2, dan mencari kemungkinan baud-rate dari sana, tetapi karena saya malas, saya pikir sederhana, pengujian empiris akan bekerja.

Sekilas tentang lembar data ATmega328P menghasilkan tabel berikut:
masukkan deskripsi gambar di sini

Jadi mengingat max baud-rate 2 Mbps, saya menulis program uji cepat:

void setup(){};

void loop()
{

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

Dan kemudian melihat port serial yang relevan dengan terminal serial:

masukkan deskripsi gambar di sini

Jadi tampaknya perangkat keras dapat berjalan pada 2.000.000 baud tanpa masalah.

Perhatikan bahwa baud rate ini hanya memberikan MCU 64 80 clock-cycles per byte, jadi akan sangat menantang untuk membuat antarmuka serial tetap sibuk. Sementara masing-masing byte dapat ditransfer dengan sangat cepat, ada kemungkinan banyak waktu ketika antarmuka hanya menganggur.


Edit: Pengujian Aktual!

2 Mbps adalah nyata:
masukkan deskripsi gambar di sini
setiap bit-time adalah 500 ns, yang cocok persis dengan apa yang diharapkan.

Masalah kinerja! Panjang paket keseluruhan:
500 Kbaud: masukkan deskripsi gambar di sini

1 Mbaud: masukkan deskripsi gambar di sini

2 Mbaud: masukkan deskripsi gambar di sini
Catatan: overshoot yang terlihat disebabkan oleh praktik grounding probe lingkup yang buruk, dan mungkin tidak nyata. Saya menggunakan ground-clip-lead yang merupakan bagian dari probe lingkup saya, dan induktansi-lead kemungkinan merupakan penyebab mayoritas overshoot.

Seperti yang Anda lihat, panjang transmisi keseluruhan adalah sama untuk 0,5, 1 dan 2 Mbaud. Ini karena kode yang menempatkan byte dalam buffer serial dioptimalkan dengan buruk. Dengan demikian, Anda tidak akan pernah mencapai sesuatu yang lebih baik daripada 500 Kbaud yang efektif , kecuali Anda menulis perpustakaan serial Anda sendiri. Perpustakaan Arduino dioptimalkan dengan sangat buruk, sehingga mungkin tidak akan terlalu sulit untuk mendapatkan 2 Mbaud yang tepat, setidaknya untuk transmisi burst, jika Anda menghabiskan sedikit waktu untuk itu.


4
Ilustrasi bagus dari batasan throughput!
jippie

1
@AnnonomusPerson - Jika Anda beralih ke jam 20 Mhz, Anda dapat melakukan 2,5 Mbps.
Connor Wolf

1
@AnnonomusPerson - Anda harus menukar keduanya, atau menggunakan antarmuka serial-USB FTDI dengan osilator ATmega328P 20 Mhz. ATmega328P tidak dapat melakukan 2,5 Mbps tanpa 20 Mhz crystal / resonator. Hal yang sama berlaku untuk antarmuka ATmega16U2.
Connor Wolf

1
Jawaban bagus! Hanya satu koreksi kecil: pada 2 Mb / s, setiap transmisi byte membutuhkan 80 siklus CPU, bukan 64. Ini karena, berdasarkan waktu, setiap byte bernilai 10 bit (1 start, 8 data, 1 stop).
Edgar Bonet

1
@ linhartr22 - Kabel hanya benar-benar ikut bermain jika mereka panjang , seperti dalam 12 "+. Saya pikir itu mungkin tidak mungkin bahwa terlalu banyak orang menggunakan kabel sepanjang 100 kaki terlalu banyak. Selain itu, pertanyaannya adalah seberapa tinggi arduino / ATmega baud rate bisa naik, bukan seberapa tinggi perakitan kabel yang sewenang-wenang bisa pergi
Connor Wolf

7

Jendela Arduino Serial Monitor membatasi Anda hingga 115200, tapi itu bukan kemampuan baud rate tertinggi. Anda dapat membaca lembar data Atmel dan FT232 (atau apa pun yang Anda gunakan) untuk mengetahui secara maksimal, tetapi saya dapat berhasil menggunakan 230400 (dua kali lebih cepat dari yang terbesar yang didukung Arialino Serial Monitor) tanpa masalah.

Jika Anda ingin melihat hasilnya di komputer Anda, Anda memerlukan monitor serial lain yang mendukung opsi baud rate lainnya. Saya suka CoolTerm dan Rayap .

Perhatikan bahwa ini sangat tergantung pada kecepatan jam Anda juga.

Berikut ini kalkulator untuk membantu Anda menghitung apa yang mungkin.


Ketika Anda mulai berjalan lebih cepat dan lebih cepat, batasannya menjadi perpustakaan Serial - implementasinya tidak terlalu efisien.
Cybergibbons

situs web tautan sudah mati
Codebeat

3

Ini mungkin salah satu dari sedikit aspek di mana papan el-Cheapo berbeda dari papan asli. Kecepatan transfer serial maksimum hanya dibatasi oleh kualitas papan dan tata letaknya. Setelah data serial memasuki baik AVR atau chip antarmuka USB, data akan diproses secara berbeda dari protokol serial UART.

Perlu diingat bahwa mikrokontroler memiliki beberapa perangkat keras dasar untuk memindahkan / mematikan data serial ke / dari pin IO, tetapi tingkat maksimum absolut terbatas pada clock 16MHz (untuk AVR). Setelah byte dipindahkan ke buffer serial, perangkat keras UART akan mengambil alih dan mendorong keluar / menarik bitnya sendiri. AVR paling baik mencapai 16 juta instruksi per detik dan interupsi yang digunakan untuk mengisi buffer serial memiliki beberapa overhead (setidaknya 8 jam kutu untuk penanganan interupsi + instruksi untuk menyimpan keadaan saat ini + beberapa instruksi untuk benar-benar mengisi buffer). Pada bitrate yang diberikan, protokol akan berjalan dengan kecepatan n bit per detik, tetapi controller Anda membutuhkan lebih banyak waktu untuk mengisi buffer serial daripada yang dibutuhkan untuk benar-benar menampilkan data, menghasilkan throughput rata-rata yang lebih rendah daripada yang Anda harapkan dan pemalasan UART untuk waktu yang relatif lama.

Efek lain yang perlu diingat adalah bahwa semua overhead yang diperlukan untuk mendorong data ke UART (atau menariknya) tidak dapat digunakan dalam program Anda yang sebenarnya, sekali lagi mempengaruhi throughput praktis rata-rata. Anda hanya dapat menggunakan setiap siklus instruksi sekali, baik untuk mengisi buffer atau untuk menghitung loop utama.

Throughput maksimum karena itu tergantung pada aplikasi yang Anda gunakan (seberapa cepat data dihasilkan / dihitung / siap untuk pindah ke / dari buffer serial) dan bitrate 'fisik' yang sebenarnya hanya sebagian kecil dari keputusan desain.


1
Saya benar-benar, BENAR-BENAR ragu salah satu papan di luar sana memiliki masalah tata letak yang cukup parah untuk mencegah sinyal 2 Mhz bekerja dengan baik. 2 Mhz bukan frekuensi tinggi.
Connor Wolf

@FakeName Setidaknya satu papan di meja saya di sini telah meningkatkan BER ketika saya mendorong kecepatan serial. Saya biasanya menggunakan 9600, itu lebih dari cukup untuk sebagian besar aplikasi dan kuat.
jippie

Tidak bercanda! Hah. Saya bertanya-tanya seberapa buruk tata letak yang harus terjadi? Saya menduga itu bukan tata letak sebanyak resonator / kristal toleransi buruk.
Connor Wolf

1
Baud-rate tinggi, terutama jika U2Xn = 1di USART, cenderung menjadi sangat marah tentang ketidakcocokan.
Connor Wolf

@FakeName Saya dinosaurus, saya agak suka "9600 8N1" untuk semua alasan warisan yang salah yang dapat Anda pikirkan; o)
jippie

2

Pengecekan kesalahan sebenarnya sangat mudah dan ada lib AVR yang melakukan ini dalam satu liner.

Baca terus util/crc16.hdan Anda harus segera melakukannya dengan contoh-contoh yang disertakan.

CRC cukup kuat dan cepat untuk aplikasi sederhana.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.