ESP8266 Arduino and serial.disableDTR

388 views
Skip to first unread message

Wayne Holder

unread,
May 4, 2015, 12:59:46 AM5/4/15
to Arduino Developers
I've been testing out the Arduino add-on for the ESP8266 processor/wifi module, as described here:


To upload to the ESP8266, the uploader uses the RTS and DTR lines to put the ESP8266 into load mode.  However, this same mechanism cause the ESP8266 to go into upload mode whenever the serial console is brought up, rendering the console useless.  There is mention of a branch mod to add new serial.disableDTR and serial.disableRTS properties to boards.txt and the ESP8266 add-in linked above tries to use them.  However, it seems that this does not work using 1.6.3 (at least in MacOS 1.6.3.)

Is this something that's still working its way through the approval process?  If so, it would be really great to have this feature, as would greatly simplify development with the ESP8266.

Wayne

Mike

unread,
May 4, 2015, 1:09:11 AM5/4/15
to devel...@arduino.cc
Wayne, it would probably be best to not connect your serial cable flow control to the ESP8266.  Rather, you can manually connect GPIO0 to ground and reset the ESP8266 (power off is fine), then do your download.  Power off, disconnect GPIO0, then when you power back on, your program is loaded.  A bit more manual but I was doing it often last night.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

Roger Clark

unread,
May 4, 2015, 2:01:50 AM5/4/15
to devel...@arduino.cc
Wayne

There are endless discussions about using DTR and other pins on USB Serial to control more than one pin on a microprocessor... (I think this was discussed on the EEVBlog forum a while back)

Basically what may work for you, will not necessarily work for all brands of USB to Serial.

Using one line (DTR I think) - connected to Reset seems to be reasonable stable across different USB to Serial devices, but using 2 lines is problematic.

I'd recommend you only connect Reset, and manually push and hold a switch while the upload is happening, or do like I do and have 2 push buttons

David Mellis

unread,
May 4, 2015, 10:56:50 AM5/4/15
to Arduino Developer's List
I seem to remember that not all operating systems give you control over the DTR or RTS lines.

--

Wayne Holder

unread,
May 4, 2015, 1:16:19 PM5/4/15
to Arduino Developers
As I understand it, Arduino 1.6.3 now uses JSSC to handle serial communication which, in my experience, seems to handle setting and clearing the state of the RTS and DTR lines quite reliably.  Using my own Java code, I've tested this with the FTDI USB serial bridges, the SiLabs CP2102 and the Prolific chipsets and found no problems.  Perhaps someone could revisit this issue, as it would be very useful to have the ability to disable these signals when bringing up the console.  Actually, I often use the Leonardo for some of my projects because it doesn't have this issue.  So, it's not like the behavior is new.

Wayne

Paul Stoffregen

unread,
May 4, 2015, 1:51:40 PM5/4/15
to devel...@arduino.cc
On 05/04/2015 10:16 AM, Wayne Holder wrote:
As I understand it, Arduino 1.6.3 now uses JSSC to handle serial communication which, in my experience, seems to handle setting and clearing the state of the RTS and DTR lines quite reliably.

Sure, it gives you great control over RTS and DTR _after_ you've opened the port.  RXTX did too.

But can you control what happens _during_ port opening?  In other words, can you open the port in such a way that DTR and RTS do not change from their pre-open state?


Wayne Holder

unread,
May 4, 2015, 3:36:04 PM5/4/15
to Arduino Developers
Yes, if you set flow control to NONE (which I believe is the default.)   Here's some Java code that shows one way to test this:

  SerialPort serialPort = new SerialPort(portName); 
  try {
    serialPort.openPort();
    // Set to 115200 baud, 8 bits, 1 stop bit, no parity
    serialPort.setParams(115200, 8, 1, 0);
    serialPort.setEventsMask(SerialPort.MASK_RXCHAR);
    serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE);
  } catch (SerialPortException ex) {
    System.out.println(ex);
  }
  boolean loop = true;
  boolean ledState = false;
  while (loop) {
    // Toggle DTR at 1 Hz rate
    try {
      serialPort.setDTR(ledState ^= true);
      serialPort.setRTS(!ledState);
     Thread.sleep(500);
    } catch (Exception ex) {
      System.out.println(ex);
      loop = false;
    }
  }

Note: this is just a code snippet which was extracted from a larger program that handles and displays events created when the flow control inputs are toggled.

The code will open the serial port, then alternately change the state of DTR and RTS, which I can observe via LEDs connected to each.  If I comment out the two lines that call setDTR() and setRTS() hey each remain off (HIGH, since this is inverted logic.)  Of course, both will return to the off (HIGH) state when the port is closed, but is expected.

Wayne


Álvaro Lopes

unread,
May 4, 2015, 4:01:02 PM5/4/15
to devel...@arduino.cc, Wayne Holder
You misread what Paul said, and the objective of discussion.

Paul said you cannot change settings *before* opening the Serial port. And, when you open Serial port, the "default" settings will be applied.

In you example, all you can achieve is a small pulse on DTR/RTS. But that pulse will still exist, and is enough to reset ESP8266.

Also please note that DTR/DSR are lines not related to flow control at all.

Alvie

On 04/05/15 20:36, Wayne Holder wrote:
> Yes, if you set flow control to NONE (which I believe is the default.) Here's some Java code that shows one way to test this:
>
> SerialPort serialPort = new SerialPort(portName);
> try {
> serialPort.openPort();
> // Set to 115200 baud, 8 bits, 1 stop bit, no parity
> serialPort.setParams(115200, 8, 1, 0);
> serialPort.setEventsMask(SerialPort.MASK_RXCHAR);
> serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_NONE);
> } catch (SerialPortException ex) {
> System.out.println(ex);
> }
> boolean loop = true;
> boolean ledState = false;
> while (loop) {
> // Toggle DTR at 1 Hz rate
> try {
> serialPort.setDTR(ledState ^= true);
> serialPort.setRTS(!ledState);
> Thread.sleep(500);
> } catch (Exception ex) {
> System.out.println(ex);
> loop = false;
> }
> }
>
> /Note: this is just a code snippet which was //extracted //from a larger program that handles and displays events created when the flow control inputs are toggled./
>
> The code will open the serial port, then alternately change the state of DTR and RTS, which I can observe via LEDs connected to each. If I comment out the two
> lines that call setDTR() and setRTS() hey each remain off (HIGH, since this is inverted logic.) Of course, both will return to the off (HIGH) state when the
> port is closed, but is expected.
>
> Wayne
>
>
> On Mon, May 4, 2015 at 10:51 AM, Paul Stoffregen <pa...@pjrc.com <mailto:pa...@pjrc.com>> wrote:
>
> On 05/04/2015 10:16 AM, Wayne Holder wrote:
>> As I understand it, Arduino 1.6.3 now uses JSSC to handle serial communication which, in my experience, seems to handle setting and clearing the state of
>> the RTS and DTR lines quite reliably.
>
> Sure, it gives you great control over RTS and DTR _after_ you've opened the port. RXTX did too.
>
> But can you control what happens _during_ port opening? In other words, can you open the port in such a way that DTR and RTS do not change from their
> pre-open state?
>
>
> --
> You received this message because you are subscribed to the Google Groups "Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc <mailto:developers+...@arduino.cc>.
>
>
> --
> You received this message because you are subscribed to the Google Groups "Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc <mailto:developers+...@arduino.cc>.

david gauchard

unread,
Nov 17, 2015, 4:31:22 AM11/17/15
to Developers
Hi,

There is a simple, generic, proposed working patch that addresses this very question.
With it I am able to run, reflash and reset the esp8266 remotely (me@home, chip@work) without having to press any buttons (which I've been doing so much in the past) like any at328p.


Some people including me would be pleased that this patch be reviewed.

david

Reply all
Reply to author
Forward
0 new messages