Khi nào cần một trình điều khiển thiết bị và khi nào thì đọc / ghi trực tiếp vào cổng?

Tôi đang gặp khó khăn khi hiểu trình điều khiển thiết bị là cần thiết và khi nói chuyện trực tiếp với bộ điều khiển cổng thông qua bộ nối tiếp / song song / USB / vv do hệ điều hành cung cấp. người lái xe.

Ví dụ, Ví dụ 1 : hãy dùng OpenBCI , BCI phần cứng nguồn mở cho phép bạn đọc các bài đọc EEG + EKG ("sóng não"). Tai nghe OpenBCI gửi tín hiệu RF đến ổ USB được cắm vào máy của bạn và sau đó bạn có thể viết phần mềm của riêng mình để đọc dữ liệu đi vào cổng đó; do đó, cho phép bạn đọc sóng não của riêng bạn và giải thích dữ liệu sóng não ở lớp ứng dụng. Tuyệt đấy. Để đọc dữ liệu sóng não "truyền phát" của bạn, bạn không chỉ cần đọc từ cổng nối tiếp (sử dụng trình điều khiển nối tiếp do HĐH cung cấp), mà bạn cần diễn giải dữ liệu theo thông số kỹ thuật OpenBCI . Vì vậy, ngăn xếp trông như thế này:

Nhưng không nơi nào ở đây chúng ta có một "trình điều khiển thiết bị" dành riêng cho tai nghe OpenBCI. Chỉ cần trình điều khiển nối tiếp cần thiết để đọc byte dữ liệu từ đó, và sau đó bạn cần diễn giải ý nghĩa của các byte đó từ bên trong ứng dụng của bạn. Vì vậy, ví dụ, nếu tôi muốn một ứng dụng Java diễn giải dữ liệu sóng não, tôi có thể sử dụng JSerialComm để đọc dữ liệu từ cổng COM cục bộ của tôi (hoặc bất kỳ USB nào có trên hệ thống cục bộ). Sau đó, ứng dụng của tôi sẽ can thiệp vào dữ liệu đó theo thông số kỹ thuật được liệt kê ở trên.

Bây giờ, Ví dụ 2 : một webcam USB Logitech như thế này . Tại đây, bạn cần cài đặt trình điều khiển thiết bị của webcam trên máy của mình để có thể sử dụng nó. Tôi đang tự hỏi tại sao. Hãy giả vờ (chỉ cần nhấn nút " Tôi tin! " Trong giây lát) rằng sơ đồ chân cho webcam này thật đơn giản:

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

Đây là một thiết bị USB, giống như OpenBCI. Vậy tại sao tôi không thể viết một ứng dụng (bằng bất kỳ ngôn ngữ nào) cũng chỉ đọc / ghi trực tiếp vào cổng USB / nối tiếp (một lần nữa, có lẽ sử dụng JSerialComm hoặc tương tự)? Khi tôi muốn ứng dụng bắt đầu ghi dữ liệu video webcam, tôi gửi byte đến cổng nối tiếp ( một lần nữa qua JSerialComm, v.v.) để bật Pin # 3 cao / bật và sau đó bắt đầu đọc dữ liệu video từ Chân 4 và 5.

Tôi đoán tôi không hiểu tại sao OpenBCI không có hoặc không cần trình điều khiển thiết bị, trong khi webcam (hoặc bất kỳ thiết bị USB tiêu chuẩn nào khác như máy in, chuột, bàn phím, v.v.) thì không. Cảm ơn trước!

Có một số lý do bạn có thể muốn / cần phải viết trình điều khiển thiết bị.

1. bạn đang làm một thiết bị phù hợp với một thể loại chung. Máy in, máy quét, webcam, bộ điều khiển lưu trữ, v.v. Bạn muốn viết trình điều khiển thiết bị để các ứng dụng chung có thể nói chuyện với thiết bị của bạn mà không phải sửa đổi các ứng dụng.

2. bạn muốn có một thiết bị có thể sử dụng được bởi nhiều ứng dụng chạy cùng một lúc. Trình điều khiển thiết bị cần phân xử việc sử dụng thiết bị trong số các ứng dụng. Điều đó thường có nghĩa là có mức độ hiểu biết về thiết bị cao hơn "luồng byte".

3. Thiết kế phần cứng và / hoặc hệ điều hành có thể đơn giản buộc bạn phải. Windows cần một số loại trình điều khiển gắn với thiết bị USB để nó hoạt động hoàn toàn, bạn có thể lạm dụng trình điều khiển ẩn nhưng chỉ khi phần cứng được thiết lập để tự nhận là thiết bị HID. Bạn có thể sử dụng USB hiện có để trình điều khiển thiết bị nối tiếp nhưng chỉ khi thiết bị của bạn trình bày và giao diện trông giống như một cổng nối tiếp. Nếu thiết bị của bạn nằm trên một bus được ánh xạ bộ nhớ với DMA trực tiếp thì bạn cần trình điều khiển của mình ở trong kernel để thiết lập chính xác các giao dịch DMA.

Tương tự, mặc dù có những reaons muốn tránh viết trình điều khiển thiết bị, đặc biệt là trình điều khiển thiết bị chế độ kernel.

1. Viết mã chế độ kernel là khó khăn / chuyên gia và nếu bạn làm hỏng nó, bạn sẽ đưa toàn bộ hệ thống xuống, không chỉ chương trình của bạn. Ngay cả khi HĐH cung cấp khả năng ghi trình điều khiển của bạn ở chế độ người dùng, điều đó có thể có nghĩa là lập trình bằng một ngôn ngữ và môi trường xa lạ.

2. Triển khai là nhiều hơn một nỗi đau. Trên các cửa sổ MS đã được cải thiện các yêu cầu ký trình điều khiển gần đây. Về phía Linux, các giao diện người dùng ổn định hơn nhiều so với các giao diện hạt nhân và các mô-đun hạt nhân phải được xây dựng lại cho mỗi phiên bản kernel mới.

3. Nếu mã của bạn được chia thành một ứng dụng và trình điều khiển, bạn phải lo lắng về tình trạng của các phiên bản trình điều khiển / ứng dụng hỗn hợp.

Sau đó, nó đi đến một hành động cân bằng trong đó lý do hấp dẫn hơn cho một thiết bị cụ thể.

Trình điều khiển thiết bị là một lớp trừu tượng. Chúng cho phép bạn nói chuyện với thiết bị mà không cần biết các cơ chế hệ điều hành cấp thấp hoặc các đặc điểm riêng của thiết bị. Họ cũng cung cấp một giao diện cấp cao, nổi tiếng cho hệ điều hành, một giao diện hoàn toàn giống với các thiết bị tương tự.

Nếu không có trình điều khiển thiết bị, về cơ bản bạn sẽ cần phải tự viết một trình điều khiển và trình điều khiển thiết bị đó sẽ hoàn toàn khác nhau đối với mọi kiểu thiết bị. Thay vào đó, nhà sản xuất thường cung cấp trình điều khiển thiết bị cho bạn dịch từ giao diện cụ thể phần cứng của thiết bị cụ thể đó sang giao diện cấp cao, nổi tiếng cho hệ điều hành.

Sự sắp xếp này cung cấp một số lợi ích:

1. Tất cả phần mềm được viết cho các thiết bị này đều sẽ hoạt động với bất kỳ thiết bị nào trong lớp thiết bị (ví dụ: webcam), nếu phần mềm này được viết trên cùng một giao diện cấp cao, phổ biến.

2. Các đặc điểm cụ thể của thiết bị như thời gian, xử lý tín hiệu và giao thức dữ liệu được trừu tượng hóa khỏi người dùng.

3. Trình điều khiển thiết bị cung cấp một lớp an toàn. Mặc dù trình điều khiển thiết bị thường hoạt động trong kernel (nơi các sự cố có thể làm sập hệ điều hành), ứng dụng người dùng thường giao tiếp với trình điều khiển thiết bị trong không gian người dùng, trong đó một sự cố sẽ chỉ làm hỏng ứng dụng.

4. Trình điều khiển thiết bị có quyền truy cập vào các công cụ quản lý như Bảng điều khiển.

Đôi khi, bạn có thể căn chỉnh thiết bị của mình với API như thông số HID (Thiết bị giao diện con người) và thậm chí bạn không cần phải cài đặt trình điều khiển thiết bị khác.

Tôi đã không xem xét chi tiết phần mềm OpenBCI, nhưng tôi nghi ngờ rằng nó thực sự là hoặc có trình điều khiển thiết bị. Hầu hết các hệ điều hành hiện đại thậm chí sẽ không cho phép bạn nói chuyện trực tiếp với các cổng; bạn phải đi qua hệ điều hành.

Lý do bạn cần cài đặt trình điều khiển cho webcam của mình là vì webcam của bạn có thể mới hơn HĐH của bạn hoặc trình điều khiển của nó không có trong HĐH của bạn. Nhiều webcam không yêu cầu bạn cài đặt trình điều khiển, vì nhiều webcam sử dụng các nền tảng đã có từ lâu và trình điều khiển cho chúng đi kèm với hệ điều hành của bạn. Tìm một webcam logitech 15 năm tuổi và cắm nó vào, và bạn có cơ hội tốt để tìm thấy rằng bạn có thể sử dụng nó mà không cần cài đặt bất cứ thứ gì *

Các cổng nối tiếp hầu như luôn có các trình điều khiển đi kèm với HĐH của bạn, bởi vì phần cứng cho các cổng nối tiếp về cơ bản là giống nhau trong 20 năm.

Tuy nhiên, hai loại trình điều khiển cung cấp quyền truy cập theo chương trình vào các bản tóm tắt khác nhau của phần cứng khác nhau. Đó là lý do tại sao bạn không thể, trong không gian người dùng, nói chuyện với webcam thông qua các luồng byte vào và ra. Thay vào đó, webcam "nói" DirectShow hoặc Video4Linux hoặc bất kỳ video nào trừu tượng hóa hệ điều hành của bạn đang sử dụng *

Điều ngược lại là đúng một lần nữa, cổng nối tiếp chỉ 'nói' các luồng byte, vì vậy bạn không thể yêu cầu các khung hình video và lấy chúng từ trình điều khiển.

* Một số trình điều khiển yêu cầu bạn cài đặt trình điều khiển đặc biệt, bất kể tuổi tác, để sử dụng đầy đủ thiết bị vì đôi khi các thiết bị có các khả năng không được hỗ trợ trong DirectShow / etc, chẳng hạn như webcam có thể xoay, nghiêng và thu phóng hoặc nhận dạng khuôn mặt, hoặc những thứ khác. Nhưng đừng suy nghĩ quá nhiều về điều đó vì đó là những trường hợp đặc biệt.

Một số câu trả lời khác có những điểm rất tốt về lợi ích của việc tách ứng dụng của bạn khỏi giao diện thiết bị và tính trừu tượng nhưng có hai điểm chưa được đề cập - đặc quyền truy cập và hiệu suất .

Hiệu suất

Trình điều khiển thiết bị thường ngồi đợi đầu vào hoặc ngắt để yêu cầu họ đọc đầu vào, vì vậy khi bạn viết mã của riêng mình, bạn sẽ cần thực hiện một trong:

• Thăm dò thiết bị phần còn lại của mã của bạn phải đảm bảo rằng điều này xảy ra thường xuyên đủ
• Xử lý làm gián đoạn đây là một kỹ năng chuyên môn và nếu bạn cần nói chuyện với nhiều thiết bị
• Kỹ năng chuyên môn đa xử lý hoặc đa xử lý lại, không phải tất cả các ngôn ngữ đều có hỗ trợ tốt và nếu bạn định chia trình xử lý thiết bị của mình thành một luồng riêng biệt thì bạn hầu hết sẽ là một trình điều khiển thiết bị

Đặc quyền truy cập

Trên nhiều hệ điều hành, và thậm chí ở một số chỉ tiêu kim loại trần lắp ráp mức truy cập vào phần cứng và bộ nhớ vị trí tuyệt đối đòi hỏi phải nâng đặc quyền siêu người dùng, root, quyền quản trị - Nó không phải là một thói quen tốt cho bạn ứng dụng , và người sử dụng của nó, đòi hỏi như vậy quyền nhưng nếu nó thực hiện các giao diện thiết bị của riêng mình thì nó sẽ phải có chúng.

Khi phần mềm của bạn chỉ có ý định hoạt động với một phần cứng cụ thể thì bạn không cần trình điều khiển thiết bị bổ sung. Tuy nhiên, nếu có phần cứng đầu đọc sóng não khác với các giao diện khác nhau mà bạn muốn hỗ trợ, thì trình điều khiển thiết bị bổ sung sẽ hữu ích. Tất cả phụ thuộc vào phạm vi dự án của bạn. Đối với việc sử dụng sở thích, không cần phải tạo thêm trình điều khiển thiết bị.

Về cơ bản, câu trả lời là, khi bạn không nói chuyện với trình điều khiển thiết bị, chương trình của bạn là trình điều khiển thiết bị.

Trình điều khiển thiết bị giúp nói chuyện với phần cứng dễ dàng hơn, nhưng chúng cũng hạn chế: bạn chỉ có thể thực hiện những điều mà trình điều khiển thiết bị cung cấp.

Nhưng nói chung: Nếu bạn cần hoàn toàn tự do, bạn nói chuyện trực tiếp với một cổng. Điều này thường làm cho phần mềm của bạn đan xen với phần cứng như trong: nó sẽ chỉ hoạt động cho thiết bị cụ thể mà bạn tạo ra.

Nếu không có trình điều khiển thiết bị khả dụng, rõ ràng bạn cần nói chuyện trực tiếp với phần cứng của mình.

Nếu trình điều khiển thiết bị khả dụng không đủ tốt, bạn có thể nói chuyện trực tiếp với phần cứng của mình.

Về cơ bản trong tất cả các trường hợp khác, bạn sử dụng trình điều khiển thiết bị. (nhưng hãy nhớ, ngay cả khi bạn không sử dụng trình điều khiển thiết bị, bạn vẫn sử dụng nó, bạn chỉ tự làm nó)

Trên thực tế, bạn đang thiếu một vài khối quan trọng trong sơ đồ. "Bộ thu RF (thẻ nhớ USB)" không gửi dữ liệu tới "cổng nối tiếp / USB". Đầu tiên, không có "cổng USB". Khóa RF gửi dữ liệu USB vào "ống USB" để đáp ứng yêu cầu máy chủ. Máy chủ tạo yêu cầu thông qua bộ điều khiển máy chủ Trình điều khiển USB, ehci.sys hoặc một cái gì đó. Trình điều khiển máy chủ hình thành các gói USB và tuân theo giao thức USB.

Tuy nhiên, nội dung gói cho bộ điều khiển máy chủ được khởi tạo bởi trình điều khiển lớp COM chung, một lớp phần mềm khác (cũng là mặc định của hệ điều hành). Đây là "trình điều khiển thiết bị", mô phỏng một cổng COM tiêu chuẩn và ánh xạ / chuyển đổi cổng đọc / ghi thành các yêu cầu USB theo định nghĩa / định dạng lớp. Phần thư viện Java, JSerialComm, chỉ là một giao diện giống như luồng (được đệm) cho cổng COM ảo, giả lập này.

Như mọi người có thể thấy, không có gì giống như "nói trực tiếp với phần cứng của bạn" hay "ghi trực tiếp vào cổng COM", có một số lớp cổng ảo. Không thể tạo một lần chuyển đổi trên bus USB mà không thiết lập các cấu trúc dữ liệu rất lớn, rất cụ thể và phức tạp (bối cảnh thiết bị / khe cắm, bộ đệm vòng truyền, vòng lệnh, vòng sự kiện, v.v.) trong bộ nhớ chính và định cấu hình bộ điều khiển máy chủ USB để liên kết xử lý danh sách, sau đó bấm chuông đăng ký chuông cửa để bắt đầu giao dịch USB. Tất cả điều này được thực hiện với hai lớp trình điều khiển, bộ điều khiển máy chủ và thiết bị, với hàng ngàn dòng mã và nửa tá năm phát triển và gỡ lỗi. Để hiểu rõ hơn và đánh giá cao về lớp dịch vụ ẩn này, hãy kiểm tra với Microsoft .

Giao diện để xuất dữ liệu từ không gian kernel sang không gian người dùng không được biểu cảm cho lắm. Đặc biệt, nó được tháo gỡ. Bạn nhận được một chuỗi byte và chương trình không gian người dùng của bạn sau đó phải chuyển đổi các byte đó thành một cái gì đó có ý nghĩa ngữ nghĩa. Vì vậy, trình điều khiển thiết bị thường được ghép nối với các thư viện không gian người dùng.

Nếu bạn đã thêm một trình điều khiển không gian hạt nhân OpenBCI trên trình điều khiển nối tiếp chung, điều đó về cơ bản sẽ cung cấp cho bạn khả năng chuyển đổi một cách để sắp xếp các byte thành một cách khác để sắp xếp các byte. Nếu bạn có thể làm điều này, bạn sẽ chọn trình tự nào khác nhau? Nếu một trình tự khác sẽ tốt hơn, tại sao bạn không xây dựng trình tự tốt hơn đó vào phần sụn OpenBCI ngay từ đầu?

Bạn có thể có lý do hiệu suất để viết trình điều khiển chế độ nhân dành riêng cho thiết bị hoặc bạn có thể cần dịch để phù hợp với giao diện hiện có, nhưng nếu không, bạn sẽ nhận được nhiều giá trị hơn từ việc tạo thư viện không gian người dùng biểu cảm như OpenBCI_Python hơn là tạo ra những gì sẽ lên tới trình điều khiển chế độ kernel rất thiếu máu.