چراغ لینک روشن است، ولی داده به سرویس نمی‌رسد
Ethernet FeatherWing آدافروت با شناسه محصول ۳۲۰۱ ارتباط سیمی را به برد میزبان Feather اضافه می‌کند. کنترلر شبکه از طریق SPI با میکروکنترلر صحبت می‌کند و در سمت دیگر یک سوکت اترنت با چراغ‌های لینک و فعالیت قرار دارد. این تقسیم کار برای عیب‌یابی ارزشمند است. ممکن است کابل به سوئیچ وصل باشد و چراغ لینک روشن شود، اما برنامه هنوز نتواند با کنترلر روی SPI ارتباط بگیرد. برعکس، برنامه می‌تواند کنترلر را بشناسد ولی به علت تنظیم شبکه به سرویس مقصد دسترسی نداشته باشد.
یک کاربرد مناسب، گره آزمایشگاهی است که دما یا وضعیت یک دستگاه را به سرور محلی می‌فرستد. ارتباط سیمی نیاز به انتخاب شبکه بی‌سیم و مدیریت قدرت سیگنال را حذف می‌کند، اما طراحی آدرس‌دهی، کنترل دسترسی و رفتار برنامه هنگام قطع ارتباط همچنان لازم است. راهنمای محصول، نمونه کار در نقش مشتری شبکه را توضیح می‌دهد. قابلیت‌های کتابخانه و پشتیبانی از نقش‌های دیگر باید برای همان محیط نرم‌افزاری بررسی شود. در این راهنما گره آزمایشی خودش ارتباط خروجی به سرویس محلی برقرار می‌کند.
از مدل دقیق کنترلر تا انتخاب پایه
برد از خانواده کنترلر W5500 استفاده می‌کند و از طریق خطوط مشترک SPI و یک پایه انتخاب تراشه با میزبان ارتباط دارد. هنگام ترکیب با FeatherWing دیگر، نخست بررسی کنید خطوط انتخاب تراشه با هم تداخل نداشته باشند. کلاک و خطوط داده می‌توانند روی باس مشترک باشند، ولی دو وسیله نباید همزمان خروجی خط داده را کنترل کنند. وضعیت پایه‌های انتخاب در آغاز برنامه نیز اهمیت دارد. وسیله‌ای که پیش از راه‌اندازی نرم‌افزار ناخواسته انتخاب شده است می‌تواند تشخیص کنترلر شبکه را مختل کند.
در اولین آزمون فقط برد میزبان، FeatherWing شبکه و منبع تغذیه مناسب را روی میز قرار دهید. مدل دقیق میزبان و نسخه کتابخانه را ثبت کنید، زیرا مثال‌های Arduino و CircuitPython تنظیم‌های یکسانی ندارند. پایه انتخاب را از راهنمای برد بگیرید و از تطبیق آن با برنامه مطمئن شوید. وقتی ارتباط پایه کار کرد، بردهای جانبی را یکی‌یکی اضافه کنید. این ترتیب به شما اجازه می‌دهد تشخیص دهید از دست رفتن شبکه به تداخل سخت‌افزاری، مصرف برق یا تغییر برنامه مربوط بوده است.
تغذیه مستقل از کابل اترنت
محصول به طور داخلی PoE ارائه نمی‌کند. وجود سوکت RJ45 به معنی دریافت برق از کابل شبکه نیست. برای شروع، میزبان را به روش معمول خودش تغذیه کنید و کابل شبکه را برای داده به سوئیچ آزمایشگاهی وصل کنید. اگر نصب نهایی به برق روی کابل نیاز دارد، تجهیزات سازگار مانند جداکننده مناسب باید جداگانه ارزیابی شوند. از رساندن ولتاژ نامشخص به کانکتور یا پایه تغذیه خودداری کنید. روشن شدن چراغ سوئیچ درباره کافی بودن منبع برق میکروکنترلر زیر بار چیزی ثابت نمی‌کند.
اگر دستگاه در آغاز کار می‌کند ولی هنگام ارسال داده بازنشانی می‌شود، ولتاژ را نزدیک ورودی برد در شرایط واقعی اندازه بگیرید. همزمان شدن بازنشانی با فعالیت شبکه می‌تواند از افت تغذیه یا اشکال برنامه ناشی شود. دلیل بازنشانی، زمان آغاز و حجم داده را ثبت کنید. سپس همان برنامه را با منبع مطمئن و کابل کوتاه اجرا کنید. تغییر همزمان تنظیم شبکه و منبع برق تشخیص را سخت می‌کند؛ برای هر فرضیه آزمایش جدا داشته باشید و نتیجه آن را به شاهد مشخص متصل کنید.
اولین اتصال در یک شبکه کوچک
برای تشخیص اولیه، یک سوئیچ و یک سرویس محلی تحت کنترل تیم کافی است. پیش از اتصال برد، با یک رایانه دیگر سلامت کابل و درگاه را بررسی کنید. سپس چراغ لینک و فعالیت را در دو سمت ببینید. لینک نشان می‌دهد مسیر فیزیکی تا حدی برقرار شده است. چراغ فعالیت می‌تواند به علت ترافیک عمومی شبکه چشمک بزند حتی وقتی برنامه شما هیچ بسته موفقی به سرویس نفرستاده است. معیار پذیرش مرحله فیزیکی را از معیار پذیرش کاربرد جدا نگه دارید.
اگر از تخصیص خودکار آدرس استفاده می‌کنید، زمان درخواست، نتیجه و آدرس دریافت‌شده را چاپ کنید. در یک شبکه بدون سرور DHCP، روشن ماندن لینک همراه با نداشتن آدرس رفتار قابل انتظار است. برای آزمایش با آدرس ثابت، یک نشانی آزاد در زیرشبکه مناسب انتخاب کنید و ماسک، دروازه و سرویس نام را آگاهانه تنظیم کنید. اختصاص دادن یک آدرس به دو دستگاه می‌تواند خطای متناوب ایجاد کند که فقط زمانی رخ می‌دهد که هر دو روشن هستند. فهرست اجاره‌های شبکه یا نقشه آزمایش را بررسی کنید.
نام، مسیر و سرویس سه مسئله متفاوت‌اند
برای نخستین ارسال، نشانی عددی یک سرویس محلی و درگاه معلوم را استفاده کنید. اگر ارتباط موفق شد، سپس همان مقصد را با نام امتحان کنید. موفقیت نشانی عددی همراه با شکست نام، مسئله را به مسیر حل نام محدودتر می‌کند. اگر هیچ‌کدام موفق نیستند، ابتدا مطمئن شوید سرویس روی رابط درست گوش می‌دهد، درگاه انتخابی صحیح است و سیاست شبکه ارتباط از گره آزمایشی را می‌پذیرد. تغییر DNS پیش از اثبات مسیر محلی معمولاً قدم مناسبی نیست.
دسترسی به سرویس داخل همان زیرشبکه درباره دروازه پیش‌فرض چیزی ثابت نمی‌کند. برای بررسی مسیریابی، یک مقصد آزمایشگاهی در زیرشبکه مجاز دیگر انتخاب کنید و مسیر رفت و برگشت را جدا بسنجید. ثبت همزمان در سرور کمک می‌کند بفهمید درخواست اصلاً به آن رسیده است یا نه. اگر درخواست می‌رسد اما پاسخ به برد نمی‌رسد، مسیر برگشت، تنظیم آدرس یا دیواره آتش باید بررسی شود. خطای برنامه را با یک پیغام کلی مانند «اینترنت قطع است» گزارش نکنید؛ مرحله دقیق شکست برای اقدام بعدی لازم است.
شناسه شبکه و چند نمونه مشابه
در یک نمونه اولیه ممکن است برنامه‌نویس یک نشانی سخت‌افزاری ثابت را در همه نسخه‌ها قرار دهد. این کار روی میز تک‌دستگاه ممکن است مشکلی نشان ندهد، اما روشن کردن دو گره یکسان روی همان شبکه می‌تواند نگاشت‌ها را به هم بزند. برای نمونه‌های آزمایشگاهی نیز سیاست مشخصی برای تخصیص نشانی یکتا تعریف کنید و مطمئن شوید آن را با شناسه هویتی امن دستگاه اشتباه نمی‌گیرید. نشانی شبکه برای رساندن فریم به مقصد است؛ دانستن آن به برنامه مجوز ارسال داده حساس نمی‌دهد.
برای آزمایش، دو گره با شناسه‌های یکتا بسازید و زمان روشن شدن، آدرس دریافتی و اتصال هر یک را ثبت کنید. سپس یکی را خاموش و روشن کنید و ببینید سرویس چگونه اتصال تازه را از نشست قبلی تشخیص می‌دهد. اگر سامانه برای هویت فقط به آدرس IP تکیه کند، تغییر اجاره DHCP ممکن است داده را به دستگاه اشتباه نسبت دهد. شناسه کاربردی و سازوکار اعتماد باید مستقل از جایگاه موقت شبکه تعریف شوند. این موضوع در گزارش‌های سنجش و کنترل صنعتی اهمیت ویژه دارد.
ساخت پیام قابل بازپخش در آزمایش
یک پیام ساده شامل شناسه آزمایشی گره، شماره نمونه، زمان محلی و مقدار اندازه‌گیری بسازید. سرور باید نتیجه پذیرش یا رد را با دلیل قابل ثبت پاسخ دهد. برای آزمون نخست از داده ساختگی استفاده کنید تا بتوانید بسته‌ها را در محیط توسعه بررسی کنید. دریافت اتصال TCP معادل ثبت موفق رکورد در سرویس نیست. ممکن است اتصال برقرار شود ولی قالب پیام نامعتبر باشد، سرویس خطا بدهد یا پاسخ پیش از رسیدن قطع شود. برای هر مرحله نتیجه جدا داشته باشید.
اگر برنامه پس از ندیدن تأیید، همان داده را دوباره می‌فرستد، سرور باید برای شماره تکراری رفتار تعریف‌شده داشته باشد. فرض کنید سرویس رکورد را نوشته ولی پاسخ در مسیر برگشت از دست رفته است. ارسال مجدد نباید تعداد اندازه‌گیری‌ها را دو برابر کند. یک شناسه پایدار برای عملیات، همراه با ثبت پاسخ قبلی، راهی برای آزمون این وضعیت است. روی میز، پاسخ یک درخواست را عمداً دیر تحویل دهید و ببینید گره چند بار می‌فرستد و در پایان چند رکورد واقعی ثبت می‌شود.
قطع کابل و بازگشت سرویس
کابل را در میانه یک نشست آزمایشی جدا کنید و رویدادها را در برد و سرور مشاهده کنید. برنامه نباید برای همیشه در انتظار پاسخ بماند و همه کارهای دیگر را متوقف کند. مهلت مشخص، محدود کردن تعداد تلاش نزدیک به هم و فاصله مناسب برای تلاش بعدی بخشی از طراحی بازیابی است. پس از اتصال دوباره کابل، لینک، آدرس و نشست کاربردی ممکن است هر کدام در زمان متفاوتی آماده شوند. روشن شدن چراغ نباید بلافاصله به معنی آماده بودن سرویس فرض شود.
آزمون دوم را با باقی ماندن کابل و خاموش کردن فقط سرویس انجام دهید. این بار لینک و آدرس برقرارند، ولی برنامه مقصد پاسخ نمی‌دهد. اگر نرم‌افزار این دو وضعیت را یکسان نمایش دهد، اپراتور احتمالاً کابل سالم را بارها جابه‌جا خواهد کرد. در آزمایش سوم، سرور آدرس‌دهی را موقتاً از شبکه تازه‌راه‌اندازی‌شده بردارید. نتیجه هر سه وضعیت را جدا نام‌گذاری کنید. چنین آزمون‌هایی برای نوشتن متن درست روی نمایشگر محصول و طراحی گزارش پشتیبانی مفیدتر از نمایش یک چراغ سبز کلی هستند.
مرز کنترلر شبکه و امنیت برنامه
سیمی بودن ارتباط به خودی خود محتوا را محرمانه یا سرویس مقابل را معتبر نمی‌کند. اگر داده حساس ارسال می‌شود، روش احراز هویت و حفاظت ارتباط باید با توان میکروکنترلر، کتابخانه شبکه و طراحی سرویس سازگار باشد. پشتیبانی یک نمونه از اتصال ساده به معنی آماده بودن مدیریت گواهی یا ساعت معتبر برای ارتباط امن نیست. برای محصول، مسیر تأمین اعتبارنامه، مدت اعتبار آن، تعویض و رفتار هنگام شکست تأیید را جدا طراحی و آزمایش کنید.
در گزارش پایان کار، تصویر سیم‌کشی، پایه انتخاب تراشه، نسخه کتابخانه، آدرس‌ها، وضعیت لینک و نمونه درخواست و پاسخ معتبر را نگه دارید. معیار پذیرش می‌تواند این باشد که پس از قطع کابل یا توقف سرویس، دستگاه وضعیت درست را اعلام کند، اطلاعات از دست رفته را طبق سیاست تعریف‌شده مدیریت کند و پس از بازگشت شبکه رکورد تکراری نسازد. ارزش این FeatherWing برای میز امنیت سخت‌افزار در همین امکان تفکیک لایه‌هاست؛ از انتقال روی SPI تا اتصالی که واقعاً به سرویس مورد اعتماد می‌رسد.
