USB I/O HID ... cách đơn giản để bạn điều khiển qua USB

[queduong]

- Thôi thì ...Nhân ngày chủ nhật ... mà cũng chẳng đi đâu ( đang bị trọng thương phải nằm giường ... điều trị dưỡng sức ) ... Ngồi hí hoáy làm cái giao tiếp USB đơn giản ... cho các anh em mới tiếp cận .

- Tiêu chí : Đơn giản , gọn nhẹ ... demo được sự điều khiển từ USB
- Hành động : Đương nhiên là mình lựa chọn PIC18F4550 (vì đang có sẵn nó trong tay ) ... trình dịch MikroC ( đơn giản vì đã làm sẵn thư viện HID rồi ... chỉ mang ra là sài thôi ... có vài dòng code !!! )
+ Phần mềm PC : Mình viết trên nền .NET ( Visual basic ) cũng sử dụng thư viện mcHid luôn ! ...

Nói thực là mình không thích dot Net phụ thuộc vào Microsoft lắm ... nên cũng không khoái VB , C# , C++ chạy trên framework ... vừa chậm chạp ... vừa cồng kềnh !

Nếu bạn nào thích thì mình viết trên môi trường khác RAD studio Delphi chẳng hạn sẽ gọn nhẹ hơn ... vác đi máy nào cũng được ... không phụ thuộc .NET framework ( mình thỉnh thoảng lập trình cho Mac , linux , iOS ...v.v với Embarcadero ! ) . Nhưng sau cùng lại chọn viết trên Visual basic vì thấy nó phổ thông ... những người mới học lập trình giao tiếp cũng dễ hiểu hơn các ngôn ngữ khó khác !


--- Mạch điện cụ thể ( demo mà ... chỉ là điều khiển từ PC bật tắt mấy cái Led trên PORTB ... gửi trạng thái led ngược trở lại PC.


--- Phần mềm PC : ( viết trên visual basic ) . ( Visual studio 2010) ... lúc chưa kết nối USB ... nó trông trắng trơn thế này : và hiện " DISCONNECT "


Lúc đã kết nối với thiết bị nó sẽ " CONNECTED " và ra thế này : ( Giờ thì có thể Click vào các ô để điều khiển bật tắt LED ... ( có thể dùng PROTEUS để mô phỏng )




---- Còn dưới đây ... là đầy đủ ... từ a--> Z của Project .
USB_IO.zip

Mời các cụ trẻ Xơi đi ạ !

[queduong]

Một số bạn có ... nhắn tin hỏi tôi . mang các project này share ... phổ cập sang các diễn đàn khác được không ?

--- Quan điểm của tôi : Đây là những cái đơn giản , Phổ cập ( gọi là xóa mù tin học , vi điều khiển ) ... nên có thể dùng nó vô tư ... Có thể mang sang các diễn đàn khác . ( Xin ghi rõ link nguồn gốc LINK ... tránh sự kiện tụng , kêu ca linh tinh ... nhức đầu) .

Đương nhiên là Free cả nhưng cũng tránh hình thức thương mại ( bởi trong project ... ví như cái mcHID.dll ) là 1 thư viện USB ( chắc của hãng Microchip ) ... không phải tôi viết cái thư viện DLL đó . Nên cần chú ý !

[minh_cly]

Bây giờ, giao tiếp làm xơi ngay 1 giao tiếp USB đã la dễ như ăn cháo, hy vọng sinh viên ko còn than về vấn đề này nữa. Phải công nhận bác queduong làm bài này còn dễ hơn cả dễ.

[queduong]

Để an toàn cho các giao tiếp , điều khiển ... dù có dây hay là không thì các bạn nên mã hóa/ giải mã dữ liệu ( kiểm tra CRC hoặc 1 hình thức kiểm tra dữ liệu bị lỗi cao cấp hơn chẳng hạn ) ...
Khi đó luồng tín hiệu điều khiển của bạn là luồng có tín hiệu chất lượng cao ... không có chuyện điều khiển chập chờn .. sai , lỗi ... dó các yếu tố " bên ngoài môi trường " tác động làm ảnh hưởng !

[queduong]

Bây giờ, giao tiếp làm xơi ngay 1 giao tiếp USB đã la dễ như ăn cháo, hy vọng sinh viên ko còn than về vấn đề này nữa. Phải công nhận bác queduong làm bài này còn dễ hơn cả dễ.

Thanks ! Viết trên mấy con phổ thông này cho anh em dễ tiếp cận !
Có thời gian mình sẽ viết những chuyên đề riêng trên 1 số dòng VĐK, VXL khác như FPGA , ARM,PSOC ..hay những dòng của AMD, Analog device, ziglog , moto ,speadtrum, stk ... có những dòng MCU , VXL rất mạnh

[minh_cly]

Để an toàn cho các giao tiếp , điều khiển ... dù có dây hay là không thì các bạn nên mã hóa/ giải mã dữ liệu ( kiểm tra CRC hoặc 1 hình thức kiểm tra dữ liệu bị lỗi cao cấp hơn chẳng hạn ) ...
Khi đó luồng tín hiệu điều khiển của bạn là luồng có tín hiệu chất lượng cao ... không có chuyện điều khiển chập chờn .. sai , lỗi ... dó các yếu tố " bên ngoài môi trường " tác động làm ảnh hưởng !

Trong giao tiếp USB, thì truyền tải Interrupt, Bulk và Control đã có CRC rồi mà, chỉ có Isochronous là ko có thôi... Dữ liệu giao tiếp qua USB đã được coi là luồn tín hiệu chất lượng cao rồi...

[queduong]

Trong giao tiếp USB, thì truyền tải Interrupt, Bulk và Control đã có CRC rồi mà, chỉ có Isochronous là ko có thôi... Dữ liệu giao tiếp qua USB đã được coi là luồn tín hiệu chất lượng cao rồi...

ai bảo cậu là như vậy ??? dữ liệu đến thiết bị cuối và được xử lý an toàn mới là dữ liệu chất lượng cao !

--- Con PIC kia vẫn có thể bị điều khiển sai nếu :
+ dây USB quá dài hoặc có từ trường gây nhiễu loạn , sai lệch tín hiệu trên dây USB ... ( việc mã hóa tín hiệu của protocol là vô nghĩa) Việc mã hóa Dữ Liệu ở PC và giải mã Dữ liệu ở PIC là cách an toàn nhất kể cả các tín hiệu đã được mã hóa !

[minh_cly]

ai bảo cậu là như vậy ??? dữ liệu đến thiết bị cuối và được xử lý an toàn mới là dữ liệu chất lượng cao !

--- Con PIC kia vẫn có thể bị điều khiển sai nếu :
+ dây USB quá dài hoặc có từ trường gây nhiễu loạn , sai lệch tín hiệu trên dây USB ... ( việc mã hóa tín hiệu của protocol là vô nghĩa) Việc mã hóa Dữ Liệu ở PC và giải mã Dữ liệu ở PIC là cách an toàn nhất kể cả các tín hiệu đã được mã hóa !

Bản thân phần cứng của mỗi bên đã có CRC rồi, phần cứng của USB đã đảm bảo dữ liệu truyền đi ít lỗi nhất có thể, nên chúng ta ko cần phải check lại bằng CRC một lần nữa làm gì (đương nhiên vẫn có một số ng mún chất lượng dữ liệu mình là cực cực cực cao, nhưng với điều khiển bình thường, điều đó ko cần thiết cho lắm).

Trích cuốn USB Complete 3th edition trang 56:

All token, data, and Start-of-Frame packets include bits for use in
error-checking. The bit values are calculated using a mathematical algorithm
called the cyclic redundancy check (CRC). The USB specification explains
how the CRC is calculated. The hardware handles the calculations, which
must be done quickly to enable the device to respond appropriately.
The CRC is applied to the data to be checked. The transmitting device performs
the calculation and sends the result along with the data. The receiving
device performs the identical calculation on the received data. If the results
match, the data has arrived without error and the receiving device returns an
ACK. If the results don’t match, the receiving device sends no handshake.
The absence of the expected handshake tells the sender to retry.

[queduong]

Bản thân phần cứng của mỗi bên đã có CRC rồi, phần cứng của USB đã đảm bảo dữ liệu truyền đi ít lỗi nhất có thể, nên chúng ta ko cần phải check lại bằng CRC một lần nữa làm gì (đương nhiên vẫn có một số ng mún chất lượng dữ liệu mình là cực cực cực cao, nhưng với điều khiển bình thường, điều đó ko cần thiết cho lắm).

Trích cuốn USB Complete 3th edition trang 56:

All token, data, and Start-of-Frame packets include bits for use in
error-checking. The bit values are calculated using a mathematical algorithm
called the cyclic redundancy check (CRC). The USB specification explains
how the CRC is calculated. The hardware handles the calculations, which
must be done quickly to enable the device to respond appropriately.
The CRC is applied to the data to be checked. The transmitting device performs
the calculation and sends the result along with the data. The receiving
device performs the identical calculation on the received data. If the results
match, the data has arrived without error and the receiving device returns an
ACK. If the results don’t match, the receiving device sends no handshake.
The absence of the expected handshake tells the sender to retry.

lý thuyết là như vậy thôi ! Tuy nhiên chỉ ở mức độ ứng hụng Home , Office ... là khá an toàn !

[minh_cly]

lý thuyết là như vậy thôi ! Tuy nhiên chỉ ở mức độ ứng hụng Home , Office ... là khá an toàn !

Phần cứng USB xài CRC-16, tỉ lệ ko phát hiện đc lỗi chỉ là 1/2^16 = 1/65536. Mà đâu phải lần nào cũng có lỗi (nếu lần nào cũng có thì đừng nên xài giao tiếp USB làm gì, hay mua cái cáp bọc nhiều lớp vào), nên chắc phải chờ rất lâu, rất lâu thì qua phần cứng, USB mới có 1 lỗi (đề nghị ko chơi USB trong công nghiệp).

[queduong]

Phần cứng USB xài CRC-16, tỉ lệ ko phát hiện đc lỗi chỉ là 1/2^16 = 1/65536. Mà đâu phải lần nào cũng có lỗi (nếu lần nào cũng có thì đừng nên xài giao tiếp USB làm gì, hay mua cái cáp bọc nhiều lớp vào), nên chắc phải chờ rất lâu, rất lâu thì qua phần cứng, USB mới có 1 lỗi (đề nghị ko chơi USB trong công nghiệp).

Người ta thay các Card tổng đài với card công nghiệp chạy theo kiểu bus ( USB) ... lỗi xảy ra là thường xuyên ! Và phải can thiệp xử lý nhiều phần ở Đầu cuối ... còn USB chẳng có gì cao sang cả !
Nếu mình làm nhiều thiết bị điều khiển trên 1 lớp cơ sở ( input device)
Nên dùng mã hóa/ giải mã dữ liệu là an toàn hơn cả ... vì rằng nếu chỉ đơn giản ... 1 thiết bị nào đó ( có thể trùng VID , PID , ID, số serial) vẫn có thể xảy ra trường hợp gây loạn !

[minh_cly]

Người ta thay các Card tổng đài với card công nghiệp chạy theo kiểu bus ( USB) ... lỗi xảy ra là thường xuyên ! Và phải can thiệp xử lý nhiều phần ở Đầu cuối ... còn USB chẳng có gì cao sang cả !
Nếu mình làm nhiều thiết bị điều khiển trên 1 lớp cơ sở ( input device)
Nên dùng mã hóa/ giải mã dữ liệu là an toàn hơn cả ... vì rằng nếu chỉ đơn giản ... 1 thiết bị nào đó ( có thể trùng VID , PID , ID, số serial) vẫn có thể xảy ra trường hợp gây loạn !

Vậy thì điều đó ko thể thực hiện được trên con PIC 8-bit, chạy USB vs PIC 8-bit mà còn CRC bằng phần mềm nữa thì còn nghĩa lý gì (ngoại trừ vài trường hợp đặc biệt khác). Nhưng hầu hết việc phải cho phần mềm con PIC 8 bit nó còng lưng check CRC lại lần nữa là 1 việc rất hiếm, nếu cần yêu cầu cao hơn thì ng ta cũng xài PIC làm chi.

[queduong]

Vậy thì điều đó ko thể thực hiện được trên con PIC 8-bit, chạy USB vs PIC 8-bit mà còn CRC bằng phần mềm nữa thì còn nghĩa lý gì (ngoại trừ vài trường hợp đặc biệt khác). Nhưng hầu hết việc phải cho phần mềm con PIC 8 bit nó còng lưng check CRC lại lần nữa là 1 việc rất hiếm, nếu cần yêu cầu cao hơn thì ng ta cũng xài PIC làm chi.

Bác chẳng hiểu cái gì trong ngành điều khiển học cả ... bác biết tại sao cái thằng PICkit2 nó cũng là 1 cái ( input device ) thông thường mà khi ta can thiệp vào VID , PID của nó ... không làm nhiễu loạn chương trình của nó được không ? ...

Đơn giản bây giờ bác làm cái điều khiển như trên ... có thằng nào nó cũng làm tương tự ... nhân lúc sơ ý nó cắm trộm vào máy ... hoặc xem VID , PID rồi nghịch phá .... thì cái điều khiển đó thế nào ???

--- Chưa cần nói đến CRC hay cái gì cao cấp ... ở trên bác truyền 8 byte ... nếu ta thêm 1 checksum

checksum += byte [1..n] ; thì mức an toàn của gói dữ liệu đã lên 1 level mới rồi ...!

bác đã học khái niệm về đóng gói ( packet) dữ liệu trong truyền tin chưa ?

Ngoài chuyện đóng gói ra đôi khi người ta còn cho vào như Hamming code , FEC ...v.v để sửa lỗi dữ liệu nữa . Chứ không phải đơn thuần mang cái USB cắm phịch vào rồi truyền đâu .
Tại sao khi truyền file ( data ) qua USB ... máy tính vẫn phải check CRC , check file ... sao nó không truyền luôn có nhanh hơn không !


Còn 8 bit chứ kể cả 4bit ... đôi khi cần vẫn phải có CRC và thậm chí có cả haming code , FEC nữa ( mặc dù mấy cái này không đơn giản tí nào đâu ) ... chỉ chừ những người chuyên nghiệp !!!

[minh_cly]

Bác chẳng hiểu cái gì trong ngành điều khiển học cả ... bác biết tại sao cái thằng PICkit2 nó cũng là 1 cái ( input device ) thông thường mà khi ta can thiệp vào VID , PID của nó ... không làm nhiễu loạn chương trình của nó được không ? ...

Đơn giản bây giờ bác làm cái điều khiển như trên ... có thằng nào nó cũng làm tương tự ... nhân lúc sơ ý nó cắm trộm vào máy ... hoặc xem VID , PID rồi nghịch phá .... thì cái điều khiển đó thế nào ???

--- Chưa cần nói đến CRC hay cái gì cao cấp ... ở trên bác truyền 8 byte ... nếu ta thêm 1 checksum

checksum += byte [1..n] ; thì mức an toàn của gói dữ liệu đã lên 1 level mới rồi ...!

bác đã học khái niệm về đóng gói ( packet) dữ liệu trong truyền tin chưa ?

Ngoài chuyện đóng gói ra đôi khi người ta còn cho vào như Hamming code , FEC ...v.v để sửa lỗi dữ liệu nữa . Chứ không phải đơn thuần mang cái USB cắm phịch vào rồi truyền đâu .
Tại sao khi truyền file ( data ) qua USB ... máy tính vẫn phải check CRC , check file ... sao nó không truyền luôn có nhanh hơn không !


Còn 8 bit chứ kể cả 4bit ... đôi khi cần vẫn phải có CRC và thậm chí có cả haming code , FEC nữa ( mặc dù mấy cái này không đơn giản tí nào đâu ) ... chỉ chừ những người chuyên nghiệp !!!

Ồ, ra thế! Công nhận, tranh luận mới học hỏi đc , bik thêm đc chút ít trong điều khiển học, merci bác.

[duong_act]

Ôi giời bấy nay bác QueDuong cứ im ỉm giữ bí kíp không truyền lại cho anh em gì cả Chắc giờ bị thằng nào nó tông trọng thương mới lo bí kíp thất truyền nên mới chịu đem võ công ra thi triển. Chắc phải cảm ơn lão nào tông vào bác quá