PRACTICAL USAGE
There is a plenty of sensors that can be interconnected into aquisition networks using popular ESP8266 WiFi chips. This approach implements a controllable Internet of Things. For example for growing plants, you can study per-plant solar radiation intensity, temperature, humidity profile. With more advanced sensors it is possible to collect chemical characteristics of hydroponic solution. Generally - whatever can be measured depending on the measurement cost. Maximum sampling frequency of this chip  (50 mxn) ESP8266 PCBs can be at least 1 MHz that is more that enough for the long term processes. Another obvious possibility is a programmable ambient control. It is possible to connect chip to the light sources, to control air access, to control feeding solution components. And than - study the biological consequences. 


BOARD OVERVIEW
To see what do we have in our hands
ESP Board datasheet (TODO: Find the correct one!)



HARDWARE AND FLASH PROCESS
Connecting programmer to the ESP board via USART seems to be the most cheep option. Flashing over SPI is another solution that is used on ESP developer boards. When ESP8266 already have firmware, it can also support a wireless firmware upload, however for the first time it is impossible. Study the next document to touch the ESP mainstream considerations, especially from the point of view of the memory mapping rules:
Manual on how to connect UART programmer

To flash a new image into the board a third party cross-platform esptool.py can be used. It seems to be the best tool for automatic firmware image upload than officially proposed "downloader" that works under Windows only and has graphical interface. The esptool.py home is here:
ESPTool Home

If something goes wrong during the firmware upload process, this document can be useful for low level debugging: 
ESP8266 SDK Application Note Firmware Download Protocol



FIRMWARE COMPILATION
It is tricky to prepare a cross compiler for Xtensa CPU architecture that was used in ESP8266. Many collateral documentation needs to be studied to fully understand a crosstool-ng package. The ESP developers have made a VirtualBox image with preinstalled tools and explain how to use it in the next basic document with many board specific comments:
Getting Start Guide for creating ESP projects

However, the suggested by developers firmware compilation process using the VirtualBox in the CMake-driven framework doesn't seem optimal. The disadvantage of this approach is that the VirtualBox must be run under the GUI with reduced automation capability.

 For the moment it is better to create everything manually in order to understand the complete process. Basically, there are two required components described below.

The first one is the ESP NONOS-SDK. This SDK contains all chip-specific configurations as well as  many practical hints.

It seems that FreeRTOS is more preferable choice for described proposes because the NONOS-SDK is less advanced than FreeRTOS while the multiprocessing features are not required.  
Files: ESP SDK Sources on GitHub
Docs: Native ESP8266 Non-OS SDK by Espressif Systems

Secondly it is required to compile and install a cross-compiler toolchain for Xtensa processor architecture.

Of course, some automation procedures prepared by third-party developers can be implemented, however it is required to follow the canonical steps first in order to understand how it works.
Basic Crosstool-NG recepie
Crosstool-NG documentation

After these two requirements are completed, the first binary image based on any example project from SDK has to be at hand should have been prepared. The uploaded firmware has to should be used to demonstrate any signs of life on the hardware (ex.: the controlled diode blinking). The steps mentioned above are just the main line hints. There is still a lot of work to do.



THE TARGET
Now it is possible to insert implement our own code into ESP8266 chip. First of all, look at the native SDK API documentation:
NON-OS API Reference  
Programming Guide

The programming is based on the interrupt callbacks. There is just one specific rule: statistically callbacks processing should not overlap. This programming style permits to achieve the maximum level of the real-time processing accessible on embedded CPUs. Usually an interrupt call would take 2-5 processor cycles. The physical limit comes from is caused by the inevitable internal chip synchronization needed to join synchronous sequential CPU assembler pipeline with asynchronous external events. The true real-time can be achieved on FPGA's only, however with one remark that is a PLL synchronization (that one lies within rising/falling edge width of the processing cycle)

The first interesting point is to measure and explain ESP8266 hardware limits on Wi-Fi data transmission. What is the maximum TD speed? How stable is it? Measure it's temperature dependence and study automatic frequency correction algorithms.
(Lic.)

The next question is speed and stability of the real data transmission. The first data source is an embedded ADC. The second data source is SPI interface. An optimal solutions overview is needed to be done and experimentally tested.
(Maestria)

In this course the maximum speed and quality acquisition task will be mathematically described. For sure, there will appear the optimal policy problem which has one of the possible solutions fully described in the Game Theory. That is what is a main stream and a theoretical base in developmrnt of professional IoTs. Do not think that these questions  are already solved - in the most cases they have met a happy path only. Recent discoveries in the sense of the formulated questions and electronic solutions has to be analyzed.
(Doctorado)