Kapan driver perangkat diperlukan dan kapan OK untuk membaca / menulis langsung ke porta?

Saya mengalami kesulitan memahami kapan driver perangkat diperlukan, dan kapan boleh berbicara langsung ke pengontrol port melalui serial / paralel / USB / yang disediakan OS. sopir.

Sebagai contoh, Contoh 1 : mari kita ambil OpenBCI , BCI perangkat keras sumber terbuka yang memungkinkan Anda membaca bacaan EEG + EKG ("gelombang otak"). Headset OpenBCI mengirimkan sinyal RF ke drive USB yang terhubung ke mesin Anda, dan kemudian Anda dapat menulis perangkat lunak Anda sendiri untuk membaca data yang masuk ke port itu; dengan demikian, memungkinkan Anda untuk membaca gelombang otak Anda sendiri dan menafsirkan data gelombang otak pada lapisan aplikasi. Cukup keren. Untuk membaca data gelombang otak "streaming" Anda, Anda tidak hanya perlu membaca dari port serial Anda (menggunakan driver serial yang disediakan oleh OS), tetapi Anda perlu menafsirkan data sesuai dengan spesifikasi OpenBCI . Jadi tumpukan terlihat seperti ini:

Tapi tidak ada tempat di sini kita memiliki "driver perangkat" khusus untuk headset OpenBCI. Hanya driver serial yang diperlukan untuk membaca byte data, dan kemudian Anda perlu menafsirkan apa arti byte tersebut dari dalam aplikasi Anda. Jadi misalnya, jika saya ingin aplikasi Java untuk menginterpretasikan data gelombang otak, saya mungkin menggunakan JSerialComm untuk membaca data dari port COM lokal saya (atau apa pun USB pada sistem lokal). Maka akan tergantung pada aplikasi saya untuk memadukan data tersebut sesuai dengan spesifikasi yang tercantum di atas.

Sekarang, Contoh 2 : webcam USB Logitech seperti ini . Di sini, Anda perlu menginstal driver perangkat webcam pada mesin Anda sehingga Anda dapat menggunakannya. Saya bertanya-tanya mengapa. Mari kita berpura-pura (cukup tekan tombol " Saya percaya! " Sejenak) bahwa pinout untuk webcam ini sangat sederhana:

PIN #       Meaning
===================
1           Power
2           Ground
3           Send data (if 1 then the camera will start "streaming" its video data over data pins)
4           Data pin 1
5           Data pin 2

Ini adalah perangkat USB, sama seperti OpenBCI. Jadi mengapa saya tidak bisa menulis aplikasi (dalam bahasa apa pun) yang juga hanya membaca / menulis langsung ke port USB / serial (sekali lagi, mungkin menggunakan JSerialComm atau yang serupa)? Ketika saya ingin aplikasi mulai menangkap data video webcam, saya mengirim byte ke port serial ( lagi melalui JSerialComm, dll.) Yang mengaktifkan Pin # 3 high / on, dan yang kemudian mulai membaca data video dari Pin 4 dan 5.

Saya kira saya tidak mengerti mengapa OpenBCI tidak memiliki atau membutuhkan driver perangkat, sedangkan webcam (atau perangkat USB standar lainnya seperti printer, mouse, keyboard, dll.). Terima kasih sebelumnya!

Ada beberapa alasan Anda mungkin ingin / perlu menulis driver perangkat.

1. Anda membuat perangkat yang cocok dengan kategori umum. Printer, pemindai, webcam, pengontrol penyimpanan, dll. Anda ingin menulis driver perangkat sehingga aplikasi umum dapat berbicara dengan perangkat Anda tanpa harus memodifikasi aplikasi.

2. Anda ingin perangkat dapat digunakan oleh beberapa aplikasi yang berjalan pada saat yang sama. Driver perangkat perlu menengahi penggunaan perangkat di antara aplikasi. Itu biasanya berarti memiliki tingkat pemahaman perangkat yang lebih tinggi daripada "aliran byte".

3. Desain perangkat keras dan / atau sistem operasi mungkin memaksa Anda untuk melakukannya. Windows memerlukan beberapa jenis pengikat yang terikat pada perangkat USB agar dapat berfungsi sama sekali, Anda dapat menyalahgunakan pengandar hid tetapi hanya jika perangkat keras diatur untuk mengklaim sebagai perangkat HID. Anda mungkin dapat menggunakan USB yang ada untuk driver perangkat serial tetapi hanya jika perangkat Anda menyajikan dan antarmuka yang terlihat seperti port serial. Jika perangkat Anda berada pada bus yang dipetakan dengan DMA langsung, maka Anda perlu driver Anda berada di kernel untuk mengatur transaksi DMA dengan benar.

Sama-sama ada alasan untuk menghindari penulisan driver perangkat, terutama driver perangkat mode kernel.

1. Menulis kode mode kernel rumit / spesialis dan jika Anda mengacaukannya Anda menjatuhkan seluruh sistem, bukan hanya program Anda. Bahkan jika OS menawarkan kemampuan untuk menulis driver Anda dalam mode pengguna, itu mungkin berarti pemrograman dalam bahasa dan lingkungan yang tidak dikenal.

2. Penempatan jauh lebih menyusahkan. Di sisi windows MS telah meningkatkan persyaratan penandatanganan driver baru-baru ini. Di sisi Linux, antarmuka userland jauh lebih stabil daripada yang di sisi kernel dan modul kernel harus dibangun kembali untuk setiap versi kernel baru.

3. Jika kode Anda dibagi menjadi aplikasi dan driver Anda harus khawatir tentang situasi aplikasi campuran / versi driver.

Kemudian turun ke tindakan penyeimbangan yang alasannya lebih menarik untuk perangkat tertentu.

Driver perangkat adalah lapisan abstraksi. Mereka memungkinkan Anda untuk berbicara dengan perangkat tanpa mengetahui mekanisme sistem operasi tingkat rendah atau keanehan khusus perangkat. Mereka juga menyediakan antarmuka tingkat tinggi yang terkenal untuk sistem operasi, antarmuka yang persis sama untuk perangkat serupa.

Tanpa driver perangkat, Anda pada dasarnya perlu menulis sendiri, dan driver perangkat itu akan sangat berbeda untuk setiap model perangkat. Sebagai gantinya, pabrikan biasanya menyediakan driver perangkat untuk Anda yang diterjemahkan dari antarmuka khusus perangkat keras dari perangkat spesifik itu ke antarmuka tingkat tinggi yang terkenal untuk sistem operasi.

Pengaturan ini memberikan beberapa manfaat:

1. Perangkat lunak yang ditulis untuk perangkat ini semuanya akan bekerja dengan perangkat apa pun di kelas perangkat (misalnya webcam), jika ditulis dengan antarmuka tingkat tinggi yang sama.

2. Karakteristik khusus perangkat seperti pengaturan waktu, penanganan sinyal, dan protokol data disarikan dari pengguna.

3. Driver perangkat memberikan lapisan keamanan. Sementara driver perangkat biasanya beroperasi di kernel (di mana masalah dapat merusak OS), aplikasi pengguna biasanya berkomunikasi dengan driver perangkat di ruang pengguna, di mana masalah hanya akan crash aplikasi.

4. Driver perangkat memiliki akses ke alat manajemen seperti Control Panel.

Terkadang, Anda dapat menyelaraskan perangkat Anda dengan API seperti spesifikasi HID (Perangkat Antarmuka Manusia), dan Anda bahkan tidak perlu menginstal driver perangkat lain.

Saya belum melihat perangkat lunak OpenBCI secara detail, tetapi saya menduga itu sebenarnya atau memiliki driver perangkat. Sebagian besar sistem operasi modern bahkan tidak akan memungkinkan Anda untuk berbicara dengan port secara langsung; Anda harus melalui sistem operasi.

Alasan Anda perlu menginstal driver untuk webcam Anda, adalah karena webcam Anda mungkin lebih baru dari OS Anda, atau driver-nya tidak disertakan dengan OS Anda. Banyak webcam tidak mengharuskan Anda untuk menginstal driver, karena banyak webcam menggunakan platform yang sudah ada sejak lama, dan driver untuk mereka datang dengan OS Anda. Temukan webcam logitech berusia 15 tahun dan pasang, dan Anda memiliki peluang bagus untuk menemukan bahwa Anda dapat menggunakannya tanpa menginstal apa pun *

Port serial hampir selalu memiliki driver yang disertakan dengan OS Anda, karena perangkat keras untuk port serial pada dasarnya adalah hal yang sama selama 20 tahun.

Kedua jenis driver ini menyediakan akses terprogram ke berbagai abstraksi perangkat keras yang berbeda. Itu sebabnya Anda tidak bisa, di userspace, berbicara dengan webcam melalui aliran byte masuk dan keluar. Sebagai gantinya, webcam "berbicara" DirectShow atau Video4Linux atau abstraksi video apa pun yang digunakan OS Anda *

Kebalikannya adalah benar lagi, port serial hanya 'berbicara' aliran byte, sehingga Anda tidak dapat meminta bingkai video dan mendapatkannya dari driver.

* Beberapa driver mengharuskan Anda untuk menginstal driver khusus, berapa pun usianya, untuk sepenuhnya menggunakan perangkat ini karena terkadang perangkat memiliki kemampuan yang tidak didukung dalam DirectShow / etc, seperti webcam yang dapat menggeser, memiringkan dan memperbesar, atau melakukan pengenalan wajah, atau barang lainnya. Tapi jangan berpikir terlalu keras karena itu adalah kasus khusus.

Beberapa jawaban lain memiliki poin yang sangat bagus tentang manfaat memisahkan aplikasi Anda dari antarmuka perangkat dan abstraksi, tetapi ada dua poin yang belum disebutkan - hak istimewa kinerja dan akses .

Performa

Driver perangkat sering duduk menunggu input atau interupsi untuk memberitahu mereka membaca input sehingga ketika Anda menulis kode Anda sendiri, Anda perlu melakukan salah satu dari:

• Polling perangkat sisa kode Anda harus memastikan bahwa ini cukup sering terjadi
• Menangani interupsi ini adalah keahlian khusus dan bagaimana jika Anda perlu berbicara dengan lebih dari satu perangkat
• Keterampilan multi-threading atau Multi-processing lagi spesialis, tidak semua bahasa memiliki dukungan yang baik dan jika Anda akan membagi handler perangkat Anda ke utas terpisah Anda sebagian besar jalan menuju driver perangkat

Akses Hak Istimewa

Pada banyak Sistem Operasi, dan bahkan di beberapa tingkat perakitan, bare metal menargetkan akses ke perangkat keras dan lokasi memori absolut memerlukan hak istimewa super user, root, hak admin - Ini bukan praktik yang baik untuk Aplikasi Anda , dan penggunanya, untuk meminta hak tetapi jika mengimplementasikan antarmuka perangkatnya sendiri ia harus memilikinya .

Ketika perangkat lunak Anda hanya dimaksudkan untuk bekerja dengan satu perangkat keras tertentu maka Anda tidak perlu driver perangkat tambahan. Namun, jika ada perangkat keras pembaca gelombang otak lainnya dengan antarmuka berbeda yang ingin Anda dukung, maka driver perangkat tambahan akan bermanfaat. Itu semua tergantung pada ruang lingkup proyek Anda. Untuk penggunaan hobi, tidak perlu membuat driver perangkat tambahan.

Pada dasarnya jawabannya adalah, ketika Anda tidak berbicara dengan driver perangkat, program Anda ADALAH driver perangkat.

Driver perangkat membuat berbicara dengan perangkat keras lebih mudah, tetapi mereka juga membatasi: Anda hanya dapat melakukan hal-hal yang ditawarkan driver perangkat.

Tetapi secara umum: Jika Anda membutuhkan kebebasan total, Anda berbicara langsung dengan pelabuhan. Ini sering membuat perangkat lunak Anda terjalin dengan perangkat keras seperti pada: itu hanya akan bekerja untuk perangkat khusus yang Anda buat.

Jika tidak ada driver perangkat yang tersedia, Anda jelas perlu berbicara langsung dengan perangkat keras Anda.

Jika driver perangkat yang tersedia tidak cukup baik Anda berbicara langsung ke perangkat keras Anda.

Pada dasarnya dalam semua kasus lain Anda menggunakan driver perangkat. (tapi ingat, bahkan jika Anda tidak menggunakan driver perangkat Anda masih menggunakannya, Anda hanya membuatnya sendiri)

Sebenarnya, Anda kehilangan beberapa blok penting dalam diagram. "Penerima RF (stik USB)" tidak mengirim data ke "port serial / USB". Pertama, tidak ada "port USB". Dongle RF mengirim data USB ke "pipa USB" sebagai respons terhadap permintaan host. Host menghasilkan permintaan melalui driver USB pengontrol host, ehci.sys, atau sesuatu. Driver host membentuk paket USB dan mematuhi protokol USB.

Isi paket untuk pengontrol host, bagaimanapun, diinisiasi oleh driver kelas COM generik, lapisan perangkat lunak lain (juga merupakan OS standar). Ini adalah "driver perangkat", yang mengemulasi port COM standar dan memetakan / mengubah port membaca / menulis menjadi permintaan USB sesuai dengan definisi / format kelas. Bagian perpustakaan Java, JSerialComm, hanyalah antarmuka stream-like (buffered) untuk port COM virtual yang ditiru ini.

Seperti yang dapat dilihat, tidak ada yang seperti "berbicara langsung ke perangkat keras Anda", atau "menulis langsung ke port COM", ada beberapa lapisan port virtual. Tidak mungkin untuk menghasilkan toggle tunggal pada bus USB tanpa menetapkan struktur data yang besar, sangat spesifik dan rumit (konteks perangkat / slot, transfer ring buffer, ring perintah, ring acara, dll.) Di memori utama dan konfigurasi pengontrol host USB untuk dihubungkan daftar pemrosesan, dan kemudian membunyikan register bel untuk memulai transaksi USB. Semua ini dilakukan dengan dua lapisan driver, pengontrol host, dan perangkat, dengan ribuan baris kode dan setengah lusin tahun pengembangan dan debug. Untuk pemahaman dan apresiasi yang lebih baik tentang lapisan layanan tersembunyi ini, tanyakan kepada Microsoft .

Antarmuka untuk mengekspor data dari ruang kernel ke ruang pengguna tidak terlalu ekspresif. Secara khusus, ini tidak diketik. Anda mendapatkan urutan byte dan program ruang pengguna Anda kemudian harus mengubah byte tersebut menjadi sesuatu dengan makna semantik. Jadi driver perangkat biasanya dipasangkan dengan perpustakaan ruang pengguna.

Jika Anda menambahkan driver perangkat OpenBCI ruang kernel di atas driver serial generik, yang pada dasarnya akan memberi Anda kemampuan untuk mengkonversi satu cara untuk mengurutkan byte menjadi cara yang berbeda untuk mengurutkan byte. Jika Anda bisa melakukan ini, urutan berbeda apa yang akan Anda pilih? Jika urutan yang berbeda lebih baik, mengapa Anda tidak membuat urutan yang lebih baik itu ke dalam firmware OpenBCI?

Anda mungkin memiliki alasan kinerja untuk menulis driver mode kernel khusus perangkat, atau Anda mungkin perlu menerjemahkan untuk menyesuaikan dengan antarmuka yang ada, tetapi jika tidak, Anda akan mendapatkan nilai lebih banyak dengan membuat perpustakaan ruang pengguna ekspresif seperti OpenBCI_Python daripada membuat apa yang berarti driver mode kernel yang sangat anemia.