@Kurt: USB_HOST (T4.1) Serial, hardware handshake

Frank B · Jul 8, 2021

Hi Kurt, Paul referred me to you.

In the USB_HOST_ the functions for the hardware handshake signals (dtr, rts) are missing.
I tried to connect a UNO. This one uses DTR.
But it is not only practical for the UNO - you could also connect an ESP which uses both HW handshake signals.
You could then program the boards with the Teensy.

But it is also useful for many other things.
Can you extend the library to be able to use hardware handshake/switch the signals??

Thanks!!!
Frank

Just for the sake of completeness:
- https://www.arduino.cc/en/uploads/Main/arduino-uno-schematic.pdf
- https://docs.ai-thinker.com/_media/esp32/docs/nodemcu-32s_product_specification.pdf (Page 11)

Uno says:
16:59:12.343 ->
16:59:12.343 ->
16:59:12.343 -> USB Host Testing - Serial
16:59:12.582 -> *** Device USERIAL1 2341:43 - connected ***
16:59:12.582 -> manufacturer: Arduino (www.arduino.cc)
16:59:12.582 -> product: Arduino (www.arduino.cc)
16:59:14.334 ->

PaulStoffregen · Jul 8, 2021

I believe DTR & RTS should be possible with CDC-ACM devices using only control transfers. The other modem signals require listening to the 3rd endpoint.

KurtE · Jul 9, 2021

Hi Frank and Paul , I am really rusty with some of CDC-ACM stuff, Will try to take a look. First up will be to brush back up on the the drivers...

KurtE · Jul 9, 2021

First with like DTR... We already set and clear them when we startup... So are you maybe needing method in class to allow your sketch to control?

mjs513 · Jul 9, 2021

Ok curious now Frank - are you connecting the uno directly to the usbhost connector so usb on the arduino is connected to the USBHost on the Teensy?

Frank B · Jul 9, 2021

Yes. With my son, I'm working on a system where both communicate.
That's the most convenient way.
But it's pain to develop...

It would be great for ESP, too. Plug@play WLAN and the opportunity to program the ESP without disconnecting it..

Frank B · Jul 9, 2021

Kurt, yes. As a minimum that would be enough. Full access to all hs signals(both directions) would be better, but is not needed for my application.
Just would be good for completeness..

Frank B · Jul 9, 2021

He asked me why we need level shifters wires etc to connect a usb serial board when we have USB.
...

And he' s right

ETMoody3 · Jul 9, 2021

This has intriguing potential

Frank B · Jul 9, 2021

Yes it has

KurtE · Jul 9, 2021

I will hack something in soon...

Was sort of distracted today with similar but different stuff.

It looks like to work for several different boards, will need to implement it for several Serial types...

That is Serial Uno: CDC(ACM)

Code:

 manufacturer: Arduino (www.arduino.cc)
  product: Arduino Uno
  Serial: 649353433333
control callback (serial) 6
CDCACM setup: 00 96 00 00 00 00 08

I plugged in an ESP32

Code:

Manufacturer: Silicon Labs
enumeration:
Product: CP2102 USB to UART Bridge Controller

Edit: ESP32 in MicroMod: different CP2102

Code:

product: CP2102N USB to UART Bridge Controlle

I plugged in an UNO clone (earlier Seeedstudio)...
Shows up as an FTDI:

Code:

Manufacturer: FTDI
enumeration:
Product: FT232R USB UART
enumeration:
Serial Number: A100WP2C

And if I remember correctly one of the Adafruit boards showed up as something else as well...

But will give it a try.

KurtE · Jul 10, 2021

I started playing with some of this, but brings me up to interesting question.

What does for example FTDI devices work with Arduino IDE? Example the Trossen Arbotix board using FTDI cable to program the AVR chip..
If you look at the FTDI Cable pin outs you see:

I am thinking they are driving the RTS line

That is if you look at the Sparkfun Serial basic board, which uses a CH340 That pin is DTR

Now back to playing

KurtE · Jul 10, 2021

Quick update, I put up a new branch: https://github.com/KurtE/USBHost_t36/tree/Serial_DTR

That has setDTR(true/false);

Only partially there.

I was able to verify that I could set DTR and in the case I mentioned above I also set RTS pin...

Sketch I am running:

Code:

// Simple test of USB Host Mouse/Keyboard
//
// This example is in the public domain

#include "USBHost_t36.h"
#define USBBAUD 38400
uint32_t baud = USBBAUD;
uint32_t format = USBHOST_SERIAL_8N1;
USBHost myusb;
USBHub hub1(myusb);
USBHub hub2(myusb);
USBHIDParser hid1(myusb);
USBHIDParser hid2(myusb);
USBSerial userial(myusb);
const int led_pin = 13;  // 13 = Teensy 3.X & LC

USBDriver *drivers[] = {&userial, &hub1, &hub2, &hid1, &hid2};
#define CNT_DEVICES (sizeof(drivers)/sizeof(drivers[0]))
const char * driver_names[CNT_DEVICES] = {"USERIAL1", "Hub1", "Hub2",  "HID1", "HID2"};
bool driver_active[CNT_DEVICES] = {false, false, false, false};
void setup()
{
  pinMode(led_pin, INPUT_PULLDOWN);  // LED driven by IO pin
  while (!Serial && (millis() < 2000)) ; // wait for Arduino Serial Monitor
  Serial.println("\n\nUSB Host Testing - USB Serial to USB Serial");
  myusb.begin();
}

long led_on_time = 0;
byte buffer[80];
bool dtr_value = false;

void loop()
{
  int ch;
  myusb.Task();

  if (Serial.available()) {
    while (Serial.read() != -1);
    dtr_value = !dtr_value;
    userial.setDTR(dtr_value);
    Serial.printf("Dtr set to %u\n", dtr_value);
  }

  updateDeviceList();
  while (userial.available()) {
     Serial.write(userial.read());
  }

}

void updateDeviceList() {
  // Print out information about different devices.
  for (uint8_t i = 0; i < CNT_DEVICES; i++) {
    if (*drivers[i] != driver_active[i]) {
      if (driver_active[i]) {
        Serial.printf("*** Device %s - disconnected ***\n", driver_names[i]);
        driver_active[i] = false;
      } else {
        Serial.printf("*** Device %s %x:%x - connected ***\n", driver_names[i], drivers[i]->idVendor(), drivers[i]->idProduct());
        driver_active[i] = true;

        const uint8_t *psz = drivers[i]->manufacturer();
        if (psz && *psz) Serial.printf("  manufacturer: %s\n", psz);
        psz = drivers[i]->product();
        if (psz && *psz) Serial.printf("  product: %s\n", psz);
        psz = drivers[i]->serialNumber();
        if (psz && *psz) Serial.printf("  Serial: %s\n", psz);

        // If this is a new Serial device.
        if (drivers[i] == &userial) {
          // Lets try first outputting something to our USerial to see if it will go out...
          userial.begin(baud);
        }
      }
    }
  }

}

So far on FTDI breakout I confirmed the signals

On Arduino Uno, I have simple sketch:

Code:

uint16_t loop_count = 0; 
void setup() {
  Serial.begin(38400);
  delay(100);
  Serial.println("Program start");
}

void loop() {
  Serial.println(loop_count++, DEC);
  delay(1000);
}

Which counts up. Playing with setting and clearing appears to restart the UNO...

Have a few other chips to try ... Some of them I don't have with these signals...

Frank B · Jul 10, 2021

Great news! Thank you *very* much.
I'll test it.

Frank B · Jul 10, 2021

Hm...
DTR seems to work.
But programming the UNO.. not.
Not sure what the problem is.

As a first experiment, i use avrdude on the PC where Teensy is just "man in the middle".

Resetting the UNO with DTR seems to work.

Attached my program. Teensy must be set to usb type "Dual Serial".

The command to program the uno is:
C:\Users\Frank\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/bin/avrdude -CC:\Users\Frank\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf -v -patmega328p -carduino -PCOM19 -b115200 -D -Uflash:w:c:\temp\arduino_build_405010/Blink.ino.hex:i

(modify the paths or just copy it from the verbose output when you program the uno)
-PCOM19 is the com port

It too late now... 1:10 AM .. time to sleep..tztzt

This is the protocol: http://ww1.microchip.com/downloads/en/AppNotes/doc2525.pdf
This a zipfile with the mentioned .h file: https://ww1.microchip.com/downloads/en/AppNotes/avr061.zip
(in case some wants to take a look...

quite possible that i don't see something obvious)

Frank B · Jul 10, 2021

AVRDude sends Cmnd_STK_GET_SYNC, Sync_CRC_EOP - which is according to the PDF correct,
But UNO (seems!) to answer 0x10, 0x14 which is wrong - should be 0x14, 0x10 <- wrong order.
Why?

Good night.

mjs513 · Jul 10, 2021

@KurtE

Plugged in the 2 sketches to a Genuine Uno and a T4.1. Connected both up and they worked:

Code:

*** Device USERIAL1 2341:43 - connected ***
  manufacturer: Arduino (www.arduino.cc)
  product: Arduino (www.arduino.cc)
 Program start
0
1
2
3
4
5
6
7
8
9
10
...

Did the same thing for a Elegoo Uno with the same results:

Code:

USB Host Testing - USB Serial to USB Serial
*** Device USERIAL1 2341:43 - connected ***
  manufacturer: Arduino (www.arduino.cc)
  product: Arduino (www.arduino.cc)
 Program start
0
1
2
3
4
5
6

It does work with a T3.2 but not a T4.0 or a TMicroMod.

Frank B · Jul 11, 2021

Good Morning

mjs513 said:
It does work with a T3.2 but not a T4.0 or a TMicroMod.

Interesting!

I don't get why my programming attempt with avrdude does not work.
Must be something strange.
Perhaps it has to do with all the buffers involved? What do you think?
Would it help to flush everything *somehow* after each byte in each direction?

KurtE · Jul 11, 2021

Hard to tell... Let me check to see if I can figure out if they are doing something different instead of just doing dtr signal. We may also need to see if they are setting some special baud rate or ...

mjs513 · Jul 11, 2021

@Frank B - @KurtE
Just gave the usbhost_programmer sketch a try along with using the blink sketch. Going to start where it diverges from the the direct upload:

Code:

avrdude: Version 6.3-20190619
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Users\Merli\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf"

         Using Port                    : COM20
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
[COLOR="#FF0000"]avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x10[/COLOR]  Error but continues so sync probably reestablished?
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : Arduino
         Description     : Arduino

[COLOR="#FF0000"]avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x14

avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x03

avrdude: stk500_getparm(): (a) protocol error, expect=0x14, resp=0x10[/COLOR]  This is where seems to start getting strange
[COLOR="#FF0000"]         Hardware Version: 4744608
         Firmware Version: 0.4611299[/COLOR]  This shows as Arduino/Arduino with direct upload
         Vtarget         : 0.4 V
         Varef           : 0.3 V
         Oscillator      : 28.800 kHz
         SCK period      : 3.3 us

[COLOR="#FF0000"]avrdude: stk500_initialize(): (b) protocol error, expect=0x10, resp=0x04
[/COLOR]avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

[COLOR="#FF0000"]avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x10
[/COLOR]
avrdude done.  Thank you.

Not sure but maybe something is out of synch. If you look at the last printed data from the monitor for the last several messages:

Code:

.....
Send:0x20
RCV:0x10
RCV:0x14
RCV:0x4
RCV:0x10
RCV:0x14
RCV:0x10
RCV:0x14

KurtE · Jul 11, 2021

Good morning again,

I think with your program, I might try adding a flush in both directions.

I think I might also try something like in the section:

Code:

 if (usbserial_active) {
    dtr = SerialUSB1.dtr();
    digitalWriteFast(LED_BUILTIN, dtr);
[COLOR="#FF0000"]    if (SerialUSB1.baud() != lastBaud {
        lastBaud = SerialUSB1.baud();
        usbserial.begin(lastBaud); 
    }
[/COLOR]    if (dtr != lastDtr) {
      usbserial.setDTR( dtr );
      lastDtr = dtr;
    }
...

Not sure if it will work or not, but... It would be interesting to see if avrdude does change baud rates on you...

KurtE · Jul 11, 2021

I have not yet enabled changing the baud rate... Will try that next... I am now monitoring it.

Also changed the code to check to see how much data is sent or received per usb packet. And read it in all at once and send it all at once and then do flush...

Debug output looks like:

Code:

Programmer started.
usbhost serial connected
SerialUSB1 changed BAUD from 115200 to 0
RCV(1): 0x0
RCV(14): 0x50 0x72 0x6F 0x67 0x72 0x61 0x6D 0x20 0x73 0x74 0x61 0x72 0x74 0xD
SerialUSB1 changed BAUD from 0 to 115200
SerialUSB1 DTR change 1
Send(2): 0x30 0x20
RCV(2): 0xA 0x14
Send(2): 0x30 0x20
RCV(2): 0x10 0x14
Send(2): 0x30 0x20
RCV(2): 0x10 0x14
Send(2): 0x30 0x20
RCV(2): 0x10 0x14
Send(3): 0x41 0x80 0x20
RCV(3): 0x10 0x14 0x3
Send(3): 0x41 0x81 0x20
Send(3): 0x41 0x82 0x20
RCV(6): 0x10 0x14 0x4 0x10 0x14 0x4
Send(3): 0x41 0x98 0x20
Send(3): 0x41 0x84 0x20
RCV(6): 0x10 0x14 0x3 0x10 0x14 0x3
Send(3): 0x41 0x85 0x20
Send(3): 0x41 0x86 0x20
RCV(6): 0x10 0x14 0x3 0x10 0x14 0x3
Send(3): 0x41 0x87 0x20
Send(3): 0x41 0x89 0x20
RCV(6): 0x10 0x14 0x3 0x10 0x14 0x3
Send(3): 0x41 0x81 0x20
Send(3): 0x41 0x82 0x20
RCV(6): 0x10 0x14 0x4 0x10 0x14 0x4
Send(22): 0x42 0x86 0x0 0x0 0x1 0x1 0x1 0x1 0x3 0xFF 0xFF 0xFF 0xFF 0x0 0x80 0x4 0x0 0x0 0x0 0x80 0x0 0x20
Send(2): 0x51 0x20
SerialUSB1 DTR change 0
RCV(4): 0x10 0x14 0x10 0x14
RCV(15): 0x10 0x50 0x72 0x6F 0x67 0x72 0x61 0x6D 0x20 0x73 0x74 0x61 0x72 0x74 0xD

AVRDude is still failing. Next up see if changing baud will help...

Frank B · Jul 11, 2021

Send(2): 0x30 0x20
RCV(2): 0xA 0x14
Send(2): 0x30 0x20
RCV(2): 0x10 0x14
Send(2): 0x30 0x20
RCV(2): 0x10 0x14
Send(2): 0x30 0x20

Yup if I understand the pdf correctly, the uno should answer 0x14, 0x10
Maybe we just have one byte too much.

The first 0x0a is 0x00 for me..?!
I think it shouldn't be there.

Frank B · Jul 12, 2021

*rant about the bootloader deleted*
I'll try it again tonight for an hour, and if I don't get anywhere, I'll put it aside.

Frank B · Jul 13, 2021

@kurt: I enabled debug:

Code:

->usbhost serial connected.
control callback (serial) 0
control callback (serial) 6
CDCACM setup: 00 C2 01 00 00 00 08 
control callback (serial) 4
Control - 0x21,0x22, 0x3
setDTR: 0
control callback (serial) 0
control callback (serial) 0
->PC Connected. Baud:115200
setDTR: 1
control callback (serial) 0
->Send: 0 0x30
->Send:   0x20
txtimer
  TX data (2) 30 20 
tx1:
rx token: 803E8100 transfer length: 64 len:2 - 14 10
rx: 14 10 
->Rcv: 0x00   0x14

(messages of my sketch marked with "->")
SO, it receives a correct packet 0x14, 0x10, but the sketch receives 0, 0x14
There must be a little bug in the usb-host serial (because of DTR?)

@Kurt: USB_HOST (T4.1) Serial, hardware handshake

Senior Member

Well-known member

Senior Member+

Senior Member+

Senior Member+

Senior Member

Senior Member

Senior Member

Well-known member

Senior Member

Senior Member+

Senior Member+

Senior Member+

Senior Member

Senior Member

Attachments

Senior Member

Senior Member+

Senior Member

Senior Member+

Senior Member+

Senior Member+

Senior Member+

Attachments

Senior Member

Senior Member

Senior Member