USB Serial - differences between WIFI and MINIMA

[KurtE]

There API differences between the Serial objects on the WIFI and MINIMA.

Sorry, it is unclear to me if this should be an issue here, as code compiles on one and not the other. Or should be a discussion on the forum.

The following sketch, which is a slightly modified version of the USBToSerial Teensy example sketch, builds and runs fine on MINIMA, but compiler errors with WIFI. Note: code will not properly on current released code as availableForWrite() was not implemented and uses the default implementation which returns 0.

/* USB to Serial - Teensy becomes a USB to Serial converter
   http://dorkbotpdx.org/blog/paul/teensy_as_benito_at_57600_baud

   You must select Serial from the "Tools > USB Type" menu

   This example code is in the public domain.
*/

// set this to the hardware serial port you wish to use
#if defined(ARDUINO_UNOR4_WIFI)

UART _UART4_(18, 19);
#define SerialX Serial3
#else
UART _UART2_(18, 19);
#define SerialX Serial2
#endif


#define HWSERIAL Serial1

unsigned long baud = 115200;
const int reset_pin = 4;

void setup()
{
  pinMode(LED_BUILTIN, OUTPUT);
  pinMode(3, OUTPUT);
  pinMode(4, OUTPUT);
  pinMode(5, OUTPUT);
  pinMode(6, OUTPUT);
  pinMode(7, OUTPUT);
  pinMode(8, OUTPUT);
  digitalWrite(LED_BUILTIN, LOW);
  digitalWrite(reset_pin, HIGH);
  pinMode(reset_pin, OUTPUT);
  Serial.begin(baud);	// USB, communication to PC or Mac
  HWSERIAL.begin(baud);	// communication to hardware serial
  
}

long led_on_time=0;
byte buffer[80];
unsigned char prev_dtr = 0;

void loop()
{
  unsigned char dtr;
  int rd, wr, n;

  // check if any data has arrived on the USB virtual serial port
  rd = Serial.available();
  if (rd > 0) {
    // check if the hardware serial port is ready to transmit
    wr = HWSERIAL.availableForWrite();
    if (wr > 0) {
      // compute how much data to move, the smallest
      // of rd, wr and the buffer size
      if (rd > wr) rd = wr;
      if (rd > 80) rd = 80;
      // read data from the USB port
      n = Serial.readBytes((char *)buffer, rd);
      // write it to the hardware serial port
      HWSERIAL.write(buffer, n);
      // turn on the LED to indicate activity
      digitalWrite(LED_BUILTIN, HIGH);
      led_on_time = millis();
    }
  }

  // check if any data has arrived on the hardware serial port
  rd = HWSERIAL.available();
  if (rd > 0) {
    // check if the USB virtual serial port is ready to transmit
    wr = Serial.availableForWrite();
    if (wr > 0) {
      // compute how much data to move, the smallest
      // of rd, wr and the buffer size
      if (rd > wr) rd = wr;
      if (rd > 80) rd = 80;
      // read data from the hardware serial port
      n = HWSERIAL.readBytes((char *)buffer, rd);
      // write it to the USB port
      Serial.write(buffer, n);
      // turn on the LED to indicate activity
      digitalWrite(LED_BUILTIN, HIGH);
      led_on_time = millis();
    }
  }

  // check if the USB virtual serial port has raised DTR
  dtr = Serial.dtr();
  if (dtr && !prev_dtr) {
    digitalWrite(reset_pin, LOW);
    delayMicroseconds(250);
    digitalWrite(reset_pin, HIGH);
  }
  prev_dtr = dtr;

  // if the LED has been left on without more activity, turn it off
  if (millis() - led_on_time > 3) {
    digitalWrite(LED_BUILTIN, LOW);
  }

  // check if the USB virtual serial wants a new baud rate
  if (Serial.baud() != baud) {
    baud = Serial.baud();
    if (baud == 57600) {
      // This ugly hack is necessary for talking
      // to the arduino bootloader, which actually
      // communicates at 58824 baud (+2.1% error).
      // Teensyduino will configure the UART for
      // the closest baud rate, which is 57143
      // baud (-0.8% error).  Serial communication
      // can tolerate about 2.5% error, so the
      // combined error is too large.  Simply
      // setting the baud rate to the same as
      // arduino's actual baud rate works.
      HWSERIAL.begin(58824);
    } else {
      HWSERIAL.begin(baud);
    }
  }
}

The difference to the actual example is I added a bunch of pinMode statements to enable some debugging of my updated code base and I setup to allow optional Serial object using the SCL/SDA pins.

Compiler errors on the WIFI board:

C:\Users\kurte\Documents\Arduino\R4-Uno-wifi\USBtoSerial_r4\USBtoSerial_r4.ino: In function 'void loop()':
C:\Users\kurte\Documents\Arduino\R4-Uno-wifi\USBtoSerial_r4\USBtoSerial_r4.ino:92:16: error: 'class UART' has no member named 'dtr'
   dtr = Serial.dtr();
                ^~~
C:\Users\kurte\Documents\Arduino\R4-Uno-wifi\USBtoSerial_r4\USBtoSerial_r4.ino:106:14: error: 'class UART' has no member named 'baud'
   if (Serial.baud() != baud) {
              ^~~~
C:\Users\kurte\Documents\Arduino\R4-Uno-wifi\USBtoSerial_r4\USBtoSerial_r4.ino:107:19: error: 'class UART' has no member named 'baud'
     baud = Serial.baud();
                   ^~~~

exit status 1

Compilation error: 'class UART' has no member named 'dtr'

Notes/Questions - things to try.

MINIMA:

1. Does the MINIMA code pickup baud rate changes, with the baud() method? I have not tried to see yet.
2. Does it reflect it back to the host?
3. Does the Serial monitor care what the baud rate is set to? As it sends and receives at USB speed

WIFI:

1. baud(). Could either make Serial object, as a sub-class of the UART code, or could add baud() to the UART code, or could punt.

2. How are the communications between ESP32 and hardware UART impacted by what BAUD rate chosen? Does it change the speed between the two processors, I pretty sure YES. but could instead choose to use some fixed speed.

3. And if I do Serial.begin(new_baud_rate) is that communicated back to ESP32? And then back to the host?

[aentinger]

Hi @KurtE ☕ 👋

For general questions please take it to the forum.

If you're experiencing a real issue (= have discovered a bug) then please open a single issue for a single bug.

If you have a solution - even better - please open a PR.

Please stop creating one issue after the other, dealing with each and single one of your mostly unclear formulated issues takes time and bandwith from our team trying to patch the actual issues. I've already warned you over here.

[KurtE]

Hello @aentinger,
Sorry, I did not think this was a general question.

Maybe if you had an issue template, like the IDE, one might know in what format you would like things in.

This Issue: the WIFI version does not implement Serial.baud() and Serial.dtr() and maybe others.
The rest could be formatted, into sections like:

How to reproduce:
Expected results:
Alternative solutions:
Additional comments:

Sorry I don't have enough information on how to implement this on your board.
As for creating this as a forum question, I am guessing there are not many up there who could answer the primary question I would have:
Specifically, when the ESP32 receives the CDC_SET_LINE_CODING message on endpoint 0, what does it do with it? Is the information contained in it somehow made available to the main processor? likewise for CDC_STATUS_INTERFACE?

As for #76 (comment)
I am sorry I wasted everyone's time verifying that the corruption only happens on the Wi-Fi board, and localized the memory being changed to right after initVariant was called. Memory was fine with check right after the call, but not by the time the next call was entered. Guessing interrupt happened at that point.... Won't happen again.

As for opening new issues. I will resist.

[aentinger]

Maybe if you had an issue template, like the IDE, one might know in what format you would like things in.

That's a good feedback 👍 and this would be a good example of what could be put into a single issue, i.e. "[Feature Request] Provide issue template in order to facilitate effective communication between community and maintainers".

As for opening new issues. I will resist.

You can open new issues, but apply the following checks:

• Is this an issue or a support topic (support -> Arduino Forum or Arduino Support)
• Is this a single issue (not mixing up multiple topics in one)
• Have I gathered enough information to present the issue in the most short and concise way possible?

Similar for PRs. We do not have the bandwidth to verify large PR's that attempt to improve multiple dimensions in one changeset. Keep them small and localized. Allright, mate? 😉