एम्बेडेड रियलटाइम कार्यों के लिए इंटेल एटम का उपयोग

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



नेटबुक के समान चिप्स आमतौर पर कारखानों में उपयोग नहीं किए जाते हैं। एक विशेष मंच है। पहले यहां क्राउन बीच था, अब इसे क्वींस बे डिजाइन में इस्तेमाल किया जाने लगा है। IVI (कार कंप्यूटर) के लिए अपना स्वयं का प्लेटफ़ॉर्म है ।



स्वाभाविक रूप से, रीयलटाइम आवश्यकताओं को पूरा करना एक पूर्वापेक्षा है। कट के तहत इसके बारे में अधिक।



X86 के लिए "रीयलटाइम" क्या है? कई मापदंड हैं। सबसे अधिक बार, पहली आवश्यकता यह है कि एक गारंटीकृत समय ट्रिगर बाधित होने और उसके हैंडलर (आईएसआर) के निष्पादन कोड की शुरुआत के बीच गुजरना चाहिए। किसी के लिए यह 2 माइक्रोसेकंड है, तो किसी के लिए 10, कुछ के लिए 20 माइक्रोसेकंड देरी के साथ भी तैयार हैं। 100 माइक्रोसेकंड देरी के साथ, भले ही यह सप्ताह में एक बार होता है, लेकिन कुछ काम करने के लिए तैयार हैं।



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



एटम परिवार के प्रोसेसर काफी तेजी से काम करते हैं, एक सिमडी है। पारंपरिक डेस्कटॉप / नेटबुक विकल्पों के विपरीत, एंबेडेड रोडमैप में इंटेल द्वारा शामिल चिप्स को लंबे समय तक (7 से 10 मिनट तक) समर्थित और उत्पादित किया जाता है। X86 पर, सॉफ़्टवेयर विकसित करना या ऑफ-द-शेल्फ सॉफ्टवेयर का उपयोग करना अपेक्षाकृत सरल है - यह अभी भी सबसे आम वास्तुकला है। वीटी भी उपयोगी है - वर्चुअलाइजेशन के लिए हार्डवेयर समर्थन। उदाहरण के लिए, केवल GU86 के लिए हार्डवेयर और विंडोज एक्सपी को नियंत्रित करने के लिए आरटीओएस को काफी तेजी से चलाया जा सकता है। वैसे, इस उद्योग में उपयोगकर्ता इंटरफ़ेस को GUI नहीं, बल्कि HMI (ह्यूमन मशीन इंटरफ़ेस) कहना फैशनेबल है। और इससे पहले यह एमएमआई था। जैसे, पुरुष मशीन टूल्स के साथ काम करते थे, और अब - मनुष्य।



अगर मैंने पहले ही लिखा था - "रुकावट देरी", तो यह निर्धारित करना आवश्यक है कि कौन सा है। विरासत, एमएसआई, स्थानीय? दो सबसे महत्वपूर्ण मामले स्थानीय APIC टाइमर, और परिधि से MSI-X व्यवधान हैं।



क्या ओएस का उपयोग किया जाता है? VxWorks, वफ़ादारी, QNX, विंडोज सीई, अत्यधिक डॉप्ड लिनक्स। कभी-कभी यह विंडोज एंबेडेड और यहां तक ​​कि नियमित रूप से विंडोज एक्सपी एसपी 3 का उपयोग करता है। बाद के मामलों में, आईएसआर में रियलटाइम कोड विशेष रूप से निष्पादित किया जाता है।



कैसे करें उपाय? यह OS पर निर्भर करता है। Windows पर, आप Microsoft DPC विश्लेषक का उपयोग कर सकते हैं। यदि ISR देरी के साथ कोई समस्या है, तो DPC देरी होगी। लेकिन दूसरे तरीके से नहीं। इसलिए, यह एक अच्छा संकेतक है, लेकिन 100% सटीक नहीं है। मैं कभी-कभी बेकहोफ ट्विनकट का उपयोग करता हूं। (वैसे, बेकहोफ़ नियमित विंडोज एक्सपी पर कठिन रीयल टाइम औद्योगिक नियंत्रकों को बनाने का तरीका जानता है) जिस साइट से आप एक परीक्षण संस्करण डाउनलोड कर सकते हैं, एक खाली प्रोजेक्ट शुरू कर सकते हैं, और स्थानीय एपीआईसी टाइमर से बाधित देरी देख सकते हैं। विंडोज के तहत सबसे आसान और सटीक तरीका। इसलिए यह जांचना मुश्किल नहीं है कि आपकी नेटबुक आधुनिक मिलिंग मशीन या औद्योगिक रोबोट के लिए नियंत्रक के रूप में उपयुक्त है या नहीं। यदि यह सूट करता है, तो एक मौका है कि अतिरिक्त लोहे की भी आवश्यकता नहीं होगी - अगर अचानक मशीन में EtherCAT के माध्यम से नियंत्रण के लिए छेद है।



एक समान ड्राइवर जो 100 दिनों की लिनक्स इंटरचेंज हैंडलर के लिए समय को मापता है, उसे आधे दिन में लिखा जाता है, या आप औसत देरी को प्रदर्शित करने के लिए ड्राइवरों / आरटीसी / आरटीसी-सेमीोस सी में 20 लाइनों को पैच कर सकते हैं।



आखिर 5 से अधिक माइक्रोसेकंड में एटम बाधा क्यों संभव है? उदाहरण के लिए, सभी X86 प्रोसेसर में SMI है - औद्योगिक नियंत्रक के दृष्टिकोण से एक बहुत बड़ी बुराई। एक उपयोगी निर्देश भी है - WBINV। कुछ ड्राइवर इसे निष्पादित करेंगे - और रुकावट हैंडलर को पहले मेमोरी से डेटा को लंबे समय तक खींचना होगा। कई अन्य संभावित कारण हैं। यह सब संघर्ष किया जा सकता है।



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