Virtual COM chạy ko chuẩn ! Ai biết xin chỉ dùm

[bachelor]

Có một vấn đề gặp phải khi sử dụng Virtual COM (USB - RS232 Converter) như sau:
Kết nối giữa pic8f252 với PC. Code trong pic là:
while(1)
{
putc('A');
delay_ms(5);
}
Chương trình test trên PC được viết bằng Win32 App
Khi test với cổng COM thật thì thu rất chuẩn, nếu ngắt nguồn của pic thì ngay lập tức nhận được sự kiện BREAK (tất nhiên là khi setevenmask đã chon BREAKEVEN)
Khi test với COM ảo thì gặp 2 vấn đề:
1. Cứ nhận được 2 sự kiện DSR và DCD mới có 1 sự kiện Receiver (đọc dữ liệu). 2 sự kiện DSR và DCD khi test với COM thật thì ko gặp
2. Khi ngắt nguồn thì ko xuất hiện sự kiện BREAK, kết quả là chương trình cứ treo để chờ (vì timeout chọn là INFINITE)
Cái vấn đề đầu tôi đoán là do bộ converter nó luôn có tín hiệu ở chân DSR, DCD (????) và đang định khắc phục bằng cách nối 2 chân này xuống mức thấp (????)
Nhưng vấn đề thứ 2 thì chịu. Chỉ có cách cấp nguồn lại cho PIC, thế thì chuối quá
Mong các cao thủ chỉ giáo dùm !
Thanks !

[namqn]

Nguyên văn bởi bachelor

Có một vấn đề gặp phải khi sử dụng Virtual COM (USB - RS232 Converter) như sau:
Kết nối giữa pic8f252 với PC. Code trong pic là:
while(1)
{
putc('A');
delay_ms(5);
}
Chương trình test trên PC được viết bằng Win32 App
Khi test với cổng COM thật thì thu rất chuẩn, nếu ngắt nguồn của pic thì ngay lập tức nhận được sự kiện BREAK (tất nhiên là khi setevenmask đã chon BREAKEVEN)
Khi test với COM ảo thì gặp 2 vấn đề:
1. Cứ nhận được 2 sự kiện DSR và DCD mới có 1 sự kiện Receiver (đọc dữ liệu). 2 sự kiện DSR và DCD khi test với COM thật thì ko gặp
2. Khi ngắt nguồn thì ko xuất hiện sự kiện BREAK, kết quả là chương trình cứ treo để chờ (vì timeout chọn là INFINITE)
Cái vấn đề đầu tôi đoán là do bộ converter nó luôn có tín hiệu ở chân DSR, DCD (????) và đang định khắc phục bằng cách nối 2 chân này xuống mức thấp (????)
Nhưng vấn đề thứ 2 thì chịu. Chỉ có cách cấp nguồn lại cho PIC, thế thì chuối quá
Mong các cao thủ chỉ giáo dùm !
Thanks !

Có thể do các chip USB - RS-232 không hoàn toàn giống nhau, cũng có thể do driver bạn đang dùng không hiện thực đầy đủ giao tiếp RS-232. Bạn nên tìm hiểu thử xem chip được dùng trong bộ USB-serial converter của bạn là chip nào, sau đó tìm hiểu xem driver cho chip đó đã được hiện thực đến mức nào.

Thân,

[bachelor]

Con chip nó đóng gói trong adapter luôn nên ko xem được là loại j (hàng của bọn TQ làm). Driver là FT232 có vẻ là chuẩn vì khi cài xong nhận được 1 cổng COM trong device manager như sau ( hình 1. Sorry vì chưa biết cách up hình nên đành để ở dạng file đính kèm ) ). Các thuộc tính của cổng minh họa trong hình 2, 3, 4 và 5. So sánh với các thuộc tính của COM thật thấy y chang !
Không hiểu sao nữa ! Cái sự kiện DSR và DCD thì có thể khắc phục bằng cách trong setevenmask bỏ chọn (chỉ chọn các sự kiện BREAK, ERROR và RECEIVER) nhưng việc ko nhận sự kiện BREAK thì pó tay ! Kết quả là hàm waiteven treo luôn thread cho đến khi cấp nguồn cho pic mới thôi ! Rõ chán sự kiện cần quản lý thì ko quản lý đc, sự kiện ko cần thì cứ đến ầm ầm !
Có cách nào khắc phục ko các bác nhỉ ? Chỉ giúp em với !
Thanks !

[namqn]

Tôi hiểu là với baud rate cỡ 9600 bps thì 5 ms là đủ thời gian để tạo break event. Tuy nhiên, có vẻ như bộ chuyển đổi của bạn có vấn đề trong việc tạo ra sự kiện này. Bạn mượn một vài bộ chuyển đổi khác để thử nghiệm xem thế nào. Nếu các bộ chuyển đổi kia cũng vậy thì có lẽ bạn phải giới hạn thời gian chờ, đừng dùng infinite nữa.

Thân,

[bachelor]

Ok sẽ test thử bằng Adapter khác xem sao !
Còn về vấn đề timeout nếu bằng 0xFFFFFFFF (tức là INFINITE) thì chương trình mới chạy, còn nếu nhỏ hơn ví dụ 0xFFFF như đoạn code dưới đây:
// Wait for an event
lLastError = serial.WaitEvent(0, 0xFFFF);
if (lLastError != ERROR_SUCCESS)
return ::ShowError(serial.GetLastError(),
_T("Unable to wait for a COM-port event."));
thì ngay lập tức có thông báo lỗi "Unable to wait for a COM-port event." (error 1)
chương trình lấy từ CodeProject. Bộ mã đã được tôi post lên diễn đàn, chắc là chuẩn. Chưa test thử cái thời gian chờ nhỏ hơn INFINITE với COM thật.
Không hiểu do nguyên nhân j nữa

[bachelor]

đã debug chg trình. Ko phải do INFINITE. bản chất là do hàm WaitCommEvent treo các tiến trình đến khi nào có 1 sự kiện trả về từ cổng COM. BREAK cũng là 1 sự kiện khi ngắt nguồn, reset pic, ... Tuy nhiên vì 1 lý do nào đó nó ko gửi sự kiện này,kết quả là chương trình bị treo ! Có lẽ do lỗi phần cứng ?!

[namqn]

Nguyên văn bởi bachelor

đã debug chg trình. Ko phải do INFINITE. bản chất là do hàm WaitCommEvent treo các tiến trình đến khi nào có 1 sự kiện trả về từ cổng COM. BREAK cũng là 1 sự kiện khi ngắt nguồn, reset pic, ... Tuy nhiên vì 1 lý do nào đó nó ko gửi sự kiện này,kết quả là chương trình bị treo ! Có lẽ do lỗi phần cứng ?!

Bạn thử làm như sau:

- Hàn một điện trở kéo xuống khoảng vài k vào chân TX của PIC
- Reset PIC xem phía PC có nhận được sự kiện break hay không

Thân,

[bachelor]

Nguyên văn bởi namqn

Bạn thử làm như sau:

- Hàn một điện trở kéo xuống khoảng vài k vào chân TX của PIC
- Reset PIC xem phía PC có nhận được sự kiện break hay không

Thân,

Thanks ! Tôi sẽ thử xem, hi vog là đc !
À mà liệu có phải do dùng tụ ở các chân MAX232 không chuẩn ko nhỉ ?! Mạch nguyên lý là các tụ hóa 10uF nhưng hôm làm mạch thì trời mưa to nên dùng luôn tụ 47u ()) vì ở nhà hết đồ ko đi mua đc

[namqn]

Nguyên văn bởi bachelor

Thanks ! Tôi sẽ thử xem, hi vog là đc !
À mà liệu có phải do dùng tụ ở các chân MAX232 không chuẩn ko nhỉ ?! Mạch nguyên lý là các tụ hóa 10uF nhưng hôm làm mạch thì trời mưa to nên dùng luôn tụ 47u ()) vì ở nhà hết đồ ko đi mua đc

Tụ ở các chân MAX232 dùng cho mạch bơm điện tích, để nâng mức và đảo dấu điện áp lên theo quy định của RS-232. Tôi cho là dùng 47 uF không ảnh hưởng gì.

Thân,