![]() And counting microseconds turns out to be a far less demanding task, power-wise, than checking for incoming network requests about a hundred thousand times per second. Why does this work? Adding delay(1) actually causes the CPU to spend the vast majority of its time in that one millisecond loop. So what’s to be done? The next best thing turns out to be a simple delay(1) statement right after each server.handleClient() call in the main loop. However, that level of control just isn’t possible in the context of the Arduino’s ESP8266WebServer library. A simple web server like this one spends most of its time waiting.Ī far more efficient way to handle things would be to launch server.handleClient() only when an incoming network connection calls for it, and put the hardware to sleep whenever that is not happening. That process checks for incoming HTTP connections, handles them, sends responses, exits - and then does it all over again. In it, the main loop essentially consists of calling server.handleClient() forever. uses the “hello world” example from ESP8266WebServer to explain. The reason this works isn’t because of some strange bug or oddball feature - it’s really just a side effect of how the hardware operates under the hood. Perhaps a better summary of the above: in a multitasking application, _delay_ms() is not deterministic.Arduino has a library for quickly and easily setting up a simple web server on an ESP8622-based board, and found that power consumption on an ESP-01 can be reduced a considerable amount by simply inserting a 1 ms delay in the right place. Otherwise, a task with a higher priority may preempt the task that calls _delay_ms() as it is delaying (that is, _delay_ms() will not yield control immediately). Are you sure it's not a platform specific function? My guess is, if the highest priority task calls _delay_ms(), then it will result in a busy wait. I don't think _delay_ms() is part of the FreeRTOS library. I think you get the idea already, but if you have multiple tasks created, then vTaskDelay() will put the running task into the "Blocked" state for the specified number of tick interrupts (not milliseconds!) and allow the task with the next highest priority to run until it yields control (or gets preempted, depending on your FreeRTOS configuration). Calling vTaskDelay(0) is equivalent to calling taskYIELD(). Specifying a delay period of zero ticks will not result in the calling task being placed into the Blocked state, but will result in the calling task yielding to any Ready state tasks that share its priority. ![]() Places the task that calls vTaskDelay() into the Blocked state for a fixed number of tick interrupts. Note: the two given example tasks have different priorities. What happens with the flow of the program when the tasks are provided with a vTaskDelay versus _delay_ms? Tasks with _delay_ms static void TaskDecrement(void *param) Tasks with vTaskDelay static void TaskDecrement(void *param) XTaskCreate(TaskDecrement, (const portCHAR *)"down", 256, NULL, 1, NULL ) XTaskCreate(TaskIncrement, (const portCHAR *)"up", 256, NULL, 2, NULL ) ![]() I cannot seem to find information or a detailed explanation about the behavioral differences between the following functions in a FreeRTOS task: ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |