Electronics project notes/ESP notes

From Helpful
Revision as of 13:24, 24 March 2020 by Helpful (Talk | contribs)

Jump to: navigation, search
This is for beginners and very much by a beginner.

It's intended to get an intuitive overview for hobbyist needs. It may get you started, but to be able to do anything remotely clever, follow a proper course or read a good book.

Some basics and reference: Volts, amps, energy, power · Ground · batteries · resistors · changing voltage · transistors · fuses · diodes · varistors · capacitors · inductors · transformers · baluns · amplifier notes · frequency generation · skin effect

And some more applied stuff:

IO: Input and output pins · wired local IO wired local-ish IO · · · · Shorter-range wireless (IR, ISM RF, RFID) · bluetooth · 802.15 (including zigbee) · 802.11 (WiFi) · cell phone

Sensors: General sensor notes, voltage and current sensing · Knobs and dials · Pressure sensing · Temperature sensing · humidity sensing · Light sensing · Movement sensing · Capacitive sensing · Touch screen notes

Actuators: General actuator notes, circuit protection · Motors and servos · Solenoids

Some stuff I've messed with: Avrusb500v2 · GPS · Hilo GPRS · JY-MCU · DMX · Thermal printer

Audio notes: basic audio hacks · microphones · amps and speakers · device voltage and impedance, audio and otherwise ·

Less sorted: Common terms, useful basics, soldering · Microcontroller and computer platforms · Arduino and AVR notes · ESP series notes · Electronics notes/Phase Locked Loop notes · mounts, chip carriers, packages, connectors · signal reflection · pulse modulation · electricity and humans · Unsorted stuff

See also Category:Electronics.

Hardware, and the simplest boards

WiFi-capable microcontrollers.

You can run code on the microconroller alongside the wifi code.

It is also sometimes used standalone, with another microcontroller using it for the wifi.

See Electronics_project_notes/Microcontroller_and_computer_platforms#ESP_series for wider context.



  • Wifi 11b/g/n (no bluetooth)
  • ~160KB SRAM
  • often at 80 MHz (can be run faster)
  • 17 GPIO, 2 SPI, 2 I2S, 2 UART, 1 I2C, and a 10-bit ADC (pin overlap)
  • no hardware PWM

Note you effectively share the CPU and must yield time to the wifi code at least every few hundred ms(verify).

ESP8266 itself is a SMD IC and you probably want to get it on a board helping you along, (see e.g. http://esp8266.net/ for details), because at the least you'll want it connected to flash. It's hard to get it without unless you buy just the chip in bulk, though.

Initially from espressif, who had board variants called ESP-WROOM-something.

More common are the Ai-Thinker ones and derivatives, often one of:

  • ESP-01 - exposes little useful IO, used mostly as a wifi slave board
  • ESP-05 - also exposes little IO. Allows better antenna than 01. Discontinued?(verify)
  • ESP-12 - exposes more things, making it more useful as a standalone uC, though physically it's not so easy to use
  • ESP-201 - easier to use on a breadboard
...and yeah, a bunch more of these exist.

...or a more complete prototyping board, such as the NodeMCU or WeMOS or HUZZAH Most build on the ESP-12, and add things like USB-to-serial and power regulation. (see below)

The amount of flash will vary.


Compatible with ESP8266, has flash integrated, making it even smaller.

There seem to be some variant boards here too, at least:(verify)

ESP-M1 - antenna connector
ESP-M2 - onboard antenna
ESP-M3 - onboard antenna


See also:

see also

Larger boards

Note that particularly the cheaper ones have cheap USB-to-serial, often one of:

  • CH340G (also CH340).
Driver may or nay not be installed automatically on all OSes, so if not detected you need to find the driver and possibly some instructions.
Datasheet: https://cdn.sparkfun.com/datasheets/Dev/Arduino/Other/CH340DS1.PDF
  • CP2101 exposes a few more pins(verify)


Adafruit huzzah:


  • The board has a 500mA regulator that you should feed 4-6V
V+ and Vbat both go to it, separated via Schottky diodes
and V+ is also on FTDI header, so that you stably can power the chip while programming it (...from a powered hub / port)
if you have your own regulation, you can bypass the LDO regulator by connecting the LDO pin to ground


  • TX and RX are used for bootloading, and for serial control (exposed in two places on this board, to make FTDI plug easier)
RX is 5V safe (and Vcc goes to the regulator) so you can use a generic 5V serial cable


WeMos D1 is a Arduino-sized board, partially compatible

and a revision "D1 R2", with minor difference in pins between the two.

D1 Mini, specifically:

D1 Mini Lite
1MB Flash
PCB antenna
D1 Mini
4MB Flash
PCB antenna
D1 Mini Pro
16MB Flash
Lithium battery pin, charger chip
PCB antenna + Antenna connector

D32, based on ESP32

Lithium battery pin, charger chip
D32 Pro
Lithium battery pin, charger chip
MicroSD socket

(with some revisions)


NodeMCU devkit

NodeMCU itself refers to the firmware. It'll run on any ESP based board, really.

For clarification, there is also a breadboardable piece of hardware called the The 'NodeMCU Devkit' is the name of a specific board [1],

There seem to be three revisions of this[2].(verify)


On firmware

flashing new firmware

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


came from the community, now also adopted by espressif

nodemcu pyflasher

GUI that is a wrapper around esptool.py
easier to use
you need to install python, and the wxpython package (e.g. through pip)

ESP Flash Download tool


On flash mode

Apparently [3]

ESP8266 ESP-12 boards uses DIO
most other ESP8266 board (e.g. ESP-01 and ESP-07) use QIO
ESP8285 uses DOUT
ESP32 uses DIO

On some bare-bones boards you may need to manually get it into programming mode.

e.g. on ESP8266-01 you need to tie GPIO0 to Gnd (verify)

What's this address stuff?

In basic cases you put the whole firmware at the start of flash (0x0),

In specific cases you have distinct parts that go to distinct addresses, but you'll probably get instructions for it.

See also:

Firmware alternatives

AT commands firmware

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

The AT commands firmware (Espressif?) is useful if you want to add WiFi to an existing microcontroller with just the RX and TX serial pins, and controlling how it communicates.



https://bbs.espressif.com/viewtopic.php?f=10&t=362 - for espressif firmware?

NodeMCU firmware (Lua)

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

The NodeMCU firmware (built on top of Espressif's SDK, and primarily for the ESP8266) is firmware that can be seen as a Lua interpreter leveraging a given set of C libraries.

Since people can add their own C libraries, and you can build with any set, there are many variants on the same basis.

The easier way for tinkerers is to use the online build service: https://nodemcu-build.com/

A little more controlled, but more work, is https://github.com/nodemcu/nodemcu-firmware

Using that firmware

Once you've got that loaded, you can use one of various tools to uploading lua files, which itself is (relatively basic) serial-port stuff.


java based IDE, a little fiddly but it's a GUI

luatool [4]

uploads Lua files to ESP8266 modules running nodemcu firmware


up/down lua files, manage filesystem

esp8266 lualoader [5]

...and various other tools people have built.

See also:

Variations on the last

this page lists variants on idea of the Lua firmware but for other languages, like python, JS, Basic, Forth, Lisp, and support from some other embedded platforms.

The idea ends up being the same - flash its firmware, later upload code via the serial port (and possibly over the air)



Some notes

Lua firmware notes

Waiting answer from ESP - Timeout reached. Command aborted

You're probably using ESPlorer. This seems to be a bug related to use of CR-stlye newlines[6] (where the firmware expects CRLF(verify)), but only on specific commands. It's particularly file transfers that will be broken.

This could be fixed on both sides, but the easier may be to get a newer firmware build (verify)


On the watchdog (a.k.a. "while loops cause reset" and such)

Like many people, I found out that there's a watchdog timer -- by writing a function that stayed in control too long.

If you catch enough of the next boot's output, you'll see something like:

rst cause:2, boot mode:(3,6)

which you can also get via node.bootreason(). Those values mean a wdt reset.

If you want to feed the dog, use tmr.wdclr(), but note that if you write everything event-style there is rarely or never a need (and you will have less trouble with wifi and some other things)

If you're writing one-off debug code, you can get away with using tmr.delay() in that loop(verify), which seems to yield to the background (and/or feed the dog) too. delay() is generally a bad idea, though. (verify)

See also https://nodemcu.readthedocs.io/en/master/modules/pwm2/#troubleshooting-watchdog-timeouts

Current draw and sleep

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


~75mA with wifi on and idle-ish CPU
down to ~15mA with modem-sleep (WiFi radio waking up only occasionally)
~1mA with light-sleep (modem sleeping/off, CPU off between wifi(verify)),
~0.1mA with deep-sleep (which is roughly 'waiting to be rebooted from a pulse on RST pin')

Powering considerations:

Startup seems to include ~400mA for ~40ms[7] (RF calibration maybe?). Which is is just once and short
RF transmission peaks (connection, sends) may be ~200mA

(both shouldn't matter if there's any noticeable capacitance there)

On the sleep modes:

  • no sleep
  • modem sleep
keeps the CPU on, sleeps the wifi circuitry only
Since it times the sleep between AP beacons this applies only once connected to an AP
should average ~15mA when not transmitting
seems to often be the default
NodeMCU: seems to apply automatically once we're connected to an AP(verify)
  • light sleep - pauses modem, system clock, CPU
(cannot enter light sleep if wifi suspended)
woken via configured GPIO or timer(verify) which takes ~3ms
NodeMCU: node.sleep() but NodeMCU apparently disables light sleep by default
  • deep sleep leaves on the RTC and nothing else
can apply when not maintaining a WiFi connection.
woken up a pulse on RST, which can come from our own RTC (if GPIO16/WAKE/D0 is wired to RST)
apparently there's a maximum to each interval[8]
there are flags controlling
whether wifi will be initialised after such a sleep (you can avoid a current spike if you don't need it)
whether a calibration will be done (which you want after longer sleeps(verify))
NodeMCU: node.dsleep()



Voltage and damage

Power should be 3.3V. (Powering from 5V power won't fry it immediately, but is likely to shorten lifespan, some people report sooner rather than later (and seemingly frequently it's the flash next to it that fails first)

The ADC gets damaged by voltages above 1V, so use a voltage divider.

Putting 5V on GPIO pins (i.e. the question whether they are 5V tolerant) is a more interesting question.

It depends a little on what you're connecting and how:

The datasheet says: "All digital IO pins are protected from over-voltage with a snap-back circuit connected between the pad and ground. The snap back voltage is typically about 6V, and the holding voltage is 5.8V. This provides protection from over-voltages and ESD. The output devices are also protected from reversed voltages with diodes."

The first part means 'more than 6V will not work' (it triggers protection).

The implication of the whole is a little fuzzier - basically, 5V at small and/or intermittent currents will be dealt with by those protection diodes.

...small/intermittent currents because they are tiny and you can burn them. Relying on them without doing some math is a bad idea, and the "5V not recommended" probably comes from this.

That said, there are plenty of cases where you can control this fine. If you can a series resistor on that input to ensure these diodes never see much current it should be fine, and in some cases even that isn't necessary.

...then again, using one whole extra resistor more means you can make a proper voltage divider. (note high-speed communication often needs a little more care).

Using the 3.3V GPIO to output to things expectng 5V TTL levels is fine. It may not always work due to voltage levels (5V TTL is high is above 2V so fine; 5V CMOS is high above 3.7V so won't work. The thresholds can vary a little per device anyway, so check datasheets.).

On WiFi