मुझे एम्बेडेड सिस्टम में टाइप एब्स्ट्रक्शन का उपयोग कब करना चाहिए

मैंने कई अलग-अलग एम्बेडेड सिस्टम पर काम किया है। UINT32 जैसे प्रकारों के लिए उनके पास सभी typedef s (या #defines ) का उपयोग किया गया है।

यह एक अच्छी तकनीक है क्योंकि यह प्रोग्रामर को प्रकार के आकार को घर चलाती है और आपको ओवरफ्लो इत्यादि के अवसरों के बारे में अधिक जागरूक बनाती है।

लेकिन कुछ प्रणालियों पर आप जानते हैं कि संकलक और प्रोसेसर परियोजना के जीवन के लिए नहीं बदलेगा।

तो परियोजना-विशिष्ट प्रकारों को बनाने और लागू करने के आपके निर्णय को क्या प्रभावित करना चाहिए?

संपादित करें मुझे लगता है कि मैं अपने प्रश्न का सारांश खोने में कामयाब रहा, और शायद यह वास्तव में दो है।

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

बाकी सब कुछ के लिए प्रकार कम महत्व है।
आपको सावधान रहने की आवश्यकता नहीं है कि अतिप्रवाह न हो और पंजीकरण और ढेर के उपयोग के लिए बाहर निकलने की आवश्यकता हो। जो आपको UINT16 , UCHAR पर ले जा सकता है। UCHAR जैसे प्रकारों का उपयोग हालांकि कंपाइलर 'fluff' जोड़ सकते हैं। चूंकि पंजीयक आमतौर पर बड़े होते हैं, इसलिए कुछ कंपाइलर परिणाम को बल में बल देने के लिए कोड जोड़ सकते हैं।

i++;
can become
ADD REG,1
AND REG, 0xFF
which is unecessary.

तो मुझे लगता है कि मेरा सवाल होना चाहिए था: -

एम्बेडेड सॉफ़्टवेयर की बाधाओं को देखते हुए एक परियोजना के लिए सेट करने की सबसे अच्छी नीति क्या है जिसमें बहुत से लोग इस पर काम करेंगे - जिनमें से सभी अनुभव के समान स्तर के नहीं होंगे।

0
ro fr bn

9 उत्तर

मेरी राय यह है कि यदि आप न्यूनतम / अधिकतम / विशिष्ट आकार नहीं के आधार पर हैं तो मान लें कि (कहें) एक हस्ताक्षरित int 32 बाइट्स है - uint32_t का उपयोग करें इसके बजाय (मान लें कि आपका कंपाइलर सी 99 का समर्थन करता है)।

0
जोड़ा

शायद मैं अजीब हूँ, लेकिन मैं अपने पूर्णांक प्रकारों के लिए ub, ui, ul, sb, si, और sl का उपयोग करता हूं। शायद 16 बिट्स के लिए "मैं" थोड़ा दिनांकित लगता है, लेकिन मुझे यू / एस से बेहतर ui / si की पसंद पसंद है।

0
जोड़ा
मुझे लगता है कि संदर्भ पर यह dpeends। एम्बेडेड प्रोग्रामिंग के लिए, आकार बहुत महत्वपूर्ण है इसलिए मैं और डब्ल्यू प्रभावी ढंग से "परवाह नहीं करते" मान हैं।
जोड़ा लेखक itj, स्रोत
@itj: मुझे यकीन नहीं है कि आप इसका क्या मतलब है। मैं अपने दो-चरित्र प्रकार पहचानकर्ताओं का उपयोग करता हूं क्योंकि वे छोटे और दृष्टि से साफ और विशिष्ट होते हैं। मैं किसी भी अन्य 2-वर्ण पहचानकर्ताओं के बारे में नहीं सोच सकता जो मैं किसी भी उद्देश्य के लिए उपयोग करता हूं जो 'एस' या 'यू' से शुरू होता है, इसलिए यह स्पष्ट रूप से स्पष्ट होता है कि किस प्रकार का अर्थ है (संभवतः, 'ui' या 'si' के लिए अलगाव में)।
जोड़ा लेखक supercat, स्रोत

मेरा मानना ​​है कि मिस्रा मानकों का सुझाव है (टाइप?) टाइपपीफ का उपयोग।

व्यक्तिगत परिप्रेक्ष्य से, टाइपपीफ का उपयोग करके कुछ प्रकार के आकार (बिट्स / बाइट्स में) के रूप में कोई भ्रम नहीं होता है। मैंने लीड डेवलपर्स को मानक प्रकारों का उपयोग करके विकास के दोनों तरीकों का प्रयास किया है। int और कस्टम प्रकारों का उपयोग उदा। Uint32।

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

0
जोड़ा
हां, यह एक सलाहकार नियम है (MISRA-C 2004 का # 6.3 क्रमशः # 13 मिसरा-सी '9 8)
जोड़ा लेखक ollo, स्रोत

मुझे विशेष रूप से सिस्टम एपीआई को परिभाषित करने के लिए stdint.h प्रकारों का उपयोग करना पसंद है क्योंकि वे स्पष्ट रूप से कहते हैं कि बड़ी वस्तुएं कितनी बड़ी हैं। पाम ओएस के पुराने दिनों में, सिस्टम एपीआई को "वर्ड" और "स्वाद" जैसे इच्छा-धोखे वाले प्रकारों का एक समूह का उपयोग करके परिभाषित किया गया था जो बहुत क्लासिक मैक ओएस से विरासत में मिला था। उन्होंने इंटेल 16 कहने के लिए क्लीनअप किया और यह एपीआई को नए सिस्टम के समझने के लिए आसान बना दिया, खासकर उस प्रणाली पर अजीब 16-बिट पॉइंटर मुद्दों के साथ। जब वे पाम ओएस कोबाल्ट डिजाइन कर रहे थे, तो उन्होंने stdint.h के नामों से मेल खाने के लिए उन नामों को दोबारा बदल दिया, जिससे उन्हें और अधिक स्पष्ट और टाइप किए गए टाइपिफ़ीज़ की मात्रा को कम कर दिया गया।

0
जोड़ा
stdint.h में प्रकारों का उपयोग करने के लिए +1। पोर्टेबिलिटी के लिए जाने का सबसे अच्छा तरीका। यदि किसी प्लेटफार्म में यह नहीं है, तो इसे बनाने के लिए यह छोटा है।
जोड़ा लेखक tomlogic, स्रोत

यदि आपकी एम्बेडेड सिस्टम किसी भी तरह सुरक्षा महत्वपूर्ण प्रणाली (या समान) है, तो यह सादे प्रकारों पर टाइपपीफ का उपयोग करने के लिए दृढ़ता से सलाह दी गई है (यदि आवश्यक नहीं है) ।

जैसा कि टीके। ने पहले कहा है, MISRA-C में ऐसा करने के लिए एक (सलाहकार) नियम है:

नियम 6.3 (सलाहकार): typedefs जो मूल संख्यात्मक प्रकारों के स्थान पर आकार और हस्ताक्षर का संकेत देते हैं।

(मिसरा-सी 2004 से; यह मिसरा-सी 1 99 8 का नियम # 13 (एड) है)


इस क्षेत्र में सी ++ पर भी लागू होता है; जैसे। जेएसएफ सी ++ कोडिंग मानकों :

एवी नियम 20 9 सभी स्टे को परिभाषित करने के लिए एक सार्वभौमिक प्रकार फ़ाइल बनाई जाएगी   डेवलपर्स के उपयोग के लिए ndard प्रकार। प्रकारों में शामिल हैं: [uint16, int16, uint32_t आदि।]

0
जोड़ा

संगति, सुविधा और पठनीयता। "यूआईएनटी 32" बहुत अधिक पठनीय और "हस्ताक्षरित लंबे लंबे" से लिखने योग्य है, जो कुछ प्रणालियों के बराबर है।

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

0
जोड़ा

The C99 standard has a number of standard sized-integer types. If you can use a compiler that supports C99 (gcc does), you'll find these in and you can just use them in your projects.

साथ ही, यह एम्बेडेड प्रोजेक्ट्स में यूनिट रूपांतरणों जैसी चीजों के लिए "सुरक्षा नेट" के प्रकार के रूप में उपयोग करने के लिए विशेष रूप से महत्वपूर्ण हो सकता है। यदि आप सी ++ का उपयोग कर सकते हैं, तो मैं समझता हूं कि वहां कुछ "यूनिट" लाइब्रेरी हैं जो आपको भौतिक इकाइयों में काम करने देती हैं जो सी ++ टाइप सिस्टम (टेम्पलेट्स के माध्यम से) द्वारा परिभाषित की जाती हैं जिन्हें अंतर्निहित स्केलर प्रकारों पर परिचालन के रूप में संकलित किया जाता है। उदाहरण के लिए, ये पुस्तकालय आपको distance_t को mass_t में जोड़ने नहीं देंगे क्योंकि इकाइयां लाइन नहीं होती हैं; आपको वास्तव में एक कंपाइलर त्रुटि मिल जाएगी।

यहां तक ​​कि यदि आप सी ++ या दूसरी भाषा में काम नहीं कर सकते हैं जो आपको इस तरह कोड लिखने देता है, तो आप कम से कम सी प्रकार प्रणाली का उपयोग कर सकते हैं ताकि आपको आंखों से त्रुटियों को पकड़ने में मदद मिल सके। (यह वास्तव में सिमोनी के हंगेरियन नोटेशन का मूल उद्देश्य था।) सिर्फ इसलिए कि संकलक आपको meter_t को जोड़ने के लिए \ code> index_t जोड़ने के लिए चिल्लाएगा, इसका मतलब यह नहीं है कि आपको चाहिए इस तरह के प्रकार का उपयोग नहीं करते हैं। तब यूनिट त्रुटियों की खोज करने पर कोड समीक्षा अधिक उत्पादक होगी।

0
जोड़ा

Using makes your code more portable for unit testing on a pc.

जब आप सब कुछ के लिए परीक्षण करते हैं तो यह आपको बहुत कठिन बना सकता है लेकिन यह अभी भी आपके लक्षित सिस्टम पर टूट जाता है क्योंकि int अचानक 16 बिट लंबा होता है।

0
जोड़ा
हां यह स्पष्ट आकार के प्रकारों का उपयोग करते समय सबसे व्यावहारिक प्रदर्शनों में से एक है जो बहुत समझ में आता है। बेशक, अगर आप कभी पीसी-होस्टेड परीक्षण नहीं करते हैं तो आप क्यों परवाह करेंगे?
जोड़ा लेखक barny, स्रोत

मैं बहुत ही कम प्रकार का सार तत्व का उपयोग करता हूं। यहां मेरे तर्क हैं, जो विषयपरकता के बढ़ते क्रम में क्रमबद्ध हैं:

  1. Local variables are different from struct members and arrays in the sense that you want them to fit in a register. On a 32b/64b target, a local int16_t can make code slower compared to a local int since the compiler will have to add operations to /force/ overflow according to the semantics of int16_t. While C99 defines an intfast_t typedef, AFAIK a plain int will fit in a register just as well, and it sure is a shorter name.

  2. Organizations which like these typedefs almost invariably end up with several of them (INT32, int32_t, INT32_T, ad infinitum). Organizations using built-in types are thus better off, in a way, having just one set of names. I wish people used the typedefs from stdint.h or windows.h or anything existing; and when a target doesn't have that .h file, how hard is it to add one?

  3. The typedefs can theoretically aid portability, but I, for one, never gained a thing from them. Is there a useful system you can port from a 32b target to a 16b one? Is there a 16b system that isn't trivial to port to a 32b target? Moreover, if most vars are ints, you'll actually gain something from the 32 bits on the new target, but if they are int16_t, you won't. And the places which are hard to port tend to require manual inspection anyway; before you try a port, you don't know where they are. Now, if someone thinks it's so easy to port things if you have typedefs all over the place - when time comes to port, which happens to few systems, write a script converting all names in the code base. This should work according to the "no manual inspection required" logic, and it postpones the effort to the point in time where it actually gives benefit.

  4. Now if portability may be a theoretical benefit of the typedefs, readability sure goes down the drain. Just look at stdint.h: {int,uint}{max,fast,least}{8,16,32,64}_t. Lots of types. A program has lots of variables; is it really that easy to understand which need to be int_fast16_t and which need to be uint_least32_t? How many times are we silently converting between them, making them entirely pointless? (I particularly like BOOL/Bool/eBool/boolean/bool/int conversions. Every program written by an orderly organization mandating typedefs is littered with that).

  5. Of course in C++ we could make the type system more strict, by wrapping numbers in template class instantiations with overloaded operators and stuff. This means that you'll now get error messages of the form "class Number has no operator+ overload for argument of type class Number, candidates are..." I don't call this "readability", either. Your chances of implementing these wrapper classes correctly are microscopic, and most of the time you'll wait for the innumerable template instantiations to compile.

0
जोड़ा
एक और चिमटा जो मैंने देखा और सराहना की है, फिक्स्ड प्रकारों का उपयोग और "सर्वोत्तम उपयोग" प्रकारों का उपयोग है। यानी typedef unsigned char UINT8 typedef unsigned uint255; uint 255 मानों की सीमा निर्दिष्ट करता है, लेकिन प्रति सिस्टम इष्टतम आकार निर्दिष्ट करने देता है
जोड़ा लेखक itj, स्रोत
@itj: uint255 के बजाय, uint_fast8_t stdint.h से उपयोग करें। इसे एक तेज़ प्रकार के रूप में परिभाषित किया गया है जो एक हस्ताक्षरित 8-बिट मान का समर्थन कर सकता है। एक मंच पर, यह एक हस्ताक्षरित char हो सकता है। दूसरे पर यह बस एक हस्ताक्षरित int हो सकता है।
जोड़ा लेखक tomlogic, स्रोत
यह तब तक ठीक है जब तक कि आपके कोड को बहुत सीमित प्रोसेसर पर काम नहीं करना पड़ेगा और आप एक अलग प्रोसेसर पर परीक्षण करना चाहते हैं या नहीं, शायद वास्तविक लक्ष्य पर परीक्षण और डिबगिंग मुश्किल / असंभव है। इस स्थिति में, आपको लक्ष्य पर समान आकार के चर के साथ अपने देव होस्ट पर परीक्षण करने की आवश्यकता है, और यदि आप आकार-विशिष्ट टाइपिफ़ीफ़ के साथ कोड किए गए हैं तो आपकी प्रक्रिया पूरी तरह से बोर्कन होगी।
जोड़ा लेखक barny, स्रोत