सिंहावलोकन
एक फर्मवेयर फ़ाइल पूरी तरह से वैध हो सकती है और फिर भी उत्पादन के लिए तैयार नहीं हो सकती है।
पीसीबी असेंबली पर फर्मवेयर प्रोग्रामिंग के लिए, ईएमएस टीम को जारी की गई छवि, सटीक लक्ष्य डिवाइस, बोर्ड संशोधन जिस पर यह लागू होता है, प्रोग्रामिंग इंटरफ़ेस, किसी भी आवश्यक मेमोरी एड्रेस या डिवाइस कॉन्फ़िगरेशन और परिणाम को सत्यापित करने के लिए एक परिभाषित तरीके की आवश्यकता होती है। जिन उत्पादों को सीरियल नंबर, मैक पते, अंशांकन मान या सुरक्षा क्रेडेंशियल की भी आवश्यकता होती है, उन्हें अतिरिक्त हैंडलिंग निर्देशों की आवश्यकता होती है।
एक उपयोगी उत्पादन जाँच सरल है:
क्या कोई तकनीशियन जिसने फ़र्मवेयर प्रोग्राम नहीं लिखा है, वह जारी निर्देशों से बोर्ड को सही ढंग से लिख सकता है?
यदि नहीं, तो सॉफ़्टवेयर विकास के दृष्टिकोण से समाप्त हो सकता है, लेकिन विनिर्माण हैंडऑफ़ नहीं है।
प्रोग्रामिंग रिलीज़ को एक पेज पर रखें
फ़र्मवेयर छवि हैंडऑफ़ का केवल एक भाग है।
कई परियोजनाओं के लिए, सबसे उपयोगी सहयोगी दस्तावेज़ एक छोटी प्रोग्रामिंग रिलीज़ शीट है जो उत्पादन को बताती है कि क्या स्वीकृत किया गया है और इसका उपयोग कैसे किया जाना चाहिए।
इससे कोई फर्क नहीं पड़ता कि ग्राहक इसे प्रोग्रामिंग निर्देश, रिलीज़ नोट, विनिर्माण निर्देश, या नियंत्रित कार्य निर्देश कहता है। महत्वपूर्ण बात यह है कि ऑपरेटर को ईमेल थ्रेड्स, पुराने विकास नोट्स और फ़ाइल नामों से सेटअप का पुनर्निर्माण नहीं करना पड़ता है।
एक व्यावहारिक रिलीज़ शीट में शामिल हो सकते हैं:
|
रिलीज़ फ़ील्ड |
उत्पादन को क्या चाहिए |
|
फ़र्मवेयर रिलीज़ |
सटीक अनुमोदित फ़ाइल या फ़ाइलें |
|
फ़र्मवेयर संशोधन |
सॉफ़्टवेयर संस्करण जारी किया गया |
|
लक्ष्य युक्ति |
सटीक प्रोग्रामयोग्य डिवाइस |
|
बोर्ड संशोधन |
फ़र्मवेयर के लिए हार्डवेयर संशोधन स्वीकृत |
|
प्रोग्रामिंग इंटरफ़ेस |
SWD, JTAG, UART, USB DFU, SPI, या कोई अन्य परिभाषित इंटरफ़ेस |
|
प्रोग्रामिंग पहुंच |
हेडर, कनेक्टर, फिक्स्चर-सुलभ परीक्षण बिंदु, या कोई अन्य विधि |
|
स्मृति गंतव्य |
जहां आवश्यक हो वहां पता या मेमोरी क्षेत्र प्रारंभ करें |
|
उपकरण का प्रारूप |
विकल्प बाइट्स, कॉन्फ़िगरेशन शब्द, फ़्यूज़, बूट या सुरक्षा सेटिंग्स जहां लागू हो |
|
प्रोग्रामिंग सेटअप |
स्वीकृत प्रोग्रामर, प्रोजेक्ट, स्क्रिप्ट, या सेटिंग्स जहां आवश्यक हो |
|
इकाई-विशिष्ट डेटा |
सीरियल नंबर, मैक पता, अंशांकन मान, या अन्य प्रति यूनिट डेटा जहां लागू हो |
|
सत्यापन विधि |
प्रोडक्शन कैसे पुष्टि करता है कि प्रोग्रामिंग पास हो गई है |
|
पोस्ट करें-प्रोग्रामिंग चरण |
बूट जांच, कार्यात्मक परीक्षण, लेबलिंग, पता लगाने की क्षमता, या अन्य आवश्यक कार्रवाई |
एक साधारण MCU बोर्ड को इनमें से केवल कुछ ही वस्तुओं की आवश्यकता हो सकती है। कई प्रोग्राम योग्य डिवाइस, कई फ़र्मवेयर वेरिएंट, विशिष्ट पहचानकर्ता या सुरक्षा कार्यों वाले उत्पाद को और अधिक की आवश्यकता होगी।
रिलीज़ शीट इंजीनियरिंग निर्णयों को ऑपरेटर के हाथों से दूर रखती है। जब तक बोर्ड प्रोग्रामिंग तक पहुंचता है, स्वीकृत छवि, सेटअप और सत्यापन नियम पहले से ही स्पष्ट होना चाहिए।
तीन तरीके जिनसे एक सही फ़र्मवेयर फ़ाइल अभी भी उत्पादन रोक सकती है
फ़ाइल स्वयं अक्सर समस्या नहीं होती है. इसके आसपास की जानकारी है.
बिन सही है, लेकिन किसी ने पता परिभाषित नहीं किया
एक कच्ची बाइनरी फ़ाइल में प्रोग्राम किया जाने वाला डेटा होता है, लेकिन यह स्वाभाविक रूप से प्रोग्रामर को यह नहीं बताता है कि वह डेटा कहां है।
यह इंटेल हेक्स या मोटोरोला एस रिकॉर्ड जैसे पते वाले प्रारूपों से भिन्न है।
इसलिए एक .bin फ़ाइल पूरी तरह से मान्य हो सकती है जबकि उत्पादन निर्देश अभी भी अधूरा है। यदि प्रोग्रामिंग वर्कफ़्लो को प्रारंभ पते या मेमोरी क्षेत्र की आवश्यकता होती है, तो वह जानकारी बाइनरी फ़ाइल के अलावा कहीं और से आनी होगी।
यही कारण है कि फ़र्मवेयर प्राप्त करना प्रयोग करने योग्य प्रोग्रामिंग रिलीज़ के समान नहीं है।
फ़र्मवेयर सही है, लेकिन यह एक अलग बोर्ड संशोधन से संबंधित है
फ़र्मवेयर और हार्डवेयर संशोधनों को अक्सर अलग-अलग नियंत्रित किया जाता है। यह आमतौर पर तब तक ठीक है जब तक हार्डवेयर परिवर्तन अनुकूलता को प्रभावित नहीं करता।
फ़र्मवेयर V1.6, बोर्ड Rev.B और बोर्ड Rev.C के साथ एक प्रोजेक्ट पर विचार करें। ये तीनों वैध जारी किए गए आइटम हो सकते हैं, लेकिन फ़र्मवेयर V1.6 केवल Rev.C के लिए अनुमोदित किया गया हो सकता है।
दो व्यक्तिगत रूप से सही संशोधन अभी भी गलत उत्पादन संयोजन बना सकते हैं।
जब भी कोई हार्डवेयर परिवर्तन प्रभावित हो सकता है तो प्रोग्रामिंग रिलीज़ को लागू बोर्ड संशोधन की पहचान करनी चाहिए:
- पिन असाइनमेंट;
- सेंसर प्रकार;
- मेमोरी डिवाइस;
- संचार इंटरफ़ेस;
- बूट कॉन्फ़िगरेशन;
- I/O मैपिंग;
- अंशांकन व्यवहार.
फ़र्मवेयर फ़ाइल नाम से उस निर्णय को स्वयं ले जाने की अपेक्षा नहीं की जानी चाहिए।
प्रोग्रामर पास कहता है, लेकिन बोर्ड अभी तक जारी नहीं हुआ है
प्रोग्रामर पर एक हरा पास आपको बताता है कि प्रोग्रामिंग चरण उसके परिभाषित सत्यापन नियम को पूरा करता है।
यह आपको नहीं बताता कि असेंबल किया गया बोर्ड सही ढंग से संचार करता है, इसके सेंसर को पढ़ता है, इसके आउटपुट को स्विच करता है, या लोड के तहत ठीक से व्यवहार करता है।
एक बोर्ड सफलतापूर्वक प्रोग्राम कर सकता है और फिर भी उसमें असेंबली दोष, गलत हार्डवेयर कॉन्फ़िगरेशन, संचार समस्या, बिजली दोष, या एप्लिकेशन स्तर की विफलता हो सकती है।
यहीं पर कार्यात्मक परीक्षण एक अलग काम करना शुरू कर देता है।
प्रोग्रामिंग सत्यापन प्रोग्रामिंग ऑपरेशन की पुष्टि करता है। कार्यात्मक परीक्षण प्रोग्राम किए गए असेंबली के व्यवहार की जाँच करता है।
फ़ाइल स्वरूप एक स्पष्ट प्रोग्रामिंग विधि से कम मायने रखता है
HEX और BIN आम हैं, लेकिन प्रत्येक उत्पाद के लिए कोई भी स्वचालित रूप से सही उत्तर नहीं है।
उत्पादन प्रोग्रामिंग वर्कफ़्लो का भी उपयोग किया जा सकता है:
- ईएलएफ या संबंधित निष्पादन योग्य प्रारूप;
- मोटोरोला एस-रिकॉर्ड;
- विक्रेता-विशिष्ट प्रोग्रामिंग फ़ाइलें;
- डिवाइस -विशिष्ट कॉन्फ़िगरेशन पैकेज।
एक कच्चे बिन को आम तौर पर एक अलग से परिभाषित गंतव्य पते की आवश्यकता होती है। पता- वाले प्रारूप फ़ाइल के भीतर उस जानकारी को अधिक ले जा सकते हैं। क्या ईएलएफ, एचईएक्स, बिन, एस-रिकॉर्ड, या किसी अन्य प्रारूप का उपयोग किया जाता है, यह लक्ष्य डिवाइस और अनुमोदित प्रोग्रामिंग सेटअप पर निर्भर करता है।
उत्पादन स्तर पर, नियम सरल है:
स्वीकृत प्रोग्रामिंग सेटअप द्वारा समर्थित प्रारूप का उपयोग करें, और ऐसी किसी भी चीज़ का दस्तावेज़ीकरण करें जिसे फ़ाइल स्वयं परिभाषित नहीं करती है।
यदि ईएमएस का दायरा किसी अनुमोदित उत्पादन छवि की प्रोग्रामिंग तक सीमित है, तो स्रोत कोड आमतौर पर अनावश्यक होता है। स्रोत कोड, आईडीई परियोजनाएं और निर्माण वातावरण तब प्रासंगिक हो जाते हैं जब संकलन, डिबगिंग, फर्मवेयर संशोधन, या उत्पादन छवि निर्माण सहमत दायरे का हिस्सा होता है।
संपूर्ण रिपॉजिटरी भेजने से अभी भी उत्पादन को यह नहीं पता चलता है कि कौन सा निर्माण स्वीकृत है।
प्रोग्रामिंग एक्सेस एक हार्डवेयर निर्णय भी है
सिस्टम प्रोग्रामिंग में, सॉफ़्टवेयर पैकेज सेटअप का केवल आधा हिस्सा है।
उत्पादन स्टेशन को लक्ष्य डिवाइस तक भौतिक और विद्युत पहुंच की भी आवश्यकता होती है।
उत्पाद के आधार पर, वह निम्न के माध्यम से हो सकता है:
- एसडब्ल्यूडी;
- जेटीएजी;
- UART या अन्य बूटलोडर इंटरफ़ेस;
- यूएसबी डीएफयू;
- एसपीआई;
- एक समर्पित प्रोग्रामिंग कनेक्टर;
- स्थिरता-सुलभ परीक्षण बिंदु;
- अन्य डिवाइस-विशिष्ट इंटरफ़ेस.
प्रोग्रामिंग निर्देश को बोर्ड पावर स्थिति, कनेक्टर या परीक्षण बिंदु पिनआउट, आवश्यक बूट स्थिति, प्रोग्रामिंग एडाप्टर, रीसेट व्यवहार और अपेक्षित मिटा/प्रोग्राम/सत्यापित अनुक्रम को परिभाषित करने की भी आवश्यकता हो सकती है।
इकट्ठे बोर्डों के प्रोग्रामिंग स्टेशन तक पहुंचने से पहले इन विवरणों को सबसे अच्छा हल किया जाता है।
एक बेहतर HEX फ़ाइल भेजकर दुर्गम SWD सिग्नल को ठीक नहीं किया जा सकता है।
उन उत्पादों के लिए जो फिक्सचर एक्सेस या प्रोग्रामिंग परीक्षण बिंदुओं पर निर्भर हैं, प्रोग्रामिंग तैयारी आंशिक रूप से एक डीएफटी मुद्दा है, न कि केवल एक सॉफ्टवेयर हैंडऑफ़।
फ़र्मवेयर रिवीज़न और बोर्ड रिवीज़न एक साथ रखें
नवीनतम.हेक्स या फाइनल_न्यू_वी2.बिन नाम की फ़ाइलें उस व्यक्ति के लिए पूरी तरह से समझ में आ सकती हैं जिसने उन्हें बनाया है। वे खराब उत्पादन नियंत्रण हैं।
विनिर्माण को स्वीकृत रिलीज़ को निम्न से अलग करने के लिए एक विश्वसनीय तरीके की आवश्यकता है:
- एक अप्रचलित संस्करण;
- एक इंजीनियरिंग निर्माण;
- एक परीक्षण-केवल छवि;
- अन्य उत्पाद प्रकार.
ग्राहक के दस्तावेज़ नियंत्रण प्रणाली के आधार पर, जारी पहचान में फ़र्मवेयर संशोधन, नियंत्रित फ़ाइल नाम, रिलीज़ दिनांक, लागू बोर्ड संशोधन, ग्राहक अनुमोदन संदर्भ, फ़ाइल आकार, या चेकसम/हैश शामिल हो सकता है।
उत्पादन को एक सार्वभौमिक नामकरण या चेकसम योजना की आवश्यकता नहीं है। फ़ोल्डर में बाकी सभी चीज़ों से रिलीज़ किए गए बिल्ड को बताने के लिए इसे एक विश्वसनीय तरीके की आवश्यकता है।
यह तब और भी महत्वपूर्ण हो जाता है जब एक हार्डवेयर प्लेटफ़ॉर्म कई सॉफ़्टवेयर वेरिएंट का समर्थन करता है। बोर्ड एक जैसे दिख सकते हैं जबकि तैयार उत्पाद एक जैसे नहीं दिखते।

जब प्रोग्रामिंग में यूनिट - विशिष्ट डेटा शामिल हो
कई उत्पादों के लिए, प्रत्येक बोर्ड को समान फ़र्मवेयर छवि प्राप्त होती है।
अन्य उत्पादों को भी इकाई विशिष्ट जानकारी की आवश्यकता होती है जैसे:
- क्रम संख्या;
- मैक पते;
- उत्पाद आईडी;
- अंशांकन गुणांक;
- क्षेत्रीय विन्यास;
- ग्राहक-विशिष्ट सेटिंग;
- डिवाइस क्रेडेंशियल.
उस समय, सामान्य फ़र्मवेयर और प्रति यूनिट डेटा दो अलग-अलग डेटा प्रवाह हैं।
प्रोडक्शन को पता होना चाहिए कि अद्वितीय मान कहां से आते हैं, वे कहां लिखे गए हैं, प्रत्येक मान सही भौतिक बोर्ड से कैसे जुड़ा है, और डुप्लिकेट असाइनमेंट को कैसे रोका जाता है।
एक विवरण को नज़रअंदाज करना आसान है: एक अद्वितीय मूल्य को कब उपभोग माना जाता है?
किसी सीरियल नंबर या मैक एड्रेस को असाइन किए जाने पर, प्रोग्रामिंग सफल होने पर, या यूनिट द्वारा आवश्यक परीक्षण पास करने के बाद ही इसका उपयोग माना जा सकता है। प्रत्येक उत्पाद के लिए कोई एक नियम नहीं है, लेकिन निर्माण शुरू होने से पहले एक सहमत नियम होना चाहिए।
यही बात विफल इकाइयों पर भी लागू होती है। टीम को यह जानने की जरूरत है कि क्या निर्दिष्ट मूल्य का पुन: उपयोग किया जा सकता है, उसे हटा दिया जाना चाहिए, या पता लगाने की क्षमता के लिए विफल बोर्ड से जुड़ा रहना चाहिए।
प्रोग्रामिंग पास एफसीटी पास नहीं है
विनिर्माण प्रवाह में प्रोग्रामिंग सत्यापन और कार्यात्मक परीक्षण एक साथ हो सकते हैं, लेकिन वे अलग-अलग सवालों के जवाब देते हैं।
प्रोग्रामिंग सत्यापन
प्रोग्रामिंग सत्यापन पूछता है:
क्या इच्छित डेटा अनुमोदित प्रोग्रामिंग पद्धति के अनुसार सही ढंग से लिखा गया था?
डिवाइस और सेटअप के आधार पर, इसमें प्रोग्रामर का सत्यापन फ़ंक्शन, जहां अनुमति हो वहां रीडबैक तुलना, सीआरसी, कॉन्फ़िगरेशन सत्यापन, या कोई अन्य अनुमोदित विधि शामिल हो सकती है।
क्रियात्मक परीक्षण
कार्यात्मक परीक्षण पूछता है:
क्या संचालित और क्रमादेशित पीसीबी असेंबली उत्पाद के लिए आवश्यक कार्य करती है?
परियोजना के आधार पर, इसमें शामिल हो सकते हैं:
- पावर{{0}अप व्यवहार;
- संचार;
- इनपुट/आउटपुट प्रतिक्रिया;
- सेंसर इनपुट;
- रिले या एक्चुएटर आउटपुट;
- वर्तमान ड्रा;
- ग्राहक द्वारा परिभाषित परिचालन स्थितियाँ।
पास प्रदर्शित करने वाले प्रोग्रामर को स्वचालित रूप से इस बात का प्रमाण नहीं माना जाना चाहिए कि पीसीबी असेंबली ने एफसीटी पारित कर दिया है।
उन परियोजनाओं के लिए जिनके लिए फ़र्मवेयर लोडिंग को बोर्ड स्तर सत्यापन, एसटीएचएल के साथ समन्वयित करने की आवश्यकता होती हैपरीक्षण एवं निरीक्षणक्षमताएँ प्रासंगिक सेवा पथ प्रदान करती हैं।

दो स्थितियाँ जिनमें अतिरिक्त निर्देशों की आवश्यकता है
अधिकांश प्रोग्रामिंग नौकरियों को विस्तृत प्रावधान प्रक्रिया की आवश्यकता नहीं होती है। लागू होने पर दो स्थितियाँ अतिरिक्त ध्यान देने योग्य हैं।
परीक्षण फ़र्मवेयर और उत्पादन फ़र्मवेयर
कुछ उत्पाद विनिर्माण के दौरान डायग्नोस्टिक फ़र्मवेयर का उपयोग करते हैं और शिपमेंट के लिए एक अलग फ़र्मवेयर रिलीज़ का उपयोग करते हैं।
यदि ऐसा है, तो उत्पादन को यह जानने की आवश्यकता है कि प्रत्येक चरण में कौन सी छवि लागू होती है, जब परीक्षण छवि को प्रतिस्थापित किया जाता है, अंतिम रिलीज की पुष्टि कैसे की जाती है, और क्या बाद में किसी अन्य कार्यात्मक जांच की आवश्यकता होती है।
अन्यथा, एक बोर्ड विनिर्माण निदान को पारित कर सकता है और गलत फर्मवेयर स्थापित होने पर भी उत्पादन छोड़ सकता है।
प्रत्येक उत्पाद को अलग परीक्षण फर्मवेयर की आवश्यकता नहीं होती है। प्रक्रिया को वास्तविक उत्पाद का अनुसरण करना चाहिए।
सुरक्षित प्रावधान
कुछ सुरक्षा सक्षम उपकरणों को हस्ताक्षरित या एन्क्रिप्टेड छवियों, सुरक्षित बूट सेटिंग्स, ओटीपी/ईफ्यूज कॉन्फ़िगरेशन, कुंजी, प्रमाणपत्र या अन्य नियंत्रित प्रावधान डेटा की आवश्यकता होती है।
जब ये आवश्यकताएं लागू होती हैं, तो ओईएम और ईएमएस प्रदाता को इस बात पर सहमत होना चाहिए कि संवेदनशील डेटा का मालिक कौन है, कौन से परिचालन उत्पादन को निष्पादित करने के लिए अधिकृत है, और कैसे अपरिवर्तनीय सेटिंग्स को मंजूरी दी जाती है।
इन वस्तुओं को सामान्य फ़र्मवेयर अनुलग्नकों की तरह नहीं संभाला जाना चाहिए।
यदि प्रोग्रामिंग शुरू होने के बाद फ़र्मवेयर बदल जाए तो क्या होगा?
एक नई फ़र्मवेयर छवि को लगभग तुरंत ही किसी साझा फ़ोल्डर में रखा जा सकता है।
उत्पादन तल पर पहले से मौजूद बोर्ड इसके साथ नहीं बदलते हैं।
यदि प्रोग्रामिंग शुरू होने के बाद कोई नई रिलीज़ आती है, तो टीम को इसके लिए एक स्पष्ट स्वभाव की आवश्यकता होती है:
- इकाइयाँ पहले से ही पिछले संस्करण के साथ प्रोग्राम की गई हैं;
- इकाइयों का पहले ही परीक्षण किया जा चुका है;
- प्रोग्रामिंग की प्रतीक्षा कर रही इकाइयाँ;
- क्या रिप्रोग्रामिंग की आवश्यकता है;
- क्या कार्यात्मक परीक्षण प्रभावित है;
- क्या पुनः परीक्षण की आवश्यकता है;
- जहां पुनरीक्षण सीमा उत्पादन लॉट के भीतर बैठती है।
समीक्षा का स्तर परिवर्तन के अनुरूप होना चाहिए.
एक सही डिस्प्ले स्ट्रिंग और पावर नियंत्रण व्यवहार में बदलाव से समान विनिर्माण जोखिम नहीं होता है। लेकिन इनमें से किसी को भी केवल फ़ाइल को प्रतिस्थापित करके और लाइन को जारी रखने के लिए कहकर प्रस्तुत नहीं किया जाना चाहिए।
यहीं पर संस्करण नियंत्रण कागजी कार्रवाई बनकर रह जाता है और उत्पादन नियंत्रण बन जाता है।
एक लघु पूर्व -उत्पादन जाँच
पहली उत्पादन इकाई को प्रोग्राम करने से पहले, खरीदार और ईएमएस टीम को उत्तर देने में सक्षम होना चाहिए:
- कौन सी सटीक छवि या छवियाँ जारी की जाती हैं?
- कौन सा प्रोग्रामयोग्य उपकरण प्रत्येक छवि प्राप्त करता है?
- फ़र्मवेयर किस बोर्ड संशोधन के लिए स्वीकृत है?
- क्या लोड एड्रेस या मेमोरी मैप आवश्यक है?
- क्या विकल्प बाइट्स, फ़्यूज़ या कॉन्फ़िगरेशन डेटा एम्बेडेड या अलग हैं?
- किस प्रोग्रामिंग इंटरफ़ेस का उपयोग किया जाता है?
- क्या आवश्यक प्रोग्रामिंग एक्सेस बोर्ड पर उपलब्ध है?
- प्रोग्रामिंग के दौरान बोर्ड को कैसे संचालित किया जाता है?
- कौन सा प्रोग्रामर, प्रोजेक्ट या स्वीकृत सेटअप लागू होता है?
- क्या इकाई -विशिष्ट डेटा आवश्यक है?
- क्या साबित होता है कि प्रोग्रामिंग ऑपरेशन सफल हो गया?
- क्या कार्यात्मक परीक्षण या बाद में कोई अन्य जाँच आवश्यक है?
- क्या प्रोजेक्ट परीक्षण फ़र्मवेयर, सुरक्षित प्रावधान, या किसी अन्य विशेष वर्कफ़्लो का उपयोग करता है?
यदि वे उत्तर स्पष्ट हैं, तो प्रोग्रामिंग पैकेज में केवल कुछ ही फ़ाइलें हो सकती हैं।
यदि वे नहीं हैं, तो अधिक फ़ाइलें जोड़ने से शायद ही कभी हैंडऑफ़ का समाधान होता है।

कैसे एसटीएचएल पीसीबीए विनिर्माण के भीतर फर्मवेयर प्रोग्रामिंग का समर्थन करता है
शेन्ज़ेन एसटीएचएल टेक्नोलॉजी कं, लिमिटेड (एसटीएचएल) लागू पीसीबी असेंबली परियोजनाओं के हिस्से के रूप में एमसीयू, एफपीजीए और ईईपीरोम प्रोग्रामिंग का समर्थन करता है। जहाँ आवश्यक हो, प्रोग्रामिंग को कार्यात्मक परीक्षण और प्रोजेक्ट विशिष्ट ट्रैसेबिलिटी आवश्यकताओं के साथ समन्वित किया जा सकता है।
व्यक्तिगत निर्माण के लिए, प्रोग्रामिंग समीक्षा में जारी छवि, लक्ष्य डिवाइस, बोर्ड संशोधन, प्रोग्रामिंग एक्सेस, आवश्यक डिवाइस कॉन्फ़िगरेशन, सत्यापन विधि और ग्राहक द्वारा आपूर्ति की गई कोई भी इकाई विशिष्ट डेटा शामिल हो सकता है।
सटीक प्रोग्रामर, फिक्सचर या केबल, सुरक्षा आवश्यकताएँ, फ़र्मवेयर स्वामित्व, और आवश्यक उत्पादन रिकॉर्ड को सामान्य क्षमता विवरण के बजाय विशिष्ट परियोजना के लिए सहमत किया जाना चाहिए।
निष्कर्ष
सबसे महत्वपूर्ण PCBA फ़र्मवेयर प्रोग्रामिंग आवश्यकताओं को इस बात से परिभाषित नहीं किया जाता है कि ग्राहक HEX, BIN, ELF, या कोई अन्य समर्थित फ़ाइल भेजता है या नहीं।
प्रोडक्शन के लिए तैयार हैंडऑफ़ से निर्माण टीम को चार बुनियादी सवालों के जवाब देने चाहिए:
- कौन सा डेटा प्रोग्राम किया जाना चाहिए?
- यह किस डिवाइस और बोर्ड रिवीजन से संबंधित है?
- प्रोडक्शन प्रोग्राम को कैसे और कैसे सत्यापित करना चाहिए?
- पीसीबी असेंबली को अगले उत्पादन चरण में ले जाने से पहले क्या होना चाहिए?
एक साधारण एमसीयू बोर्ड के लिए, वे उत्तर एक पृष्ठ पर फिट हो सकते हैं। कई प्रोग्रामयोग्य डिवाइस, अद्वितीय डेटा, एकाधिक फ़र्मवेयर वेरिएंट या सुरक्षा आवश्यकताओं वाले उत्पाद को स्वाभाविक रूप से अधिक विवरण की आवश्यकता होगी।
फ़र्मवेयर निर्माण के लिए तब तैयार होता है जब एक योग्य उत्पादन टीम केवल डेवलपर के दिमाग में मौजूद ज्ञान पर निर्भर रहने के बजाय, जारी जानकारी से अनुमोदित प्रोग्रामिंग प्रक्रिया को दोहरा सकती है।
ऐसे निर्माण के लिए जिसके लिए फ़र्मवेयर प्रोग्रामिंग की आवश्यकता होती है, उपलब्ध प्रोग्रामिंग फ़ाइलों और निर्देशों को BOM, Gerber फ़ाइलों, असेंबली जानकारी, मात्रा और परीक्षण आवश्यकताओं के साथ शामिल करें जब आपअपना पीसीबीए प्रोजेक्ट विवरण जमा करें.
प्रोग्रामिंग {{0}विशेष प्रश्नों के लिए, एसटीएचएल से संपर्क करेंinfo@pcba-china.com.

