Support for reading RI control changes

[SDOperations]

Hi! Thanks for this great library!

We use this on one of our applications and it works great for getting serial data and such.

However we now require reading RI control changes. Is that possible using this?

Thanks

[kai-morich]

You can use getRI method https://github.com/mik3y/usb-serial-for-android/blob/fd8c155ca5f69ec80f8f0ac28bb73ffc97b92511/usbSerialForAndroid/src/main/java/com/hoho/android/usbserial/driver/UsbSerialPort.java#L202

[SDOperations]

Hi @kai-morich,

It seems I don't quite understand how this works.

How can I attach an interrupt handler to execute a method whenever the RI changes?

I could not find an example for this in the samples.

Thank you very much!

[SDOperations]

I was not able to detect whether or not the getRI method works.

I created a new thread to verify the RI status.

Please note I was able to verify the RI status through realterm.

val ppsThread = Thread {
            while (true) {
                try {
                      if (serialPort.getRI()) {
                          Log.d("Serial State", "RI State is on!");
                      }

                    Thread.sleep(1)
                } catch (e: Exception) {
                    Log.d(this.javaClass.simpleName, e.message)
                }
            }
       }

        Log.d("Serial", "Starting RI Thread")
        ppsThread.start();

The device in question uses the FTDI Serial Driver

[kai-morich]

you have to poll for changes as you did in above example.

note: the FTDI device is the only device that regularily sends control line status as side effect of read call, but as it is not supported by other devices and your app not necessarily always does read, this info is not used, but the FTDI device is actively called in your poll.

[SDOperations]

Do you have any suggestions I could try? I don't quite understand what you meant with the following:

but as it is not supported by other devices and your app not necessarily always does read, this info is not used,

I also tried it without the sleep method, this does not seem to impact the results.

[kai-morich]

Your above code snippet is exactly what you need, but you only sleep for 1 milliseconds. I recommend something like 100 milliseconds to avoid high CPU load and USB traffic.