Mengapa FTDI dan bukan AVR dengan built-in USB controller?

8

Saya membuat program sederhana dalam Visual C # yang berkomunikasi dengan AVR melalui chip FT232RL.

PC <-> FTDI <-> MCU.

Saya menggunakan FTD2XX_NET.dll untuk akses langsung ke Perangkat USB.

Saya bertanya-tanya, apa perbedaan antara sepasang FTDI-AVR dan AVR tunggal dengan USB Controller bawaan? Saya pikir pasti ada beberapa perbedaan dalam kecepatan komunikasi. Apa lagi yang berbeda?

MrBit
sumber
2
Dengan FTDI, programmer untuk AVR tidak harus mengimplementasikan tumpukan USB, tetapi hanya mendukung UART. Ada banyak perbedaan lain yang saya tidak tahu saya yakin, itu sebabnya saya tidak menjawab tetapi hanya berkomentar
Funkyguy
1
Juga FTDI datang dengan driver yang ditandatangani untuk sebagian besar platform dan VID & PID dengan kode keras yang valid sehingga Anda tidak perlu membayar 65536 alamat ketika Anda hanya membutuhkan satu.
venny
Terima kasih atas komentarnya. Perbedaan lain tentang kinerja? Cara mana yang lebih baik untuk komunikasi PC dan MCU? Sejujurnya, FTDI JAUH lebih mudah dari buil-in usb controllers.
MrBit
Dalam perangkat lunak PC dengan cara FTDI, ada fungsi sulit yang sangat rendah. Dan saya tidak tahu apakah upaya dengan AVR tunggal sepadan
MrBit
1
FTDI adalah serial bodoh. MCU dapat melakukan preproses, mengaktifkan saluran samping, mendukung UMS, dll.
Ignacio Vazquez-Abrams

Jawaban:

11

Ada beberapa alasan, tetapi mereka, setidaknya bagi kebanyakan orang, cukup niche.

Alasan yang saya lihat dan alami

  • Pilihan dalam AVR yang diaktifkan USB sangat terbatas, terutama keluarga TINY. Jika karena alasan tertentu AVR diperlukan yang tidak memiliki kombinasi USB dan beberapa perangkat lain, ini adalah pilihan yang mudah. Salah satu contoh yang muncul dalam pikiran adalah AVR yang mendukung PLL.
  • Meskipun periferal USB diimplementasikan dalam perangkat keras, Anda masih perlu memasukkan tumpukan USB ke firmware. Ini membutuhkan banyak sumber daya (mis. LUFA membutuhkan setidaknya 6kB flash dan 1.5kB RAM untuk implementasi CDC penuh, dan ini adalah salah satu perpustakaan yang paling ringan)
  • Interupsi USB dan peristiwa bus USB menghabiskan sumber daya yang dapat mengacaukan firmware yang menentukan waktu. Misalnya: pengukuran ADC kecepatan tinggi dapat menjadi sangat buruk ketika tugas USB terganggu.
  • Tidak semua implementasi perpustakaan USB berfungsi dengan baik dengan semua AVR yang mendukung USB. Misalnya: bootloader USB menggunakan LUFA tidak berfungsi dengan perangkat XMEGA.
  • FTDI menggunakan driver yang ditandatangani yang secara otomatis menginstal menggunakan Pembaruan Windows, sedangkan banyak perpustakaan USB, misalnya ASF dan LUFA, tidak. Ini membuat penyebaran ke pengguna akhir lebih rumit.
  • Beberapa implementasi memiliki kinerja yang lebih rendah, misalnya FT2232H dapat menjembatani FIFO ke USB pada 8MiB / s, yang tidak mungkin dilakukan dengan AVR.
  • Banyak proyek yang tidak memiliki kontrol penuh atas perangkat keras dan perangkat lunak, misalnya printer 3D memiliki proyek perangkat keras dan firmware yang sepenuhnya terpisah. Untuk menjaga tingkat interoperabilitas setinggi mungkin, fungsi USB dan mikrokontroler dipisahkan.

Namun, dengan perpustakaan USB yang siap digunakan, biaya signifikan jembatan FTDI USB (biasanya lebih mahal daripada AVR yang sangat canggih) dan tidak ada penalti kinerja di sebagian besar aplikasi, sangat sulit untuk membenarkan chip FTDI saat ini jika Anda memiliki kontrol penuh atas perangkat keras dan firmware.

pengguna36129
sumber
2
Bahkan jika sebuah proyek menggunakan mikrokontroler yang telah dibangun di antarmuka USB dan rencananya adalah untuk menggunakannya, masih layak memiliki header untuk mengakses pin UART, karena Anda dapat secara sepele mendapatkan hasil debug yang berguna dari itu ketika mencoba untuk mendapatkan USB kode untuk bekerja.
Chris Stratton
4
Komentar @ ChrisStratton menunjukkan masalah lain: Perangkat USB lebih sulit untuk di-debug daripada serial UART sederhana. Jadi ini mempercepat pengembangan dan menghilangkan yang tidak dikenal untuk meninggalkan ujung USB ke chip FDTI yang berfungsi. Jelas ekonomi berubah dengan kuantitas, tetapi untuk produksi kecil dengan tekanan waktu solusi FDTI biasanya lebih baik.
markrages
Wow, Anda tl;drparagraf yakin adalah kejutan berakhir ... Anda sampah-berbicara USB / tumpukan seri firmware-satunya (meskipun dengan poin yang sangat valid), dan kemudian BAM ... "hanya idiot akan menggunakan FTDI". Lucu sekali. Menyukainya!
alex grey
@alexgray: Wow, Anda benar-benar berbicara dengan ekstrem di sana. Saya tidak berpikir saya berbicara tentang sampah; ini hanya jenis khas tujuan orang dalam desain produk. Saya sudah berurusan dengan proyek yang dioptimalkan hampir semua kombinasi dari poin-poin ini. Untuk proyek hobi mungkin ada pendekatan Trump vs Sanders untuk menyelesaikan 'apakah saya atau saya tidak mengambil jembatan FTDI RS-232?', Tetapi dalam rekayasa nyata Anda harus benar-benar hanya secara objektif mempertimbangkan semua pro dan kontra dan datang ke sebuah kesimpulan yang optimal.
user36129
4

Ada keuntungan menggunakan chip USB yang terpisah, dan membiarkan AVR berkomunikasi melalui UART-nya.

Tumpukan USB harus merespons polling dari PC host. Ini terjadi setidaknya setiap milidetik. Itu berarti bahwa bahkan lebih sulit untuk menjamin respons waktu nyata yang sulit untuk peristiwa, karena MCU mungkin akan terganggu untuk menanggapi jajak pendapat USB host.

Ketika tidak ada apa pun untuk dikomunikasikan, atau MCU ingin fokus penuh pada tugas waktu nyata, ia masih harus menanggapi beberapa acara pemungutan suara host USB, atau tuan rumah akan 'kehilangan' perangkat. Jadi sulit untuk diabaikan. Chip USB khusus, seperti FTDI melepas tugas-tugas dari AVR.

Masalah kecil adalah tumpukan USB akan mengkonsumsi cukup banyak memori flash dan RAM, sehingga chip tersebut membutuhkan lebih banyak sumber daya daripada AVR sederhana.

Juga, dua bagian dapat dipisahkan menjadi dua papan, sehingga USB bukan biaya tetap, tetapi mungkin dibagi di beberapa papan.

Di sisi sebaliknya, manfaat utama menggunakan AVR dengan perangkat USB dan tumpukan USB bawaan adalah hanya ada satu bagian untuk dibeli, dan dipasang.

Saya belum memeriksa baru-baru ini, tapi saya percaya chip FTDI yang lebih baru memberikan kecepatan transfer data USB yang lebih tinggi daripada AVR's USB. Namun, AVR UART sangat lambat sehingga AVR dengan USB lebih cepat ditransfer daripada kombinasi FTDI (atau antarmuka USB apa pun) yang berkomunikasi melalui AVR AVR karena AVR UART yang lambat.

Sunting: FTDI membuat antarmuka lain selain UART. Misalnya SPI. Saya tidak punya pengalaman menggunakannya. Beberapa AVR mendukung 9 (mungkin 12) transfer SPI megabit. FTDI adalah master SPI, yang tidak ideal. Jika AVR mentransmisikan, itu mungkin baik-baik saja. Karena FTDI memang memiliki buffer, tetapi menerima mungkin 'seperti minum dari selang kebakaran'. AFAIK, Anda harus melakukan pekerjaan pada PC host untuk membuatnya bekerja.

Transfer kecepatan tertinggi mungkin melalui papan Ethernet Ethernet 100MB, tapi saya belum melihat pengukuran throughput.

Saya senang menggunakan mikrokontroler selain AVR. Jadi saya mungkin menggunakan sesuatu dengan UART cepat dan pengontrol DMA yang dapat memindahkan karakter tanpa keterlibatan CPU. Jika itu adalah pendekatan yang bermanfaat, mungkin lihat Arduin Due, atau mbed, ST mb disebut nucelo yang berbiaya rendah.

gbulmer
sumber
seperti tentang kecepatan transfer AVR UART, ya itu benar-benar lambat ... jadi, (untuk memperbaikinya) ada cara berbeda untuk melakukan komunikasi antara AVR & FTDI Chips? Sekarang saya dalam 230,4 kbps dalam mode uart
MrBit
@ user3829694 - Saya tidak yakin apa yang Anda maksud. Anda bertanya bagaimana cara melaju lebih cepat dari 230,4 kbps? Atau apakah Anda mengatakan 230,4 kbps tidak masalah untuk Anda?
gbulmer
Saya bertanya, jika saya ingin kecepatan lebih, apa lagi yang bisa saya lakukan? Saya pikir FT245 FIFO, bisa sampai 1Mbps. Saya mencoba membuat proyek HID dengan "pemantauan waktu nyata" hanya untuk mengumpulkan data dari AVR (dengan sensor dll) ke formulir PC. Tetapi dengan UART bahkan dalam kecepatan maks (230,4 kbps) kecepatan transfer seluruh buffer (256byte) dibutuhkan sekitar 9ms: 230,4kbit = 28,8kByte = 1 / 28,8 = 34,722us per byte * 256byte = 8,88ms / 256byte saya pikir kali ini tidak baik untuk pemantauan waktu nyata
MrBit
jika saya ingin menyegarkan formulir saya setiap 10-100ms (mengirim-menerima data setiap 10-100ms) tidak ada waktu tersisa bagi AVR untuk memproses tugas-tugas lain.
MrBit
@ user3829694 - Oke, jadi Anda ingin memindahkan data dengan cepat, dengan sedikit overhead.
gbulmer