search

Fazecast / jSerialComm

Platform-independent serial port access for Java
GNU Lesser General Public License v3.0
1.34k stars 287 forks source link

Fail to communicate with no flow control #235

Closed neil-benn closed 5 years ago

neil-benn commented 5 years ago

Hello,

I've got a device I'm talkng to (A Laird bluetooth device) with a Silicon Labs CP210x working as the USB to UART bridge and a converter with 3.3V logic and RS232. The Laird device has it's CTS permanently 'ON' by the use of a resistor. The OS is windows (later to be linux).

I've got a fairly complicated set of conditions that is causing an issue-

  1. I have a dev board for the Laird chip that has CTS/RTS wired up and jSerialComm works just fine with flow control set to SerialPort.FLOW_CONTROL_DISABLED. I've also tested it with Termite and a test program from Laird (again without flow control) - everything works

  2. However; I also have a prototype board that only has Rx, Tx and Ground connected with the CTS on the laird device permanently 'ON' with a resistor on the prototype board. I can communicate with no flow control on termite and the Laird test program - however jSerialComm fails. I can write but nothing comes backs. However if I connect again with jSerialComm then the response to the previous command comes back as if it were sat in a windows buffer somewhere!

    The fact that Termite and Laird work in case 2 but jSerialComm does not points to a jSerialComm issue. Is there some way to look at the logging inside jSerialComm to determine what the issue could be?

    Thanks for your help - any suggestions would be gratefully received!

Regards,

Neil Benn

hedgecrw commented 5 years ago

Sorry it's taken me so long to respond to this! So, in essence, the problem you're running into is that jSerialComm is not returning any data when you have the CTS line permanently set to the high state? In that case, the only thing I can think of would be that the Windows default serial configuration is expecting something different on either the CTS or RTS line than is actually present.

Would you mind trying the following and seeing if any of these changes work for you:

1) Before you open the com port, call yourComPort.clearRTS(), and see if it works 2) Before you open the com port, call yourComPort.clearDTR(), and see if it works 3) Before you open the com port, call both yourComPort.clearRTS() and yourComPort.clearDTR(), and see if it works

Let me know the results of those tests, and thanks for your patience!

hedgecrw commented 5 years ago

Any updates on this issue?

hedgecrw commented 5 years ago

Closing due to inactivity

yannick818 commented 3 years ago

Sorry it's taken me so long to respond to this! So, in essence, the problem you're running into is that jSerialComm is not returning any data when you have the CTS line permanently set to the high state? In that case, the only thing I can think of would be that the Windows default serial configuration is expecting something different on either the CTS or RTS line than is actually present.

Would you mind trying the following and seeing if any of these changes work for you:

  1. Before you open the com port, call yourComPort.clearRTS(), and see if it works
  2. Before you open the com port, call yourComPort.clearDTR(), and see if it works
  3. Before you open the com port, call both yourComPort.clearRTS() and yourComPort.clearDTR(), and see if it works

Let me know the results of those tests, and thanks for your patience!

Had a similar application, where I use the flow control pins for a different purpose. Although I set FLOW_CONTROL_DISABLED, DTS and CTS pins seem to change. After this changes it works, thanks!