Wemos D1/R1/ESP8266 UART communication

I've used a heap of NodeMCU Amica ESP8266 boards and also Adafruit Feather Huzzah ESP8266 boards. I haven't got first-hand experience with the Wemos D1/R1 (looks to be a smaller version of a similar board).

Perhaps it would be worthwhile checking a few things -

• The ESP8266 uses the hardware serial lines for connection to the USB-to-Serial bridge (usually a CH340 or CP2102 in most designs) which means that using these pins to talk to a serial device is not a great idea as you have two devices potentially driving lines to opposite states.
• To overcome this, it is probably best to use some other pins and a SoftwareSerial library (https://github.com/plerup/espsoftwareserial ).
• The ESP8266 is a (strictly) 3.3V device, so if you're trying to interface 5V-TTL serial then you could cause some damage to the ESP, or data sent from the ESP may not be recognised by your sensor. Use of a logic shifter is recommended in such circumstances, although for receive-only operation, a voltage divider may be sufficient.

- Gough

Hi,

I know espsoftwareserial library, but that is a bit complicated at least for me as a beginner. Another thing was to use the only available serial to use at serial. but as you have said, using two devices for serial is not a good idea.

I did something like the following to read the sensor data. I am taking care not to use the same serial for serial.print etc. Shouldn't I get the data?

void get_distance(){
  Serial.begin(9600);
  distance=0;
  
  //Serial1.println();
  for(int i=0; i<=8; i++){
    if(Serial.available()>0){
      char c= Serial.read();
      //Serial.print(c);
      dist_data[i]=c;
      //
      if(c==13){
        //Serial.println();
      }
      else{
        for(int i=0; i<=8;i++){
          dist_data[i]==0;
          }
        }
    }
    delay(50);
  }
  }

Sorry, but that code is very confusing. It seems like you are trying to print to both Serial1 and Serial. It's not clear why you are trying to do that and then you have commented it out. As it stands, I can't be certain you'd read anything as you're reading from Serial, which is connected to the USB-serial bridge chip. I'd advise you check this regarding the use of Serial and Serial1 - Reference · ESP8266 Arduino Core

Basically, if you're using Serial, that is the connection on UART0 RX and UART0 TX. This is the connection that is already connected on the board to the USB to Serial bridge. As a result, if you're using Serial, that should be stuff you're either reading from or writing to the computer. Hooking anything else to the UART0 RX and TX lines is strongly not recommended despite how much you might think it would simplify your life as it is going to result in logic level conflicts, potential damage to chips and (more likely than not) not getting the results you expect.

The only exception to this is if you're both sure that the USB to serial bridge tri-states the lines (i.e. goes high impedance) when the USB connection is not active and you also aren't intending to communicate the data to the computer at all - e.g. you are displaying it locally on an LCD, passing data over Wi-Fi/Bluetooth, storing it to a microSD card etc. The first part is not something I'm sure of - I've had issues before. I've used the hardware serial before, but that's only on boards where I've also ended up desoldering the USB to Serial bridge chip entirely from the board - which in essence means it's a pain to reprogram.

If you're using Serial1, then it is using UART1 RX and UART1 TX. Yes, there are two hardware serial ports on the ESP8266 and this one uses different pins for connection, but this second UART comes with a major issue - you cannot use it for receiving data because the RX line is shared with the flash chip that is providing the data for the sketch itself!!! Attempting to use it will (you guessed it) cause logic level conflicts and potentially even sketch crashes as the core fails to read from the serial flash memory. This is just how the ESP8266 "package" is, unfortunately, and the ESP32 is a bit more forgiving in this regard (to what I know).

This is why I've recommended you set-up softwareserial to have a second software-based UART on any set of pins you would like. This is not 100% perfect especially at higher baud rates or if you're doing a lot of work inside the sketch as it does consume some CPU time and comes with risks of losing data if the timings are unfavourable.

- Gough

In the above code, I am only using Serial and Serial1 was just commented!

ESP's hardware TX0 and RX0 are for communication with PC, and RX1 cannot be used cause it gets program data from the flash memory. I knew this more or less.

But as far as I read somewhere, I could use Serial only to get the sensor data, only the condition is that I use that for only that purpose once the sketch is uploaded!. As you have mentioned similarly in yr reply in the 3rd paragraph.

Well, I am using MQTT to send data from the ESP of the sensor which only sends serial distance data.

But thanks for your reply, I will find a workaround.

embeddedguy  wrote:

But as far as I read somewhere, I could use Serial only to get the sensor data, only the condition is that I use that for only that purpose once the sketch is uploaded!. As you have mentioned similarly in yr reply in the 3rd paragraph.

As I said, this is only possible given the two preconditions - that the USB-serial bridge chip tri-states the lines when the USB connection is not active and you are not intending to communicate to the computer at all. While you have fulfilled the latter, I'm not sure about the bridge used on the Wemos - it could be a CH340 and I don't have any on hand to test.

If the USB-serial bridge does not tri-state, what this means is as soon as the chip is powered but has no data to send to the ESP8266, it could be holding the RX line on the ESP8266 at low. If you then connect your sensor and it tries to send data by toggling high-low in a serial pattern, then you have a logic conflict and the line level is dependent on the internal resistance of the line drivers - essentially when the sensor tries to drive high, you have a "short" through the USB-serial bridge and damage to your sensor is a possibility.

If the bridge tri-states, then it basically "drops off" of the RX line entirely, allowing you to use it. This behaviour is dependent on the model and features of the USB-serial bridge and usually there's not much you can do to change it (bar removing the chip entirely). This is why the softwareserial method makes things easy as you can choose pins that you know for sure are not going to have any logic level conflicts. Of course, you still have to ensure other parameters are correct - baud rate, voltages, etc.

If you suspect the USB-bridge can tristate, you might be able to get it to work as long as you plug the USB into a "dumb" power bank supply. Any USB-communications (e.g. just by being plugged into a PC, Raspberry Pi) might prevent tri-state from occurring even if the virtual COM port is not opened. Sometimes, smart "fast-charge" power banks may cause enough activity on the USB D+/D- pins to cause the bridge to think it has a valid USB connection. Otherwise, leave the USB port disconnected and power the board appropriately via the pins and see if that makes a difference.

- Gough

I had finally decided to use ESP32 based board and now it works nice!