Làm thế nào một bộ chuyển đổi USB-RS232 có thể tự xác nhận chân TX của nó?


8

Tôi đã tạo ra một PCB dựa trên PICAXE tùy chỉnh tích hợp tất cả các thành phần cần thiết để lập trình vi điều khiển. Tôi cho rằng mọi thứ đều ổn vì tôi có thể sử dụng nó để lập trình trong Windows. Tuy nhiên, dưới Mac OSX tôi không thể lập trình được. Ồ, và tôi đang sử dụng chip USB-RS232 WCH CH340G để giảm chi phí, vì FTDI FT232RQ có giá cao hơn 7 lần và tôi không cần tất cả các tính năng của nó.

Tôi đã hoàn toàn tin tưởng rằng có một cái gì đó sai về mặt điện với thiết kế của tôi đã khiến CH340G hoạt động sai trong OSX ... Tôi đã sửa đổi bảng của mình để tôi có thể thực hiện kiểm tra loopback trong Coolterm và việc truyền tải sẽ đóng băng mỗi vài ký tự. Rõ ràng, một cái gì đó đã bị rối và tôi nghĩ rằng đây là một lỗi trong trình điều khiển OSX CH340G. Bộ phận hỗ trợ kỹ thuật của WCH đảm bảo với tôi rằng không phải như vậy và đó có thể là chip giả. Trong cuộc săn phù thủy này, tôi đã chọn một bộ chuyển đổi USB-RS232 sẵn có dựa trên cùng một con chip và nó hoạt động hoàn hảo. Quá nhiều cho một "lỗi trình điều khiển" gây đau đầu của tôi!

Sau đó, tôi đã xây dựng một đơn vị khác với số lượng thành phần tối thiểu cần thiết để thực hiện kiểm tra loopback (tức là không có PICAXE) và tôi đã có thể đưa nó đến điểm mà kiểm tra loopback đáng tin cậy và không còn bị đóng băng nữa. Do đó, tôi có thể có điều gì đó xảy ra với mạch gây ra sự đóng băng, nhưng bây giờ, tôi có thể tiếp tục bằng cách nối PCB của mình vào bảng mạch và sử dụng loại DIP cho các thành phần bên ngoài để hoàn thành mạch lập trình.

Bây giờ đến phần câu hỏi của tôi ...

Tôi đã sử dụng hai thiết lập thử nghiệm - 1) PCB của tôi được nối với một bảng mạch với PICAXE và 2) một bảng mạch với PICAXE và bộ chuyển đổi OTS USB-RS232. Tôi đã kết nối từng chiếc với máy tính xách tay Windows của mình và kết nối các tín hiệu mà tôi nghĩ là phù hợp nhất với Saleae Logic 8 Pro của tôi. Tôi đã bắt được các tín hiệu khi lập trình trong Windows, rồi chuyển cáp USB sang iMac của tôi và bắt lại các tín hiệu. Đây là những gì tôi đã thấy:

Lập trình PICAXE hoạt động trong Windows

nhập mô tả hình ảnh ở đây

Vì vậy, sự khác biệt rõ ràng ở đây là tín hiệu "Nối tiếp" sẽ không logic cao khi quá trình lập trình bắt đầu. Điều này là bắt buộc vì đó là cách giao thức lập trình PICAXE hoạt động (hoặc ít nhất, đó là giao diện của nó). Bạn phải xác nhận đường TX trên RS232, đặt PICAXE vào chế độ truyền sóng vuông, theo sau là các bit xác định loại chip.

Có vẻ như khá rõ ràng từ trình phân tích logic rằng trình điều khiển CH340G trong OSX không được phép xác nhận chân TX của nó, nhưng phiên bản Windows thì có thể. Trong cố gắng để thu thập càng nhiều thông tin càng tốt vì vậy tôi có thể lấy cớ với WCH để giúp tôi ra với vấn đề này, tôi đang cố gắng để hiểu làm thế nào nó thậm chí có thể khẳng định TX ở tất cả . Trong thế giới Windows, tôi tin rằng mọi thứ kết thúc như một cuộc gọi WIN32API. Tôi đã xem tài liệu trình điều khiển FTDI giống như một khung tham chiếu và tôi có thể thấy rằng nó có các chức năng để thiết lập trạng thái của DTR và RTS, ví dụ, nhưng không phải là cách để đặt trạng thái TX. Về phía Windows API, bạn ghi dữ liệu ra khỏi TX bằng cách gọi WriteFile. Không có cách nào tôi biết về điều đó cho phép bạn chỉ cần nói "giữ TX thấp" hoặc "giữ TX cao".

Bất cứ ai cũng có thể giải thích làm thế nào điều này có thể đạt được trên Windows hoặc OSX, để tôi có thể tiếp tục điều tra và gỡ lỗi? Phải có một cách để làm điều đó mà tôi đang thiếu, hoặc bằng chứng rằng thực sự thiếu thứ gì đó trong trình điều khiển của WCH. Rốt cuộc, tôi cũng có cáp lập trình PICAXE AXE027 và nó có thể lập trình các chip khi chạy trong OSX. Nếu bạn biết các chức năng nào được sử dụng trong Windows và / hoặc OSX để đạt được kiểm soát mức logic đối với dòng TX, điều đó cũng cực kỳ hữu ích!

Tôi không biết về tính năng phá vỡ . Có vẻ như đây có thể là những gì trình điều khiển WCH bị thiếu trong OSX.

Trong nhiệm vụ đang diễn ra để tìm ra cách làm cho con chip này hoạt động, tôi đã tải Ubuntu 16.04 LTS, có trình điều khiển WCH tích hợp (ít nhất, tôi nghĩ đó là từ WCH). Tôi đã chạy công cụ lập trình trong Ubuntu và nó cũng không hoạt động. Nguồn WCH không biên dịch theo 16.04 do sự khác biệt trong phiên bản kernel. Tôi đã cố tải phiên bản tôi xây dựng vào ngày 12.04 nhưng không tải được. Tôi không thể kiểm tra dưới 12.04 vì Chrome không được hỗ trợ trong HĐH đó nữa.


3
Cách bạn thường đặt "xác nhận" dài trên truyền phát từ UART là "gửi ngắt", trên PC, sẽ được thực hiện bằng cách sử dụng lệnh gọi hệ thống (tôi không biết điều gì trên Windows). Tuy nhiên, tôi không biết cách nào để làm điều này với một cổng nối tiếp bình thường.
DoxyLover

2
Chỉ để biết thông tin, những gì tôi tìm thấy liên quan đến việc tạo ra sự phá vỡ trên Windows: stackoverflow.com/questions/4585661/ Lời
mờ

2
Trong Mac OS X, cuộc gọi là tcsendbreak . Nhưng có vẻ như tính khả dụng của nó thực sự phụ thuộc vào trình điều khiển và một số bộ điều hợp nối tiếp USB giá rẻ không triển khai nó. Một ví dụ khác về một người cũng đã chiến đấu với điều này (nhưng với chip pl2303): aaronkondziela.com/2015/04/ Kẻ
mờ

1
Tiêu đề làm cho âm thanh này giống như nó có thể là một câu hỏi hay, nhưng điều này là quá dài. Tôi đã đọc đoạn đầu tiên, nhưng đó là tất cả những lời giới thiệu lãng phí thời gian, vì vậy dừng lại ở đó. Chắc chắn bạn có thể chắt lọc câu hỏi của bạn xuống còn ba đoạn. Cho đến lúc đó, di chuyển trên.
Olin Lathrop

7
@OlinLathrop Tôi nhận ra rằng bạn là người nóng bỏng trong lĩnh vực này, nhưng bạn chắc chắn bên ngoài rất thô lỗ trong các bình luận của bạn. Bạn có làm việc với những người thực tế, hoặc ngồi sau một màn hình cả ngày?
Dave

Câu trả lời:


1

Bạn gửi một dấu ngắt để xác nhận chân TX, nhưng một số trình điều khiển / chipset được triển khai kém không thể thực hiện việc này trong thời gian dài (dài hơn một hoặc hai ký tự).

Trong win32api, bạn sử dụng SetCommBreak () và ClearCommBreak () để xác nhận và giải phóng chân TX.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.