You can chat about native SDK questions and issues here.
User avatar
By zephram
#75351 Hi guys,

i just began to learn ESP8266 and try to figure out how to program simple applications on it while not starving system tasks like WiFi handling etc. I know that the SoC needs to care about internal processing at least every xx msecs or so. My goal is to realize a looped function that is recalled after a minimum amount of time, without neglecting the systems need to care about its internals like wifi handlung, fedding the watchdog etc. As the NON-OS SDK does not offer a yield() function like the arduino environment i dont know exactly how to do this...

One way is to call a user routine by a timer periodically, but this will waste some amount of cpu cycles for the user task, as shown in: https://github.com/esp8266/source-code- ... ser_main.c

Another way is to let a task schedule itself after is has done its work, like in this example: https://www.penninkhof.com/2015/03/how- ... n-esp8266/

In the second example the author sets a call to: os_delay_us(1000) in order to let the system perform its tasks.

My question now is: Will the system perform its own tasks when a user task functions has returned because system tasks having higher priority anyways ? Cant the call to os_delay_us be omitted anyways because of that ?

At least i am unclear if os_delay_us(short delaytime) has the side effect of letting the system perform its tasks, like delay on arduino or sming does...

Greetings Zephram
User avatar
By petenort
#77230 Perhaps these threads will help you in this issue:

https://esp32.com/viewtopic.php?t=1137
https://bbs.espressif.com/viewtopic.php?t=1323

When I have such questions, I address them to the specialists of site AnswerShark.com and it helps me to work with my projects, as it is difficult to find different answers to the most specific topics.
User avatar
By quackmore
#77487 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

good luck!

Code: Select allThe 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
execution.
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
execute espconn_disconnect.
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.