كان العمل دائمًا مع CAN بسيطًا ، ولكن حدث خطأ ما (في الجهاز على KDPV) ...
لقد تمكنت مؤخرًا من استخدام متحكم STM32H750VB ، وفي أحد الأجهزة كنت بحاجة لاستخدام ناقل CAN ، لكن المحاولة الأولى التي أجريتها
أظهرت أن ثقتي بالنفس أعطت نتيجة غريبة. ويرد وصف القصة أدناه.
لذلك ، أولا عن الدوائر. على KDPV محاط باللون الأخضر ، بطبيعة الحال ، الجاني هو متحكم ، لا يوجد شيء معقد مع CAN - متصل وفقًا
يتم استخدام MAX3051 كطبقة مادية (حسناً ، أنا أحب ذلك ..) ، مثل هذا:
في السابق ، بدلاً من STM32H750VB ، كان STM32F107 في نفس النظام ، لكن الرجل العجوز لم يستطع التعامل مع المهام وتقرر استبداله بمزيد من الحداثة
والشباب .
ولكن هذا هو الحظ السيئ - فقد كان المتحكم القديم لديه bxCAN ، أما الجديد فقد كان لديه FDCAN بالفعل. على الرغم من وجود اختلافات ، ولكن من وجهة نظر الكود (والعمل - تعد الأجهزة الموجودة على الحافلة قديمة): الاستبدال بسيط للغاية. بالنسبة لأولئك الذين يرغبون ، يمكنك مقارنة:
بشكل عام ، الاختلافات مستحضرات التجميل. وبدا لي أنها ستعمل في وقت واحد وبشكل صحيح.
ومع ذلك ، لم يعمل على الفور ...
تعذر على وحدة التحكم CAN ضبط مستوى مهيمن ودخلت في حالة Bus-Off ، ولم يتم تلقي أي بيانات من الحافلة (على الرغم من أن جهازًا آخر على الحافلة أرسل الحزم بثبات مرتين في الثانية).
حسنًا ، حسب اعتقادي ، جاء خط التصحيح ، وقام بتوصيل الأسلاك على خطي CAN-RX و CAN-TX (في الواقع ، بدا أن الحافلة نفسها تبدو منطقية - كان الجهاز صامتًا ، وأرسل الجهاز الآخر المتصل حزمًا
، كما هو متفق عليه ).
بعد ذلك ، تم تشغيل وضع FDCAN_MODE_BUS_MONITORING لأول مرة. وها ، لقد رأيت على الفور عبوات من الحافلة! (في هذا الوضع ، تستمع وحدة التحكم CAN فقط إلى البيانات ، ولكنها لا تنقل أي شيء). رائع جدا ...
بعد ذلك ، تم تشغيل وضع FDCAN_MODE_EXTERNAL_LOOPBACK (في هذا الوضع ، على العكس ، نحن نستمع إلى أنفسنا فقط ، ولكن بعد ذلك ننقل كل شيء إلى الحافلة). وعلى خطي CAN_RX و CAN_TX ، ظهرت كل حزم البيانات - تم إرسالهما بواسطة الجهاز نفسه وتلقيهما من الناقل ، هنا على
في الشكل أدناه (بيانات رمادية TX من متحكم ، خط بيانات برتقالي RX) تكون مرئية كقمم:
لذلك ، بعد هذه التجربة ، أصبح من الواضح أن الدائرة تعمل بشكل صحيح ، ويمكن لوحدة التحكم CAN في المعالج الدقيق تلقي البيانات ونقلها.
ومع ذلك ، عند محاولة تلقي البيانات ونقلها في وقت واحد ، لا يزال النظام قد أصبح Bus-Off مع وجود خطأ في سجل التحكم في الأخطاء (سجل حالة بروتوكول FDCAN (FDCAN_PSR)) LEC [2: 0] = 5 - مما يعني من ورقة البيانات Bit0Error: أثناء إرسال رسالة (أو إقرار بت ، أو خطأ نشط
إشارة أو إشارة التحميل الزائد) ، أراد الجهاز إرسال مستوى مهيمن (بت البيانات أو معرف المعرف
القيمة المنطقية 0) ، ولكن قيمة الحافلة التي تم مراقبتها كانت متنحية ...
بعد يومين من العذاب (من الواضح ما هو الخطأ ، ولكن ليس من الواضح كيفية إصلاحه) ودراسة مدروسة لورقة البيانات والخطأ ومجموعة من التعليمات البرمجية والأدلة الخاصة بالطرف الثالث ، أصبح
التنوير على ما أفهمه - أفعل كل شيء بشكل صحيح ، لكنه لا يعمل!
حسنًا ، لقد فكرت ، ربما تكون المسألة في التكنولوجيا ، و ... استبدلت وحدة التحكم الدقيقة نفسها (بآخر من نفس المجموعة). و ... عملت! حسنا ، هذا هو ، دون
الرقص مع الدف من المشاكل ، مع شفرة المصدر وكما ينبغي أن تكون المرة الأولى.
ملخص موجز
على ما يبدو ، جاءت مثل هذه العينة الماكرة. لكن من ناحية أخرى ، تمكنت من الخوض في عمل FDCAN بشكل عام ، والذي يمكن أن يعزى إلى الإيجابيات. وإلى السلبيات ... ولهم يمكن أن يعزى الوقت الضائع (يمكن أن تعلق وحدة تحكم لمشروع آخر) وفهم أن وحدات التحكم الحديثة عربات التي تجرها الدواب
مع القوة الرهيبة ، أيضا ، بطريقة حديثة (أم أنها أيضا زائد؟).