Install
cargo build --releaseلمن يناسب
إذا أردت أن يتولى وكيل تنقيح لوحة مضمّنة بدل أن تضبط أولاً منقّحاً رسومياً كاملاً، فهذه الخدمة توافق ذلك. هي خادم MCP مكتوب بـ Rust يستطيع اكتشاف المسابير والتحكم بالهدف وقراءة الذاكرة ونقاط التوقف والوميض وRTT وتشخيص أعطال موجّه للوكلاء عبر probe-rs أو GDB Remote Serial Protocol الخاص بـ OpenOCD. معها سطر أوامر صغير وتدفق تغليف يمكن استخدامهما قبل ربط عميل MCP. ليست كتيّب شريحة ولن تلحم الأسلاك نيابة عنك.
الملاحظات الرسمية:
https://github.com/adancurusul/embedded-debugger-mcp
الشرط الأهم: عمل العتاد يحتاج مسباراً متوافقاً، أو openocd يعمل أصلاً ويعرض منفذ GDB، مع توصيل SWD/JTAG صالح. النص الرسمي يسمّي ST-Link وJ-Link وDAPLink وBlack Magic Probe أو مسبار FTDI مدعوماً؛ ويمكن لـ ESP32 استخدام openocd-esp32. بلا مسبار لا تبدأ الوميض.
أول محاولة في 3 دقائق
اتبع المسار الرسمي الواحد: انسخ المستودع ثم بناء Cargo للإصدار.
المتطلبات: Rust / cargo مثبّتان. عمل العتاد يحتاج أيضاً المسبار أو OpenOCD أعلاه. المحاولة الأولى اكتشاف فقط — لا تبرمج flash.
انسخ أولاً:
https://github.com/adancurusul/embedded-debugger-mcp.git
أمر التثبيت:
cargo build --release
الثنائي في target/release/embedded-debugger-mcp.
موضع الإعداد: يضع عميل MCP الأمر على embedded-debugger-mcp serve. للتوافق، تشغيل الثنائي بلا أمر فرعي يقدّم أيضاً MCP على stdio. الأدلة لا تقول أي عميل إلزامي؛ لا تضف قائمة أسماء.
الاستدعاء الأول منخفض المخاطر: اكتشاف المسابير فقط. ذلك يعدد المسابير المحلية وليس إيقافاً ولا وميضاً. إن لمست الهدف فأكّد التوصيل أولاً. أداتا التشخيص diagnose_fault وunwind_exception تقرآن موقع الاستثناء وقد تؤثران على البرنامج الثابت الجاري — لا تستخدمهما في المحاولة الأولى.
إشارة النجاح: ينتهي بناء الإصدار ويستطيع العميل تشغيل serve ويعيد الاكتشاف جرد مسابير أو مجموعة فارغة بوضوح. إن فشل Cargo وحده فتوقف عند البناء ولا تنتقل إلى flash.
حالات الاستخدام
الحالة الأولى: اكتشف المسابير وأكّد إن كان ST-Link أو J-Link أو جهاز متوافق آخر مرئياً. يضع النص الرسمي probe discovery أولاً في مجموعة الأدوات. ما يمكنك التحقق منه هو ظهور المسبار الذي وصلته في الجرد. الأدلة لا تكتب اسم الدالة الدقيق ولا المعاملات؛ لا تخترع الناقص.
الحالة الثانية: بعد اتصال الهدف أصلاً استخدم diagnose_fault أو unwind_exception لرؤية عطل. يكتبها النص الرسمي كـ crash diagnosis. يناسب عندما تكون اللوحة متوقفة أصلاً عند استثناء وتحتاج أن يقرأ الوكيل سياق العطل. الوصول إلى الذاكرة وRTT في المجموعة نفسها، لكن هذه الصفحة لا توسّع عروض القراءة/الكتابة ولا تنسيقات المخزن. حتى هنا تؤكد فقط وجود أسماء التشخيص. flash programming وbreakpoints كتابات لها آثار جانبية — لا تجعلهما المثال الأول.
حدود الاستخدام
بلا مسبار أو بلا توصيل SWD/JTAG لا يمكن عمل العتاد. مسار OpenOCD يحتاج عملية تعمل أصلاً وتعرض منفذ GDB، مثلاً ESP32 مع openocd-esp32. الوميض ونقاط التوقف والإيقاف تغيّر حالة الهدف. ليست صفر مخاطر وليست «بلا لمس عتاد» أو «بلا قراءة ذاكرة».
يذكر النص الرسمي أيضاً Cortex-M وRISC-V وXtensa، لكن هذه الصفحة بلا جرد شرائح ولا خطوات تراجع. يغطي هذا الدليل فقط بناء Cargo للإصدار وstdio serve والاكتشاف أولاً ثم التشخيص عند الحاجة. إن لم يُكتب تدفق آخر في الصفحة نفسها فلا توسّع.