🖲️ 🎯 🔑 أغنية نقل البيانات 👩🏼 😎 🏨

في السطور الأولى من نزيف النص الخاص بي ، أود أن أقول ما يلي: لقد كتب كثيرًا حول هذا الأمر ، وسأكتب رؤيتي أيضًا. تعد الواجهات القياسية لإرسال المعلومات رائعة ، ولكن بالنسبة لاحتياجاتي ، فإنها لا توفر ما يكفي من نقل البيانات المرضي (جيدًا أو تقريبًا). سأحاول القيام ببعض الإضافات من أجل جلب هذا إلى الدولة التي تناسبني.

يوجد جهازان أو أكثر على مسافة كبيرة بما فيه الكفاية (1-100 متر) يجب إرسال البيانات بينهما. بعد فحص بعض الواجهات (rs232 / 422/485 ، I2C ، Ethernet) ، توصلت إلى استنتاج مفاده إما أنها لا تضمن نقل بيانات لا لبس فيه ، ولم يعجبني العديد من الأسلاك أيضًا ، ولا يعطون إجابة على قبول المعلومات. قررت اتخاذ واجهة RS485 كأساس - يمكن أن تذهب بعيدًا عن مزاياها ، سلكين ، يمكنك توصيل مجموعة من الأجهزة في نفس الوقت ، الأمر بسيط ، (UART) على أي وحدة تحكم تقريبًا.

في حالتي ، المخطط الكلاسيكي 1 الذي يقود بقية العبيد مناسب لي. خوارزمية الرسائل هي كما يلي: يتم إرسال البيانات في دورات التبادل ، تتكون دورة تبادل واحدة من رسالة يتم إرسالها من الرئيسي إلى العبد ، استجابةً للرسالة الرئيسية تتلقى الرسالة من العبد ، كل الآخرين صامتون. على نفس الأساس ، قم بتنفيذ طلب للحصول على بيانات من جهاز تابع.

الصورة

دورة تبادل واحدة.

لتلبية احتياجات نقل البيانات ، أحتاج إلى حل سؤالين فقط. السؤال الأول: يعتمد التحقق من البايت المرسَل على واجهة RS-485 نفسها ، ولكنه لا يضمن وجود بايت يُرسَل بشكل موثوق - إذا تم العثور على بايت في الواجهة نفسها ، فسيتم التخلص منه من البيانات المستلمة ، ولكن لا يزال من الممكن نقل البايت الخاطئ - إذا تغير (لقد أصبح سيئًا) ) عدد زوجي من البتات في البايت. أي مطلوب التحقق من عدد البايتات المرسلة وصلاحية البايتات في البيانات المرسلة.

السؤال الثاني: استقبال رسالة الرد على الرسالة المرسلة.

حول السؤال الأول: تم اقتراح هذا المخطط: البايت الأولي ، البايت لعدد
الأحرف المرسلة في الرسالة بأكملها ، شيء آخر ، البايت الاختباري (BCS) ، البايت النهائي.

الصورة

ملاحظة: يجب اعتبار البايت الاختباري المعياري 2.

بناءً على المخطط المقترح ، يمكن الحكم على أنه إذا لم يتم إرجاع الإجابة ، فلن يكون المتابع متاحًا. في هذه الحالة ، تكون الخيارات ممكنة عندما تصل رسالة تالفة إلى المتابع ولا يستجيب لها ، أو تصل إليه الرسالة ويرسل الجواب ، لكن الإجابة تسوء ويتجاهلها القائد.

لتصحيح هذا ، تم قبوله: إذا لم يأت الجواب (أو جاء ولكن غير موثوق به) ، فكرر (عدد المرات بدون جنون) كرر دورة التبادل الحالية. قد يحدث الخطأ التالي هنا. لنفترض أننا أرسلنا أمرًا يخبر الجهاز أنك بحاجة إلى رفع مستوى الصوت عن طريق وحدة +1. عندما تصل الرسالة إلى العبد ، ينفذ الأمر لرفع مستوى الصوت ويرسل الرد "حسنًا ، لقد فعلت ما تريد" ، ولكن قد يتبين أن الإجابة تسوء وأن مقدم العرض لا يفهم أن الأمر قد تم تنفيذه بالفعل ، ويرسل الرسالة مرة أخرى. ونتيجة لذلك ، عند تلقي أمر على الجانب التابع ، ستتم إضافة وحدة التخزين بالفعل +2 وحدة. لتجنب هذه الظاهرة ، من المعتاد إدخال معرف (NS - رقم الرسالة) لفرق الرسالة. إذا تم تكرار رقم الرسالة ، فهذه رسالة متكررة ولا يلزم تنفيذ الأمر المحدد ،ولكن فقط أرسل رسالة الرد السابقة.

كما أدخل هنا معلمتين إضافيتين - هذا هو رقم (رمز) الجهاز الذي يتم إرسال البيانات إليه والرقم (رمز فرعي) الذي يشير إلى الأمر الذي يجب تنفيذه (أو البيانات الموجودة داخل الرسالة).

الصورة

نتيجة لذلك ، سأضع كل ذلك معًا وأذهب عبر الخوارزمية ، باستخدام مثال زيادة عتبة التتابع بمقدار 5 درجات مئوية وأخذ درجة الحرارة الحالية من الرقيق لدورة تبادل واحدة: أقوم

بإنشاء البيانات المرسلة من المعلم:

الصورة

عند تلقي الرسالة ، ينظر العبد إلى 2 بايت ، أين هو عدد البايتات المرسلة ، إذا كان عدد البايتات المرسلة يساوي عدد البايتات المستلمة ، فلن تفقد الرسالة البايتات ، ثم ننظر إلى بايت البداية (الحرف) إذا كانت = '$' ، وأيضًا بايت النهاية (الحرف) إذا كانت = ' # '- هذه رسالة من السفر إلى الرقيق.

على الفور سأفكر في خيارات الرسالة الممكنة من المعلم إلى التابع مع وجود أخطاء في البايتات الأولية والنهائية ، بالإضافة إلى الخيار مع وجود خطأ في عدد البايتات في الرسالة. سأحجز على الفور من 3 قيم معلمات سأعتبرها صحيحة 2 و 3 ، أي إذا توافقت معلمتان من 3 ممكنة ، فإنني أعتبر الرسالة صالحة.

1. بداية البايت = '$' ، عدد البايتات المستلمة = 7 (عدد البايتات المرسلة = 7) ، البايت النهائي لا يساوي '#' ؛
2. البايت الأولي لا يساوي '$' ، عدد البايتات المستلمة = 7 (عدد البايتات المرسلة = 7) ، البايت النهائي = '#' ؛
3. تبدأ البايت = '$' ، عدد البايتات المستلمة = 7 (عدد البايتات المرسلة = 7 ، عدد البايتات ليست 7) ، البايت النهائي = '#'.

بعد ذلك ، نحسب المجموع الاختباري للبايت 3 المتبقية (البايتات 3 ، 4 ، 5) ، إذا تزامن مع BCS ، واصلنا تحليل البيانات ، فنحن نبحث عن هذا الجهاز لهذه البيانات وما يجب القيام به عليه ، في حالتنا ، يكون رمز العبد 55 والرمز الفرعي 2 يقول حول الحاجة إلى إضافة 5 درجات أخرى إلى عتبة التتابع وفي رسالة الاستجابة لإرسال بيانات درجة الحرارة الحالية. أتحقق من NS إذا كانت لا تساوي رقم الرسالة السابقة ، ثم أقوم بتنفيذ الأمر وأضيف 5 درجات إلى القيمة الحالية لعتبة الترحيل. إذا كانت متساوية (NS) ، فأنا لا أقوم بتنفيذ الإجراءات المشار إليها ، ثم أمضي في تشكيل رسالة استجابة.

تطبيق النظام ['$'] [عدد وحدات البايت المرسلة / المستلمة] [...] ['#'] - مع احتمالية عالية تضمن عدم إمكانية العثور على هذه المجموعة في البيانات المرسلة ، وإثارة رسالة خاطئة.

أقوم بتشكيل البيانات المرسلة من الرقيق بناءً على الرسالة المستلمة:

الصورة

مبدأ المعالجة هو كما يلي: انظر إلى 2 بايت حيث يوجد عدد البايتات المرسلة ، إذا كان عدد البايتات المرسلة يساوي عدد البايتات المستلمة وأيضًا البايت البادئة = '@' والنهاية البايت = '&' - هذه رسالة من العبد إلى الرئيسي. إذا لزم الأمر ، أستخدم آلية 2 من أصل 3 ، على غرار الآلية الموضحة أعلاه فقط لرسالة الاستجابة (للحروف "@" و "&"). عند تلقي هذه الرسالة ، يقوم المضيف بتحليل المجموع الاختباري 9 (من الثالث إلى الحادي عشر) ، إذا تطابق المجموع الاختباري ، تعتبر البيانات في الرسالة موثوقة ويستمر تحليل البيانات الإضافي. إذا تزامن الرمز والشفرة الفرعية و NS للرسائل المرسلة والمستلمة ، فإننا نواصل تحليل الاستجابة للرسالة المرسلة من قبل المضيف. التالي هو تحليل البيانات المستلمة ،في حالتي ، في البايت السادس ، تعني القيمة 1 أن الأمر لزيادة 5 درجات إلى عتبة الترحيل كان ناجحًا ، تشير البايتات الخمس المتبقية إلى قراءات درجة الحرارة الحالية ؛ البايت السابع هو إشارة تشير إلى موثوقية درجة الحرارة المرسلة (أي أنا أفكر في الخيار الذي يعمل فيه العبد ويستجيب ، ولكن قد لا يعمل المستشعر) و 4 بايت من قيم درجة حرارة التعويم.

يضمن استخدام حرفين اختبار في بداية ونهاية الرسالة باحتمالية عالية أنه في حالة حدوث خطأ عدم الخلط بين الرسائل من العبد والماجستير. كما أن البيانات العشوائية (غير العشوائية) في القناة لن تفسد التبادل.

القليل عن نقل بيانات العبد إلى العبد ، ورسالة مركزية لجميع العبيد من السيد.

أولاً ، آخر واحد - يتم الإرسال من الرئيسي بواسطة العبد عن طريق تعيين رمز الجهاز 255 ، الذي يخبر العبد أن هذه رسالة مركزية ، ثم يبقى فقط لحل مشكلة الرموز الفرعية الشائعة ، ومن الممكن أيضًا التجميع حسب رموز الجهاز ، أي تعيين رمز الجهاز 254 و 3 أو 4 أجهزة ستتلقى رسالة باستخدام هذا الرمز ؛ والباقي سيتجاهله ، بطبيعة الحال ، لا يجب أن يعمل جزء إرسال الردود من العبيد هنا ، أي ليس من المضمون أن المتابعين قبلوا هذه الرسائل بشكل لا لبس فيه!

يرسل الرقيق معلومات حول نقل البيانات إلى الرقيق ، التي ينفذها السيد يرسل رسالة إلى الرقيق (الرقيق 1) الذي يجب إرسال المعلومات منه إلى الرقيق الآخر (الرقيق 2) ، يرسل الرقيق 1 رداً إلى السيد بينما يستمع الرقيق 2 لهذه الإجابة مع أخذ البيانات إلى نفسه. مرة أخرى ، لا يوجد ضمان لتسليم رسالة لا لبس فيها من slave1 إلى slave2 ، يجب أن يؤخذ هذا في الاعتبار!

يبلغ عدد إمكانات الواجهة للأجهزة المتصلة نظريًا حوالي 250 ، وأنواع الأوامر / البيانات حتى 248 لكل جهاز ، ويصل طول المعلومات المفيدة في الرسالة إلى 250 بايت.

الحديث عن المزالق:

تم تصميم جميع عمليات نقل البيانات للعمل في الوقت المحدد ، أي يجب ملاحظة بعض التأخيرات بين الرسائل. أوصي أيضًا بإجراء تأخير ثابت بين الرسالة التي يرسلها السيد واستجابة العبد حتى يتمكن العبد من إنشاء البيانات ونقلها بالكامل إلى القناة.

لحظة تنظيم الردود من العبد مهمة أيضًا ، قد يحدث أن العبد كان مشغولًا وكان لديه العديد من رسائل البيانات في قناته في وقت واحد ، يجب عليك تجنب الردود على الرسائل القديمة (لأن القائد لم يعد ينتظرها) تجاهلها ، وتنفيذ أوامر من الأحدث فقط الرسائل وإعطاء إجابة عليها.

بشكل منفصل ، أود أن أسلط الضوء على مسألة مزامنة الأجهزة حسب الوقت - يجب أن يوضع في الاعتبار أن مزامنة الوقت للعبد عند تلقي رسالة تتطلب مراعاة التأخير الزمني لإرسال البيانات إلى القناة (بسرعة 9600 ، سيتم إرسال رسالة 10 بايت لحوالي 11 مللي ثانية) ولحظة تشغيل المقاطعة في النهاية استقبال البيانات على الجانب التابع ، إذا لم يكن هناك انقطاع ، يجدر النظر في وقت التحقق من وصول البيانات إلى مخزن الجهاز المؤقت ، إلخ.

من الجدير بالذكر أيضًا أن إعادة إرسال حلقة رسالة تضيف أيضًا فروق دقيقة ، أوصي باستخدام إرسال الرسائل بدون تكرار لمزامنة الوقت ، وإنشاء الرسائل باستخدام NS جديدة.

ملاحظةلدي شكوك في أنني اكتشفت شيئًا جديدًا هنا ، كل هذا يستخدم إلى حد ما في مكان ما في واجهات مختلفة! بيد خفيفة لمؤلف هذا الخربشة وتطبيق هذا البروتوكول في تطوري ، أريد أن أعطي الاسم لبروتوكول نقل البيانات هذا "SRDB2".

أغنية نقل البيانات

More articles: