رفتن به محتوا
IROSG.
ابزارها

Feather M4 CAN Express؛ ساخت میز آزمایش گذرگاه CAN

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

تصویر رسمی Feather M4 CAN Express
سازنده—
نوع ابزار—
وضعیت—
رابط‌ها / حوزه—

یک شبکهٔ کوچک CAN روی میز

Feather M4 CAN Express با شمارهٔ محصول 4759 بردی است که می‌تواند یک گرهٔ آزمایشی روی گذرگاه CAN باشد. کنترل‌کنندهٔ داخلی تراشه، فرستنده‌گیرندهٔ روی برد و ترمینال اتصال، امکان ارسال و دریافت پیام را در یک قطعه جمع می‌کنند. برای نمونه می‌توان دو برد روی میز گذاشت، یکی را فرستندهٔ مقدار یک حسگر فرضی و دیگری را ثبت‌کننده قرار داد. این چیدمان به تیم اجازه می‌دهد قالب پیام، زمان ارسال، رفتار هنگام قطع ارتباط و روش تشخیص خطا را پیش از اتصال به تجهیز واقعی بررسی کند.

در چنین فیکسچری سه پرسش را جدا نگه دارید. آیا لایهٔ الکتریکی ارتباط پایدار دارد؟ آیا پیام با شناسه و قالب درست دریافت می‌شود؟ آیا نرم‌افزار معنی داده را درست تفسیر می‌کند؟ دیدن چند بایت روی صفحه فقط به پرسش دوم بخشی از پاسخ را می‌دهد. ممکن است پیام سالم برسد ولی گیرنده ترتیب بایت‌ها یا واحد اندازه‌گیری را اشتباه در نظر گرفته باشد. آزمون خوب برای هر پرسش شاهد جدا تولید می‌کند و به یک پیام «ارتباط برقرار شد» بسنده نمی‌کند.

سخت‌افزار و مسیر سیگنال

طبق صفحهٔ آدافروت، پردازندهٔ ATSAME51J19 دارای هستهٔ Cortex M4 با فرکانس 120 مگاهرتز، 512 کیلوبایت فلش و 192 کیلوبایت RAM است. برد دو مگابایت فلش SPI جدا نیز دارد که می‌تواند برای فایل‌ها یا ثبت داده استفاده شود. بخش CAN سخت‌افزاری در پردازنده قرار دارد و فرستنده‌گیرندهٔ روی برد ارتباط با دو خط گذرگاه را انجام می‌دهد. وجود این دو جزء اهمیت دارد. پایهٔ منطقی میکروکنترلر را نمی‌توان به جای خط تفاضلی CAN به کابل شبکه وصل کرد.

منطق برد 3.3 ولتی است. مبدل روی برد تغذیهٔ 5 ولت مورد نیاز فرستنده‌گیرنده را حتی هنگام کار با باتری فراهم می‌کند. این توضیح به این معنا نیست که ورودی‌های عمومی پردازنده برای 5 ولت مجازند یا ترمینال CAN خروجی تغذیهٔ عمومی در اختیار کاربر می‌گذارد. روی ترمینال سه‌پایه، دو خط سیگنال و مرجع زمین معرفی شده‌اند. برچسب پایه‌ها را از روی برد و راهنمای همان بازنگری بخوانید و مسیر تغذیهٔ دو گره را جداگانه مشخص کنید.

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

طراحی سیم‌کشی آزمایشی

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

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

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

نوشتن قرارداد پیام

برای مثال آموزشی، یک پیام دوره‌ای تعریف کنید که شامل شمارهٔ توالی، یک مقدار اندازه‌گیری و یک وضعیت باشد. برای هر فیلد، محل بایت، ترتیب، علامت، ضریب مقیاس و واحد را بنویسید. تعریف کنید اگر حسگر در دسترس نبود چه مقدار یا کد وضعیتی ارسال می‌شود. مقدار عددی صفر ممکن است یک اندازه‌گیری معتبر باشد، بنابراین نباید بدون تعریف روشن هم‌زمان معنای «خطا» داشته باشد. قرارداد باید از روی نسخهٔ برنامهٔ فرستنده و گیرنده قابل شناسایی باشد.

تفسیر شناسهٔ CAN نیز باید در همین قرارداد ثبت شود. شناسه اطلاعاتی دربارهٔ پیام و اولویت داوری فراهم می‌کند، ولی اصالت فرستنده را به تنهایی ثابت نمی‌کند. در یک شبکهٔ آزمایشی با دو گرهٔ شناخته‌شده این موضوع به‌سادگی کنترل می‌شود. اگر بعداً برد به شبکه‌ای وصل می‌شود که گره‌های بیشتری دارد، مالک هر شناسه و مجازبودن پیام باید از قبل روشن باشد. انتخاب تصادفی شناسه‌ای که روی شبکهٔ واقعی استفاده می‌شود می‌تواند رفتار گره‌های دیگر را تغییر دهد.

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

اجرای نخست با CircuitPython یا Arduino

برد از Arduino و CircuitPython برای کار با CAN پشتیبانی می‌کند و با بوت‌لودر UF2 عرضه می‌شود. در مسیر CircuitPython می‌توان برنامه را به عنوان فایل روی حافظهٔ برد نگه داشت. پیش از شروع، نسخهٔ محیط، نسخهٔ کتابخانه و نوع برد انتخاب‌شده را ثبت کنید. برنامه‌ای که برای Feather دیگری نوشته شده ممکن است از نام پایه‌ها یا سخت‌افزار متفاوتی استفاده کند. برای آزمون پایه از مثال مخصوص Feather M4 CAN Express آغاز کنید و پس از دریافت نخستین پیام، منطق پروژه را اضافه کنید.

یک گره را با فاصلهٔ زمانی ثابت فرستنده و دیگری را گیرنده قرار دهید. گرهٔ گیرنده در هر خط، زمان محلی، شناسه، طول و محتوای بایت‌ها را ثبت کند. ابتدا نرخ انتشار پایین باشد تا بررسی دستی ممکن شود. شمارهٔ توالی باید به ترتیب پیش برود و تعداد پیام‌های ارسال و دریافت در بازهٔ معلوم قابل مقایسه باشد. اگر از رایانه برای ضبط خروجی سریال استفاده می‌کنید، تأخیر یا حذف داده در مسیر USB را با حذف واقعی پیام روی CAN یکی نگیرید.

پس از نتیجهٔ اولیه، جهت ارتباط را عوض کنید یا پاسخ تأیید در سطح برنامه تعریف کنید. تأیید درخواست کاربردی با تأیید سطح گذرگاه تفاوت دارد. ممکن است پیام روی شبکه پذیرفته شود، ولی نرم‌افزار گیرنده به دلیل نسخهٔ ناموافق یا مقدار خارج از محدوده آن را اعمال نکند. پاسخ سطح برنامه می‌تواند شناسهٔ درخواست و نتیجهٔ بررسی را بازگرداند. برای فرمانی که تکرار آن اثر جانبی دارد، رفتار در برابر دریافت دوباره و تأخیر پاسخ را از پیش تعریف کنید.

آزمون زمان‌بندی و خطا

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

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

اگر خطاهای ارتباطی افزایش یافت، ابتدا تغذیه و مرجع زمین، سپس جابه‌جایی خطوط، نرخ بیت و پایان‌دهی را بررسی کنید. برای مشاهدهٔ شکل موج از ابزار و اتصال مناسب استفاده کنید و محل اندازه‌گیری را در گزارش بیاورید. یک وضعیت موفق در سمت نرم‌افزار لزوماً حاشیهٔ مناسب لایهٔ فیزیکی را ثابت نمی‌کند. ممکن است شبکه روی میز کوتاه کار کند ولی پس از افزودن کابل یا گرهٔ دیگر ناپایدار شود. آزمایش نهایی باید توپولوژی و طول‌های مورد نظر کاربرد را بازنمایی کند.

ذخیره‌سازی و تحویل فیکسچر

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

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

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

TRACEABLE KNOWLEDGE

منابع و مطالعهٔ بیشتر

01
راهنمای رسمی Adafruithttps://www.adafruit.com/product/4759

آخرین بررسی تحریریه:

IROSG / EDITORIAL

خبرها و معرفی مشاهیر با نگارش مستقل و ذکر منبع تهیه شده‌اند. اعتبار و مجوز تصاویر در بخش منابع همین صفحه نگه‌داری می‌شود تا متن زیر عکس‌ها شلوغ نشود. داده‌های مرجع CVE با اعتباردهی به منابع اصلی ارائه می‌شوند.

سیاست تألیف و حقوق تصاویر ↗

ادامهٔ کشف.

ابزارها ↗