ESP8266 digital pin working in reverse manner than mentioned in documentation.

On digitalWrite(D2, 1) or digitalWrite(D2, true) led gets turned off and
On digitalWrite(D2, 0) or digitalWrite(D2, false) led gets turned on.

Well, the blue led on ESP8266 board works different as you figured out by yourself.

you can use this snippet to revert this

var LED1 = { 
        set : ()=> {D2.reset();},
        reset : ()=>{ D2.set();} 
};

Invalid Pin Error

var LED1 = { 
    set : ()=> {D2.reset();},
    reset : ()=>{ D2.set();} 
};

digitalWrite(LED1, true);

 ____                 _ 
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v06 (c) 2019 G.Williams

Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
Flash map 4MB:512/512, manuf 0x20 chip 0x4016

>Uncaught Error: Invalid pin!
 at line 7 col 24
digitalWrite(LED1, true);

Uncaught Error: Invalid pin!

// on
LED1.set()

// off
LED1.reset();

Flash map 4MB:512/512, manuf 0x20 chip 0x4016

better use a _4MB firmware

Thank you for your response.
Can you please suggest me how can I use it with:

digitalWrite();

Correctly?

Sat 2020.09.19

While there isn't any reference link to the suspect documentation, I'd have to guess whether it is actually the documentation that is in error. Also checked out http://www.espruino.com/Tutorials with no luck, which is why providing links to aid those of us attempting to assist is of great benefit.

Unless Pin D2 is an absolute must, it is quite possible that the LED anode is wired to the positive rail, and the cathode to the pin, (D2?) in which case, to turn it on will require dropping voltage across it. To do so will require sending a vaild 'false' or '0' as was discovered when detailing #1 post. This may seem counter intuitive, but how the parts are wired will determine the correct code needed.

Sparkfun has some great tutorials. A simple Google search will reveal.

So basically we need to figure out manually what type of code will work?
This can be a nightmare for a new user.

Sat 2020.09.19

Hi @bk, I sense a bit of frustration, but please look at it from my end. I have no reference to what it is you feel is incorrect. I suggested the inclusion of a link, and that still hasn't been supplied. So from my view, not being able to 'see' what it is being attempted, nor am I able to 'see' how the circuit is wired. Now, through experience, I might be able to visulaize what is being attempted, but again, I'm not going to just guess.

As is in the documentation, it is suggested that a new user start with an 'Official Supported Board' as the evolution of Espruino and it's development along with all the documentation were created specifically for Original boards that @Gordon developed. From that complexity we can't just expect the documentation to work for all boards out there.

See note beneath the board listings:

http://www.espruino.com/Other+Boards

There are several in the community willing to assist, and @MaBe has extended his expertise using the ESP8266. Now having several years under my belt, I understand the explanation, but a lot of assumptions have been made. Mine from the side of how things are wired, as it appeared to me to be a hardware thing, more so than that of software.

'So basically we need to figure out manually what type of code will work?'

To answer this accurately, will require me to look at what documentation is being considered incorrect. It is likely (yes another S.W.A.G. response) that the documentation was for a specific circuit, and the attempt being made now isn't exactly that same circuit.

Actually I am not frustrated but trying to figure out how can I use esp8266 with espruino firmware, especially digitalRead() and digitalWrite() correctly. Anyways, it seems to be a bit weird that on

digitalWrite(D2, true)

or

digitalWrite(D1, 1)

LED does gets turned off. I tried on multiple esp8266 board but same results.
And

D2.set();

and

D2.reset();

Feels much more inconvenient but it works as mentioned by @MaBe.
And I am referring https://www.espruino.com/Reference
for documentation.

Sat 2020.09.19

Thank you for the link @bk, now we are on the same page. On a hunch, it appears the onboard LED is being used??

While this isn't your particular board, several manufactures, including the knock-offs may have a slightly different PCB routing, there may be some insight garnered from the sister Espruino WiFi schematic from the link at:

https://www.espruino.com/WiFi
which leads to:
https://github.com/espruino/EspruinoBoard/blob/master/WiFi/pdf/espruino_wifi_sch.pdf

Note how the Red and Green LEDs for the Espruino are wired to it's pins in comparrison to how the ESP12 Blue LED is wired to Vdd. Should the board you have be wired in this fashion, the use of digitalWrite() would have to be inverted

Also, when reading the reference: (and I had to learn this after quite some time)

https://www.espruino.com/Reference#l__global_digitalWrite

please note the Right Facing arrow adjacent to the heading 'digitalWrite' which when clicked, takes one to the source:

https://github.com/espruino/Espruino/blob/master/src/jswrap_io.c#L244

I had hoped to locate the definition for LED1, but my configured PC that had easy access isn't at my disposal, and I wasn't able to quickly locate the file, but it most likely is within:

https://github.com/espruino/Espruino/tree/master/src

The intent was to show how in source that snippet funtioned for the defined LEDs with official boards.

I did however locate a tutorial that was for the Pico (~circa 2017) that demonstrates what (then) was the suggested snippet for the onboard LED, which is slightly different than using digitalWrite() with an off-board LED. Maybe that will clear up a bit of the confusion.

http://www.espruino.com/Control+LED+with+Button

Ref: 'it seems to be a bit weird that on . . . LED does gets turned off'

See explanation #7 post and onboard vs off-board above

digitalWrite() is an instruction to set the specified GPIO pin to a specific state. As the controlled device is unknwon before the code (that you will create) is written, it can't be Ass-U-Me'd that the unknown device is an LED or how it is wired. It could just as easily be a GPS module or a Temperature sensor, for instance.

The Espruino reference is accurate for official boards. The ESP8266, being a community port and manufactured by parties other than Espruino, may wire things up differently as @Robin has mentioned several times.

You seem to be under the impression that a "1" or a "true" means on, while a "0" or a "false" means off. Those really are just conventions, and will do different things depending on how things are wired. Sending "true" just means pulling the gpio up, while sending "false" means pulling it down (to ground).

There's a good explanation on stackoverflow: https://electronics.stackexchange.com/questions/20740/why-are-pull-up-resistors-more-common-than-pull-down-resistors which talk about switches; however since we're talking about LEDs one possible reason is that that in this case LED is wired to be pulled up in hardware; hence when setting the gpio low the LED turns on (because the circuit is complete) while setting the gpio high the LED turns off (because there is no voltage potential anymore).

We don't have the schematics so we can't know for sure. The official boards have schematics of course so we can inspect that and know for sure.

That said, there are ways to "invert" the logic so it's more "intuitive" but that involves possible issues with backwards compatibility on future firmware upgrades. Another one is to update the documentation on the ESP8266 specific page to mention this fact (then again, with all the different manufacturers of ESP8266 modules how do we know for sure which one we're working with?)

I just found another possible reason. I think that LED is usually used as a TX indicator by the default AT firmware (it flashes whenever there's data being sent).

https://electronics.stackexchange.com/a/78102

Apparently, TX is set to high by default. If the LED were connected with TX and ground, that means the LED would be on all while the chip is inactive, which would be horrible in terms of power consumption because you're just using power even when there's nothing being done.

So in this case, the LED is wired to VCC which means no voltage potential between the two. Then when TX goes low (e.g. the mcu starts transmitting data), the LED turns off. It blinks of course because the TX pin goes low and high alternately, but at the end of a transmission it defaults to high again, and the LED remains off.

hi @bk, when accessing a pin directly as you do with digitalWrite(), just take a look at the schematics/wiring and all will be clear to you. It is not what you feel is right but how the LED is wired.

When wiring looks like in the left picture, it works like (Espruino) documented, because the Espruino boards' LEDs are wired this way. (Pin is configured - pinMode() - as 'push/pull' - "output"; 'pull - "opendrain" - will not work).

When wiring looks like in the right picture, it works like the blue LED on the board with the ESP8266EX, since it is wired this way. Most of the time LEDs are actually wired this way, because the simplest NPN bipolar / N ...MOS... (pin) driver is implemented to work as Open Collector / Open Drain configuration. (Pin can be configured - pinMode() - either way: 'pull' - "opendrain" - or 'push/pull' - "output").

Pics are modified from pic 'borrowed' from http://sheepdogguides.com/arduino/aht0led.htm (Sorry @MaBe, no Strichzeichnungen today). Any Web search of how to drive an LED will provide you with explanation. With a resistor and LED at hand you can experience both cases yourself.

Enjoy your bright LED day...

PS: sequence of LED and Resistor do not matter.

1 Attachment