खरोंच से एक वाणिज्यिक इलेक्ट्रॉनिक उपकरण का विकास

नमस्ते!

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

यह सब कैसे शुरू हुआ

प्रारंभ में, हम चिप ट्यूनिंग के लिए सॉफ्टवेयर के विकास में लगे हुए थे। जिनमें से एक मुख्य कार्य कंप्यूटर (इलेक्ट्रॉनिक इंजन कंट्रोल यूनिट) से फर्मवेयर पढ़ना और इसे वापस लिखना है। यह स्पष्ट है कि इन उद्देश्यों के लिए आपको एडेप्टर का उपयोग करके किसी तरह कंप्यूटर और कंप्यूटर को कनेक्ट करना होगा। जब ECUs के विशाल बहुमत ने डेटा प्राप्त करने और संचारित करने की सबसे सरल विधि का उपयोग किया, तो यह ट्रांजिस्टर या एक विशेष चिप पर सरलतम एडेप्टर का उपयोग करने के लिए पर्याप्त था। हालांकि, आज अधिकांश कारें बाहरी वातावरण के साथ अपने घटकों को "संवाद" करने के लिए CAN बस का उपयोग कर सकती हैं। आप ट्रांजिस्टर पर CAN बस के लिए एडॉप्टर को इकट्ठा नहीं कर सकते हैं, और यहां आपको निश्चित रूप से एक प्रोसेसर की आवश्यकता है जो एक विशिष्ट कार्यक्रम के अनुसार सब कुछ नियंत्रित करेगा।
तो पहली समस्या उत्पन्न हुई - कैन बस को कैसे पार किया जाए। पहिया को सुदृढ़ नहीं करने के लिए, विकल्प तैयार किए गए एडेप्टर के उपयोग पर बनाया गया था जो J2534 मानक के अनुसार काम करता है। जो लोग नहीं जानते हैं, उनके लिए J2534 मानक एक मानक है जो डिवाइस के हार्डवेयर और सॉफ़्टवेयर भागों का वर्णन करता है, जिसके साथ आप कंप्यूटर का उपयोग करके कंप्यूटर से जुड़ सकते हैं। यह अमेरिकियों द्वारा विकसित किया गया था। इसके विकास का मुख्य कारण ईसीयू फर्मवेयर को किसी विशेष डीलर सेवा द्वारा अद्यतन करने की संभावना का विधायी समेकन नहीं था, बल्कि किसी की इच्छा के अनुसार। दरअसल, अगर हर कोई अपने फोन पर फर्मवेयर अपडेट कर सकता है, तो वह अपनी कार के साथ ऐसा क्यों नहीं कर सकता है।

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

प्रयोगों

हार्डवेयर में जिन कार्यों की हमें आवश्यकता थी, वे ELM327 के निदान के लिए सामान्य एडॉप्टर में मौजूद थे। यह केवल J2534 ड्राइवर (वास्तव में, यह एक DLL है, जो कंप्यूटर और डिवाइस पर प्रोग्राम के बीच एक परत के रूप में कार्य करता है) लिखने के लिए बना हुआ है। हालांकि, उन्होंने ELM327 के डेवलपर्स से संपर्क किया, उन्होंने बताया कि उनके पास इस तरह के ड्राइवर को लिखने की कोई योजना नहीं है, हालांकि, वे ELM327 के लिए मुफ्त फ़्लैश चिप प्रदान करने के लिए तैयार थे। पहले, मैंने ऐसे ड्राइवर को लिखा था जो केवल आईएसओ 11898 प्रोटोकॉल (रॉ कैन) का समर्थन करता था। हालाँकि, निराशा ने यहाँ मेरा इंतजार किया। 1 एमबी / एस की गति पर, ईएलएम 327 बस इतनी बड़ी संख्या में पैकेट प्राप्त करने का प्रबंधन नहीं करता है, लगातार आंतरिक संदेश बफर को बहाने में एक त्रुटि को बाहर निकालता है। इसके अलावा, कंप्यूटर और ELM327 के बीच विनिमय प्रोटोकॉल एक ASCII संदेश विनिमय के रूप में आयोजित किया जाता है (ताकि टर्मिनल में काम करना सुविधाजनक हो)। तदनुसार, डेटा के एक बाइट को प्रसारित करने के बजाय, तीन प्रसारित किए जाते हैं (दो बाइट्स - चरित्र मानचित्रण प्लस एक अलग स्थान)। यह पता चला कि अधिकांश USB ट्रैफ़िक बर्बाद हो गया था। और यह देखते हुए कि USB के माध्यम से ELM327 के साथ काम करने की अधिकतम गति 3 एमबी / एस है, ऐसे एक्सचेंज संगठन के साथ CAN बस के माध्यम से 1 एमबी / एस को स्वीकार करना संभव नहीं है।

मुझे कभी भी किसी पर निर्भर रहना पसंद नहीं था, इसलिए, अपने स्वयं के J2534 एडेप्टर बनाने के विचार ने मुझे नहीं छोड़ा।

पहला कदम

यहां यह कहा जाना चाहिए कि मेरे J2534 एडाप्टर को विकसित करने से पहले मुझे प्रोसेसर का उपयोग करने का कोई विकास अनुभव नहीं था, लेकिन मुझे प्रोग्रामिंग का बहुत अनुभव था। प्रारंभ में, ऐसे कलाकारों को खोजने का प्रयास किया गया जो इस तरह के "टर्नकी" उपकरण का निर्माण कर सकते थे, लेकिन वे असफल थे। इसलिए, अपने दम पर ऐसा करना शुरू करने का फैसला किया गया था। सबसे पहले, प्रोसेसर पर निर्णय लेना आवश्यक था। विकल्प एसटी - एसटीएम 32 एफ 105 से एआरएम प्रोसेसर पर गिर गया। प्रोसेसर चुनने के मानदंड प्रचलन, मूल्य और तीसरे पक्ष के विशेषज्ञों की उपस्थिति थे जो समस्याओं को जल्द से जल्द हल करने में मदद करेंगे। ब्रेडबोर्ड के रूप में, ओलीमेक्स से एक ब्रेडबोर्ड खरीदा गया था। इसकी मदद से, प्रोसेसर के विकास के लिए "प्रयोगशाला का काम" सफलतापूर्वक पूरा किया गया: ब्लिंकिंग एलईडी, बीपिंग साउंड, एलसीडी स्क्रीन पर डिस्प्ले, यूएआरटी के साथ काम।



CooCox IDE को पसंद किया। केइल के साथ नमूने भी थे, लेकिन जैसा कि वे कहते हैं - "यह नहीं हुआ"।

काम की प्रक्रिया

जैसा कि मैंने ऊपर लिखा था, ऐसे कलाकारों को खोजने की कोशिश की गई जो "टर्नकी" सब कुछ करेंगे, लेकिन वे असफल रहे। मैं लंबे समय तक विकास को खींचना नहीं चाहता था और खुद को सब कुछ समझता था। इसलिए, कार्य को स्वतंत्र भागों में विभाजित करने का निर्णय लिया गया था, और उनमें से कुछ को उन डेवलपर्स को सौंपा जाना चाहिए जिनके पास ऐसी चीजों का अनुभव था। ऐसे डेवलपर को फ्रीलांस एक्सचेंज का उपयोग करते हुए पाया गया था। दरअसल, फ्रीलांसर को एक प्रोग्राम बनाना पड़ता था जो प्रोसेसर को नियंत्रित करता है। अंतिम सर्किट, मुद्रित सर्किट बोर्ड और उत्पादन क्रम के विकास से संबंधित बाकी काम पहले से ही किसी को सौंपा जाना था। मेरे मार्ग का अनुसरण करने वालों के लिए, मेरा कहना है कि इस पूरी प्रक्रिया में फ्रीलांसर कोई रामबाण नहीं है, और उसके बाद भी मुझे कोड को ऑप्टिमाइज़ करना होगा ताकि यह कोड सिर्फ काम न करे, बल्कि गुणवत्ता और एक्स्टेंसिबल हो।

ठेकेदार ने तुरंत सुझाव दिया कि मैं STM32 से मानक पुस्तकालय के बजाय इस परियोजना में RTOS का उपयोग करता हूं। ईमानदारी से, मैं हैरान था। मैंने कभी आरटीओएस से निपटा नहीं, और मेरा साथी स्पष्ट रूप से इस परियोजना के लिए आरटीओएस का उपयोग करने के खिलाफ था। अंत में, मैं अभी भी RTOS का उपयोग करने के लिए सहमत हुआ और बाद में इसे पछतावा नहीं हुआ।



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

CAN के साथ समस्याएं शुरू हुईं। CAN ChibiOS के साथ काम करने के लिए मानक ड्राइवर (यह इस RTOS पर था जिसे मैंने रोका) प्राप्त संदेशों को संग्रहीत करने के लिए प्रोसेसर हार्डवेयर स्लॉट का उपयोग करता है। उनमें से केवल तीन हैं, इसलिए, यदि आपके पास वहां से संदेश चुनने का समय नहीं है, तो वे बस खो जाएंगे। और इसलिए यह हुआ। जबकि संदेश "धीरे-धीरे" चले गए - उन्हें सुरक्षित रूप से प्राप्त किया गया था, लेकिन जैसे ही प्रति सेकंड CAN संदेशों की संख्या हजारों से अधिक हो गई - समस्याएं शुरू हुईं। "ओवरक्लॉकिंग" या मानक चालक पर रिसेप्शन का अनुकूलन करने से काम नहीं चला, इसलिए इसे पूरी तरह से फिर से लिखने का निर्णय लिया गया। यानी एक सॉफ्टवेयर बना सकते हैं एक हार्डवेयर के बजाय बफर संदेश कर सकते हैं। इस तरह के सॉफ्टवेयर बफर का आकार 256 संदेश था और यह काफी हद तक निकला।

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

उस समय का भाग ISO 15765-4 (CAN), ISO 9141-2 प्रोटोकॉल का अध्ययन करने में बिताया गया था। मुझे कहना होगा कि वास्तविक ईसीयू ने उनके साथ जल्दी से निपटने में मदद की - यह ईसीयू एक्सचेंज को "सुनने" के लिए पर्याप्त था।

पहला नमूना

डिवाइस का पहला मॉडल STM32F105 और इंटरफ़ेस L9637D और TJA1050 के साथ एक ब्रेडबोर्ड के रूप में मौजूद था। यह पहला प्रयोगशाला नमूना जैसा दिखता था।



और इसलिए दूसरी ओर:



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

इस तरह के परीक्षण निश्चित रूप से बंद का भुगतान किया। डिवाइस के फ़र्मवेयर में इतने कीड़े भी नहीं पाए गए क्योंकि डिवाइस को एडॉप्टर J2534 के रूप में उपयोग करने वाले विभिन्न निर्माताओं के प्रोग्राम के लिए डिवाइस को अनुकूलित करना आवश्यक था।

अंतिम चरण

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

एक अलग विषय डिवाइस के मामले को उजागर कर सकता है। यह एक अलग विषय के लिए एक विषय है। इसलिए, मैं कहूंगा कि फिलहाल मैं एक ऐक्रेलिक मामले के कारखाने के निर्माण पर बस गया, और हम दूसरे दिन इस मामले के साथ अपने उपकरणों को पूरा करने की योजना बना रहे हैं।



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

परिणाम

मुझे आप थोड़ा कालक्रम दें, ताकि आप समझ सकें कि इसकी कीमत क्या थी।

1. मार्च 2013 - STM32 के साथ पहली बार परिचित
2. जून 2013 - काम की शुरुआत
3. अक्टूबर 2013 - पहला परीक्षण नमूना
4. जनवरी 2014 - आधिकारिक बिक्री लॉन्च

यह भी कहा जाना चाहिए कि यह एकमात्र परियोजना नहीं है जो इस समय सीमा के भीतर की गई थी।

प्रोजेक्ट बनाने के लिए क्या उपयोग किया गया था:

1. RTOS ChibiOS
2. उदात्त पाठ २
3. जीसीसी (कोडसौर)

परियोजना बनाने के लिए सहायक लोहा:

1. हैकर कर सकते हैं
2. Saleae तर्क विश्लेषक
3. USB- UART कनवर्टर

नतीजतन, हमें एक J2534 उपकरण मिला जो प्रोटोकॉल की निम्नलिखित सूची का समर्थन करता है:

निम्नलिखित प्रोटोकॉल के लिए समर्थन:

1. आईएसओ 11898 (कच्ची कैन) 1Mb / s तक
2. आईएसओ 15765-4 (CAN)
3. आईएसओ 14230-4 (कीवर्ड प्रोटोकॉल 2000)
4. आईएसओ 9141-2

इस तथ्य के कारण कि J2534 मानक में वर्णित कई फ़ंक्शन उन कार्यक्रमों में उपयोग नहीं किए जाते हैं जिनके साथ डिवाइस का उपयोग करने की योजना बनाई गई थी, उन्हें बाहर करने का निर्णय लिया गया था। विशेष रूप से, यह J1850 प्रोटोकॉल (PWM / VPW) का समर्थन करता है। शायद जब समय होगा, मैं J2534 प्रोटोकॉल के 100% कवरेज प्राप्त करने के लिए इन प्रोटोकॉल को डिवाइस में खींचूंगा।