چه فایل های میان افزاری برای برنامه نویسی PCBA مورد نیاز است؟

نمای کلی

یک فایل میان‌افزار می‌تواند کاملاً معتبر باشد و هنوز برای تولید آماده نباشد.

برای برنامه‌نویسی میان‌افزار روی مجموعه PCB، تیم EMS به تصویر منتشر شده، دستگاه هدف دقیق، نسخه‌ای که روی برد اعمال می‌شود، رابط برنامه‌نویسی، هر آدرس حافظه مورد نیاز یا پیکربندی دستگاه، و روشی تعریف‌شده برای تأیید نتیجه نیاز دارد. محصولاتی که به شماره سریال، آدرس MAC، مقادیر کالیبراسیون یا اعتبارنامه‌های امنیتی نیز نیاز دارند، به دستورالعمل‌های مدیریت اضافی نیاز دارند.

یک بررسی مفید تولید ساده است:

آیا تکنسینی که فریمور را ننوشته است می تواند برد را از روی دستورالعمل های منتشر شده به درستی برنامه ریزی کند؟

در غیر این صورت، نرم افزار ممکن است از نقطه نظر توسعه به پایان برسد، اما انتقال تولید اینطور نیست.

نسخه برنامه نویسی را در یک صفحه قرار دهید

تصویر سفت‌افزار تنها یک بخش از دستیابی است.

برای بسیاری از پروژه‌ها، مفیدترین سند همراه، برگه انتشار برنامه‌نویسی کوتاهی است که به تولید می‌گوید چه چیزی تایید شده و چگونه باید استفاده شود.

فرقی نمی کند که مشتری آن را دستورالعمل برنامه نویسی، یادداشت انتشار، دستورالعمل ساخت یا دستورالعمل کار کنترل شده بنامد. بخش مهم این است که اپراتور مجبور نیست تنظیمات را از رشته های ایمیل، یادداشت های توسعه قدیمی و نام فایل ها بازسازی کند.

یک برگه انتشار عملی ممکن است شامل موارد زیر باشد:

یک برد MCU ساده ممکن است تنها به تعدادی از این موارد نیاز داشته باشد. محصولی با چندین دستگاه قابل برنامه‌ریزی، انواع سیستم‌افزارهای متعدد، شناسه‌های منحصربه‌فرد یا عملکردهای امنیتی به موارد بیشتری نیاز دارد.

برگه انتشار تصمیمات مهندسی را از دست اپراتور دور نگه می دارد. تا زمانی که برد به برنامه‌نویسی برسد، تصویر تأیید شده، تنظیم و قانون تأیید باید از قبل مشخص باشد.

فرمت فایل کمتر از یک روش برنامه نویسی واضح اهمیت دارد

HEX و BIN رایج هستند، اما هیچ کدام به طور خودکار پاسخ مناسبی برای هر محصول نیستند.

گردش کار برنامه نویسی تولید همچنین ممکن است از موارد زیر استفاده کند:

• ELF یا فرمت های اجرایی مرتبط؛
• رکورد موتورولا S-.
• فروشنده-فایل های برنامه نویسی خاص؛
• بسته های پیکربندی خاص دستگاه-.

یک BIN خام به طور کلی نیاز به یک آدرس مقصد تعریف شده جداگانه دارد. قالب‌های حاوی آدرس{1}}می‌توانند اطلاعات بیشتری را در فایل حمل کنند. اینکه ELF، HEX، BIN، S{3}}و یا فرمت دیگری استفاده شود بستگی به دستگاه مورد نظر و تنظیم برنامه‌نویسی تأیید شده دارد.

در طبقه تولید، قانون ساده تر است:

از قالبی استفاده کنید که توسط تنظیمات برنامه نویسی تایید شده پشتیبانی می شود و هر چیزی را که خود فایل تعریف نمی کند مستند کنید.

اگر دامنه EMS محدود به برنامه نویسی یک تصویر تولیدی تایید شده باشد، کد منبع معمولاً غیر ضروری است. کد منبع، پروژه‌های IDE و محیط‌های ساخت زمانی مرتبط می‌شوند که کامپایل، اشکال‌زدایی، اصلاح میان‌افزار، یا تولید{1}}تصویر بخشی از محدوده مورد توافق است.

ارسال کل مخزن هنوز به تولید نمی گوید که کدام ساخت تایید شده است.

دسترسی به برنامه نویسی نیز یک تصمیم سخت افزاری است

برای برنامه‌نویسی سیستم، بسته نرم‌افزاری تنها نیمی از راه‌اندازی است.

ایستگاه تولید همچنین نیاز به دسترسی فیزیکی و الکتریکی به دستگاه مورد نظر دارد.

بسته به محصول، ممکن است از طریق:

• SWD;
• JTAG;
• UART یا یک رابط بوت لودر دیگر؛
• USB DFU;
• SPI;
• یک رابط برنامه نویسی اختصاصی؛
• ثابت-نقاط آزمایشی قابل دسترسی؛
• یک دستگاه{0}}رابط خاص دیگر.

دستورالعمل برنامه‌نویسی همچنین ممکن است نیاز به تعریف وضعیت برق برد، اتصال یا آزمایش{0}نقطه پین‌آت، وضعیت راه‌اندازی مورد نیاز، آداپتور برنامه‌نویسی، رفتار بازنشانی و دنباله پاک کردن/برنامه/تأیید مورد انتظار داشته باشد.

این جزئیات بهتر است قبل از رسیدن بردهای مونتاژ شده به ایستگاه برنامه نویسی حل شوند.

یک سیگنال SWD غیرقابل دسترسی با ارسال یک فایل HEX بهتر قابل رفع نیست.

برای محصولاتی که به نقاط تست برنامه‌نویسی یا دسترسی به فیکسچر بستگی دارند، آمادگی برنامه‌نویسی تا حدی یک مشکل DFT است، نه فقط یک انتقال نرم‌افزار.

 

ویرایش سیستم عامل و ویرایش برد را با هم نگه دارید

فایل هایی با نام last.hex یا final_new_v2.bin ممکن است برای شخصی که آنها را ایجاد کرده کاملاً قابل درک باشد. آنها کنترل تولید ضعیفی دارند.

تولید به روشی قابل اعتماد برای تشخیص نسخه تایید شده از موارد زیر نیاز دارد:

• نسخه منسوخ شده؛
• یک ساختمان مهندسی؛
• فقط یک تصویر{0}}تست.
• یک نوع محصول دیگر

بسته به سیستم کنترل{0} سند مشتری، هویت منتشر شده ممکن است شامل بازبینی میان‌افزار، نام فایل کنترل‌شده، تاریخ انتشار، بازبینی هیئت مدیره قابل اجرا، مرجع تأیید مشتری، اندازه فایل، یا جمع‌بندی/درهم‌سازی باشد.

تولید به یک نامگذاری جهانی یا طرح جمع کنترلی نیاز ندارد. به یک روش قابل اعتماد برای تشخیص بیلد منتشر شده از هر چیز دیگری در پوشه نیاز دارد.

هنگامی که یک پلتفرم سخت افزاری از چندین نوع نرم افزار پشتیبانی می کند، این مهم تر می شود. ممکن است تخته ها یکسان به نظر برسند در حالی که محصولات نهایی شبیه به هم نیستند.

 

وقتی برنامه‌نویسی شامل واحد{0}داده‌های خاص می‌شود

برای بسیاری از محصولات، هر برد یک تصویر سیستم عامل را دریافت می کند.

سایر محصولات نیز به اطلاعات واحد{0}} خاص نیاز دارند، مانند:

• شماره سریال؛
• آدرس های مک؛
• شناسه محصول؛
• ضرایب کالیبراسیون؛
• پیکربندی منطقه ای؛
• تنظیمات خاص مشتری-.
• اعتبار دستگاه

در آن مرحله، میان‌افزار مشترک و داده‌های هر{0} واحد، دو جریان داده متفاوت هستند.

تولید باید بداند که مقادیر منحصربه‌فرد از کجا می‌آیند، کجا نوشته شده‌اند، چگونه هر مقدار با برد فیزیکی صحیح مرتبط است و چگونه از تخصیص‌های تکراری جلوگیری می‌شود.

نادیده گرفتن یک جزئیات آسان است: چه زمانی یک ارزش منحصر به فرد مصرف می شود؟

شماره سریال یا آدرس MAC ممکن است در زمان اختصاص داده شدن، موفقیت برنامه‌نویسی یا تنها پس از گذراندن واحد آزمون مورد نیاز، مورد استفاده در نظر گرفته شود. هیچ قانون واحدی برای هر محصول وجود ندارد، اما قبل از شروع ساخت باید یک قانون توافق شده وجود داشته باشد.

همین امر در مورد واحدهای شکست خورده نیز صدق می کند. تیم باید بداند که آیا یک مقدار اختصاص‌یافته می‌تواند دوباره استفاده شود، باید بازنشسته شود یا برای ردیابی به تابلوی شکست خورده مرتبط می‌ماند.

 

مجوز برنامه نویسی یک مجوز FCT نیست

تأیید برنامه نویسی و تست عملکرد ممکن است در جریان تولید نزدیک به هم اتفاق بیفتند، اما به سؤالات مختلفی پاسخ می دهند.

تایید برنامه نویسی

تأیید برنامه نویسی می پرسد:

آیا داده های مورد نظر طبق روش برنامه نویسی مصوب به درستی نوشته شده است؟

بسته به دستگاه و راه‌اندازی، این ممکن است شامل عملکرد تأیید برنامه‌نویس، مقایسه بازخوانی در صورت مجاز، CRC، تأیید پیکربندی یا روش تأیید شده دیگری باشد.

تست عملکردی

تست عملکردی می پرسد:

آیا مجموعه PCB تغذیه شده و برنامه ریزی شده عملکردهای مورد نیاز محصول را انجام می دهد؟

بسته به پروژه، این ممکن است شامل موارد زیر باشد:

• تقویت-رفتار؛
• ارتباط؛
• پاسخ ورودی/خروجی؛
• ورودی سنسور؛
• خروجی رله یا محرک؛
• قرعه کشی فعلی;
• شرایط عملیاتی تعریف شده توسط مشتری-.

برنامه نویسی که PASS را نمایش می دهد نباید به طور خودکار به عنوان مدرکی تلقی شود که مجموعه PCB FCT را پاس کرده است.

برای پروژه‌هایی که نیاز به بارگذاری میان‌افزار دارند تا با اعتبارسنجی سطح برد{0}} هماهنگ شود، STHL'sتست و بازرسیقابلیت ها مسیر خدمات مربوطه را فراهم می کند.

 

دو موقعیتی که به دستورالعمل های اضافی نیاز دارند

اکثر مشاغل برنامه نویسی نیازی به فرآیند تهیه دقیق ندارند. دو موقعیت زمانی که به کار می روند مستحق توجه بیشتری هستند.

تست سفت افزار و سفت افزار تولیدی

برخی از محصولات در حین ساخت از سیستم عامل تشخیصی و برای ارسال از سیستم عامل متفاوتی استفاده می کنند.

اگر چنین است، تولید باید بداند که کدام تصویر در هر مرحله اعمال می شود، زمانی که تصویر آزمایشی جایگزین می شود، چگونه انتشار نهایی تایید می شود، و اینکه آیا بعد از آن بررسی عملکرد دیگری لازم است یا خیر.

در غیر این صورت، یک برد می تواند عیب یابی تولید را پاس کند و همچنان با نصب سیستم عامل اشتباه تولید را ترک کند.

هر محصولی به سیستم عامل آزمایشی جداگانه نیاز ندارد. فرآیند باید از محصول واقعی پیروی کند.

تامین امن

برخی از دستگاه‌های امنیتی{0}}فعال به تصاویر امضا شده یا رمزگذاری‌شده، تنظیمات راه‌اندازی ایمن، پیکربندی OTP/eFuse، کلیدها، گواهی‌ها یا سایر داده‌های کنترل‌شده نیاز دارند.

هنگامی که این الزامات اعمال می‌شود، ارائه‌دهنده OEM و EMS باید به توافق برسند که چه کسی مالک داده‌های حساس است، تولید کدام عملیات مجاز به انجام آن است و چگونه تنظیمات برگشت‌ناپذیر تأیید می‌شوند.

این موارد نباید مانند ضمیمه های سیستم عامل معمولی مورد استفاده قرار گیرند.

اگر پس از شروع برنامه نویسی، سفت افزار تغییر کند چه؟

یک تصویر سیستم عامل جدید را می توان تقریباً بلافاصله در یک پوشه مشترک قرار داد.

تابلوهایی که از قبل در کف تولید هستند با آن تغییر نمی کنند.

اگر نسخه جدیدی پس از شروع برنامه‌نویسی ارائه شود، تیم به یک تمایل روشن برای موارد زیر نیاز دارد:

• واحدهایی که قبلاً با نسخه قبلی برنامه ریزی شده اند.
• واحدهای قبلاً آزمایش شده؛
• واحدهای منتظر برنامه نویسی
• آیا برنامه ریزی مجدد مورد نیاز است.
• آیا تست عملکردی تحت تأثیر قرار می گیرد یا خیر.
• آیا آزمایش مجدد لازم است
• جایی که مرز بازبینی در داخل لات تولید قرار دارد.

سطح بررسی باید به دنبال تغییر باشد.

یک رشته نمایش تصحیح شده و یک تغییر{0}}رفتار کنترلی به قدرت، خطر تولید یکسانی ندارد. اما هیچکدام نباید به سادگی با جایگزین کردن یک فایل و گفتن خط به ادامه معرفی شوند.

اینجاست که کنترل نسخه دیگر کاغذبازی نیست و به کنترل تولید تبدیل می شود.

 

یک بررسی کوتاه قبل از-تولید

قبل از اینکه اولین واحد تولیدی برنامه ریزی شود، خریدار و تیم EMS باید بتوانند پاسخ دهند:

• چه تصویر یا تصاویر دقیقی منتشر می شود؟
• کدام دستگاه قابل برنامه ریزی هر تصویر را دریافت می کند؟
• فریمور برای کدام ویرایش برد تایید شده است؟
• آیا آدرس بار یا نقشه حافظه مورد نیاز است؟
• آیا بایت های گزینه، فیوزها یا داده های پیکربندی تعبیه شده اند یا جداگانه؟
• کدام رابط برنامه نویسی استفاده می شود؟
• آیا دسترسی برنامه نویسی مورد نیاز روی برد موجود است؟
• بورد در حین برنامه نویسی چگونه تغذیه می شود؟
• کدام برنامه نویس، پروژه یا تنظیمات تایید شده اعمال می شود؟
• آیا واحد{0}}داده خاصی مورد نیاز است؟
• چه چیزی ثابت می کند که عملیات برنامه نویسی انجام شده است؟
• آیا تست عملکرد یا بررسی دیگری بعد از آن لازم است؟
• آیا پروژه از سیستم عامل آزمایشی، تأمین امن یا گردش کار خاص دیگری استفاده می کند؟

اگر این پاسخ ها واضح باشد، بسته برنامه نویسی خود ممکن است فقط حاوی چند فایل باشد.

اگر اینطور نیست، افزودن فایل های بیشتر به ندرت مشکل را حل می کند.

 

چگونه STHL از برنامه نویسی سفت افزار در تولید PCBA پشتیبانی می کند

Shenzhen STHL Technology Co., Ltd. (STHL) از برنامه نویسی MCU، FPGA و EEPROM به عنوان بخشی از پروژه های مونتاژ PCB قابل اجرا پشتیبانی می کند. برنامه‌نویسی را می‌توان با آزمایش‌های عملکردی و الزامات قابلیت ردیابی خاص پروژه در صورت نیاز هماهنگ کرد.

برای یک ساخت منفرد، بررسی برنامه‌نویسی ممکن است تصویر منتشر شده، دستگاه هدف، بازبینی برد، دسترسی برنامه‌نویسی، پیکربندی دستگاه مورد نیاز، روش تأیید، و هر واحد{0}}داده‌ای خاص ارائه‌شده توسط مشتری را پوشش دهد.

برنامه نویس دقیق، فیکسچر یا کابل، الزامات امنیتی، مالکیت سیستم عامل و سوابق تولید مورد نیاز باید برای پروژه خاص توافق شود تا اینکه از یک بیانیه قابلیت کلی فرض شود.

نتیجه گیری

مهمترین الزامات برنامه نویسی سیستم عامل PCBA با ارسال HEX، BIN، ELF یا فایل پشتیبانی شده دیگری توسط مشتری تعریف نمی شود.

یک تحویل آماده-تولید باید به تیم سازنده اجازه دهد به چهار سؤال اساسی پاسخ دهد:

• چه داده هایی باید برنامه ریزی شوند؟
• مربوط به کدام دستگاه و ویرایش برد است؟
• چگونه تولید باید برنامه ریزی و تایید شود؟
• قبل از اینکه مونتاژ PCB به مرحله تولید بعدی برود چه اتفاقی باید بیفتد؟

برای یک برد MCU ساده، این پاسخ ها ممکن است در یک صفحه قرار گیرند. محصولی با چندین دستگاه قابل برنامه ریزی، داده های منحصر به فرد، انواع سفت افزارهای متعدد یا الزامات امنیتی طبیعتاً به جزئیات بیشتری نیاز دارد.

زمانی که یک تیم تولید واجد شرایط بتواند فرآیند برنامه نویسی تایید شده را از روی اطلاعات منتشر شده تکرار کند، به جای تکیه بر دانشی که فقط در ذهن توسعه دهنده وجود دارد، سفت افزار آماده تولید است.

برای ساختی که نیاز به برنامه‌نویسی سیستم‌افزار دارد، فایل‌های برنامه‌نویسی موجود و دستورالعمل‌ها را همراه با BOM، فایل‌های Gerber، اطلاعات اسمبلی، کمیت، و الزامات آزمایشی درج کنید.جزئیات پروژه PCBA خود را ارسال کنید.

برای سؤالات خاص برنامه‌نویسی{0}}، با STHL تماس بگیریدinfo@pcba-china.com.