Seberapa kritis frekuensi UART?


17

Saya akan menggunakan kristal 8 MHz untuk menjalankan mikrokontroler saya di 16 MIPS (PLL 4x, instruksi siklus 2). Namun, 8 MHz tidak membagi ke frekuensi UART AFAIK ... jadi seberapa penting frekuensi ini? Saya berencana untuk menggunakan 115.200 baud.

Bisakah UART beroperasi dalam ± 1%? Jika ini tidak berhasil, frekuensi apa yang harus saya gunakan? (Saya ingin mendekati 16 MIPS mungkin, untuk kecepatan pemrosesan maksimum.) Jika itu penting, saya menggunakan PIC24FJ64GA004.

Jawaban:


13

Jika Anda berada dalam 1%, Anda harus OK.

Misalkan UART Anda menggunakan jam oversampling 16x, misalnya, Anda dapat mengaturnya menjadi 1.843.200 Hz hingga 16x oversample 115.200 bps. (oversampling seperti ini cukup umum) Hal ini memungkinkan UART menghitung 8 over-jam dari tepi jatuh bit mulai, sehingga dapat menemukan pusat sel bit ke dalam +/- satu periode jam berlebih, setelah yang dihitung 16 periode over-clock untuk menentukan kapan harus mengambil sampel data.

Jika Anda menganggap itu bisa mengenai pusat bit mulai, maka untuk menjaga pengambilan sampel data serial dalam sel bit yang benar di 8 bit data, frekuensi jam harus tetap antara (8-0.5) / 8 dan (8 + 0,5 ) / 8, atau +/- 6,25% dari bit rate yang dimaksudkan. Overclocking yang lebih tinggi semakin mendekati kondisi ideal mengenai memukul bit mulai, tetapi 8x atau 16x biasanya cukup dekat sehingga Anda dapat menganggap ketidakcocokan 5% akan bekerja.

Namun, Anda tidak dapat mengandalkan sisi lain dari frekuensi yang sempurna. Jika Anda menghubungkan perangkat yang 4% cepat ke perangkat yang 4% lambat, Anda akan mengalami masalah. Saya pernah mengalami setidaknya satu kasing di mana PC berjalan agak lambat, dan perangkat sedikit cepat, dan keduanya hanya bisa berkomunikasi secara marjinal, meskipun perangkat yang sama baik-baik saja dengan PC lain, dan PC baik-baik saja dengan yang lain perangkat. (O-cakupan ini sekitar 112kbps dan 119kbps) Untuk alasan itu ada baiknya mencoba menekan frekuensi nominal sedekat mungkin. Saya belum pernah melihat sesuatu dalam 2% dari nominal memiliki masalah.

Hal yang biasa dilakukan adalah menggunakan laju jam master yang memberikan kelipatan angka seluruh dari laju pengambilan sampel berlebih UART yang dimaksudkan dengan laju baud rate. Misalnya, jika Anda menginginkan CPU yang berjalan sekitar 8MHz, Anda mungkin menggunakan osilator 7.3728MHz, yang dapat dibagi dengan 4 untuk mendapatkan 1.8432MHz, yang kebetulan persis 16 kali 115200.


8 MHz dapat dibagi 69 untuk mendapatkan 115.942 yang baik dalam ± 1%. Saya ingin tahu apakah PIC mendukung jenis divisi ini untuk generator baud rate-nya. Saya berharap begitu, tapi saya rasa itu tidak akan terjadi.
Thomas O

PIC memiliki generator baud rate. Itu akan bekerja dengan baik tetapi hanya untuk baud rendah seperti 9600, itu tidak akan bekerja untuk baud tinggi seperti 115.200, itu menjadi terlalu tidak tepat.
Thomas O

Apakah Anda pikir saya bisa menggunakan kristal 7.3728 MHz? (Saya tidak akan menggunakan osilator internal 7,37 MHz karena saya ingin presisi.) Ini memungkinkan saya untuk membagi dengan 64 untuk mendapatkan frekuensi UART 115.200. Ini yang tercepat yang bisa saya lakukan dengan toleransi tinggi.
Thomas O

1
jika UART Anda mendukungnya, lebih baik memberikannya overclock (seperti 16x) sehingga dapat mengecoh bit awal dan menemukan pusat sel bit, tetapi mendapatkan 16x untuk 115K ke dalam 1% bisa menjadi tantangan, kecuali Anda menggunakan kristal baud-multiple.
JustJeff

4

1% @JustJeff menyebutkan tidak diperlukan. Kebanyakan UART memungkinkan kesalahan setengah bit pada bit terakhir. Sebagian besar waktu frame terdiri dari 1 bit awal, 8 database dan 1 stop bit, dengan total 10 bit. Setengah bit pada 10 bit adalah 5% (JustJeff's 6,25% tidak mengambil bit start dan stop dalam akun).


1
jangan salah mengutip saya; "1%", pernyataan saya adalah bahwa ini bisa sulit dicapai. The "6,25%" itu dengan asumsi Anda terjadi untuk memukul pusat mulai sedikit, dan akan menjadi yang diijinkan max perbedaan di receiver-vs-pemancar tarif jam di bawah kondisi seperti itu.
JustJeff

1

JustJeff lupa tentang bit start, tetapi Stevenh menambahkan bit stop. Dengan asumsi protokol umum 8 bit data, 1 bit awal, dan tidak ada bit paritas, (jumlah bit stop tidak masalah), ada 8 1/2 bit kali dari tepi terkemuka bit mulai ke pusat bit bit data terakhir. Secara umum, Anda ingin penerima mengambil sampel bit terakhir ini dalam waktu 1/4 bit. Perhatikan bahwa 1/2 bit adalah ambang batas gagal dijamin. Apa pun di dekat sana menjadi tidak dapat diwujudkan karena selalu ada suara listrik dan jitter.

1/4 dibagi 8 1/2 = 2.94%.

Seperti disebutkan JustJeff, sebagian besar implementasi UART sebenarnya mengambil sampel data yang masuk dengan clock 16x asinkron. Itu menambah ketidakpastian waktu 1/16 bit lainnya karena itu adalah kesalahan dengan mana tepi depan bit mulai dapat diukur. 1/16 bit waktu dari 8 1/2 bit adalah 0,74% lainnya. Itu keluar dari kesalahan anggaran yang dihitung sebelumnya. Anda berakhir dengan ketidakcocokan jam 2,2% yang diizinkan untuk penerima untuk mencicipi bit terakhir dalam waktu 1/4 bit dari pusatnya.

Seperti orang lain katakan, menggunakan kristal 7.3728MHz adalah praktik umum ketika baud rate yang akurat diperlukan. Biasanya Anda dapat mengatur untuk menjalankan CPU di dekat tingkat maksimum sambil menekan baud rate UART dalam kesalahan kristal.


Saya tidak setuju bahwa stop bit tidak masalah. Dalam pertanyaan ini komunikasi gagal karena bit stop secara keliru diatur ke level rendah.
stevenvh

Bit stop harus ada di sana agar komunikasi keseluruhan dapat berfungsi, tetapi itu tidak masuk ke dalam perhitungan anggaran kesalahan untuk sebagian besar UART. UART akan membutuhkan beberapa waktu minimum setelah data terakhir sebelum tepi terkemuka berikutnya dari bit awal berikutnya. Itulah gunanya waktu berhenti. Ketika waktu ini tidak terpenuhi, Anda mendapatkan "kesalahan pembingkaian". Mungkin itu sampel seperti data bit, tapi saya tahu kasus di mana itu ditangani secara berbeda. Teletype lama membutuhkan 2 stop bit untuk memberikan mekanisme waktu untuk siap mengambil karakter berikutnya.
Olin Lathrop

Saya merujuk sedikit mulai tiga kali, bukan?
JustJeff

@ OlinLathrop: Stop bit diperlukan untuk memastikan bahwa ketika mengirim byte yang MSB-nya nol, akan ada tepi jatuh untuk bit awal berikutnya. Perangkat yang berbeda berperilaku berbeda dalam kasus di mana garis data menjadi rendah sebelum seharusnya, tetapi jika tidak ada sedikit pun urutan yang ditransmisikan dari nol byte tidak akan mengandung informasi waktu yang berguna. Persyaratan seperti itu dapat dipenuhi melalui cara lain dengan overhead framing tetap kurang dari 25%, tapi saya tidak tahu ada yang melakukannya.
supercat

1

Satu hal yang belum disebutkan adalah bahwa beberapa perangkat berharap untuk mengirimkan byte data untuk setiap byte data yang mereka terima. Jika perangkat semacam itu diumpankan data secara terus-menerus, laju baud-nya bahkan lebih lambat 0,1% dari perangkat pengirim, dan tidak memiliki fasilitas untuk mengirimkan bit penghenti yang sedikit menyusut, outputnya akan turun satu byte di belakang untuk setiap 1000 kali berturut-turut byte yang masuk. Jika perangkat dibatasi hingga 16 byte buffering, itu akan menjatuhkan satu byte data setelah melewati sekitar 16.000 dan akan turun sekitar satu byte per seribu sesudahnya. Penting untuk dicatat bahwa apa yang disebut "1200 baud" modem sebenarnya beroperasi pada kecepatan yang sedikit lebih tinggi dari 1.200 bit / detik (saya pikir ini sekitar 1202) untuk alasan ini (sehingga meskipun pemancar adalah 0,15% lebih cepat dari yang seharusnya. menjadi,

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.