ESP8266 RTOS SDK

The Virtual Filesystem (VFS) component provides a unified interface for drivers that perform operations on file-like objects. This includes real filesystems (like FAT or SPIFFS) and device drivers that implement a file-like interface.

By using VFS, standard C library functions such as fopen and fprintf can interact with various FS drivers. Each driver is associated with a path prefix (mount point). When a file is opened via a path, the VFS component identifies the correct driver based on the prefix and forwards the call.

libsodium is a portable, cross-compilable software library designed for easy-to-use cryptographic operations. It is a fork of NaCl with a compatible API and provides core operations for:

• Encryption and decryption
• Digital signatures
• Password hashing
• Other core cryptographic tools

It is designed to be used as a foundation for building higher-level cryptographic applications.

The ESP8266 SPI driver provides two performance modes for use as an SPI slave. Because the ESP8266 lacks DMA, it is limited to a maximum of 64 bytes per transmission.

• normal_performance: Designed for standard SPI speed requirements. It provides easy-to-use SPI slave APIs, but performance is lower because the software schedules between tasks and interrupts during data transfer.
• high_performance: Designed for high-speed SPI requirements. Data transmission and reception are handled entirely within interrupts. For optimal results, the host MCU (SPI master) should also handle SPI transmission within an interrupt to avoid performance degradation caused by software task scheduling.

The OpenSSL component in this SDK is not a standalone OpenSSL implementation. It serves as a wrapper for applications that use the OpenSSL API, delegating the actual cryptographic work to the mbedTLS library.

Requirements:

• To compile code using these APIs, you must have the mbedtls library and its header files available.

Limitations:

• Only the OpenSSL APIs explicitly documented in this component are supported. Calling undocumented OpenSSL functions will result in compilation errors (linking failures) or runtime errors.

The WLC divides the memory defined by start_addr and full_mem_size into three distinct regions:

1. Configuration: Stores configuration information. This region can be used to recover the WLC from a memory dump.
2. Data: The region where user data is actually stored.
3. States: Stores internal WLC state information. This region contains two copies of the state to prevent data loss if a power failure occurs during a state write. If one copy is corrupted, the WLC recovers from the other and overwrites the broken copy.

Protocomm uses Google Protobuf to define language, transport, and architecture-agnostic protocol communication packets. The packet structures are defined across the following files:

• constants.proto: Defines the Status structure used to convey the success or failure of a single protocomm transaction.
• sec0.proto: Defines the Security0 Command and Response packet structures.
• sec1.proto: Defines the Security1 Command and Response packet structures.
• session.proto: Defines the protocomm transaction packets for session establishment (contains a Security packet as a payload).

The Handshake pin is critical for ensuring data integrity and managing asynchronous transfers between the MCU and ESP8266. It serves two primary functions:

1. ESP8266 Notification: When the ESP8266 is ready to receive or send data, it pulls this pin high. This triggers a GPIO interrupt on the MCU, prompting the MCU to perform the necessary SPI read/write.
2. MCU Synchronization: When the MCU finishes sending a data chunk, it must wait for a GPIO interrupt triggered by the ESP8266. The ESP8266 pulls the pin high after it has successfully extracted the data from the SPI register, allowing the MCU to proceed with the next transaction.

The FreeRTOS kernel within the ESP8266 RTOS SDK is organized into common core components and hardware-specific portable layers:

• Core Kernel Components: Located in FreeRTOS/Source, the kernel is primarily contained within list.c, queue.c, and tasks.c.
• Optional Co-routines: croutine.c provides optional co-routine functionality, typically reserved for extremely memory-constrained systems.
• Hardware/Compiler Portability: Files specific to the microcontroller or compiler are located in FreeRTOS/Source/Portable.
• Kernel Headers: All real-time kernel header files are located in FreeRTOS/Source/include.

SPIFFS (SPI Flash File System) is designed for SPI NOR flash devices on embedded targets with small RAM footprints.

Key Features:

• Low RAM usage using statically sized buffers.
• POSIX-like API (open, close, read, write, seek, stat, etc.).
• Static wear leveling and built-in consistency checks.
• Highly configurable.

Limitations:

• No Directory Support: It produces a flat file structure. A path like tmp/myfile.txt is treated as a single filename rather than a file in a directory.
• Non-Realtime: Write operation latency can vary significantly.
• Scalability: Not intended for devices larger than ~128MB due to RAM constraints.
• No Bad Block Management: Does not currently detect or handle bad blocks.
• Configuration-Specific: Each configuration requires its own binary.