बिल्ड एनवायरमेंट को सेट अप करें

GitHub पर सोर्स देखें

इन्होंने मेसन ट्रान

SiLabs का योगदान देने वाला व्यक्ति

बिना किसी शुल्क के और ओपन डेवलपमेंट को बढ़ावा देने के लिए, OpenThread ने इन्हें बनाने के लिए CMake का इस्तेमाल किया है बनाने के लिए डिज़ाइन किया गया है. फ़िलहाल, इस टूलचेन की पोर्टिंग के लिए ज़रूरत है OpenThread को नए हार्डवेयर प्लैटफ़ॉर्म पर ले जाना.

आने वाले समय में, अन्य बिल्ड टूलचेन काम कर सकते हैं. हालांकि, वे पोर्ट करने से जुड़ी इस गाइड का दायरा.

ध्यान दें: इस पोर्टिंग गाइड में दिए गए सभी पाथ और कोड के उदाहरणों के लिए, platform-name को अपने नए प्लैटफ़ॉर्म के नाम के साथ जोड़ें. ज़्यादातर गाइड में दिए गए उदाहरणों में, efr32 प्लैटफ़ॉर्म का नाम इस्तेमाल किया गया है.

डेटा स्टोर करने की नई जगह बनाना

सबसे पहले, अपने हार्डवेयर प्लैटफ़ॉर्म के लिए एक नया होम सेट अप करें. इस गाइड में, हम ot-efr32 नाम की एक नई रिपॉज़िटरी बनाएंगे. इसमें प्लैटफ़ॉर्म ऐब्स्ट्रक्शन लेयर, हार्डवेयर प्लैटफ़ॉर्म का SDK टूल, और काम की कुछ स्क्रिप्ट शामिल होंगी.

ध्यान दें: अगर आपको OpenThread संगठन में अपना डेटा स्टोर करने की जगह होस्ट करनी है, तो अपने प्लैटफ़ॉर्म के लिए डेटा स्टोर करने की नई जगह का अनुरोध करें. इसके अलावा, OpenThread संगठन से मौजूदा डेटा स्टोर करने की जगह को फ़ोर्क करने का अनुरोध भी किया जा सकता है.

इस उदाहरण में, हमने GitHub पर SiliconLabs/ot-efr32 रिपॉज़िटरी बनाया है और उसे ~/repos/ot-efr32 में क्लोन किया है.

mkdir -p ~/repos
cd ~/repos
git clone [e-mail]:SiliconLabs/ot-efr32.git
Cloning into 'ot-efr32'...
remote: Enumerating objects: 99, done.
remote: Counting objects: 100% (99/99), done.
remote: Compressing objects: 100% (60/60), done.
remote: Total 333 (delta 65), reused 39 (delta 39), pack-reused 234
Receiving objects: 100% (333/333), 170.78 KiB | 5.69 MiB/s, done.
Resolving deltas: 100% (194/194), done.
git status
On branch main
Your branch is up to date with 'origin/main'.

nothing to commit, working tree clean

डेटा स्टोर करने की जगह

OpenThread GitHub संगठन में, प्लैटफ़ॉर्म के मौजूदा डेटा स्टोर करने की जगहों को एक जैसा बनाए रखने के लिए, हो सकता है कि आप डेटा स्टोर करने की जगह को इस तरह स्ट्रक्चर करना चाहें:

tree -F -L 1 --dirsfirst
.
├── examples/
├── openthread/
├── script/
├── src/
├── third_party/
├── CMakeLists.txt
├── LICENSE
└── README.md

फ़ोल्डर	ब्यौरा
examples	ज़रूरी नहीं ऐप्लिकेशन के उदाहरण
openthread	सब-मॉड्यूल के तौर पर openthread रिपॉज़िटरी
script	लिंट करने, बनाने, जांच करने की स्क्रिप्ट
src	प्लैटफ़ॉर्म ऐब्स्ट्रैक्ट लेयर को लागू करना
third_party	किसी तीसरे पक्ष के सोर्स की जगह

सबमॉड्यूल जोड़ें

अगला चरण, openthread और अन्य ज़रूरी रेपो को सबमॉड्यूल के तौर पर जोड़ना है

git submodule add [e-mail]:openthread/openthread.git
Cloning into '/home/user/repos/ot-efr32/openthread'...
remote: Enumerating objects: 78281, done.
remote: Counting objects: 100% (1056/1056), done.
remote: Compressing objects: 100% (488/488), done.
remote: Total 78281 (delta 639), reused 864 (delta 556), pack-reused 77225
Receiving objects: 100% (78281/78281), 76.62 MiB | 35.24 MiB/s, done.
Resolving deltas: 100% (61292/61292), done.

ध्यान दें: कोई भी ऐसा कोड जो ओरिजनल नहीं है या डेरिवेटिव है. उदाहरण के लिए, लिंकर स्क्रिप्ट या टूलचेन स्टार्टअप कोड) third_party की डायरेक्ट्री में शामिल होना चाहिए.

उदाहरण के लिए, हम third_party में Silicon Labs Gecko SDK टूल के लाइट वर्शन को सबमॉड्यूल के तौर पर जोड़ेंगे.

cd third_party
git submodule add [e-mail]:SiliconLabs/sdk_support.git
Cloning into '/home/user/repos/ot-efr32/third_party/sdk_support'...
remote: Enumerating objects: 32867, done.
remote: Counting objects: 100% (8181/8181), done.
remote: Compressing objects: 100% (3098/3098), done.
remote: Total 32867 (delta 4945), reused 7469 (delta 4732), pack-reused 24686
Receiving objects: 100% (32867/32867), 128.83 MiB | 30.91 MiB/s, done.
Resolving deltas: 100% (19797/19797), done.

स्क्रिप्ट

सामान्य कामों को आसान बनाने के लिए, हो सकता है कि आप script फ़ोल्डर में कुछ स्क्रिप्ट बनाना चाहें. इसमें बूटस्ट्रैपिंग, बनाने, कोड-लिंटर चलाने, और GitHub CI जांच के लिए टेस्ट स्क्रिप्ट जैसे टास्क के लिए स्क्रिप्ट शामिल हो सकती हैं.

यहां स्क्रिप्ट के कुछ उदाहरण दिए गए हैं, जो प्लैटफ़ॉर्म का डेटा स्टोर करने की ज़्यादातर मौजूदा जगहों के लिए स्टैंडर्ड हैं.

bootstrap

इस स्क्रिप्ट से आपके हार्डवेयर प्लैटफ़ॉर्म के लिए ज़रूरी सभी टूल और पैकेज इंस्टॉल हो जाएंगे. इसे openthread की बूटस्ट्रैप स्क्रिप्ट को भी एक्ज़ीक्यूट करना चाहिए, ताकि यह पक्का किया जा सके कि उपयोगकर्ता के पास OpenThread स्टैक बनाने के लिए ज़रूरी सभी चीज़ें मौजूद हैं.

उदाहरण के लिए, ot-efr32 में बूटस्ट्रैप स्क्रिप्ट देखें.

build

CMake बिल्ड स्क्रिप्ट से लोगों को आपके प्लैटफ़ॉर्म के लिए OpenThread स्टैक बनाने में मदद मिलनी चाहिए. अगर आपका रिपॉज़िटरी किसी उदाहरण के ऐप्लिकेशन के बारे में बताता है, तो इस स्क्रिप्ट को भी वे ऐप्लिकेशन बनाने चाहिए. इस स्क्रिप्ट में, सिस्टम के बुनियादी कॉन्फ़िगरेशन के बुनियादी विकल्प होने चाहिए. इनमें, प्लैटफ़ॉर्म के हिसाब से मैक्रो की परिभाषाएं भी शामिल होनी चाहिए.

उदाहरण के लिए, ot-efr32 में बिल्ड स्क्रिप्ट देखें.

test

टेस्ट स्क्रिप्ट, उपयोगकर्ताओं के लिए मददगार हो सकती है. इसकी मदद से, वे आपके तय किए गए किसी भी टेस्ट का इस्तेमाल करके, बदलावों की जांच कर सकते हैं. यह कुछ भी हो सकता है, जितना कि सनिटी-चेक बिल्ड चलाने जैसा आसान या यूनिट-टेस्ट सुइट को लॉन्च करने जितना मुश्किल.

ot-efr32 में, स्क्रिप्ट हर efr32 प्लैटफ़ॉर्म पर काम करने वाले हर बोर्ड के लिए सिर्फ़ build स्क्रिप्ट को एक्ज़ीक्यूट करती है.

उदाहरण के लिए, ot-efr32 में टेस्ट स्क्रिप्ट देखें.

ध्यान दें: यह स्क्रिप्ट ज़रूरी नहीं है, लेकिन ot-efr32 के साथ-साथ कुछ मौजूदा प्लैटफ़ॉर्म डेटा स्टोर करने की जगहों में इसका इस्तेमाल GitHub CI जांच के हिस्से के तौर पर किया जा सकता है. इसे main में पुल-अनुरोधों को बंद करने के लिए सेट अप किया जा सकता है. जैसे: ot-efr32#35

make-pretty

एक जैसी स्टाइल बनाए रखने के लिए, इस स्क्रिप्ट को कोड, स्क्रिप्ट, और मार्कडाउन फ़ाइलों को फ़ॉर्मैट करना चाहिए.

आप खुद इस स्क्रिप्ट को तय कर सकते हैं. हालांकि, make-pretty स्क्रिप्ट का इस्तेमाल करना सबसे आसान हो सकता है, जिसमें मौजूदा प्लैटफ़ॉर्म रिपॉज़िटरी इस्तेमाल की जा रही हैं. स्क्रिप्ट, openthread की स्टाइल स्क्रिप्ट को कॉल करती है. इससे यह पक्का करने में मदद मिलती है कि सभी OpenThread डेटा स्टोर करने की जगहों में, एक जैसी स्टाइल बनी रहे.

ध्यान दें: अगर आपका प्लान है कि आप OpenThread संगठन पर डेटा स्टोर करने की जगह को कभी होस्ट करें, तो आपको अपनी main ब्रांच में पुल के अनुरोधों को सीमित करने के लिए इस स्क्रिप्ट का इस्तेमाल करना होगा. इस सीआई चेक को जोड़ने का तरीका यहां देखा जा सकता है.

लिंकर स्क्रिप्ट कॉन्फ़िगरेशन

GNU लिंकर स्क्रिप्ट इनपुट फ़ाइलों के सभी सेक्शन को मैप करने का तरीका (.o "ऑब्जेक्ट" फ़ाइलें) बताता है फ़ाइनल आउटपुट फ़ाइल में GNU कंपाइलर कलेक्शन (जीसीसी) से जनरेट होगा (इसके लिए उदाहरण के लिए, .elf). यह किसी सेगमेंट के हर सेगमेंट के सेव होने की जगह की जानकारी भी तय करता है प्रवेश पते की जानकारी शामिल कर सकते हैं. प्लैटफ़ॉर्म के हिसाब से लिंक करने वाला टैग स्क्रिप्ट अक्सर प्लैटफ़ॉर्म के बीएसपी के साथ दी जाती है.

प्लैटफ़ॉर्म के हिसाब से लिंक करने वाली स्क्रिप्ट पर ले जाने के लिए, ld टूल को कॉन्फ़िगर करें src/CMakeLists.txt में आपके प्लैटफ़ॉर्म CMake टारगेट पर target_link_libraries:

set(LD_FILE "${CMAKE_CURRENT_SOURCE_DIR}/efr32mg12.ld")

target_link_libraries(openthread-efr32mg12
    PRIVATE
        ot-config
    PUBLIC
        -T${LD_FILE}
        -Wl,--gc-sections -Wl,-Map=$.map
)

टूलचेन स्टार्टअप कोड

टूलचेन स्टार्टअप कोड, अक्सर प्लैटफ़ॉर्म के बीएसपी के साथ दिया जाता है. यह कोड आम तौर पर:

1. एक्ज़ीक्यूटेबल प्रोग्राम के एंट्री फ़ंक्शन (Reset_Handler) को लागू करता है
2. इंटरप्ट वेक्टर टेबल तय करता है
3. हीप और स्टैक को शुरू करता है
4. .data सेक्शन को नॉन-वोलाटाइल मेमोरी से रैम में कॉपी करता है
5. ऐप्लिकेशन लॉजिक लागू करने के लिए, ऐप्लिकेशन के मुख्य फ़ंक्शन पर जाता है

स्टार्टअप कोड (C या असेंबली सोर्स कोड) आपके प्लैटफ़ॉर्म के openthread-platform-name लाइब्रेरी या फिर लिंकर में इस्तेमाल किए जाने वाले कुछ मुख्य वैरिएबल स्क्रिप्ट को सही ढंग से कोट नहीं किया जा सकता है:

• src/CMakeLists.txt

उदाहरण: ot-cc2538 में startup-gcc.c - src/CMakeLists.txt

add_library(openthread-cc2538
    alarm.c
...
    startup-gcc.c
...
    system.c
    logging.c
    uart.c
    $
)