FreeRTOS

Started by tha, October 08, 2021, 08:24:01 AM

Previous topic - Next topic

tha

configUSE_16_BIT_TICKS

Time ที่ถูกวัดเป็น 'ticks' - ซึ่งคือจำนวนครั้งที่ the tick interrupt ปฏิบัติแล้วตั้งแต่ the RTOS kernel ถูกสตาร์ทมาแล้ว. The tick count ถูกเก็บไว้ในตัวแปรประเภท TickType_t.

การกำหนด configUSE_16_BIT_TICKS เป็น 1 เป็นเหตุให้ TickType_t ถูกกำหนด (typedef'ed) เป็น an unsigned 16bit type. การกำหนด configUSE_16_BIT_TICKS เป็น 0 เป็นเหตุให้ TickType_t ถูกกำหนด (typedef'ed) เป็น an unsigned 32bit type.

การใช้ a 16 bit type จะช่วยปรับปรุงประสิทธิภาพการทำงานบน 8 and 16 bit architectures, แต่จำกัด the maximum specifiable time period เป็น 65535 'ticks'. ดังนั้น, ถือว่า a tick frequency of 250Hz, the maximum time a task สามารถ delay หรือ block เมื่อ a 16bit counter ถูกใช้คือ 262 seconds, เปรียบเทียบกับ 17179869 seconds เมื่อใช้ a 32bit counter.

tha

configIDLE_SHOULD_YIELD

parameter นี้ควบคุมพฤติกรรมของ tasks ที่ the idle priority. มันมีผลเฉพาะถ้า:

     1. The preemptive scheduler กำลังถูกใช้.
     2. The application สร้าง tasks ที่รันที่ the idle priority

ถ้า configUSE_TIME_SLICING ถูกเซ็ตเป็น 1 (หรือไม่ได้กำหนด) ดังนั้น tasks ที่แชร์ the same priority จะแบ่งเวลา. ถ้าไม่มี the tasks ใดได้รับการจองไว้ก่อนดังนั้นก็อาจสันนิษฐานได้ว่าแต่ละ task ที่ given priority จะถูกจัดสรรเวลาในการประมวลผลที่เท่ากัน - และถ้า the priority อยู่เหนือ the idle priority ดังนั้นจะเป็นกรณีนี้จริง.

เมื่อ tasks แชร์ the idle priority พฤติกรรมสามารถแตกต่างกันเล็กน้อย. ถ้า configIDLE_SHOULD_YIELD ถูกเซ็ตเป็น 1 ดังนั้น the idle task จะส่งผลทันทีถ้า task อื่นใดๆที่ the idle priority พร้อมที่จะรัน.  สิ่งนี้ทำให้แน่ใจได้ว่าเวลาที่น้อยที่สุดถูกใช้ใน the idle task เมื่อ application tasks มีให้ใช้ประโยชน์สำหรับการจัดกำหนดการ. อย่างไรก็ตามพฤติกรรมนี้สามารถมีผลที่ไม่พึงประสงค์ (ขึ้นอยู่กับความต้องการของ your application) ดังที่แสดงด้านล่าง:

         

The diagram ข้างบนแสดง the execution pattern ของ four tasks ที่ทั้งหมดกำลังรันที่ the idle priority. Tasks A, B and C เป็น application tasks. Task I เป็น the idle task. A context switch เกิดขึ้นด้วยคาบเวลาประจำที่เวลา T0, T1, ..., T6. เมื่อ the idle task ส่งผลให้ task A สตาร์ทเพื่อปฏิบัติ - แต่ the idle task ได้กินบางส่วนของ the current time slice ไปแล้ว. นี้ส่งผลให้ task I and task A แชร์อย่างมีประสิทธิภาพ the same time slice. The application tasks B and C ดังนั้นได้รับ processing time มากกว่า the application task A.

สถานการณ์นี้สามารถถูกหลีกเลี่ยงโดย:

     •  ถ้าเหมาะสม, ใช้ an idle hook แทน tasks ที่แยกกันที่ the idle priority.
     •  สร้าง application tasks ทั้งหมดที่ a priority ที่ใหญ่กว่า the idle priority.
     •  ตั้งค่า configIDLE_SHOULD_YIELD เป็น 0.

การตั้งค่า configIDLE_SHOULD_YIELD เป็น 0 ป้องกัน the idle task จากการให้ processing time จนกระทั่งสิ้นสุด its time slice. นี้ทำให้แน่ใจว่า tasks ทั้งหมดที่ the idle priority ถูกจัดสรรในจำนวนที่เท่ากันของ processing time (ถ้าไม่มี the tasks ใดได้รับการจองไว้ล่วงหน้า) - แต่ด้วยต้นทุนในสัดส่วนที่มากขึ้นของเวลาการประมวลผลทั้งหมดที่จัดสรรให้กับ the idle task.

tha

configUSE_TASK_NOTIFICATIONS

การตั้งค่า configUSE_TASK_NOTIFICATIONS เป็น 1 (หรือทิ้งไว้ไม่กำหนด configUSE_TASK_NOTIFICATIONS) จะรวม direct to task notification functionality และ its associated API ในการบิ้วด์.

การตั้งค่า configUSE_TASK_NOTIFICATIONS เป็น 0 จะไม่รวม direct to task notification functionality และ its associated API จากการบิ้วด์.

แต่ละ task กิน 8 additional bytes of RAM เมื่อ direct to task notifications ถูกรวมในการบิ้วด์.

configTASK_NOTIFICATION_ARRAY_ENTRIES

แต่ละ RTOS task มี an array of task notifications. configTASK_NOTIFICATION_ARRAY_ENTRIES ตั้งค่า the number of indexes ใน the array.

ก่อนหน้า FreeRTOS V10.4.0 tasks มีเพียง a single notification value, ไม่ an array of values, ดังนั้นสำหรับความเข้ากันได้แบบย้อนหลัง configTASK_NOTIFICATION_ARRAY_ENTRIES ค่าเริ่มต้นเป็น 1 ถ้ามันถูกทิ้งไว้ไม่กำหนด.


tha

configUSE_MUTEXES

เซ็ตเป็น 1 เพื่อรวม mutex functionality ใน the build, หรือ 0 เพื่อละเว้น mutex functionality จาก the build. ผู้อ่านควรทำความค้นเคยด้วยตัวเองกับความแตกต่างระหว่าง mutexes and binary semaphores ที่เกี่ยวข้องกับ the FreeRTOS functionality.

configUSE_RECURSIVE_MUTEXES

เซ็ตเป็น 1 เพื่อรวม recursive mutex functionality ใน the build, หรือ 0 เพื่อละเว้น recursive mutex functionality จาก the build.

configUSE_COUNTING_SEMAPHORES

เซ็ตเป็น 1 เพื่อรวม counting semaphore functionality in the build, หรือ 0 เพื่อละเว้น counting semaphore functionality จาก the build.

tha

configUSE_ALTERNATIVE_API

เซ็ตเป็น 1 เพื่อรวม the 'alternative' queue functions in the build, หรือ 0 เพื่อละเว้น the 'alternative' queue functions จาก the build. The alternative API ถูกอธิบายไว้ภายใน the queue.h header file. The alternative API เลิกใช้แล้วและไม่ควรใช้ในการออกแบบใหม่.

configCHECK_FOR_STACK_OVERFLOW

The stack overflow detection page อธิบายการใช้ของ parameter นี้.

tha

configQUEUE_REGISTRY_SIZE

The queue registry มีจุดประสงค์สองประการ ซึ่งทั้งสองอย่างนี้เกี่ยวข้องกับ RTOS kernel aware debugging:

     1. มันยอมให้ a textual name ถูกเกี่ยวข้องกับ a queue สำหรับง่ายต่อ queue identification ภายใน a debugging GUI.
     2. มันบรรจุ the information ที่ต้องการโดย a debugger เพื่อค้นหาแต่ละ registered queue and semaphore.

The queue registry ไม่มีจุดประสงค์เว้นแต่คุณกำลังใช้ a RTOS kernel aware debugger.

configQUEUE_REGISTRY_SIZE กำหนด the maximum number of queues and semaphores ที่สามารถถูก registered. มีเพียง queues and semaphores เหล่านั้นที่คุณต้องการจะดูโดยใช้ a RTOS kernel aware debugger จำเป็นต้องถูก registered. ดู the API reference documentation for vQueueAddToRegistry() and vQueueUnregisterQueue() สำหรับข้อมูลที่เพิ่มขึ้น.

configUSE_QUEUE_SETS

เซ็ตเป็น 1 เพื่อรวม queue set functionality (ความสามารถในการ block, หรือ pend, บนหลาย queues and semaphores), หรือ 0 เพื่อละเว้นt queue set functionality.

tha

configUSE_TIME_SLICING

โดยค่าเริ่มต้น (ถ้า configUSE_TIME_SLICING ไม่ถูกกำหนด, หรือถ้า configUSE_TIME_SLICING ถูกกำหนดเป็น 1) FreeRTOS ใช้ prioritised preemptive scheduling ด้วย time slicing. นั่นหมายความว่า the RTOS scheduler จะรัน the highest priority task เสมอที่อยู่ใน the Ready state, และจะ switch ระหว่าง tasks of equal priority บนทุก RTOS tick interrupt.  ถ้า configUSE_TIME_SLICING ถูกเซ็ตเป็น 0 ดังนั้น the RTOS scheduler จะยังคงรัน the highest priority task ที่อยู่ใน the Ready state, แต่จะไม่ switch ระหว่าง tasks of equal priority เพียงเพราะว่า a tick interrupt ได้เกิดขึ้น.

tha

configUSE_NEWLIB_REENTRANT

ถ้า configUSE_NEWLIB_REENTRANT ถูกเซ็ตเป็น 1 ดังนั้น a newlib reent structure จะถูกจัดสรรสำหรับแต่ละ created task.

หมายเหตุ Newlib support ถูกรวมไว้โดยความต้องการที่ได้รับความนิยม แต่ไม่ได้ถูกใช้โดย the FreeRTOS maintainers themselves. FreeRTOS จะไม่รับผิดชอบต่อผลลัพธ์ newlib operation. ผู้ใช้ต้องทำความคุ้นเคยกับ newlib และต้องจัดให้มี system-wide implementations of the necessary stubs. ขอเตือนว่า (ในขณะที่เขียน)  the current newlib design จัดให้มีใช้ a system-wide malloc() ที่ต้องถูกจัดให้มีพร้อมด้วย locks.