- Mon Jul 30, 2018 9:28 am
I had questions like yours when I first approached non-os-sdk.
I found it very helpful the "code structure" section in the "2c-esp8266_non_os_sdk_api" manual.
I'm quoting it below but my suggestions are:
+ think about non-os-sdk like something similar to node.js (an asynchronous event driven engine) not an operating system
+ let your application be driven by events (wifi events, communications events, interrupts ...)
+ in case you need to do polling or periodic tasks use timers (checkout differences between sw and hw timers)
+ the only thing you have to care about is that your code execution does not take that long to trigger the watchdog
Code: Select all
The non-OS SDK is meant to be used for applications where users require complete
control over the execution sequence of code. Due to a lack of operating system, the non-
OS SDK does not schedule tasks or preempt the user functions.
The non-OS SDK is most suitable for use in event-driven applications. As there is no RTOS
overhead, the non-OS SDK does not impose stack size restrictions or execution time slots
on any user functions.
•The non-OS SDK does not implement user task scheduling like RTOS based
systems do. The non-OS SDK uses four types of functions:
- Application functions
- Callback functions
- Interrupt service routines (ISRs)
- User tasks
Application functions refer to the usual type of C functions used in embedded C
programming. These functions must be called by another function. Application
functions may be attributed with ICACHE_FLASH_ATTR to fetch and execute programs
from the flash. IRAM_ATTR-attributed functions are stored in the iRAM prior to
Callback functions refer to functions that are not called directly from the user
program. Callback functions are executed by the non-OS SDK core when a system
event occurs. This enables the programmer to respond to real-time events without
using RTOS or polling for events.
To program a callback function, users first need to register the callback function using
the corresponding register_cb API. Examples of callback functions include timer
callback functions and network event callback functions.
Interrupt Service Routines (ISRs) are simply callback functions of a special type.
These functions are called when a hardware interrupt occurs. When an interrupt is
enabled, a corresponding interrupt handler functions must be registered. Note that
ISRs must be attributed as IRAM_ATTR.
User tasks can be classified according to three priority levels: 0, 1, 2. Priority level
has the following order: 2>1>0. Non-OS SDK can only support up to three tasks at a
time. One priority level for one task.
•User tasks are normally used when a function cannot be called directly. To create a
user task, please refer to the API description of system_os_task() in this document.
For example, espconn_disconnect() API may not be called from within an espconn
callback, therefore a user task must be created within the espconn callback to
As stated earlier, the non-OS SDK does not preempt tasks or switch context. Users
are responsible for the proper execution of code and the user code must not occupy
the CPU on a particular function for too long. This may cause a watchdog reset and
prompt ESP8266 to reboot.
If for some reason the user application must execute a task for too long (say, longer
than 500 ms), it is recommended that the system_soft_wdt_feed() API be called
often to reset the WDT. Disabling the softWDT is not recommended.