Serial OTG. Arduino CH340. FTDI. rkl099's Extension

no it doesn't. before this i'm using the built in serial blocks. the only reason i'm switching is because the built in blocks doesn't have the block to check whether there is 'byte to read' before actually 'reading the data', causing me to get null or weird characters as explained in this topic,

therefore, i'm switching to your extension and it works excellently (i could also remove some blocks to deal with the "\n" that i get from using the built in serial component to read) but only this small weird .Open issue cause problem. I could actually deal with it by using if then blocks like so but I think if it can be fixed, the extra blocks just not necessarily needed.
ai2 ss

OK, I will put it on the to do list.

Dear you!
How much I dug through to at least light the Arduino bulb! Thank you!
Please send me a link to the latest release of the extension!

The latest version of SerialOTG extension:
Release 1.5, GitHub - rkl099/Appinventor-SerialOTG: Appinventor extension SerialOTG with BT/WIFI client/server support, examples of apps and Arduino code, ver 1.5
1.5.1 adds improved FTDI write speed, GitHub - rkl099/Appinventor_Debug: Debug versions: SerialOTG, Modbus and test programs (Note: can be changed any time). Updated to 1.5.1

Dear Rolf @rkl099,
Appinventor-SerialOTG is a fantastic extension - thanks a lot !
I've recently run into 2 radios (IC705, X6100) that expose serial port on USB as 2nd device (CDC).
Would it be possible to allow to choose serial port at initialisation/before opening port ?
best rgds
Kuba, SP5NZF

This is a part of the code that i have not reviewed yet. I don't have the opportunity to do it know, but i will put the src Appinventor1.5b on github.

1 Like

Thanks. I'll see if it is within my reach

Dear Rolf,
thanks a lot again for your continued support and for uploading source codes.

It took me a while but I've found that it is hidden very low in UsbCdcConnection.java class of package com.physicaloid_ai.lib.usb;
There is method:

public boolean open(int vid, int pid ) {
return open( vid, pid, false, 0);
}

And it calls another method open( vid, pid, false, 0) - now with expected channel being hardcoded to 0.
This one in turn iterates until it finds that channel. For reasonable maintability, I propose to modify just this one class, not the whole stack.
Do you think the following would work:

  1. In UsbCdcConnection class add a static property and a setter for it:
private static int serialChannel = 0;
public static void setChannel(int channel) {
    serialChannel = channel;
}
  1. In UsbCdcConnection class modify open method to use serialChannel not zero:

public boolean open(int vid, int pid ) {
return open( vid, pid, false, serialChannel); // was serialChannel instead of 0
}

  1. In the SerialOTG.java, add a property Channel (as you did with baud, pariti, stop...) with default value 0 and a setter that would execute static setter on the class UsbCdcConnection: UsbCdcConnection.setChannel(Channel);

Unfortunatelly I don't have knowledge (nor environment which boils down to knowledge again) to test it and send you these 2 class changed and a compiled aix ready-to-use.
Of course, I will be glad to test it right away !
Do you think it would work and you could look into it one day?
Thanks a lot again for support and good luck on your current projects.