यहाँ जवाबों की एक विशाल विविधता ... विभिन्न तरीकों से इस मुद्दे को संबोधित करते हुए।
मैं 25 वर्षों से विभिन्न भाषाओं में एम्बेडेड लेवल सॉफ्टवेयर और फर्मवेयर लिख रहा हूं - ज्यादातर सी (लेकिन Ada, Occam2, PL / M, और रास्ते में कई कोडांतरक में विविधता के साथ)।
विचार और परीक्षण और त्रुटि की एक लंबी अवधि के बाद, मैं एक ऐसी विधि में बस गया हूं, जिसके परिणाम काफी जल्दी मिलते हैं और टेस्ट रैपर और हार्नेस बनाने में काफी आसान है (जहां वे ADD VALUE!)
विधि कुछ इस तरह है:
प्रत्येक प्रमुख परिधीय के लिए एक ड्राइवर या हार्डवेयर अमूर्त कोड इकाई लिखें जिसे आप उपयोग करना चाहते हैं। प्रोसेसर को इनिशियलाइज़ करने के लिए एक लिखें और सब कुछ सेट अप करें (यह अनुकूल वातावरण बनाता है)। आमतौर पर छोटे एम्बेडेड प्रोसेसर पर - आपका AVR एक उदाहरण है - 10 - 20 ऐसी इकाइयाँ हो सकती हैं, जो सभी छोटी हों। ये इनिशियलाइज़ होने के लिए इकाइयाँ हो सकती हैं, ए / डी कन्वर्सेन टू अनसक्लेस्ड मेमोरी बफ़र्स, बिटवाइज़ आउटपुट, पुशबटन इनपुट (नो डेब्यूज़ सिम्पल), पल्स चौड़ाई मॉड्यूलेशन ड्राइवर्स, UART / सिंपल सीरीयल ड्राइवर्स यूज़ इंटरप्ट और छोटे / O बफ़र्स। कुछ और हो सकते हैं - जैसे EEPROM, EPROM, या अन्य I2C / SPI उपकरणों के लिए I2C या SPI ड्राइवर।
हार्डवेयर एब्स्ट्रैक्शन (एचएएल) / चालक इकाइयों में से प्रत्येक के लिए, मैं फिर एक परीक्षण कार्यक्रम लिखता हूं। यह एक सीरियल पोर्ट (UART) और प्रोसेसर इनिट पर निर्भर करता है - इसलिए पहला परीक्षण कार्यक्रम केवल उन 2 इकाइयों का उपयोग करता है और बस कुछ बुनियादी इनपुट और आउटपुट करता है। इससे मुझे यह पता चलता है कि मैं प्रोसेसर शुरू कर सकता हूं और मेरे पास बेसिक डिबग सपोर्ट सीरियल I / O काम कर रहा है। एक बार जब वह काम करता है (और उसके बाद ही) मैं तब अन्य एचएएल परीक्षण कार्यक्रमों को विकसित करता हूं, जो उन्हें ज्ञात अच्छी यूएआरटी और आईएनआईटी इकाइयों के शीर्ष पर बनाते हैं। इसलिए मेरे पास अपने सीरियल डिबग टर्मिनल पर बिटवाइज़ इनपुट पढ़ने और एक अच्छे रूप (हेक्स, दशमलव, जो भी हो) को प्रदर्शित करने के लिए परीक्षण कार्यक्रम हो सकते हैं। मैं तब EEPROM या EPROM परीक्षण कार्यक्रमों की तरह बड़ी और अधिक जटिल चीजों में स्थानांतरित कर सकता हूं - मैं इनमें से अधिकांश मेनू को संचालित करता हूं इसलिए मैं चलाने, इसे चलाने और परिणाम देखने के लिए एक परीक्षण का चयन कर सकता हूं। मैं इसे SCRIPT नहीं कर सकता लेकिन आमतौर पर मैं डॉन '
एक बार जब मैं अपने सभी एचएएल चला रहा होता हूं, तो मैं एक नियमित टाइमर टिक पाने का तरीका ढूंढता हूं। यह आमतौर पर 4 और 20 एमएस के बीच कहीं दर पर होता है। यह एक बाधा में उत्पन्न, नियमित होना चाहिए। काउंटरों के रोलओवर / ओवरफ्लो आमतौर पर यह कैसे किया जा सकता है। तब बाधा हैंडलर एक बाइट आकार "सेमीफोर" में शामिल हो जाता है। यदि आप की जरूरत है तो इस बिंदु पर आप पावर मैनेजमेंट के साथ भी फील कर सकते हैं। सेमाफोर का विचार यह है कि यदि इसका मान> 0 है तो आपको "मुख्य लूप" चलाने की आवश्यकता है।
EXECUTIVE मुख्य लूप चलाता है। यह बहुत अधिक इंतजार करता है कि गैर-0 बनने के लिए उस सेमाफोर पर (मैं इस विवरण को दूर कर दूं)। इस बिंदु पर, आप इन टिकों को गिनने के लिए काउंटरों के साथ खेल सकते हैं (क्योंकि आपको टिक दर पता है) और इसलिए आप झंडे सेट कर सकते हैं यदि वर्तमान कार्यकारी टिक 1 सेकंड, 1 मिनट के अंतराल के लिए है, और अन्य सामान्य अंतराल आप उपयोग करने के लिए चाहते हो सकता है। एक बार कार्यकारी को पता चल जाता है कि सेमीफोर> 0 है, यह हर "एप्लिकेशन" प्रक्रियाओं "अपडेट" फ़ंक्शन के माध्यम से एक सिंगल पास चलाता है।
आवेदन प्रक्रियाएं प्रभावी रूप से एक दूसरे के साथ बैठती हैं और "अपडेट" टिक द्वारा नियमित रूप से चलती हैं। यह केवल एक फ़ंक्शन है जिसे कार्यकारी द्वारा बुलाया जाता है। यह एक बहुत ही सरल घर में विकसित RTOS के साथ प्रभावी रूप से गरीब-बहु मल्टी-टास्किंग है जो प्रवेश करने वाले सभी अनुप्रयोगों पर निर्भर करता है, थोड़ा सा काम करता है और बाहर निकलता है। अनुप्रयोगों को अपने स्वयं के राज्य चर बनाए रखने की आवश्यकता है और लंबे समय तक चलने वाली गणना नहीं कर सकते क्योंकि निष्पक्षता के लिए कोई पूर्व-खाली ऑपरेटिंग सिस्टम नहीं है। OBVIOUSLY अनुप्रयोगों के चलने का समय (संचयी रूप से) प्रमुख टिक अवधि से छोटा होना चाहिए।
उपरोक्त दृष्टिकोण को आसानी से बढ़ाया जाता है, ताकि आपके पास संचार स्टैक जैसी चीजें हो सकें जो अतुल्यकालिक रूप से चलती हैं और फिर कॉम्म्स संदेश अनुप्रयोगों तक पहुंचाए जा सकते हैं (आप प्रत्येक में एक नया फ़ंक्शन जोड़ते हैं जो "rx_message_handler" है और आप एक संदेश डिस्पैचर लिखते हैं जो आंकड़े हैं कौन से एप्लिकेशन को डिस्पैच करना है)।
यह दृष्टिकोण बहुत अधिक किसी भी संचार प्रणाली के लिए काम करता है जिसे आप नाम देते हैं - यह कई मालिकाना प्रणालियों के लिए काम कर सकता है (और कर चुका है), मानक मानकों को खोलता है, यह टीसीपी / आईपी स्टैक के लिए भी काम करता है।
इसमें अच्छी तरह से परिभाषित इंटरफेस के साथ मॉड्यूलर टुकड़ों में निर्मित होने का भी लाभ है। आप किसी भी समय टुकड़ों को अंदर और बाहर खींच सकते हैं, विभिन्न टुकड़ों को स्थानापन्न कर सकते हैं। प्रत्येक बिंदु पर जिस तरह से आप टेस्ट हार्नेस या हैंडलर जोड़ सकते हैं जो ज्ञात अच्छी निचली परत भागों (नीचे सामान) पर बनाते हैं। मैंने पाया है कि एक डिज़ाइन के लगभग 30% से 50% विशेष रूप से लिखित इकाई परीक्षणों को जोड़ने से लाभ उठा सकते हैं जो आमतौर पर काफी आसानी से जोड़े जाते हैं।
मैंने यह सब एक कदम आगे बढ़ाया है (एक विचार जो मैंने किसी और से किया है जिसने ऐसा किया है) और एचएएल परत को पीसी के बराबर के साथ बदल दें। तो उदाहरण के लिए आप C / C ++ और winforms या समान पीसी पर उपयोग कर सकते हैं और कोड CAREFULLY लिखकर आप प्रत्येक इंटरफ़ेस का अनुकरण कर सकते हैं (जैसे EEPROM = पीसी मेमोरी में पढ़ी गई डिस्क फ़ाइल) और फिर एक पीसी पर संपूर्ण एम्बेडेड एप्लिकेशन चलाएं। एक अनुकूल डिबगिंग वातावरण का उपयोग करने की क्षमता समय और प्रयास की एक बड़ी राशि बचा सकती है। केवल वास्तव में बड़ी परियोजनाएं आमतौर पर इस प्रयास को सही ठहरा सकती हैं।
उपरोक्त विवरण कुछ ऐसा है जो एम्बेडेड प्लेटफॉर्म पर चीजों को करने के लिए अद्वितीय नहीं है - मैं कई वाणिज्यिक संगठनों के साथ आया हूं जो समान हैं। जिस तरह से किया जाता है वह आमतौर पर कार्यान्वयन में काफी भिन्न होता है लेकिन सिद्धांत अक्सर समान होते हैं।
मुझे उम्मीद है कि ऊपर थोड़ा स्वाद देता है ... यह दृष्टिकोण छोटे एम्बेडेड सिस्टम के लिए काम करता है जो कि कुछ kB में आक्रामक बैटरी प्रबंधन के साथ 100K या अधिक स्रोत लाइनों के राक्षसों के माध्यम से चलता है जो स्थायी रूप से संचालित होते हैं। यदि आप विंडोज सीई या जैसे बड़े ओएस पर "एम्बेडेड" चलाते हैं, तो उपरोक्त सभी पूरी तरह से सारहीन है। लेकिन यह वास्तविक एम्बेडेड प्रोग्रामिंग नहीं है, किसी भी तरह।
अगर कोई भौंरा कर सकता है, तो आप भी कर सकते हैं!