w801 栈大小可以调吗?

线程创建时申请空间小了, 修改创建线程是分配空间就可以了, 修改 tls_os_status_t tls_os_task_create (tls_os_task_t *task,

  const char* name, 
  void  (*entry)  (void* param) , 
  void* param, 
  u8 *stk_start, 
  u32 stk_size, 
  u32 prio, 
  u32 flag) 的第 5 和 6 的参数就行了;  

Hello from Russia : ) In addition to YUN expert's answer. . .

Each task of the FreeRTOS system uses its own, individual stack. If a task was created using the xTaskCreate () API function, then the stack memory is automatically allocated from the FreeRTOS heap, and the allocated stack size is determined by the parameter passed to xTaskCreate () . If a task is created by calling xTaskCreateStatic () , memory for the task stack is pre-allocated by the application developer. Stack overflow is the most common cause of application instability. Therefore, FreeRTOS provides 2 mechanisms that can be used to help identify and fix stack problems. The option used is configured by the constant configCHECK_FOR_STACK_OVERFLOW.

Please note that these options are only available on architectures where the memory card is not segmented. Also, some processors may throw an error or exception in response to stack corruption before the FreeRTOS kernel overflow check can occur. An application must provide a stack overflow hook function unless configCHECK_FOR_STACK_OVERFLOW is set to 0. The hook function must be named vApplicationStackOverflowHook () , and have the following prototype:

void vApplicationStackOverflowHook ( TaskHandle_t xTask, signed char *pcTaskName ) ;

Here the parameters xTask and pcTaskName pass the handle and name of the problematic task to the hook function, respectively. However, it should be noted that depending on the severity of the overflow, these parameters themselves may become corrupted, in which case the pxCurrentTCB variable can be inspected directly.

Stack overflow checking introduces additional context switching overhead, so it is recommended to use this check only during the testing phase.

[Stack Overflow Detection, Method 1]

It is likely that a task's stack will reach its greatest use (greatest depth) after the RTOS kernel brings the task out of the Running state, because at that point the task context (i. e. , the current running state of the task) must be on the stack ) . At this point, the RTOS kernel can verify that the processor's stack pointer remains within the valid stack area. The stack overflow hook function will be called when the stack pointer contains a value that exceeds the allowed stack space.

This method is fast, but it is not guaranteed to catch all stack overflows. To use this method only, set configCHECK_FOR_STACK_OVERFLOW to 1.

[Stack Overflow Detection, Method 2]

When a task is created, its stack area is filled with a known value (usually byte 0xA5) . When a task exits the Running state (context switch) , the RTOS kernel can check the last 16 in valid stack space to see if they were overwritten by the task or an active interrupt. The stack overflow interception function will be called if these 16 are not in their original value.

This method is less efficient than method 1, but it is still quite fast. It is highly likely to catch stack overflows, but is not guaranteed to catch all overflows.

To use method 2 in combination with method 1, set configCHECK_FOR_STACK_OVERFLOW to 2. Method 2 cannot be used alone.

I hope this information will be useful
Very good explanation provided by my colleague:
https: //www. youtube. com/watch? v=ogaPlNG_jQo
Perhaps there is a way of simultaneous translation into Chinese