Detecting 2 COM Ports of IWR6843AOP Sensor

Raees Abdullah said:
My problem is that I can't send/receive data to/from the interface 1 and recently I was reading some previous forums, and I found this forum: https://forum.pjrc.com/index.php?th...-issues-with-silabs-cp2105.75211/#post-344623

This person was facing exactly the same issue I am facing and someone replied to him that "Judging from the screenshot of the hardware properties, the enhanced port is interface 0 and the standard port is interface 1. From what I can tell the CP210x driver in the USBHost_t36 library only uses interface 0, it would require a bunch of changes to use interface 1". This means that teensy 4.1 still does not have the capability to use the interface 1 completely.
Click to expand...
Sorry, I am not really following this here? If it is setup for Dual Serial ports and it actually creates two USBSerial objexts...

Is there some place here, where you plugged it in, and had debug turned on in USBHost, with the output shown here in
code tags?

As for bigbuffer version:
Code: 
USBHub hub1(myusb);
USBSerial_BigBuffer userial1(myusb, 1, 1024);  // Assume Interface 0 = CLI
USBSerial_BigBuffer userial2(myusb, 1, 1024);  // Assume Interface 1 = Data

I don't think these will work, that is the parameters for the big buffer constructor are:
Code: 
//  host - reference to the main USB object
    //  min_rxtx - defaults to 65, set to 1 if you wish for it to also handle all USB to Serial objects
    //  vid_to_claim - Vendor ID Normally 0, but if you have device that is not supported you might specify it here.
    //  pid_to_claim - Product ID - only used with VID above
    //  vid_pid_sertype - Again not normally used unless pid, vid - then one of the following FTDI, PL2303, CH341, CP210X
    // void_pid_claim_at_type = like above but 0 if claim at interface (default)  or 1 claim whole device
I don't remember adding all of those later parameters, but probably did to make it so you could try to add some new device...
But your 1024 is not the Product ID of your device (I don't think) so it won't connect.

Note: you might not necessarily rely on which of the objects will be claimed for what. That is I don't remember if they come out LIFO or FIFO.
And if something claims and releases, ...

But if you try running, this with the debug turned on, there should be some information printed by each of the objects, when/if it asks
the object if it wants to claim it or not...
 
Sorry about the delay. I meant to work on this 2 weeks ago, but got distracted by another project.

I've committed code on github to support CP2105 dual serial.

github.com

Support CP2105 Dual Serial · PaulStoffregen/USBHost_t36@2f1406b

https://forum.pjrc.com/index.php?threads/detecting-2-com-ports-of-iwr6843aop-sensor.77681
github.com github.com

So far I've tested only with this simple program (adapted from msg #11), which sends "Hello World" to both ports and prints info to the Arduino Serial Monitor about anything it hears from either port.

Code: 
#include <USBHost_t36.h>

USBHost myusb;
USBSerial userial1(myusb);
USBSerial userial2(myusb);

void setup() {
  Serial.begin(115200);
  delay(2000);

  Serial.println("\n=== Simple Detection Test ===\n");
  myusb.begin();

  Serial.println("Waiting 2 seconds for enumeration...");

  for (int i = 0; i < 20; i++) {
    myusb.Task();
    delay(100);

    if (i % 10 == 0) {
      Serial.print(".");
    }
  }

  Serial.println("\n\n--- Results ---");

  Serial.print("userial1: ");
  if (userial1) {
    Serial.print("DETECTED ✓ - VID: 0x");
    Serial.print(userial1.idVendor(), HEX);
    Serial.print(", PID: 0x");
    Serial.println(userial1.idProduct(), HEX);
  } else {
    Serial.println("NOT DETECTED ✗");
  }

  Serial.print("userial2: ");
  if (userial2) {
    Serial.print("DETECTED ✓ - VID: 0x");
    Serial.print(userial2.idVendor(), HEX);
    Serial.print(", PID: 0x");
    Serial.println(userial2.idProduct(), HEX);
  } else {
    Serial.println("NOT DETECTED ✗");
  }

  Serial.println("\n--- Conclusion ---");
  int detected = (userial1 ? 1 : 0) + (userial2 ? 1 : 0);
  Serial.print("Total interfaces detected: ");
  Serial.println(detected);

  if (detected == 0) {
    Serial.println("ERROR: No interfaces detected!");
  } else if (detected == 1) {
    Serial.println("Only ONE interface detected (expected limitation)");
  } else if (detected == 2) {
    Serial.println("BOTH interfaces detected! Library can handle it!");
  }
  if (userial1) {
    Serial.println("sending to userial1");
    userial1.println("Hello World #1");
  }
  if (userial2) {
    Serial.println("sending to userial2");
    userial2.println("Hello World #2");
  }
}

void loop() {
  myusb.Task();
  if (userial1 && userial1.available()) {
    int c = userial1.read();
    Serial.print("Received on userial1: ");
    Serial.println(c);
  }
  if (userial2 && userial2.available()) {
    int c = userial2.read();
    Serial.print("Received on userial2: ");
    Serial.println(c);
  }
}

Not yet tested:
  • Different baud rate or other settings on each port
  • Single port CP2105 - I simply don't have the hardware to test, looking for assistance
 
To answer this specific question:

Raees Abdullah said:
But when I asked Cluade that will this solve my problem or not?, it replied that you will have to add some block of code as well in order to claim it and the code it gave me this block code to be added after line #246
.....
Now was this block of code was neccessary?
Click to expand...

No, Claude completely misunderstood how interface claiming works. It tried to add unnecessay code to remember which interfaces had been claimed. But that wasn't the problem at all, and can't even become a problem because the enumeration code calls the claim function for each interface it discovers.

The problem was the control transfers which initialize the port(s) were hard-coded to send to interface 0, which of course worked fine for the case of a single interface device. All that was needed was remembering within each driver instance which interface was given during the claim function, and editing the control transfers to send the interface number in each control transfer's wIndex field.

windex.png
 
To quickly show how I tested, I connected the CP2105 cable to a Teensy 4.1. I connected each of its ports to a single-port FTDI USB serial cable.

1772986505445.png


The cable for Teensy 4.1 and the two FTDI cables plugged into this USB hub which connects to my desktop PC.

1772986551475.png


For testing, I ran two "seyon" terminal emulators on my PC, one for each FTDI cable, and of course the Arduino Serial Monitor to Teensy 4.1.

1772986631378.png


Here you can see the "Hello World" messages the test program transmits each time it starts up, and the results on the Arduino Serial Monitor after I typed a few keystrokes into each the seyon terminal emulator windows.
 
Glad you got it working.

PaulStoffregen said:
The problem was the control transfers which initialize the port(s) were hard-coded to send to interface 0, which of course worked fine for the case of a single interface device. All that was needed was remembering within each driver instance which interface was given during the claim function, and editing the control transfers to send the interface number in each control transfer's wIndex field.
Click to expand...
Figured it might be something like that...
 
Do you still have a single port CP2105 adapter handy? I don't have one.

Any chance I could talk you into running a quick test to make sure I didn't break anything?
 
PaulStoffregen said:
Do you still have a single port CP2105 adapter handy? I don't have one. Any chance I could talk you into running a quick test to make sure I didn't break anything
Click to expand...
I don't have any CP2105 adapters, but I had CP2102 which are single port... Not sure if I still had the one as I think I may have fried one once...
But will have one arriving in the next few days... Sometimes I never have enough Serial to USB adapters...
 
Ah, well that makes sense.

Any idea which chip has VID 10C4, PID EA70? That's the case we used to claim at device level but now claim at interface level.
 
Because this code previously has this line, I (incorrectly) assumed someone must have used hardware with VID 10C4, PID EA70.

Code: 
{0x10c4, 0xea70, USBSerialBase::CP210X, 0 }

I currently have these 8 cables for testing.

FTDI: 0403, 6001, 6.00
FTDI: 0403, 6001, 6.00
FTDI: 0403, 6001, 6.00
PL2303-HX: 067b, 2303, 3.00
CH340: 1a86, 7523, 2.64
PL2303-TA: 067b, 2303, 4.00
PL2303: 067b, 2303, 3.00
CP2105: 10c4, ea70, 1.00

1773087039174.png
 
I don't know about any other ESP32 family devices and/or dev kits, but my ESP32-S3 dev kit board specifically has a CP2102 USB-to-UART bridge IC on it. This device shows up as VID/PID 303a/1001. Don't know if this helps you with your testing in any way, but I thought I'd mention it just in case . . .

Mark J Culross
KD5RXT

Edit: added VID/PID info
 
Paul - from the one Adafruit USBHost_t36 issue, I believe you mentioned you purchased one of these:
www.adafruit.com

Adafruit CP2104 Friend - USB to Serial Converter

Discontinued - you can grab Adafruit CP2102N Friend - USB to Serial Converter instead! Long gone are the days of parallel ports and serial ports. Now the USB port reigns supreme! ...
www.adafruit.com www.adafruit.com

I did find this one, will try it. (it was hooked up to one of my Arduino GIGA R1 as my debug hookup)

The other one she mentioned:
www.adafruit.com

Adafruit Metro Mini 328 V2 - Arduino-Compatible - 5V 16MHz

One of our star development boards is the Adafruit METRO Mini 328, an excellent lil fellow that lets you make your Arduino-based project tiny. Recently we had to ...
www.adafruit.com www.adafruit.com
 
Yep, I tried running...
The USBtoUSBHostSerial sketch:

Code: 
*** Device USERIAL 10c4:ea60 - connected ***

  manufacturer: Silicon Labs

  product: CP2104 USB to UART Bridge Controller

Runs...

This is simple loop back test. RX connected to TX. But if connect to GIGA R1, which should output at 115200, I am getting garbage.
Code: 
ck�ŧc�c"��������gw��
 
Amazon says my CP2104 board will arrive Wednesday afternoon.

Do you recall where the info about CP210X control transfers was found? I see the original code used 0x40 rather than 0x41 for the control transfer request type to set baud rate. A link to the original source info or documentation would really help. I tried several Google searches but got bogged down in lots of Windows driver customization stuff.
 
Sorry it has been a long time since I looked at it:
Sometime today, my order for:



Should arrive in town, not sure when I will be there to pick it up.

It might have been:
a) Stuff we decoded using Logic Analyzer.
b) Some other driver such as the USB Host Shield code, or Linux...
c) Could have been a typo.
 
My first test with the CP2102 cable connected to a FTDI cable on my PC and running code from msg #27 seems to communicate fine at 115200 baud. I see the "Hello World #1" message appear on my PC, and when I type "abcde" into that window, I see this in the Arduino Serial Monitor.

Code: 
=== Simple Detection Test ===

Waiting 2 seconds for enumeration...
..

--- Results ---
userial1: DETECTED ✓ - VID: 0x10C4, PID: 0xEA60
userial2: NOT DETECTED ✗

--- Conclusion ---
Total interfaces detected: 1
Only ONE interface detected (expected limitation)
sending to userial1
Received on userial1: 97
Received on userial1: 98
Received on userial1: 99
Received on userial1: 100
Received on userial1: 101

cp2102.jpg
 
Thanks Paul,

I double checked as well, and my first attempt may have been User error.
That is I used the Serial Monitor of the Arduino IDE to talk to the Teensy, and used the USBtoUSBHostSerial sketch...
However the USB monitor overwrote my startup Baud rate...

So I ran it again but talked to it through a KiTTY(PuTTy) window configured for 115200 and now, the output and input appear to work:
```
Check max malloc
Enter max KB to start: 11
11: 24045D90 - 24048990 Stack var: 20007EBC
Enter max KB to start: 3
3: 24045D90 - 24046990 Stack var: 20007EBC
Enter max KB to start: 500
232: 24045D90 - 2407FD90 Stack var: 20007EBC
Enter max KB to start:
```
This is with the 2104... The 2102s are still in town, will probably pick them up this morning.
 
Good to hear CP2104 is working too!

Amazon is supposed to deliver a CP2104 here later today. I'll probably just store it and only do more testing if anyone reports problems. All signs look like we've got all CP210x working now.

@Raees Abdullah - any word on how the new code works with your IWR6843AOP eval board?

One minor thing I noticed, at least with my Windows 11 laptop, is Windows assigned the COM port numbers reversed to how I would have expected. The first interface #0 became COM8 and the second interface #1 became COM7. Here's a screenshot from Device Manager. The Hardware-ID shows "MI_00" which means USB interface #0 and you can see it became COM8. Quick testing with Tera Term confirms use of COM8 is indeed the yellow and orange wires (RX1 and TX1).

Why Windows assigned a higher COM number to the first interface, I have no idea. Just want to mention that Teensy's USBHost_t36 will assign the first interface to the first unused driver instance, so if your expectation of which is 1st vs 2nd is only from Windows, check those Hardware-ID numbers in Device Manager to really know which COM ports on your PC got assigned to each USB interface in the CP2105.

1773241788461.png
 
Some "off-brand" arduino uno/nanos come with CP2101 as their USB UART, does controlling DTR work since that's used for the reset signal?
 
Good question. My CP2102 and CP2105 cables have only TXD and RXD exposed.

Amazon is supposed to deliver this CP2104 tonight. It'll be my first with DTR exposed.

cp2104.jpg
 
Last edited:
You must log in or register to reply here.
Back
Top