FreeRTOS वस्तुओं का स्थैतिक वितरण

डिफ़ॉल्ट रूप से, FreeRTOS सिस्टम में सभी ऑब्जेक्ट्स को गतिशील रूप से वितरित किया जाता है - कतार, सेमीफ़ोर्स, टाइमर, कार्य (थ्रेड), और म्यूटेक्स। प्रोग्रामर केवल "हीप" देखता है - वह क्षेत्र जहाँ मेमोरी को प्रोग्राम या सिस्टम के अनुरोध पर गतिशील रूप से आवंटित किया जाता है, और अंदर क्या हो रहा है, यह स्पष्ट नहीं है। कितना बचा है? अज्ञात। क्या कुछ भी आप की जरूरत से ज्यादा लेता है? कौन जानता है? व्यक्तिगत रूप से, मैं फर्मवेयर लिखने के चरण में भी मेमोरी के आयोजन की समस्याओं को हल करना पसंद करता हूं, बिना रनटाइम त्रुटियों को लाए जब मेमोरी अप्रत्याशित रूप से समाप्त हो जाती है।

यह लेख माइक्रोकंट्रोलर की स्मृति में वस्तुओं के स्थैतिक वितरण के बारे में कल की एक तार्किक निरंतरता है , जो अब केवल फ्रीट्रॉस वस्तुओं के संबंध में है। आज हम सीखेंगे कि FreeRTOS ऑब्जेक्ट्स को सांख्यिकीय रूप से कैसे रखा जाए, जो हमें अधिक स्पष्ट रूप से समझने की अनुमति देगा कि माइक्रोकंट्रोलर की रैम में क्या हो रहा है, हमारी वस्तुएं वास्तव में कैसे स्थित हैं और वे कितना कब्जा करती हैं।

लेकिन सिर्फ FreeRTOS ऑब्जेक्ट्स को लेने और शुरू करने के लिए स्टेटिकली बहुत ज्यादा इंटेलिजेंस की जरूरत नहीं होती है - संस्करण 9.0 से शुरू होकर, FreeRTOS स्टैटिकली रखी गई वस्तुओं को बनाने के लिए फंक्शन प्रदान करता है। ऐसे कार्यों के नाम में एक स्थैतिक प्रत्यय होता है और इन कार्यों में उदाहरणों के साथ उत्कृष्ट प्रलेखन होता है। हम FreeRTOS फ़ंक्शंस पर सुविधाजनक और सुंदर सी ++ रैपर लिखेंगे जो न केवल वस्तुओं को सांख्यिकीय रूप से जगह देंगे, बल्कि सभी गिबल्स को भी छिपाएंगे, साथ ही साथ एक अधिक सुविधाजनक इंटरफ़ेस प्रदान करेंगे।

यह लेख शुरुआती प्रोग्रामर के लिए अभिप्रेत है, लेकिन जो पहले से ही फ्रीआरटीओएस की मूल बातें और मल्टीथ्रेडेड कार्यक्रमों को सिंक्रनाइज़ करने की आदिमताओं से परिचित हैं। चलो चलते हैं।

FreeRTOS माइक्रोकंट्रोलर्स के लिए एक ऑपरेटिंग सिस्टम है। ठीक है, ठीक है, एक पूर्ण ओएस नहीं है, लेकिन एक पुस्तकालय जो आपको समानांतर में कई कार्यों को चलाने की अनुमति देता है। FreeRTOS कार्यों को संदेश कतारों के माध्यम से संदेशों का आदान-प्रदान करने, टाइमर का उपयोग करने, और अर्धचालक और म्यूटेक्स का उपयोग करके कार्यों को सिंक्रनाइज़ करने की अनुमति देता है।

मेरी राय में, कोई भी फ़र्मवेयर जहाँ आपको एक साथ दो (या अधिक) कार्य करने की आवश्यकता होती है, यदि आप फ्रीआरटीओएस का उपयोग करते हैं तो बहुत आसान और अधिक शान्ति से हल किया जा सकता है। उदाहरण के लिए, धीमे सेंसर से रीडिंग पढ़ें और एक ही समय में डिस्प्ले परोसें। केवल इतना है कि बिना ब्रेक, जबकि सेंसर पढ़े जाते हैं। सामान्य तौर पर, होना चाहिए! मैं अध्ययन के लिए दृढ़ता से सलाह देता हूं।

जैसा कि मैंने पिछले लेख में कहा और लिखा है, मैं वास्तव में गतिशील रूप से वस्तुओं को बनाने के दृष्टिकोण की तरह नहीं हूं अगर हम संकलन चरण में उनकी संख्या और आकार जानते हैं। यदि ऐसी वस्तुओं को सांख्यिकीय रूप से रखा जाता है, तो हम माइक्रोकंट्रोलर में मेमोरी आवंटन की एक स्पष्ट और अधिक समझ में आने वाली तस्वीर प्राप्त कर सकते हैं, और इसलिए मेमोरी अचानक समाप्त होने पर आश्चर्य से बचें।

हम उदाहरण के रूप में STM32F103C8T6 माइक्रोकंट्रोलर पर BluePill बोर्ड का उपयोग करके FreeRTOS मेमोरी संगठन के मुद्दों पर विचार करेंगे। संकलक और निर्माण प्रणाली के बारे में चिंता न करने के लिए, हम ArduinoIDE वातावरण में काम करेंगे, इस बोर्ड के लिए समर्थन स्थापित करेंगे। STM32 के लिए Arduino के कई कार्यान्वयन हैं - सिद्धांत रूप में, कोई भी करेगा। मैंने इस आलेख में बताए अनुसार एक बूटलोडर Readme.md प्रोजेक्ट के निर्देशों के अनुसार stm32duino स्थापित किया है । FreeRTOS संस्करण 10.0 को ArduinoIDE लाइब्रेरी मैनेजर के माध्यम से स्थापित किया गया है। कम्पाइलर - gcc 8.2

हम एक छोटे प्रयोगात्मक कार्य के साथ आएंगे। इस कार्य में बहुत अधिक व्यावहारिक अर्थ नहीं हो सकता है, लेकिन सभी सिंक्रनाइज़ेशन प्राइमरी जो कि फ्रीआरटीओएस में हैं, उनका उपयोग किया जाएगा। कुछ इस तरह:

• 2 कार्य (धागे) समानांतर में काम करते हैं
• एक टाइमर भी काम करता है, जो समय-समय पर सिग्नल-वेट मोड में सेमाफोर का उपयोग करके पहले कार्य को एक अधिसूचना भेजता है
• पहला कार्य, टाइमर से सूचना प्राप्त करना, कतार के माध्यम से दूसरे कार्य को एक संदेश (यादृच्छिक संख्या) भेजता है
• दूसरा संदेश प्राप्त करने के बाद, इसे कंसोल पर प्रिंट करता है
• पहले कार्य को कंसोल को कुछ प्रिंट करने दें, और ताकि वे न लड़ें कंसोल को म्यूटेक्स द्वारा संरक्षित किया जाएगा।
• कतार का आकार एक तत्व तक सीमित हो सकता है, लेकिन इसे और अधिक रोचक बनाने के लिए हमने 1000 लगा दिए

मानक कार्यान्वयन (प्रलेखन और ट्यूटोरियल के अनुसार) इस तरह दिख सकता है।

#include <STM32FreeRTOS.h> TimerHandle_t xTimer; xSemaphoreHandle xSemaphore; xSemaphoreHandle xMutex; xQueueHandle xQueue; void vTimerCallback(TimerHandle_t pxTimer) { xSemaphoreGive(xSemaphore); } void vTask1(void *) { while(1) { xSemaphoreTake(xSemaphore, portMAX_DELAY); int value = random(1000); xQueueSend(xQueue, &value, portMAX_DELAY); xSemaphoreTake(xMutex, portMAX_DELAY); Serial.println("Test"); xSemaphoreGive(xMutex); } } void vTask2(void *) { while(1) { int value; xQueueReceive(xQueue, &value, portMAX_DELAY); xSemaphoreTake(xMutex, portMAX_DELAY); Serial.println(value); xSemaphoreGive(xMutex); } } void setup() { Serial.begin(9600); vSemaphoreCreateBinary(xSemaphore); xQueue = xQueueCreate(1000, sizeof(int)); xMutex = xSemaphoreCreateMutex(); xTimer = xTimerCreate("Timer", 1000, pdTRUE, NULL, vTimerCallback); xTimerStart(xTimer, 0); xTaskCreate(vTask1, "Task 1", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY, NULL); xTaskCreate(vTask2, "Task 2", configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY, NULL); vTaskStartScheduler(); } void loop() {} 

आइए देखें कि माइक्रोकंट्रोलर की स्मृति में क्या होता है, यदि आप इस तरह के कोड को संकलित करते हैं। डिफ़ॉल्ट रूप से, सभी फ्रीआरटीओएस ऑब्जेक्ट्स को गतिशील मेमोरी में रखा जाता है। FreeRTOS स्मृति प्रबंधकों के 5 कार्यान्वयन के रूप में प्रदान करता है जिन्हें लागू करना मुश्किल है, लेकिन सामान्य तौर पर उनके पास एक ही कार्य है - FreeRTOS और उपयोगकर्ता की जरूरतों के लिए स्मृति के टुकड़े काट देना। टुकड़े या तो माइक्रोकंट्रोलर (मॉलॉक का उपयोग करके) के सामान्य ढेर से काटे जाते हैं या अपने अलग हीप का उपयोग करते हैं। हमारे लिए किस प्रकार के ढेर का उपयोग किया जाता है, यह महत्वपूर्ण नहीं है - वैसे भी, हम ढेर के अंदर नहीं दिख सकते।

उदाहरण के लिए, FreeRTOS नाम के ढेर के लिए यह इस तरह दिखेगा (objdump उपयोगिता से आउटपुट)

 ... 200009dc l O .bss 00002000 ucHeap ... 

यानी हम एक बड़ा टुकड़ा देखते हैं, जिसके अंदर सभी FreeRTOS ऑब्जेक्ट्स में कटौती की जाती है - सेमीफॉरेस, म्यूटेक्स, टाइमर, कतार, और यहां तक ​​कि कार्य भी। अंतिम 2 अंक बहुत महत्वपूर्ण हैं। तत्वों की संख्या के आधार पर, कतार काफी बड़ी हो सकती है, और कार्यों को ढेर के कारण बहुत अधिक जगह लेने की गारंटी दी जाती है, जिसे कार्य के साथ भी आवंटित किया जाता है।

हां, यह मल्टीटास्किंग का एक माइनस है - प्रत्येक कार्य का अपना स्टैक होगा। इसके अलावा, स्टैक पर्याप्त बड़ा होना चाहिए ताकि इसमें न केवल कार्य के केवल कॉल और स्थानीय चर शामिल हों, बल्कि यदि ऐसा होता है, तो स्टैक स्टैक भी। खैर, चूंकि किसी भी समय एक रुकावट हो सकती है, तो हर कार्य में रुकावट के मामले में स्टैक पर एक रिजर्व होना चाहिए। इसके अलावा, CortexM microcontrollers नेस्टेड इंटरप्ट्स हो सकते हैं, इसलिए स्टैक को सभी इंटरप्ट्स को समायोजित करने के लिए पर्याप्त बड़ा होना चाहिए यदि वे एक साथ होते हैं।

टास्क स्टैक का आकार तब सेट किया जाता है जब कार्य xTaskCreate फ़ंक्शन के पैरामीटर द्वारा बनाया जाता है। स्टैक का आकार configMINIMAL_STACK_SIZE पैरामीटर (FreeRTOSConfig.h कॉन्फ़िगरेशन फ़ाइल में निर्दिष्ट) से कम नहीं हो सकता है - यह इंटरप्ट के लिए एक ही रिजर्व है। ढेर का आकार configTOTAL_HEAP_SIZE पैरामीटर द्वारा सेट किया गया है और इस मामले में 8kb है।


बंद करो, चर xTimer, xQueue, xSemaphore, और xMutex क्या हैं? क्या वे उन वस्तुओं का वर्णन नहीं करते जिनकी हमें आवश्यकता है? नहीं, ये केवल हैंडल हैं - एक निश्चित (अपारदर्शी) संरचना की ओर संकेत करते हैं, जो खुद को सिंक्रनाइज़ेशन ऑब्जेक्ट का वर्णन करता है

 200009cc g O .bss 00000004 xTimer 200009d0 g O .bss 00000004 xSemaphore 200009cc g O .bss 00000004 xQueue 200009d4 g O .bss 00000004 xMutex 

जैसा कि मैंने पहले ही उल्लेख किया है, मैं पिछले लेख की तरह ही इस सारी गड़बड़ी को ठीक करने का प्रस्ताव करता हूं - हम अपनी सभी वस्तुओं को संकलित अवस्था में वैधानिक रूप से वितरित करेंगे। स्थिर वितरण फ़ंक्शंस उपलब्ध हो जाते हैं यदि configSUPPORT_STATIC_ALLOCATION पैरामीटर फ्रीट्रीम कॉन्फ़िगरेशन फ़ाइल में 1 पर सेट है।

चलो लाइनों के साथ शुरू करते हैं। यहां बताया गया है कि FreeRTOS पर प्रलेखन कैसे कतार आवंटित करने की पेशकश करता है

 struct AMessage { char ucMessageID; char ucData[ 20 ]; }; #define QUEUE_LENGTH 10 #define ITEM_SIZE sizeof( uint32_t ) // xQueueBuffer will hold the queue structure. StaticQueue_t xQueueBuffer; // ucQueueStorage will hold the items posted to the queue. Must be at least // [(queue length) * ( queue item size)] bytes long. uint8_t ucQueueStorage[ QUEUE_LENGTH * ITEM_SIZE ]; void vATask( void *pvParameters ) { QueueHandle_t xQueue1; // Create a queue capable of containing 10 uint32_t values. xQueue1 = xQueueCreate( QUEUE_LENGTH, // The number of items the queue can hold. ITEM_SIZE // The size of each item in the queue &( ucQueueStorage[ 0 ] ), // The buffer that will hold the items in the queue. &xQueueBuffer ); // The buffer that will hold the queue structure. // The queue is guaranteed to be created successfully as no dynamic memory // allocation is used. Therefore xQueue1 is now a handle to a valid queue. // ... Rest of task code. } 

इस उदाहरण में, कतार को तीन चरों द्वारा वर्णित किया गया है:

• UcQueueStorage सरणी वह है जहाँ कतार तत्वों को रखा जाएगा। कतार का आकार उपयोगकर्ता द्वारा प्रत्येक कतार के लिए व्यक्तिगत रूप से निर्धारित किया जाता है।
• XQueueBuffer संरचना - यहाँ कतार का विवरण और स्थिति, वर्तमान आकार, लंबित कार्यों की सूची और साथ ही कतार के साथ काम करने के लिए FreeRTOS द्वारा आवश्यक अन्य विशेषताओं और क्षेत्रों को जानता है। वैरिएबल का नाम, मेरी राय में, पूरी तरह से सफल नहीं है, फ्रीआरटीओएस में ही इस चीज को क्यूयूडेफिनेशन (कतार का विवरण) कहा जाता है।
• चर xQueue1 कतार (हैंडल) की पहचानकर्ता है। सभी कतार प्रबंधन कार्य, साथ ही कुछ अन्य (उदाहरण के लिए, टाइमर, सेमाफोर और म्यूटेक्स के साथ काम करने के लिए आंतरिक कार्य) इस तरह के हैंडल को स्वीकार करते हैं। वास्तव में, यह क्यूवडिफाइनमेंट का एक संकेतक है, लेकिन हम यह नहीं जानते हैं (जैसा कि यह था), और इसलिए हैंडल को अलग से खींचना होगा।

उदाहरण के लिए, निश्चित रूप से, कोई समस्या नहीं है। लेकिन व्यक्तिगत रूप से, मेरे पास प्रति इकाई 3 वैरिएबल नहीं है। एक वर्ग जो इसे अलग कर सकता है वह पहले से ही इसके लिए पूछ रहा है। केवल एक समस्या - प्रत्येक कतार का आकार भिन्न हो सकता है। एक स्थान पर आपको एक बड़ी कतार की आवश्यकता होती है, दूसरे में कुछ तत्व पर्याप्त होते हैं। चूँकि हम सांख्यिकीय रूप से कतारबद्ध करना चाहते हैं, इसलिए हमें किसी भी समय इस आकार को संकलन के समय निर्दिष्ट करना चाहिए। आप इसके लिए टेम्पलेट का उपयोग कर सकते हैं।

 template<class T, size_t size> class Queue { QueueHandle_t xHandle; StaticQueue_t x QueueDefinition; T xStorage[size]; public: Queue() { xHandle = xQueueCreateStatic(size, sizeof(T), reinterpret_cast<uint8_t*>(xStorage), &xQueueDefinition); } bool receive(T * val, TickType_t xTicksToWait = portMAX_DELAY) { return xQueueReceive(xHandle, val, xTicksToWait); } bool send(const T & val, TickType_t xTicksToWait = portMAX_DELAY) { return xQueueSend(xHandle, &val, xTicksToWait); } }; 

उसी समय, संदेश भेजने और प्राप्त करने के कार्य, जो हमारे लिए तुरंत सुविधाजनक थे, इस वर्ग में भी बसे।

कतार को वैश्विक चर के रूप में घोषित किया जाएगा, कुछ इस तरह

 Queue<int, 1000> xQueue; 

संदेश भेजना

  xQueue.send(value); 

संदेश प्राप्त करें

  int value; xQueue.receive(&value); 

अब हम सेमाफोरस से निपटते हैं। और यद्यपि तकनीकी रूप से (फ्रीआरटीओएस के अंदर) सेमाफोर और म्यूटेक्स को कतारों के माध्यम से कार्यान्वित किया जाता है, शब्दार्थ ये 3 अलग-अलग प्राइमरी हैं। इसलिए, हम उन्हें अलग-अलग कक्षाओं में लागू करेंगे।

सेमाफोर वर्ग का कार्यान्वयन काफी तुच्छ होगा - यह बस कई चर को संग्रहीत करता है और कई कार्यों की घोषणा करता है।

 class Sema { SemaphoreHandle_t xSema; StaticSemaphore_t xSemaControlBlock; public: Sema() { xSema = xSemaphoreCreateBinaryStatic(&xSemaControlBlock); } BaseType_t give() { return xSemaphoreGive(xSema); } BaseType_t take(TickType_t xTicksToWait = portMAX_DELAY) { return xSemaphoreTake(xSema, xTicksToWait); } }; 

सेमाफोर घोषणा

 Sema xSema; 

सेमीफोर कैप्चर

  xSema.take(); 

सेमफोर रिलीज

  xSema.give(); 

अब म्यूटेक्स

 class Mutex { SemaphoreHandle_t xMutex; StaticSemaphore_t xMutexControlBlock; public: Mutex() { xMutex = xSemaphoreCreateMutexStatic(&xSemaControlBlock); } BaseType_t lock(TickType_t xTicksToWait = portMAX_DELAY) { return xSemaphoreTake(xMutex, xTicksToWait); } BaseType_t unlock() { return xSemaphoreGive(xMutex); } }; 

जैसा कि आप देख सकते हैं, म्यूटेक्स वर्ग सेमीफ़ोर वर्ग के लगभग समान है। लेकिन जैसा कि मैंने शब्दार्थ से कहा, ये अलग-अलग संस्थाएँ हैं। इसके अलावा, इन वर्गों के इंटरफेस पूर्ण नहीं हैं, और वे पूरी तरह से अलग दिशाओं में विस्तार करेंगे। तो, getFromISR () और takeFromISR () विधियों को अर्ध-विराम के साथ जोड़कर कार्य किया जा सकता है, ताकि बाधा में सेमाफोर के साथ काम किया जा सके, जबकि म्यूटेक्स में केवल tryLock () विधि जोड़ी गई है - यह शब्दार्थ रूप से कोई अन्य संक्रिया नहीं है।


म्यूटेक्स का उपयोग स्टाइल सी, अर्थात् में किया जा सकता है। सीधे कॉल लॉक () / अनलॉक ()। लेकिन चूंकि हम सी ++ में लिख रहे हैं, इसलिए हम आरएआईआई के आकर्षण का लाभ उठा सकते हैं और एक अधिक सुविधाजनक आवरण लिख सकते हैं जो म्यूटेक्स को स्वयं ही कैप्चर और रिलीज़ करेगा।

 class MutexLocker { Mutex & mtx; public: MutexLocker(Mutex & mutex) : mtx(mutex) { mtx.lock(); } ~MutexLocker() { mtx.unlock(); } }; 

स्कोप छोड़ते समय, म्यूटेक्स को स्वचालित रूप से मुक्त किया जाएगा।

यह विशेष रूप से सुविधाजनक है यदि फ़ंक्शन से कई निकास हैं और आपको मुक्त संसाधनों की आवश्यकता को लगातार याद रखने की आवश्यकता नहीं है।

  MutexLocker lock(xMutex); Serial.println(value); } // mutex will be unlocked here 

अब समय की बारी है।

 class Timer { TimerHandle_t xTimer; StaticTimer_t xTimerControlBlock; public: Timer(const char * const pcTimerName, const TickType_t xTimerPeriodInTicks, const UBaseType_t uxAutoReload, void * const pvTimerID, TimerCallbackFunction_t pxCallbackFunction) { xTimer = xTimerCreateStatic(pcTimerName, xTimerPeriodInTicks, uxAutoReload, pvTimerID, pxCallbackFunction, &xTimerControlBlock); } void start(TickType_t xTicksToWait = 0) { xTimerStart(xTimer, xTicksToWait); } }; 

सामान्य तौर पर, यहां सब कुछ पिछली कक्षाओं के समान है, मैं विस्तार से नहीं रहूंगा। शायद एपीआई वांछित होने के लिए बहुत कुछ छोड़ देता है, ठीक है, या कम से कम विस्तार की आवश्यकता है। लेकिन मेरा लक्ष्य सिद्धांत को दिखाना है, न कि उसे उत्पादन की स्थिति में लाना है।

और अंत में, कार्य। प्रत्येक कार्य में एक स्टैक होता है और अग्रिम में स्मृति में रखा जाना चाहिए। हम उसी तकनीक का उपयोग करेंगे जैसे कतारों के साथ - हम एक टेम्प्लेट क्लास लिखेंगे

 template<const uint32_t ulStackDepth> class Task { protected: StaticTask_t xTaskControlBlock; StackType_t xStack[ ulStackDepth ]; TaskHandle_t xTask; public: Task(TaskFunction_t pxTaskCode, const char * const pcName, void * const pvParameters, UBaseType_t uxPriority) { xTask = xTaskCreateStatic(pxTaskCode, pcName, ulStackDepth, pvParameters, uxPriority, xStack, &xTaskControlBlock); } }; 

चूंकि कार्य ऑब्जेक्ट अब वैश्विक चर के रूप में घोषित किए जाते हैं, इसलिए उन्हें मुख्य () कहने से पहले - वैश्विक चर के रूप में आरंभीकृत किया जाएगा। इसका मतलब यह है कि कार्यों को स्थानांतरित किए जाने वाले मापदंडों को इस स्तर पर भी जाना जाना चाहिए। इस बारीकियों को ध्यान में रखा जाना चाहिए यदि आपके मामले में कुछ ऐसा पारित किया गया है जिसे कार्य बनाने से पहले गणना करने की आवश्यकता है (मेरे पास केवल NULL है)। यदि यह अभी भी आपको सूट नहीं करता है, तो पिछले लेख से स्थानीय स्थिर चर के साथ विकल्प पर विचार करें ।

संकलित करें और त्रुटि प्राप्त करें:

 tasks.c:(.text.vTaskStartScheduler+0x10): undefined reference to `vApplicationGetIdleTaskMemory' timers.c:(.text.xTimerCreateTimerTask+0x1a): undefined reference to `vApplicationGetTimerTaskMemory' 

ये रही बात। प्रत्येक OS का एक विशेष कार्य है - आइडल टास्क (डिफ़ॉल्ट कार्य, कुछ भी नहीं करने का कार्य)। ऑपरेटिंग सिस्टम इस कार्य को करता है यदि अन्य सभी कार्य नहीं किए जा सकते हैं (उदाहरण के लिए, नींद, या किसी चीज़ की प्रतीक्षा)। सामान्य तौर पर, यह सबसे सामान्य कार्य है, केवल सबसे कम प्राथमिकता के साथ। लेकिन यहाँ इसे फ्रीआरटीओएस कर्नेल के अंदर बनाया जा रहा है और हम इसके निर्माण को प्रभावित नहीं कर सकते हैं। लेकिन चूंकि हमने कार्यों को सांख्यिकीय रूप से रखना शुरू कर दिया है, हमें किसी तरह ओएस को यह बताने की आवश्यकता है कि आप नियंत्रण इकाई और इस कार्य के ढेर को कहां रखना चाहते हैं। यही FreeRTOS है और हमें एक विशेष फ़ंक्शन vApplicationGetIdleTaskMemory () को परिभाषित करने के लिए कहता है।

इसी तरह की स्थिति टाइमर के कार्य के साथ है। फ्रीआरटीओएस सिस्टम में टाइमर अपने दम पर नहीं रहते हैं - ओएस में एक विशेष कार्य कताई है, जो इन टाइमर का कार्य करता है। और इस कार्य के लिए एक नियंत्रण ब्लॉक और एक स्टैक की भी आवश्यकता होती है। और ठीक उसी तरह, OS हमें यह बताने के लिए कहता है कि वे vApplicationGetTimerTaskMemory () फ़ंक्शन का उपयोग कहां कर रहे हैं।

कार्य स्वयं तुच्छ हैं और बस इसी बिंदुओं को सांख्यिकीय रूप से आवंटित वस्तुओं पर वापस लौटाते हैं।

 extern "C" void vApplicationGetIdleTaskMemory( StaticTask_t **ppxIdleTaskTCBBuffer, StackType_t **ppxIdleTaskStackBuffer, uint32_t *pulIdleTaskStackSize) { static StaticTask_t Idle_TCB; static StackType_t Idle_Stack[configMINIMAL_STACK_SIZE]; *ppxIdleTaskTCBBuffer = &Idle_TCB; *ppxIdleTaskStackBuffer = Idle_Stack; *pulIdleTaskStackSize = configMINIMAL_STACK_SIZE; } extern "C" void vApplicationGetTimerTaskMemory (StaticTask_t **ppxTimerTaskTCBBuffer, StackType_t **ppxTimerTaskStackBuffer, uint32_t *pulTimerTaskStackSize) { static StaticTask_t Timer_TCB; static StackType_t Timer_Stack[configTIMER_TASK_STACK_DEPTH]; *ppxTimerTaskTCBBuffer = &Timer_TCB; *ppxTimerTaskStackBuffer = Timer_Stack; *pulTimerTaskStackSize = configTIMER_TASK_STACK_DEPTH; } 

आइए देखें कि हमें क्या मिला।



पूरे कार्यक्रम के लिए कोड।

 Timer xTimer("Timer", 1000, pdTRUE, NULL, vTimerCallback); Sema xSema; Mutex xMutex; Queue<int, 1000> xQueue; Task<configMINIMAL_STACK_SIZE> task1(vTask1, "Task 1", NULL, tskIDLE_PRIORITY); Task<configMINIMAL_STACK_SIZE> task2(vTask2, "Task 2", NULL, tskIDLE_PRIORITY); void vTimerCallback(TimerHandle_t pxTimer) { xSema.give(); MutexLocker lock(xMutex); Serial.println("Test"); } void vTask1(void *) { while(1) { xSema.take(); int value = random(1000); xQueue.send(value); } } void vTask2(void *) { while(1) { int value; xQueue.receive(&value); MutexLocker lock(xMutex); Serial.println(value); } } void setup() { Serial.begin(9600); xTimer.start(); vTaskStartScheduler(); } void loop() {} 

आप परिणामी बाइनरी को इकट्ठा कर सकते हैं और देख सकते हैं कि यह कैसे और कैसे स्थित है (ओब्जेक्टम्प का आउटपुट बेहतर पठनीयता के लिए थोड़ा रंगा हुआ है):

 0x200000b0 .bss 512 vApplicationGetIdleTaskMemory::Idle_Stack 0x200002b0 .bss 92 vApplicationGetIdleTaskMemory::Idle_TCB 0x2000030c .bss 1024 vApplicationGetTimerTaskMemory::Timer_Stack 0x2000070c .bss 92 vApplicationGetTimerTaskMemory::Timer_TCB 0x200009c8 .bss 608 task1 0x20000c28 .bss 608 task2 0x20000e88 .bss 84 xMutex 0x20000edc .bss 4084 xQueue 0x20001ed0 .bss 84 xSema 0x20001f24 .bss 48 xTimer 

लक्ष्य प्राप्त किया जाता है - अब सब कुछ पूर्ण दृश्य में है। प्रत्येक वस्तु दिखाई देती है और इसका आकार समझ में आता है (ठीक है, सिवाय इसके कि टास्क प्रकार की यौगिक वस्तुएं अपने सभी भागों को एक टुकड़ा मानती हैं)। संकलक आँकड़े भी बेहद सटीक हैं और इस समय बहुत उपयोगी हैं।

 Sketch uses 20,800 bytes (15%) of program storage space. Maximum is 131,072 bytes. Global variables use 9,332 bytes (45%) of dynamic memory, leaving 11,148 bytes for local variables. Maximum is 20,480 bytes. 

निष्कर्ष

हालाँकि FreeRTOS आपको फ्लाई पर कार्यों, कतारों, सेमाफोर और म्यूटेक्स को बनाने और हटाने की अनुमति देता है, कई मामलों में यह आवश्यक नहीं है। एक नियम के रूप में, यह सभी वस्तुओं को एक बार शुरू करने के लिए पर्याप्त है और वे अगले रिबूट तक काम करेंगे। और संकलन के स्तर पर ऐसी वस्तुओं को सांख्यिकीय रूप से वितरित करने का यह एक अच्छा कारण है। नतीजतन, हमें अपनी वस्तुओं द्वारा कब्जा की गई स्मृति की स्पष्ट समझ मिलती है, जहां झूठ और कितनी मुक्त स्मृति बनी हुई है।

यह स्पष्ट है कि प्रस्तावित विधि केवल उन वस्तुओं को रखने के लिए उपयुक्त है, जिनका जीवनकाल संपूर्ण अनुप्रयोग के जीवनकाल के बराबर है। अन्यथा, आपको गतिशील मेमोरी का उपयोग करना चाहिए।

FreeRTOS ऑब्जेक्ट्स के स्थैतिक प्लेसमेंट के अलावा, हमने FreeRTOS प्राइमेटिव्स पर सुविधाजनक रैपर भी लिखे, जिससे हमें क्लाइंट कोड को कुछ हद तक सरल बनाया जा सके और इनकैप्स भी

यदि आवश्यक हो तो इंटरफ़ेस को सरल बनाया जा सकता है (उदाहरण के लिए, रिटर्न कोड की जांच नहीं करना, या टाइमआउट का उपयोग नहीं करना)। यह भी ध्यान देने योग्य है कि कार्यान्वयन अधूरा है - मैंने कतार के माध्यम से संदेश भेजने और प्राप्त करने के सभी संभावित तरीकों के कार्यान्वयन से परेशान नहीं किया (उदाहरण के लिए, एक रुकावट से, कतार की शुरुआत या अंत में भेजने के लिए), मैंने सिंक्रनाइज़ेशन प्राइमेटरी से इंटरप्ट, काउंटिंग (नॉन-बाइनरी) सेमाफोर, काम नहीं किया। और भी बहुत कुछ।

मैं इस कोड को "लेने और उपयोग करने" की स्थिति में लाने के लिए बहुत आलसी था, मैं सिर्फ विचार दिखाना चाहता था। लेकिन एक तैयार पुस्तकालय की जरूरत किसे है, मैं अभी frt पुस्तकालय में आया हूं। इसमें सब कुछ व्यावहारिक रूप से समान है, केवल दिमाग में लाया गया है। खैर, इंटरफ़ेस थोड़ा अलग है।

लेख से एक उदाहरण यहाँ है ।

इस लेख को अंत तक पढ़ने के लिए आप सभी का धन्यवाद। मुझे रचनात्मक आलोचना करने में खुशी होगी। मेरे लिए टिप्पणियों में बारीकियों पर चर्चा करना भी दिलचस्प होगा।