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

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?

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:

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:

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:

setiap bit-time adalah 500 ns, yang cocok persis dengan apa yang diharapkan.

Masalah kinerja! Panjang paket keseluruhan:
500 Kbaud:

1 Mbaud:

2 Mbaud:
_{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.

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.

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.

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.