Skip to main content

Talking to your ESP8266 Chip (Wired and Wireless Methods)

In my previous post, I mentioned how to setup our chip ESP8266 NodeMCU.
As a convention throughout the industry, we should have our chip printed "Hello World!" for us.
Firmware had already been installed on our chip. So, the only thing we need is to talk to our chip via Serial Communication Protocols.

I'll categorize communication protocols in two groups: REPL and WebREPLREPL stands for Read Evaluate Print Loop.

In the REPL section, I'll be talking about PuTTY and TeraTerm and in WebREPL section I'll  be talking about only WebREPL sw.


1- Wired REPL Methods

i) PuTTY:


Figure: A new Serial Session is opened thru PuTTY.



Figure: Python Scrips (Hello World)



ii) TeraTerm:

Figure: TeraTerm Serial Connection Settings



Figure: Python Scrips (Hello World)



2- Wireless REPL Methods: 

i) WebREPL:

Using any of the REPL options above (PuTTY or TeraTerm), first we need to install weprepl library onto chip.

import webrepl_setup

Follow the instructions and reboot device afterwards.

Figure: Importing webrepl library using a PuTTY session


Connect your PC to ESP8266 Wifi Access point with the password you've just defined in above steps just like you connect to any Wifi access point. Now you are connected to the Wifi of your Chip. Cool!


Figure: Connection to Wifi Access of ESP8266 Chip



Now, open local or online WebRepl:



Connect to default IP: ws://192.168.4.1:8266/
Type your password when prompted...There we go.

Figure: MicroPython scripts using local WebREPL


Figure: MicroPython scripts using online WebREPL

To summarize, both wired and wireless communication methods with our chip is mentioned in this post. You are totally free to choose whichever is most convenient for you.

Happy MicroCoding !

Comments

Popular posts from this blog

Star Wars ASCIImation with Python - Windows

In this post, we'll watch a Star Wars movie in ASCII format. The only thing we need for this demo is Python-installed PC and internet connection. Figure : Screenshots from Python Command line while Star Wars is being streamed All credits gained in this demo will go to " blinkenlights.nl " [2] website, which broadcasts this ASCII movie using Telnet protocol on Port 23, and Python which makes socket implementation very easy for us. No authentication is needed for this broadcast. Anyone who is able to create a TCP socket and listens  blinkenlights.nl  on port 23 would be able to get this stream and display on their Python command line. CODE My main source for Python source code is [1]. What  code below does is simply importing Python "socket" library, create a socket, use " towel.blinkenlights.nl " address variable to create connection, receive data from socket and display it. While typing (copy/paste) code, be careful about indentatio...

How to setup MongoDB tools to test/develop applications in C#?

In this article, I will be mentioning about how to install MongoDB infrastructure to develop any application in C#. After you have read this article, you will be ready to develop C#-MongoDB applications by following the below instructions step by step. Versions of tools used in this demo: Visual Studio 2010 .NET 4.0 MongoDB C#/.NET driver Version 1.11.0 MongoDB 3.4.0 Robomongo 0.9.0 1- Download MongoDB To download latest version of MongoDB, click here . Below page is opened. According to your Operating System, select MongoDB version and click to " DOWNLOAD ". After downloading, go ahead and install MongoDB. 2- Download RoboMongo Click  here  to download latest version of RoboMongo. As December 2016, latest version of RobomMongo is 0.9.0. To download the latest version, click " Download " button. If you want to download previous versions, click on " Download previous version " After that, select the OS and download RoboMon...

STORY: Most Challenging Bug

It was an embedded software running on a specific hardware. Software was consisting of different modules for each task. The functionality that I was testing was related to two different modules which are written by two different developers. Required functionality was not working and test was failing consistently. Then, we debugged the Module-1 with Developer-1, Module-1 seemed to work properly. Then, we debugged the Module-2 with Developer-2, Module-2 also seemed to work surprisingly. Of course, each developer was blaming the other developer for the fault : ) Then I suspected about my own test case and re-reviewed and inspected it again, but test case also seemed as OK. Afterwards, we suspected about the software testing tool and debugged it with the developer of the test tool. Not surprisingly, test tool also seemed to work properly : ). Ooopsss. What is next? The next suspicious guy was the data buses between test tool and the software/hardware. Then we checked data...