The DTR Line and ESP

Hitting an issue with ECLIPSE on the PC and the TERMINAL program.

So in our little board we’re using an ATTINY85 to control the programming process for the ESP12s…  

I have some issues..

If you’re using GPIO as an output to a relay… this whole process can cause the relay to click… the last thing you want to do if you have a lamp or heating system on that output.

Keeping things simple with 5v relays you really need to use an NPN transistor so just basing stuff on the 3v line is out.

In the ECLIPSE programming environment when programming, DTR goes low as does RTS, then RTS goes high, then DTR goes high then you program the chip. You can control all of that in ESPTOOL.PY

In the TERMINAL program addon for Eclipse, opening the terminal causes DTR to go LOW, HIGH, and LOW and STAY LOW!!!!

So my thoughts are to buffer the GPIO output to the relay via the TINY. On powerup the TINY output to relay is LOW…

So if the TINY sees DTR go low, it would pull both DTR and RESET LOW… if DTR STAYS LOW for more than a second… GPIO-0 is floated (Tiny pin becomes input) then RESET is floated (tristate on the Tiny) and  from that point on the relay output follows the input from GPIO  until DTR goes high then low and we start again.

If on the other hand DTR goes low then high, we assume programming, release RESET first then GPIO-0…  then we wait for no serial activity for a couple of seconds before resetting again and then following GPIO-0….

Make sense? I can’t find any way to control DTR on that Terminal program so this is the best I can come up with for now…



6 thoughts on “The DTR Line and ESP

  1. I like the idea of buffering GPIO-0 through the tiny. Instead of just keeping it low, how about recording GPIO-0's value when DTR goes low, and then not changing the output until the entire cycle is done? Then you don't have to guess what the "safe" setting on GPIO-0 is for whatever the user hooked up.

    The issue will be that the TINY will introduce a slight delay into whatever you do with the GPIO-0 output in normal operation... and perhaps strange timing issues.

    Since you have to put a separate uC on there anyway, it's too bad there aren't more IO pins on the ATTINY85. How about /slightly/ increasing cost and putting a larger uC there? Like an ATTINY87? Actually, the ATTINY88 costs less than the 85 right now and has more IO pins.

    Use one pin that is always set in the opposite polarity, which allows GPIO-0 to be used as a differential piezo driver for double the volume.

    Or dedicate GPIO-0 as the "multi-use" pin, and use all the extra uC IO pins as IO expansion. The ESP-8266 can be programmed to send serial data to the uC which then controls the extra IO pins.

    Different firmware packages on the uC could do timing specific things like servo control or... I don't know... carefully drive LED light strips with the exact timing needed. ,o)

    Wasn't there some complaint about the ESP-8266 not doing analog very well? The 88 has 8 ADC's and 2 timers for PWM.

    You could add code to the ESP-8266 to reprogram the ATTINY88... Then you have a fun sequence:
    1. Upload new code (including a new hex file for the ATTINY88) to the ESP-8266. The ATTINY88 manages the reset and GPIO-0 copy as above.
    2. Once finished re-programming the ESP-8266, it then turns around and resets the ATTINY88 and downloads the new hex file to it.
    3. when the ATTINY88 is reset, the ESP-8266 uses it for intelligent io expansion. Sending values to it via GPIO-0 serial for PWM settings, pin high / low, talk to LED strip, I2C device, etc...
    4. if you want input from the ATTINY88 (e.g. A2D) then you jumper one of the ATTINY88 serial out pins back to another GPIO pin on the ESP-8266... or go to I2C communication between the two.

    Ah... crazy ideas are what I love to put out there. Take with 2 grains of salt and call me in the morning.

    1. All great ideas James.... will pass them on and you never know, at some time in the future something might appear and we'll all remember it started here 🙂 The ATTINY is in fact as I've just realised having actually talked to my pal who added it to the board, merely intended as a one-off means to blow the chips. Personally I like the idea of a separate adaptor board. Of course now I've gone and soldered the ESP12 into the board. Groooooaaaann.

  2. To maximize the efficiency and reliability of the final device, my inner designer recoils from sticking another active device in the path permanently, just so you don't have to occasionally short GPIO to ground manually to flash a program.

    To me, the following would be preferable:
    - have a designated dev board or two, with the AVR Tiny wired as you've suggested, or some other scheme for temporarily disabling the relay. This is the board you will beat on, flashing repeatedly while developing and refining the firmware
    - the production boards - the ones you will be putting into regular service - don't really have a need for the Tiny. All they really need is a jumper or switch to pull GPIO low when you flash them (just occasionally, one hopes). It could be a two position jumper or switch where A is normal (GPIO0 drives the relay) and B to flash (GPIO0 to ground)

    1. Turns out I picked this up a little out of context - indeed my friend Aidan who made the board - that's just what he intended - to have a couple you could program chips up with.... so - you are both (Ken and Ian) right! Not enough sleep 🙂

  3. I think I'm with Ken. Programming these things isn't THAT difficult. If pushing a button is too much you might stick some jumpers on your board & attach the ATTiny etc via these?

  4. Maybe I was confused... I /always/ thought the point of this was as a carrier for the ESP-8266 to provide the things it doesn't, like relay drive, evenly spaced 0.1" connectors, power supply regulator, etc... A board that is the "Arduino" of ESP-8266... As the Arduino Uno is to the AVR, this board would be to the ESP-8266. So finding "cute" and "clever" uses for a co-processor beyond just programming would be valuable in that case. Uses that are very flexible and provide, again, functions the ESP-8266 isn't good at by itself.

    I was thinking of the people who see the Ras-PI as a replacement for the Arduino (or vice versa) when really, they do two totally different things. The Pi is better at multi-tasking, non-time critical, higher level processing, and the Arduino is better and IO, time critical, low level processing. The Pi is like your conscious mind and the Arduino is like your motor cortex.

    So I was pushing the idea of putting out a board with that same "higher mind" with "lizard brain" division of labor.

    If it's just for development, then yeah... pushing the button just isn't that hard.

Comments are closed.