4
Sep

AMMAURO #3 – ESP8266 IoT 2017, native C SDK Getting Started for Windows, Mac & Linux


Right, getting started with the ESP8266! Huh? Well that hardly seems rele… what?? What? What does that mean?? When I wanted to write native code and upload
my own firmware to the ESP-01 and NodeMCU modules, I embarked upon a journey through
a lot of different platforms and frameworks, out-of-date or incomplete documentation, and
a learning curve that was at odds with impatient need to write my own code and get it running
on the device. In this video I will show you in very clear
steps how I overcame this and went from “zero to hero” and got both of these modules running
my own tiny ESP8266 firmware natively. This works on Windows and macOS the same way
thanks to a tidy little Linux virtual machine which I show you in my previous video how
to set up. If you’re already running Linux, this video
should be a breeze, and if not it should be easy for you to follow along and get up to
speed and I’ll be pretty clear about everything as we go. You can follow this guide and get your system
ready even if you don’t yet have any ESP8266 hardware, but the modules that I’ll refer
to are the ESP-01 which you can get for as little as $2 on eBay and a clone of the NodeMCU
which you can get for as little as $6 on eBay, based on the ESP-12E module. The NodeMCU requires only a micro USB cord
to plug into your PC, while the ESP-01 needs a couple of other parts which I’ll explain
later in the video. I’ll show you how to build and upload firmware
to both the NodeMCU and the ESP-01 respectively, so let’s start with an overview of those two
parts. First let’s take a look at the tiny ESP-01
module. This board’s design is one of the earliest
released, but due to its ubiquity and low cost, it’s still pretty popular. It features the ESP8266 microcontroller with
integrated logic for handling Wi-Fi and TCP/IP. Adjacent the microcontroller you have the
Flash-ROM for storing program code and data, which in the blue solder-mask version of this
board is usually half a megabyte, but there’s also a 1-megabyte version identified by a
black solder-mask. You also see the integrated Wi-Fi antenna
and other support circuitry at the top, and the board also features a power LED, a serial
communications indicator LED which can alternatively be used for basic diagnostics, and 8 header
pins at the bottom for power, programming, and some basic digital I/O. Like most ESP modules this device can be run
autonomously, so long as you have a meaningful firmware loaded, and a 3.3-volt power supply. And that voltage is important because the
device is definitely not 5-volt-tolerant. Now, on its own you can’t plug this device
directly into your PC, so you’ll need some sort of basic programming jig, and I’ve got
a very simple example of one which I’ve made here. This just bridges the ESP-01 module to a cheap
USB-to-serial adapter, and includes a couple of extra buttons on the back for putting the
device into programming mode. I’ll explain the design of this board, as
well as the correct programming procedure, later in this video. Now compare the ESP-01 with the NodeMCU board,
or in this case a cheap Chinese clone, and you’ll notice that the ESP-01 has a counterpart
on this board, known as the ESP-12E. It’s effectively the same hardware but the
notable difference is that it has this RF shielding can, which conceals usually a larger
Flash-ROM, as well as extra pins around the edge which are broken out to header pins by
the NodeMCU as GPIO pins. The NodeMCU also includes an integrated USB-to-serial
adapter which is usually based on the CH340G chip or the CP2102 and there’s also a voltage
regulator which supplies 3.3 volts from USB to the rest of the board. You’ll notice that the board also has a couple
of pushbuttons, one for manually resetting the device, and another for manually putting
it into programming mode, but if you’re using the correct software in conjunction with the
USB-to-serial adapter on the board, you’ll find that this is handled for you automatically. The NodeMCU is intended to be used with a
breadboard but depending on the revision of the board you’ve got, you may find that it
doesn’t fit into a single breadboard and so I usually straddle it across two, to get the
maximum number of columns available for wiring. Now that we’ve got an overview of a couple
of different types of modules – and there are many more – we’ll go through the procedure
of setting up a development environment so that we can build firmware and upload it to
the device. At this point I should reiterate that it doesn’t
matter if you’re running Windows or in this case macOS because I’m going to be using a
virtual machine running Ubuntu Linux. My previous video shows you how to set this
up so if you haven’t seen it already I suggest you go and check it out now so you can follow
along more easily. Otherwise, let’s get on with it! Launch VirtualBox and do a “Detachable Start”
of your VM. The virtual console comes up and Linux goes
through its boot process, landing at the login screen. Now log in as your user. For me this is literally just “user”, and
then run “lsusb”. This lists USB devices that Linux has attached. We’ll now monitor the kernel log to see how
the system will react as a new device gets added, so to do that run “tail -f /var/log/kern.log”. “-f” means that we want to follow the tail
of the log file as new messages get added. We can see some messages left here from the
boot process so hit ENTER a couple of times for visual separation. Click the USB button in the status bar and
you’ll see a list of the host computer’s USB devices that you can link through to the VM. At this point I’ll plug in the NodeMCU board,
and don’t worry if you’re using the ESP-01 or a similar module, because I’ll show you
later in the video how to apply these instructions differently. With the NodeMCU now attached, clicking the
USB button again should reveal an extra device in the list, and while the name for you may
differ, mine identifies as “QinHeng Electronics USB2.0-Serial”. When I click on that it instructs VirtualBox
to hand control of the USB device over to the virtual machine, and we can see Linux
now springs to life and identifies the device as “USB2.0-Serial” and tells us that it’s
now attached on “ttyUSB0”. We can make this happen automatically in future
by going to the USB button and clicking “USB Settings”, then on the right-hand side clicking
the “Add” button and choosing the respective device. VirtualBox will now remember that we’ve associated
this device with this particular virtual machine, such that the next time it’s plugged in, it
will automatically pass it through. We’re done with the kernel log now, so hit
CTRL-C on your keyboard to break out of watching it, and run “lsusb” again and we can now see
the device in the list. We can also have a look at the “device file”
by doing “ls -al /dev/ttyUSB0”. This is the system’s interface to the device,
implemented as a serial port, thanks to Linux’s in-built device drivers. We can see here that it’s owned by the “dialout”
group, which means that in order to get control of it, our user must be a member of that group,
and to ensure that that’s the case run “sudo adduser”, then our username of “user”, then
the group name, “dialout”. Hit ENTER, supply your password, and the change
has now been made. But note that the change won’t take effect
until we start our next login session, or “shell”. We’re finished with the virtual console now,
so type “exit” and you can optionally hide it by going to the “Machine” menu and selecting
“Detach GUI”. Though it’s hidden, it’s still running in
the background. For what comes next we’ll use a terminal program
with an SSH connection through to the virtual machine because it makes things easier. On Windows you can use “PuTTY”, and on a Mac
you can either use the built-in Mac “Terminal” utility, or my favourite, “iTerm2”. Launching iTerm we land first in the Mac shell,
so we need to connect through to the virtual machine by running “ssh [email protected] -p2222”. This works according to the instructions in
my previous video, under the assumption that VirtualBox is configured to make the host
computer listen on TCP port 2222, and forward it through to the guest VM’s port 22, for
SSH. You use the same parameters with PuTTY, but
entered differently through the GUI. Once we’re logged in run “lsusb” again to
verify that the device is still there and in order to communicate with it now, we’ll
need to install a serial terminal program called “minicom”. Run “sudo apt-get install minicom”, accept
its dependencies by hitting ENTER, and then when it’s installed, run “minicom –device
/dev/ttyUSB0”. Inside minicom we can now hit CTRL-A, and
tap Z, to bring up a help screen of various options and functions available inside minicom,
and we can see Communications Parameters can be accessed by tapping P. In here we can see
that the default speed that minicom communicates with its serial ports is 115,200 bits-per-second;
what’s known as the “baud rate”. And it’s using “8-None-1 encoding” which I
won’t explain here, but suffice to say it’s most common. Hit ENTER to dismiss this screen, and note
that you can go back into it directly just by hitting CTRL-A, and then tapping P, without
first going through that help screen. Now I’m going to press the “Reset” button
a couple of times on the NodeMCU board and we can see that it’s apparently sending some
garbage through to minicom, and it turns out from my prior testing that this particular
board came pre-loaded with firmware that expects to communicate at a much slower 9600 bits-per-second. So hit CTRL-A and P again to go back into
the communications parameters, and while you could test various speeds, I’m going to just
go straight for 9600. Now when I press the “Reset” button on the
NodeMCU board, I get a more-meaningful response. Don’t worry if you can’t replicate these results
because there are many factors that may affect this, and in the next steps we’re going to
install some specialised software that allows us to take direct control of the NodeMCU and
the ESP modules, and re-program them. We’re done with minicom now, so hit CTRL-A
and then just tap X to exit. Launch a web browser now and Google for “esp-open-sdk”
and it’s the GitHub “pfalcon” page that you want. This is an Open-Source effort to bundle together
a number of firmware development tools with the official Espressif ESP SDK. Scroll down and you’ll see some prerequisites
for Ubuntu, which I actually have already installed, but I’ll go through the motions
here anyway, so that you can follow along. First we’ll copy this command here and then
paste this into our Linux shell. To paste, you can just right-click in PuTTY,
and it will paste immediately, and on a Mac you can use the Command-V keystroke, or you
can right-click and select “Paste”. There’s nothing that it needs to do on my
computer here so it completes relatively quickly, so I’ll now go back and I’ll copy and paste
the other command into the shell as well. Now that we’ve got the prerequisites, we’ll
go and fetch the actual esp-open-sdk repository, but first we need a place to put it. So I’ll make a directory called “projects”
by doing “mkdir projects”, and then I’ll change directory into that by doing “cd projects”. Back in the instructions now, as we scroll
down, we can see the “git clone” command so I’ll copy that and then paste it into the
shell, and this will start downloading the repository as well as a number of other linked
repositories that it depends on. At the end we’ll go into the repository source
code by doing “cd esp-open-sdk”, and then back in the instructions we can see that there
is the default “make” command used for building the actual software tools. So we’ll go back to the shell and we’ll run
“make”. This kicks off the longest process, which
is in the order of 30 to 50 minutes, but I’ve sped it up about a hundred times, so that
you don’t have to wait. It’s doing a lot of work in the background,
building all the different components and downloading the actual Espressif ESP SDK. At the end there is one extra step that we
need to do that it tells us about here, and that is to extend the system path so that
the system is able to actually find the commands that it’s now built for us. Rather than run this every time, I’ll just
add this on to my login script, and to do that, do “echo” and then a single quote, and
then copy and paste this line, and then a closing single quote, and a double right-angle
bracket, which means that we want to append onto a file. That file is in my home directly, which I
can signify by doing “~” and “/”, and then the name of the file is “.profile”. Now that that’s done, I can exit my shell
and I’m back in the Mac shell, then tap the up arrow to bring back the “ssh” command,
log back in, and now when I do “echo $PATH”, my login script has run, and that new location
is now prefixed on the system path, so the system can find these utilities that have
been built. The main utilities that I need begin with
“xtensa” so if I type “xtensa”, I can then use a feature of the shell called “tab completion”,
where if I press the TAB key once, the system will try and figure out what I mean. We can see here that it gives me an incomplete
command, so if I hit the TAB key two more times, it will give me a list of available
options, and the one that I’m looking for here is “gcc”. So if I append “gcc” now, and do “–version”
and hit ENTER, that command runs successfully so I now know I’m able to use the compiler. Now let’s build an example firmware. Do “cd projects/esp-open-sdk” and run “ls
-al” to have a look around. Go into the “examples” directory and you’ll
find “blinky”. In there, we’ve got the C source code, “blinky.c”,
for an example firmware that just blinks the LED on the ESP module, and it’s accompanied
by “Makefile”, which is a build script used by the “make” utility. If we run “make” we would expect it to just
build the firmware, but instead you may encounter this error where it tells us that the “memchr”
function is not defined. It turns out this is because this particular
example was designed to be used with an older version of the Espressif ESP SDK, but we can
get around that by just editing the “Makefile”, so run “nano Makefile” – “nano” is just
a Linux text editor – and it’s towards the end of this LDLIBS line that we need to add
something. You can see here a number of “-l” parameters
with various libraries specified, such as “-lphy” towards the end, so after that one
add just “-lcirom”. “cirom” is the Standard C library, but implemented
inside the internal ROM of the ESP8266 chip. Now that we’ve made that change, we can do
CTRL-O on our keyboard to write out the file, followed by CTRL-X to exit. And when we run “make” now, it goes through
and apparently it succeeds. So run “ls -al” and you’ll see four new files
in there. There’s a couple of intermediate files, but
the main ones we’re interested in are these two “bin” files which are two fragments of
the firmware that would need to be uploaded to any given ESP module. We can upload firmware to the device with
a program called “esptool” so type “esptool” and hit TAB, and you’ll see that it’s got
“.py” on the end, and then do “–help” and you’ll see a list of sub-commands. Now let’s just start with a simple one: “esptool.py
chip_id”. It gives us a result, indicating that it’s
working properly. If this doesn’t work for you though, I’ll
show you some troubleshooting shortly. Otherwise though, I’ll carry on with some
other examples. Let’s try “flash_id”. This tells us information about the Flash-ROM
that’s on the board, so that we can look that up to find out its size. I’ll try another: “read_flash”. It tells us here that we need extra parameters
so I’ll put in “0”, indicating that we want to start reading from address 0, and that
we want to read, say, 12,000 bytes, and put it in a file called “test.bin”. That works, and the LED blinks a little bit
longer as it reads data off the device, and we can now have a look at that “test.bin”
file to see what’s in it, so we can run “hexdump -C test.bin” and then I’m just going to view,
say, the first 10 lines of output so I’ll do a pipe delimiter, and use “head -10”, and
we see that data with the binary information on the left-hand side, and an attempt at an
ASCII representation on the right-hand side. Now I mentioned troubleshooting. If you’re having some trouble communicating
with the device – say, a given process doesn’t start or breaks half-way through – then
you can actually slow down the rate of communication. You’ll see that esptool supports some parameters
such as changing which specific serial port to use, or the baud rate, or data rate. So, I can do an example here of esptool with
“–port /dev/ttyUSB0” – let’s say it doesn’t find your serial port by default, and you
have to specify it – and “–baud” to specify what bit rate I want to use. So, I’ll use 9600 bits-per-second here. And then I’ll repeat that “read_flash” command. Now it runs a lot more slowly and you can
see that the LED for serial communications stays on a lot longer, but it’s going to be
a lot more reliable. Now, you may not necessarily need to go down
this slow. You might just need to drop it, say, from
the default that esptool uses, which is 115,200 bits-per-second, down to maybe half that:
57,600 bits-per-second. Now this time I’m going to try another esptool
command that may not behave the way you expect. If we have a look at the esptool sub-commands,
we see that there’s one called “dump_mem”, which supposedly reads the internal storage
of the ESP8266. So when I run that it gives me again the parameters
that I need to use, and I’m going to try reading from address 0, and in this case I’ll read
4 kilobytes, so 4096, and try and store it into a file, and it seems to just hang and
then come up with an unusual error message. So let’s just verify that the device is still
working by going back and just running “chip_id” again, and clearly it is still working, so
let’s try and find out why that is. Well, if we go and Google for “esp8266 memory
map”, and we check out, say, this page here, then we can actually see that trying to read
from address 0 will cause a fault. And there are some other addresses that we
are actually interested in, so if we scroll down we can just, say, pick this one here,
and we need to put that in, instead, as a hex value. So I’ll go back and I’ll re-issue the “dump_mem”
command with those different parameters, and now we see that it works. But it does go a lot more slowly when it’s
trying to read from the internal memory of the ESP8266 because it actually has to go
through a couple of different serial layers. We’re nearly ready now to upload our example
blinky firmware to the NodeMCU board, and actually see it running, but there is one
small change that I need to make yet. It turns out that the example is designed
for a board that has its LED wired differently from mine, and you may find the same issue. So, let’s go and modify the firmware to deal
with that. Do “cd ~” to go into our home directory, and
then do “cd projects/esp-open-sdk/examples/blinky”, and then we’ll use “nano” again to edit the
“blinky.c” file, and it’s at the end of this line here where it currently refers to pin
1; I need to change that to pin 2. So, I’ll make that change, and then do: CTRL-O
to write out the file; CTRL-X to exit. Run “make” again and then do “ls -al” and
we can see those two firmware fragments there, and we’ll now use esptool to upload it to
the NodeMCU. So “esptool”, and I’ll play it safe with the
baud rate here of 57600, use the “write_flash” command, and then starting at address 0 we
first want to write this file, then at this address we want to write this file. So hit ENTER and that’ll kick that process
off of uploading it to the NodeMCU. It will do each part in turn, and then when
it’s finished, “esptool” should automatically reset the NodeMCU board, so that we’ll then
see the LED start blinking at a regular 1Hz: Half a second off, half a second on. And we can see now that our firmware works. Woohoo! So how do you do this with the ESP-01? Well it’s actually pretty much the same; you’ll
just need a programming jig, and while you could buy one, I’ll show you the schematics
because it’s pretty easy to make one for yourself. On one side you’ve got a USB-to-serial adapter
which plugs into your computer, and ideally this would use the CH340G chip, or the CP2102. On the serial side, it must operate at 3.3
volts. On the other side, you’ve got the ESP-01,
and both devices will probably use header pins and sockets to plug into the base board,
which you will make. The pin-out of the ESP-01 is exactly as shown,
but the pin-out of your serial adapter may vary. It’ll at least have a Transmit line and a
Receive line, and these connect directly to the ESP-01, and you’ll also need to connect
a common Ground line between the two devices. The ESP-01 also needs a 3.3-volt power supply,
and it’s likely there’s a supply pin that you can use on the serial adapter, but if
you find that it isn’t strong enough to reliably power the ESP-01, then you may like to have
a jumper configuration for the option of using an external 3.3-volt power supply, which will
then also share the common Ground. The ESP-01 also has a “CH_PD” pin which must
be pulled high, and the reset pin should be pulled high as well, but with a weak 10-kiloohm
pull-up resistor. This allows for it to be overridden by a pushbutton
which can drive the reset line to Ground in order to reset the ESP8266 chip. The same arrangement will also be used on
the GPIO0 pin in order to implement the “Flash” programming mode button, which I’ll explain
shortly. The only other things that may need are a
100-nanofarad decoupling capacitor wired as closely as possible between the Ground and
VCC power pins of the ESP-01 module, in order to help stabilise its power supply, and you
also have the available GPIO2 pin which you may want to break out for interfacing with
other devices. If you were to press and release the “Reset”
button, the ESP8266 would go through a normal reset procedure, and then run its firmware. If, however, coming out of reset it senses
that GPIO0 is held low, it’ll instead go into programming mode. So the correct procedure for putting the device
into programming mode is to press and hold the “Reset” button, which also disables any
signal that it might be driving on GPIO0, then also press and hold the “Flash” button,
then release the Reset button, and then release the Flash button, and the device should now
be in programming mode. When in programming mode, esptool is able
to communicate with the device, send it commands, and re-flash it. Now, with the programming jig, you could build
it using loose wiring and a solderless breadboard, but you’ll get better signal integrity, and
hence better reliability, if you make a more permanent arrangement, such as here where
I’ve soldered it using protoboard. So now let’s try using this jig. First I’ll plug in the USB-to-serial adapter. Then I’ll plug in the ESP-01 module, and then
I’ll attach it to my computer through USB. Going back into VirtualBox now, and assuming
that the VM is still running, let’s go into the virtual console now and click the USB
button in the status bar, and you should see that your USB-to-serial adapter shows up there. The chip that’s in my USB-to-serial adapter
happens to be exactly the same as the one that was in the NodeMCU previously, so VirtualBox
has already picked it up and passed it through to the Linux VM automatically. So I will now go to my terminal program where
I have an SSH connection to the VM already running, and I’ll try running “minicom –device
/dev/ttyUSB0”. And at the default baud rate of 115,200, I’ll
click the “Reset” button on the programming jig and straight away I get some meaningful
output, because it turns out that the firmware that’s on my particular ESP-01 is already
configured to run at 115,200 bits-per-second. But of course, you can hit CTRL-A, and tap
P, if you want to experiment with different baud rates for your device. I’ll exit minicom now by doing CTRL-A and
tapping X, and now I’ll try using esptool. So I’ll run “esptool” and try first the “chip_id”
command. And then it hangs, and fails. In this case we have to manually put the board
into programming mode first so that esptool is able to communicate with it. So I’ll go through that four-step special
reset sequence. So, press and hold the “Reset” button, then
also press and hold the “Flash” button, then release the Reset button, and finally release
the Flash button. And now the device is in programming mode,
so I can tap the up arrow on my keyboard to re-run that “chip_id” command, and now it
works. And the device normally stays in programming
mode afterwards, so I can run “chip_id” again and it’s still working. But I have noticed a quirk with this board
for any of the flash commands, so for example “flash_id” and “read_flash”, and I’ll demonstrate
that. If I run “esptool flash_id”, that works, but
then it seems to throw the board out of programming mode afterwards which means that if I then
try and run, say, “chip_id”, it now doesn’t work, so I’ve got to put it back into programming
mode again, and then “chip_id” does work. So that now that we’ve verified that, let’s
prepare our firmware. So I’ll do “cd ~” to go into my home directory,
then “cd projects/esp-open-sdk/examples/blinky”, and I’m going to use “nano” again to edit
“blinky.c”. You’ll recall that for the NodeMCU example
we had to change this pin configuration from pin 1 to pin 2. Well it just so happens that with the ESP-01
we’ve got to change it back to pin 1 again. So I’ll make that change and then write out
the file with CTRL-O, and then exit with CTRL-X. I’ll now run “make clean” to remove any of
the old firmware compiled files, and then I’ll rebuild the firmware with the “make”
command. Now that that’s finished, inside there we
have the two firmware binary files that are ready to be uploaded. So I’ll run “esptool” and I’ll run it at a
baud rate of 57600 to be safe. I’ll run the “write_flash” command and start
at address 0 with this file, and then start at this address with this file. And it seems to have come out of programming
mode again, which tends to happen sometimes, so I’ll put it back into programming mode
again, tap the up arrow, re-run that command, and now it’s successfully writing, starting
first with that smaller file, and then moving on to the larger file, and when it’s finished,
esptool will automatically send a command to the ESP8266, to make it then run that firmware,
and the LED starts blinking. You now have the environment, the software,
the SDK, and the hardware know-how to be able to develop, upload, and run your own ESP8266
firmware. So what are you gonna build? If you’ve got any questions or feedback on
this video, then feel free to leave a comment below. And if you liked this video, or think it would
be useful for others, then be sure to hit the “Like” button. Also, subscribe if you want to keep track
of future videos that I release because I’ll have some interesting topics coming up along
these same lines. Otherwise, thanks for watching!

Tags: , , , , , , , , , , , , , , , , , , , , , , , ,

100 Comments

  • B1tW0lf says:

    Truly a great tutorial. I couldn't find any decent vids but this one is easy to follow all the way through. You've got another sub by making great vids keep it up

  • Iuri Castro says:

    Excellent video! Very clear, objective and walk through all the inicial steps! Subscribed!

  • Fabricio Gomes says:

    will you launch more videos?

  • Ayush Chand says:

    If your esp board is not responding after flashing try passing flash arguments.
    esptool.py –port /dev/ttyUSB0 write_flash -fm dio -fs 32m -ff 40m 0x00000 blinky-0x00000.bin 0x10000 blinky-0x10000.bin

  • Sreeprakash Neelakantan says:

    Thanks 👌

  • m3chanist says:

    Some of the best tutorial/help video production I've seen, and I'm a retired cgi lecturer. You are a natural educator, bravo.

  • Vishal Dhayalan says:

    I love the clear and concise explanations and amazing detail in your videos! Hope you do more! Everything was going well and I've been following from #2 with no problems till now… I was running the default make command as shown at 11:00 but am getting numerous warnings and finally an error before it exits the process automatically without building…

    The log of the error can be found here: https://drive.google.com/open?id=0B3n0H96Zi-fZbTltTy03cVg1emM

    I'm using windows 7 (32-bit), am I doing something terribly wrong? I tried it 2-3 times and same result every time… Please help

  • Pedro Freitas says:

    This is by far the most informative video about two things: 1. installing and using esp-open-sdk and 2. how to flash the code to the ESP module.
    Congratulations, too bad you're like 3 – 4 months without any new videos. I hope you'll be back with more soon.

    For those like me who would like to go deep, check out the API Reference Guide: https://espressif.com/en/support/download/documents?keys=&field_type_tid%5B%5D=14

    Cheers.

  • Raad Yacu says:

    well worth it – learned a lot from this video – thanks Anton

  • Muhammad Ahmed Zafar says:

    Excellent ☺

  • Cristian Arrieta says:

    Excellent recopilation of information, i've been using the esp8266 since it was released and believe me, if i had had this kind of videos before, my learning curve had been more fast, btw you should keep doing this kind of videos with the SDK.

  • anil kumar says:

    you are amazing ! more videos plz! 🙂

  • GrayCoLLC says:

    A very impressive demonstration ! I finally got the damn thing flashing. Many thanks from Alaska.

  • GrayCoLLC says:

    Any chance of a video on making & using tool chains?

  • meowsqueak says:

    I'm using the non-standalone toolchain+SDK option (make STANDALONE=n) and running 'make' in the Blinky project is giving me trouble with the linker script file 'eagle.app.v6.ld' – no such file or directory. I can see it there in the sdk/ld/ directory. Note: I added the appropriate LDFLAGS for sdk/lib. Any ideas?

  • Ruibin Li says:

    哈哈哈,
    什么?那是什么意思?

  • alpagutsencer says:

    Hey Man! Let me say this. You are just amazing. I cant tell how happy i am. I am working on this issues for a long time and you save my ass. Thank you very very much. I wish i could buy you a beer.
    <3 <3 <3

  • Patrick Roux says:

    Thank you, I can't wait to test all of that ! DO you think your second approach would work with a ESP8266-12e ?

  • Mike Collins says:

    It's such a pleasure to see a video really well edited and presented – and without music! I liked this a *lot*, though YouTube would only allow me to like it once. Subscribed. I'll go back and look at installation of Linux before re-watching this and trying to emulate it.
    I'm glad you noted the Tx/Rx crossover error. When I saw it in the vid, I thought "huh?!"

    Your web site looks excellent. Do you think it may one day develop into a forum for your followers to swap ideas, get help, cross-pollinate, etc?

  • Willian Mattos Ribeiro says:

    Hello, sorry for my bad english.

    I have a esp8266 12e, i'm trying to send commands through TX/RX pins using the AI_THINKER Firmware with AT commands.
    Let me explain:
    I set up the esp8266 12e as AP, conect a cellphone to it through wifi,, send data through UDP.
    i need to get this data from esp and send to my arduino board. but it semms not to send.
    but via USB cable it works. it's like the esp works through serial via USB cable, but not work via RX/TX pins.

    ESP8266 12E need some kind of configuration to send data directly through RX/TX pins?

  • ammar the Hasnawi says:

    How are you my friend Excuse I want to Restored The M C U I hope you that Teach me How Action..

  • Rajath Kumar says:

    Thanks a lot for the Great Tutorial.

  • Rajath Kumar says:

    Please continue video for installing Eclipse for ESP8266. It would be great for ESP8266 Amateur like me.

  • Mike Collins says:

    Can you please tell me where to get support with this? Has anybody else had this issue?
    I think it may be that available software is at later revisions than used in the video, and behaves differently.
    I went through the first video to install vbox, and that all went well, then I followed this video, which also went well up to 10:27.
    I copied the command to get the SDK repository, which appears to install for some time, but then fails with…

    [INFO ] Retrieving needed toolchain components' tarballs
    [INFO ] Retrieving needed toolchain components' tarballs: done in 266.58s (at 04:30)
    [INFO ] =================================================================
    [INFO ] Extracting and patching toolchain components
    [ERROR]
    [ERROR] >>
    [ERROR] >> Build failed in step 'Extracting and patching toolchain components'
    [ERROR] >> called in step '(top-level)'
    [ERROR] >>
    [ERROR] >> Error happened in: CT_DoExecLog[scripts/[email protected]]
    [ERROR] >> called from: CT_Extract[scripts/[email protected]]
    [ERROR] >> called from: do_binutils_extract[scripts/build/binutils/[email protected]]
    [ERROR] >> called from: main[scripts/[email protected]]
    [ERROR] >>
    [ERROR] >> For more info on this error, look at the file: 'build.log'
    [ERROR] >> There is a list of known issues, some with workarounds, in:
    [ERROR] >> 'share/doc/crosstool-ng/crosstool-ng-1.22.0-60-g37b07f6/B – Known issues.txt'
    [ERROR]
    [ERROR] (elapsed: 4:35.87)
    [04:37] / ct-ng:152: recipe for target 'build' failed
    make[2]: * [build] Error 2
    make[2]: Leaving directory '/home/colmik/projects/esp-open-sdk/crosstool-NG'
    ../Makefile:132: recipe for target '_toolchain' failed
    make[1]: * [_toolchain] Error 2
    make[1]: Leaving directory '/home/colmik/projects/esp-open-sdk/crosstool-NG'
    Makefile:128: recipe for target '/home/colmik/projects/esp-open-sdk/xtensa-lx106-elf/bin/xtensa-lx106-elf-gcc' failed
    make: * [/home/colmik/projects/esp-open-sdk/xtensa-lx106-elf/bin/xtensa-lx106-elf-gcc] Error 2

    I went back to the beginning of the video and repeated all steps, but having attempted it three times, I'm clearly not making headway.
    I can't find share/doc/crosstool-ng/crosstool-ng-1.22.0-60-g37b07f6/B – Known issues.txt'

  • Andrew Palm says:

    Anton, this was a very good video indeed. I've gravitated to PlatformIO Core + Geany for my non-PIC embedded IDE needs, but I was disappointed that PlatformIO only supports the RTOS version of the esp8266 SDK and not the non-OS version. Your video has shown me how I can fill that gap should the need arise. Fortunately my laptop runs Linux, so I won't have to deal with the VM. And the video was very well produced.

  • Hector Benito says:

    I had an error while installing the sdk but this worked for me https://github.com/pfalcon/esp-open-sdk/issues/223

  • csbluechip says:

    At 20m21s you connect Tx to TX and Rx to Rx ….In serial comms Tx and Rx are crossed (ie. {Tx–>Rx, Rx<–Tx}) …I can't transmit to your transmitter – I need to transmit to your receiver (et vice versa)

  • Juergen Wickenhaeuser says:

    Very good explained! Thanks a lot!

  • Sunil Sudevan says:

    I got this error after installing  and trying to start VM on mac OS X

    (Kernal error) ?

    Failed to open a session for the virtual machine LinuxDev.

    The virtual machine 'LinuxDev' has terminated unexpectedly during startup with exit code 1 (0x1).

    Result Code: NS_ERROR_FAILURE (0x80004005)
    Component: MachineWrap
    Interface: IMachine {85cd948e-a71f-4289-281e-0ca7ad48cd89}

  • Snake Sanders says:

    thank you! it represents how I feel right now…

  • Sunil Sudevan says:

    Blinky example does not work on ESP-12

    esptool.py write_flash 0 blinky-0x00000.bin 0x10000 blinky-0x10000.bin
    esptool.py v1.2
    Connecting…
    Auto-detected Flash size: 32m
    Running Cesanta flasher stub…
    Flash params set to 0x0040
    Writing 36864 @ 0x0… 36864 (100 %)
    Wrote 36864 bytes at 0x0 in 3.2 seconds (91.6 kbit/s)…
    Writing 196608 @ 0x10000… 196608 (100 %)
    Wrote 196608 bytes at 0x10000 in 17.1 seconds (91.9 kbit/s)…
    Leaving…

    led just rapidly blinks 
    it seems the device is in constant reboot mode

  • Juliano Oliveira says:

    Congratulations, excellent video

  • Hussain Abo Sobaie says:

    This is the best guid to use the esp. (Y) Keep it up!

  • Hubert Dylewski says:

    wow, aren't u putting this circuit on a reset button? I mean is you place this board on a reset button it can sometimes catch reset command which lead to exiting programming mode you mentioned in 26:00 .

  • Oleg Shumihin says:

    thanks a lot for you time Anton, followed every bit of it. The best introduction to the ESP SDK!

  • Shawn Duan says:

    Great video. One of the best.

    I'm not sure if somebody else has pointed out. When pin change is necessary, you need to modify the line (in the initialization function) to configure the pin to digital output. For example, for GPIO2, it should be "PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO2_U, FUNC_GPIO2);". For GPIO4, it should be "PIN_FUNC_SELECT(PERIPHS_IO_MUX_GPIO4_U, FUNC_GPIO4);".

  • Kyle Ishie says:

    Thank you for this video.  For any one using the Wemos D1 Mini Lite use the –flash_size=detect and –flash_mode=dout when running write_flash.  I found that if I did NOT do this the write_flash command would seem to succeed but the firmware wouldn't work correctly, i.e., not Blinky Blinky.  😉

    For the Blinky example in the video its:
    esptool.py –baud 57600 write_flash –flash_size=detect –flash_mode=dout 0x00000 blinky-0x00000.bin 0x10000 blinky-0x10000.bin

  • Ivan Ceasario says:

    Excellent how to video, Anton! I just started to get into programming the ESP8266 and ESP32 on my Ubuntu environment and this got me up and running in no time. Just a couple of questions, any plans to do one for esp-open-rtos? how about ESP-32 for both sdks?

  • Trey Dempsey says:

    Has anyone here built a board for the esp01 that uses the serial control lines to handle reset and flash?

  • Yas M says:

    Unfortunately, some things do not work as of December 2017 (on the same system using the same virtual machine set up).

  • William Bottger says:

    Do all c applications produce 2 .bin files? what determines the load address?

  • Sergio Aiello says:

    First of all congratulation: impressive teaching technique!! Incredibly professional 🙂

  • Sergio Aiello says:

    You mentioned CH340G and CP2102. One week ago I bought FTDI FT232R based USB to serial adapter. Do you know if it would be workng properly as well?

  • Andreas Schmidt says:

    Good job!!! Thank you for this video. I am looking forward to more such videos.

  • Jestin P.J says:

    Great tutorial 👍👍

  • Syed Ali Shan says:

    awesome video, really helpful. thank you

  • Denis Cosmin says:

    Thank you very much for creating these videos. They are really helpful and are done very professionally. Could you also add some resources in the description of the video? For example where to get help, documentation, etc..

  • Gustavo Minnucci says:

    Great video ! Thx Anton

  • Ralf M. Metzing says:

    thanks alot for this excellent explanation

  • Torsten Heß says:

    Well, Please speak a bit slower for a German hobby programmer!

  • Thomas Patrick says:

    Very good information. Very high production in your video. You could charge money for this.

  • ganesan guru says:

    Hi guys,for me everything worked nice until I compile example-blinky program. I got this strange error "blinky.c:1:21: fatal error: ets_sys.h: No such file or directory
    #include "ets_sys.h"
    ^
    compilation terminated.
    "

    Does anyone know how to solve it. Some say we have to change the Makefile. I tried it by adding

    "XTENSA_TOOLS_ROOT ?=/home/esp8266/Desktop/ESP_OPEN_SDK/esp-open-sdk/xtensa-lx106-elf/bin

    SDK_BASE ?=/home/esp8266/Desktop/ESP_OPEN_SDK/esp-open-sdk/sdk/"

    in /ESP_OPEN_SDK/esp-open-sdk/examples/blinky/Makefile. But that ain't helped.Some advice?

  • Stephan Smolek says:

    Excellent tutorial, thanks a lot.

  • romel554 says:

    Hello friend! Very well explained video, good job! I have a problem adding the bin folder to the PATH, I run the line echo 'export..etc but when I check on echo $PATH the sdk folder isnt there, what could be wrong?

  • Erik Laken says:

    Thank you very much, i am startend and i could not start without your video, Thank you so much. 🙂

  • Erik Laken says:

    One questions, rx and tx have to be Just On One site reverse, or am i wrong?

  • pastudan says:

    Direct and to the point. Love it. Cheers!

  • Raveendiran RR says:

    This is a very detailed explanation, good research on the details. In case you just want to upload a program, you could just use the Ardino IDE — https://learn.adafruit.com/adafruit-huzzah-esp8266-breakout/using-arduino-ide

  • Lucas says:

    I had to connect the ESP to the USB-to-serial adapter differently (ESP TX to adapter RX and ESP RX to adapter TX). All the explanations I saw say to connect TX to TX and RX to RX, but it didn't work for me.

  • Ginger Bakerino says:

    I see a lot of work, dedication and passion in this fantastic video. Thanks a lot and gratz

  • pastudan says:

    This is a great video 🙂 As a beginner, I'm curious why someone would want to read the contents of the flash mem off the chip? For verifying? Or is there another purpose I'm not considering?

  • dogastus says:

    That really helped – many thanks.

  • AntsPantshere says:

    This blew my mind, going fishing to cool down!

  • vinit Tirnagarwar says:

    very nicely explained!!!! can i use arduino IDE software and CP2102 module to program it serially

  • sonus89 says:

    OMG you are a fuckin genious!!! I loved this video.

  • Muaiyd Al-Zandi says:

    Thank u for ur video its really good
    I got this error after the make could u please help me?
    Build failed in step 'Retrieving needed toolchain components' tarballs'
    [ERROR] >> called in step '(top-level)'
    [ERROR] >>
    [ERROR] >> Error happened in: do_mpc_get[scripts/build/companion_libs/[email protected]]
    [ERROR] >> called from: do_companion_libs_get[scripts/build/[email protected]]
    [ERROR] >> called from: main[scripts/[email protected]]
    [ERROR] >>
    [ERROR] >> For more info on this error, look at the file: 'build.log'
    [ERROR] >> There is a list of known issues, some with workarounds, in:
    [ERROR] >> 'share/doc/crosstool-ng/crosstool-ng-1.22.0-60-g37b07f6f/B – Known issues.txt'

  • Nirav says:

    Really helped. Thanks.

  • Dariusz Fertyk says:

    Great tutorial, very professional

  • Sergio Alejandro González says:

    Wanted to thank you for you excellent video. Very well presented, carefully explained and technically sound. I usually program bare-metal ARM with eclipse and the GNU toolchain, it took me several days getting everything prepared to use eclipse and the esp8266-devkit-master from Espressif. I could have saved a lot of time seeing your videos first!. Do you think could be worth preparing a video explaining SDK usage?

  • zrogles says:

    Thank you! You just saved me hours, I'm sure!

  • Юрий Бражник says:

    This is exactly what i was looking for. Thanks dude!!!!

  • Cheeki Breeki says:

    Amazing tutorial, got me started smoothly!

    One thing that I'd like that add is that sometimes you need to flash the "SDK Init Data" to the chip as well, or it'll crash, bootloop and make the LED flash uncontrollably.

    Exact description is here (https://nodemcu.readthedocs.io/en/latest/en/flash/#upgrading-firmware), but essentially you need to flash the esp_init_data_default.bin file to 0x3fc000 (location may differ for boards different from the NodeMCU). You can find the binary file in esp-open-sdk/ESP8266_NONOS_SDK-2.1.0-18-g61248df/bin/.

  • Serdar K. says:

    This took 6 months for me, to gather that information. And you are clearing everything in 26 minutes. Excellent reference, which even Espressif people would like to refer to their customers. Interested ones can easily start and work on details like memory maps and their own application just after wathcing this and taking notes. Thanks for packing and sharing all this information with us!

  • Jay Are says:

    Why are you not more subscribed?! goes and checks out more videos oh… just 3? your videos are great!

  • Rud Dog says:

    A bit over my head but enough to get me to visit your youtube page, unfortunately, don't see any other videos targeting Esp8266, NodeMCU, Arduino IDE and C++, shame.

  • Yash Pandit says:

    Great video.
    One more thing
    Where can I get examples on how to write the codes for esp8266. On the internet, I only find the blinky sketch everywhere but how do I write the wifi part or other important functions like i2c etc? Are there any useful examples that can help me get started writing the firmware?

  • SlykeThePhoxenix says:

    This is probably one of the best tutorial methodologies I have ever watched on youtube. Keep up the good work!

  • Liu Zheng says:

    Very excellent tutorial!!! For the surface all the way to the depth, in such a pedagogical way! Thanks

  • Ben Anderson says:

    Fantastic video, thanks for putting in the hard work to make this really high quality and easy to follow. Most other tutorials would be 60+ minutes for this kind of thing, so it's easy to see the hard work you've put into this.

  • R1S8K LLTP says:

    What's the difference between programming it with Lua or with C ?

  • SfnDude! says:

    program an esp with arduino or native c which one is better?

  • Vilkoxd says:

    Instructions for linux start at 7:53

  • Ivan Di Salvo says:

    Dear Anton, Thank you so much for your videos.
    I found it very informative and detailed, I'm trying to follow your instruction, I've encountered an error during the "make" process, I past the problem with the hoping that someone can help me about, maybe a very stupid thing but I newer to linux so for me is really hard also to find the build.log file that the error mentions… please give a look when you have a bit of time to waste.

    Thank you

    make
    Makefile:186: warning: overriding recipe for target 'ESP8266_NONOS_SDK-2.1.0-18-g61248df/.dir'
    Makefile:181: warning: ignoring old recipe for target 'ESP8266_NONOS_SDK-2.1.0-18-g61248df/.dir'
    cp -f 1000-mforce-l32.patch crosstool-NG/local-patches/gcc/4.8.5/
    make -C crosstool-NG -f ../Makefile _toolchain
    make[1]: Entering directory '/home/ivands/projects/esp-open-sdk/crosstool-NG'
    ../Makefile:186: warning: overriding recipe for target 'ESP8266_NONOS_SDK-2.1.0-18-g61248df/.dir'
    ../Makefile:181: warning: ignoring old recipe for target 'ESP8266_NONOS_SDK-2.1.0-18-g61248df/.dir'
    ./ct-ng xtensa-lx106-elf
    make[2]: Entering directory '/home/ivands/projects/esp-open-sdk/crosstool-NG'
    IN config.gen/arch.in
    IN config.gen/kernel.in
    IN config.gen/cc.in
    IN config.gen/binutils.in
    IN config.gen/libc.in
    CONF config/config.in
    #
    # configuration written to .config
    #

    *********************************************************

    Initially reported by: Max Filippov <[email protected]>
    URL: http://www.esp8266.com/viewtopic.php?f=9&t=224

    *********************************************************

    WARNING! This sample may enable experimental features.
    Please be sure to review the configuration prior
    to building and using your toolchain!
    Now, you have been warned!

    *********************************************************

    Now configured for "xtensa-lx106-elf"
    make[2]: Leaving directory '/home/ivands/projects/esp-open-sdk/crosstool-NG'
    sed -r –i.org s%CT_PREFIX_DIR=.*%CT_PREFIX_DIR="/home/ivands/projects/esp-open-sdk/xtensa-lx106-elf"% .config
    sed -r -i s%CT_INSTALL_DIR_RO=y%"#"CT_INSTALL_DIR_RO=y% .config
    cat ../crosstool-config-overrides >> .config
    ./ct-ng build
    make[2]: Entering directory '/home/ivands/projects/esp-open-sdk/crosstool-NG'
    [INFO ] Performing some trivial sanity checks
    [INFO ] Build started 20190211.170937
    [INFO ] Building environment variables
    [INFO ] =================================================================
    [INFO ] Retrieving needed toolchain components' tarballs
    [ERROR]
    [ERROR] >>
    [ERROR] >> Build failed in step 'Retrieving needed toolchain components' tarballs'
    [ERROR] >> called in step '(top-level)'
    [ERROR] >>
    [ERROR] >> Error happened in: do_expat_get[scripts/build/companion_libs/[email protected]]
    [ERROR] >> called from: do_companion_libs_get[scripts/build/[email protected]]
    [ERROR] >> called from: main[scripts/[email protected]]
    [ERROR] >>
    [ERROR] >> For more info on this error, look at the file: 'build.log'
    [ERROR] >> There is a list of known issues, some with workarounds, in:
    [ERROR] >> 'share/doc/crosstool-ng/crosstool-ng-1.22.0-60-g37b07f6f/B – Known issues.txt'
    [ERROR]
    [ERROR] (elapsed: 0:24.81)
    [00:25] / ct-ng:152: recipe for target 'build' failed
    make[2]: * [build] Error 1
    make[2]: Leaving directory '/home/ivands/projects/esp-open-sdk/crosstool-NG'
    ../Makefile:135: recipe for target '_toolchain' failed
    make[1]: * [_toolchain] Error 2
    make[1]: Leaving directory '/home/ivands/projects/esp-open-sdk/crosstool-NG'
    Makefile:130: recipe for target 'crosstool-NG/.built' failed
    make: * [crosstool-NG/.built] Error 2

  • zbig83 says:

    Waiting for a followup video. Wrapping a head around an ESP toolchain is no easy task. Compiling a preexisting code is one thing, writing your own is another.
    setting up an IDE, preparing a makefile (necessary?) I wish Atmel made its own WiFi chip.

  • H2oRiz says:

    Make more videos please, you deserve crowd funding.

  • Tecnología Interactiva says:

    Thank You!

  • kevin neill cueva almendrales says:

    Yo tampoco te entiendo 😥

  • qubolo says:

    Thanks for saving my ass. This video is very informative and well made.

  • Shere' Lamm says:

    Thank the universe that YouTube has you! Prior to your tutorials I was lost, so I want to thank you for all the work you put in the these videos. But I do have a question, when I connect my NodeMCU to the computer it just briefly flashes and Linux (VM) doesn't see it. Anything would be of help!
    Thanks!

  • AndreyKandauroff says:

    nice videos, so complicated to deploy c firmwares into esp8266, lua programming seems so much easier.
    what would be the main advantages for running in native C comparing to running on LUA?
    thanks

  • Samim Rahman says:

    Wow! Excellent video. Thank you very much for your nice effort to share such an Informative video. Hope there will be many Interesting information in future. Can you share your email address to communicate with you?

  • SAI Teja says:

    love you

  • pacsmile says:

    This video is so well done and really matches the quality of any big youtuber, and now i'm sad because this was your last upload; i watched this video expecting a whole series of esp8266 programming stuff.

  • Denis D. says:

    great explanation!

  • amir udin says:

    You're a hero sir, thankyou so much

  • Eric Gamess says:

    Hi, I followed all the steps. My hypervisor is VMware Workstation. Every thing seems to work. I can flash the firmware, and no error is reported. Every thing looks good. But the led does not blink. I was able to make the led to blink without problem with the Arduino Editor. Can someone post two flash files that work? I just want to discard a problem when flashing. Thank you.

  • mahdi rafatjah says:

    This should be either too old or with a wrong purpose. For begginers just use Arduino IDE

  • Oladapo Ajala says:

    I get this error everytime I try to use make in the blinky folder:
    blinky.c:1:21: fatal error: ets_sys.h: No such file or directory
    #include "ets_sys.h"

  • Rud Dog says:

    My search on how to learn to program for the ESP series of boards like ESP8266, NodeMCU has yielded nothing other than the reference material. Everytime I ask for "How to program ESP devices" I get answer pointing me to C++. How do you ask for help programming for the ESP series? What is the name of the language used for programming on the ESP series?

  • Antonio lopez says:

    the best esp8266 tutorial on youtube. like it, subscribed and notified. i'm the 1k subscriber 🙂 Congratulations ! I hope you do more videos about esp8266 and esp32. thanks

Leave a Reply

Your email address will not be published. Required fields are marked *