لا يوجد بروتوكول اتصال واحد هو الأفضل لكل نظام مدمج. فالاختيار الصحيح ينطلق من سؤال أبسط بكثير:
ما الذي تريد توصيله، وعلى أي مسافة، وبأي سرعة، وكم جهازًا، وبأي جهد كهربائي وقيود PCB؟
وفي المشروع الواحد قد تتجاور الواجهات كلها: UART للتصحيح والـConsole، وI²C للحساسات، وSPI لذاكرة Flash أو شاشة، وRS‑232 للاتصال بجهاز صناعي أو حاسب قديم. لكن المشكلة أن هذه الأسماء تُتداول أحيانًا كأنها تقنيات متكافئة تمامًا، مع أنها لا تقف في المستوى نفسه. وأوضح مثال على ذلك:
UART ليست RS‑232.
فـUART تصف آلية إرسال واستقبال تسلسلية غير متزامنة داخل المتحكم أو المعالج، بينما RS‑232 معيار واجهة كهربائية ووظيفية يستخدم مستويات جهد مختلفة عن مستويات GPIO/UART المنطقية، ويحتاج عادة إلى Transceiver.
ولهذا تتكون السلسلة النموذجية من طبقتين متمايزتين. فالـUART داخل المتحكم يعمل بمنطق 3.3 فولت الخاص بالرقاقة، وهذه الإشارة الرقمية الهشة لا تصل إلى الكابل كما هي، بل تمر أولًا عبر Transceiver RS-232 يحوّلها إلى إشارة كهربائية ثنائية القطبية متوافقة مع مواصفات المعيار، وهي التي تسير فعليًا في كابل RS-232 حتى الطرف المقابل. وهذا الفصل بين الدور المنطقي والدور الكهربائي هو ما يسمح لبروتوكول واحد بأن يسري عبر وسائط فيزيائية مختلفة، وهو الفكرة التي سنعود إليها مرارًا في هذا الدليل.
ما المقصود ببروتوكول اتصال في النظام المدمج؟
نحتاج داخل النظام المدمج إلى اتفاق بين جهازين أو أكثر حول كيفية تبادل البيانات. وقد يشمل هذا الاتفاق شكل الإشارة الكهربائية، ولحظة قراءة البتات، ووجود Clock من عدمه، وترتيب البتات، وطريقة اختيار الجهاز، والعنونة، وإشارات ACK/NACK، وكشف الأخطاء، والتحكم في التدفق (Flow control)، وشكل الإطار (Frame).
لكن ليست كل واجهة تحدد كل هذه الطبقات، وهنا يكمن مصدر كثير من الالتباس:
| الواجهة | ما الذي تحدده |
|---|---|
| I²C | Bus ثنائي الأسلاك مع Clock وعناوين وACK/Arbitration |
| SPI | Bus متزامنة عالية البساطة، بينما تأتي كثير من تفاصيل أوامر الجهاز من الـDatasheet الخاصة به |
| UART | Framing غير متزامن، دون أن تحدد وحدها جهد الخط أو الـConnector |
| RS‑232 | خصائص كهربائية ووظيفية للواجهة فوق رابط تسلسلي |
ولذلك فإن المقارنة بين الأسماء دون فهم الطبقة التي تنتمي إليها كل واجهة قد تقود إلى تصميم خاطئ.
Serial لا تعني دائمًا الشيء نفسه
يعني "Serial Communication" أن البتات تنتقل تباعًا عبر خط واحد أو عدد صغير من الخطوط، بدل إرسال عدد كبير منها بالتوازي. لكن الواجهات التسلسلية تختلف جذريًا في طريقة ضبط التوقيت.
ففي الاتصال غير المتزامن لا يوجد خط Clock مشترك، كما في UART، حيث يتفق الطرفان مسبقًا على Baud Rate وشكل الإطار. أما في الاتصال المتزامن فتوجد Clock تقود توقيت النقل، كما في SPI وI²C. ووجود الـClock يبسّط تحديد لحظة أخذ العينة، لكنه يضيف قيودًا على سلامة الإشارة (Signal Integrity) كلما ارتفعت السرعة أو طالت المسافة.
نظرة مقارنة سريعة: UART وI²C وSPI وRS-232
قبل الغوص في كل واجهة على حدة، يرسم الجدول التالي الصورة العامة:
| الخاصية | UART | I²C | SPI | RS‑232 |
|---|---|---|---|---|
| التزامن | غير متزامن | متزامن | متزامن | غالبًا يحمل UART/serial async |
| Clock line | لا | نعم SCL | نعم SCK | لا كخط بيانات أساسي |
| خطوط البيانات الأساسية | TX + RX | SDA + SCL | SCK + data + CS | TX/RX + GND، وقد توجد Handshake lines |
| Duplex | Full duplex عادةً | Half-duplex منطقيًا على SDA ثنائي الاتجاه | Full duplex عادةً | Full duplex ممكن |
| العنونة | لا | نعم | لا توجد عنونة Bus موحدة؛ CS يختار الجهاز غالبًا | Point-to-point |
| عدة أجهزة | يحتاج تصميمًا إضافيًا | طبيعي | ممكن مع CS إضافية/طرق أخرى | لا على الخط نفسه عادةً |
| السرعة | تعتمد على Hardware/Clock | أوضاع معيارية حتى عدة Mbit/s | لا يوجد حد عالمي موحد؛ يعتمد على الأجهزة | أقل عادةً من واجهات PCB المحلية |
| الاستخدام المعتاد | Debug، modules، MCU↔MCU | Sensors/ICs متعددة | Flash، ADC، Displays | أجهزة صناعية/Legacy/PC interfaces |
| مسافة PCB | جيدة عند السرعات المناسبة | قصيرة غالبًا بسبب السعة | قصيرة غالبًا | مصمم أكثر للكابلات |
| مستوى الإشارة | CMOS/TTL حسب الجهاز | CMOS/open-drain | CMOS/push-pull غالبًا | مستويات RS‑232 موجبة/سالبة |
| Pull-ups | لا عادةً | نعم | لا عادةً | لا |
| Clock polarity/phase | لا | لا بالشكل نفسه | CPOL/CPHA مهمان | لا |
هذه مقارنة مفاهيمية؛ فلا تستبدل بأرقام "الحد الأقصى" العامة المنقولة من جداول الإنترنت الـDatasheet الخاصة بالمتحكم والطرفية واللوحة والكابل.
UART: أبسط طريق بين جهازين
الأسلاك والتوقيت
Universal Asynchronous Receiver/Transmitter وحدة Hardware موجودة في كثير من المتحكمات والمعالجات. وفي أبسط صورها تحتاج ثلاثة أسلاك فقط: مخرج الإرسال TX في الجهاز A يتصل بمدخل الاستقبال RX في الجهاز B والعكس، مع أرضية مشتركة GND بين الطرفين.
لا يوجد خط ساعة على السلك، فكيف يعرف المستقبل توقيت كل بت؟ الحل أن يتفق الطرفان مسبقًا على معدل الباود (Baud Rate)، بقيم شائعة مثل 9600 و115200 ومليون بت في الثانية، بشرط أن يدعم الـHardware القيمة المختارة ضمن هامش خطأ مقبول.
كيف يبدو إطار UART؟
من أشهر الإعدادات 115200 8N1، أي 115200 baud، وثمانية بتات بيانات، ودون Parity، وبت توقف واحد. ويُقرأ الإطار زمنيًا على خط واحد: يبدأ الخط في حالة Idle مرتفعًا، ثم يهبط إلى بت البداية معلنًا بدء الإرسال ومزوّدًا المستقبل بنقطة المزامنة، ويتبعه مباشرة بتات البيانات الثمانية من D0 إلى D7 تُقرأ واحدًا تلو الآخر على الإيقاع المتفق عليه، وأخيرًا يعود الخط إلى بت التوقف ليؤمّن فاصلًا صامتًا قبل الإطار التالي. وفي إعدادات أخرى يمكن إضافة بت Parity بين البيانات والتوقف لكشف أخطاء النقل البسيطة.
دور بتات البداية والتوقف
لأن الطرفين لا يتشاركان Clock على السلك، يحتاج المستقبل إلى اكتشاف بداية الحرف ثم أخذ العينات وفق الـBaud Rate المتفق عليها. فبت البداية يحدد مطلع الإطار، وبت التوقف يمنح النهاية أو فترة الخمول المطلوبة قبل الإطار التالي. وإذا اختلفت ساعتا الطرفين أكثر مما يحتمله المستقبل، تظهر أخطاء الإطار (Framing errors) وبايتات تالفة.
Parity: ما تفعله وما لا تفعله
تضيف Parity بتًا يمكن استخدامه لاكتشاف بعض أخطاء النقل، بنمطيه الزوجي (Even) والفردي (Odd). لكن العبارة الشائعة «Parity تضمن عدم ضياع المعلومات» غير صحيحة؛ فهي تكشف بعض أنماط الأخطاء فقط، ولا توفر تصحيح الخطأ، ولا تضمن وصول الرسالة، ولا تكشف جميع الأخطاء متعددة البتات، ولا تتضمن إعادة الإرسال. فإذا كانت سلامة الرسائل مهمة، فالحل بروتوكول أعلى يضيف CRC ورقم تسلسل (sequence number) وإشعار استلام (ACK) ومهلة (timeout) وإعادة محاولة (retry).
Baud Rate أم Bit Rate؟
المصطلحان ليسا مترادفين في الاتصالات عمومًا: فالـBaud عدد الرموز (Symbols) في الثانية، والـBit rate عدد البتات في الثانية. لكن في UART التقليدية، حيث يمثل كل رمز قيمة بت واحد، يكون الرقمان متساويين تقريبًا:
غير أن الحمولة الفعلية أقل، لأن الإطار يحمل بتات Start وStop وParity. ففي إعداد 8N1 يتكون الإطار الواحد من:
ولذلك تعطي سرعة 115200 baud نظريًا نحو:
وذلك قبل أي بروتوكول إضافي فوقها.
هل 115200 هي الحد الأقصى لـUART؟
لا. فـ115200 قيمة شائعة تاريخيًا، لا حدًا أقصى عالميًا. وبعض المتحكمات تدعم سرعات أعلى بكثير، بحسب ساعة الطرفية (Peripheral clock)، ومقسّم معدل الباود، وأخذ العينات المتعدد (oversampling)، ودقة الساعة، وتصميم الـPCB، والطرف الآخر. فلا تكتب في وثيقة التصميم أن الحد الأقصى لـUART هو 115.2 kbps، بل اقرأ الـDatasheet للطرفين.
UART ليست دائمًا TTL 5V
من الأخطاء الشائعة المساواة بين UART وTTL. والأصح أن طرفية UART قد تعمل على جهد الإدخال والإخراج الخاص بالشريحة، سواء كان 1.8 أو 3.3 أو 5 فولت. ولا يجوز وصل UART بجهد 5 V مباشرة بمدخل غير متحمل لهذا الجهد (5V-tolerant). لذلك تحقق من VIH وVIL وVOH وVOL ومن Absolute Maximum Ratings، وقد تحتاج Level Shifter بين الجهدين.
لماذا تتألق UART في التصحيح؟
لأنها بسيطة، ولا تحتاج Clock، وتعمل بسهولة مع محوّل USB-to-UART، وتناسب سجلات الـConsole، ويسهل مراقبتها بمحلل منطقي. ومثالها الأشهر جلسة Bring-up على لوحة جديدة: يتصل الـUART في المتحكم بـجسر USB-UART صغير على اللوحة، فيظهر الجسر للحاسوب منفذًا تسلسليًا افتراضيًا، ويفتح المهندس طرفية على حاسوبه فيرى رسائل السجل وردود الأوامر مباشرة. بهذا تبقى UART من أوائل الواجهات التي يلجأ إليها مهندس Firmware عند إحياء أي لوحة، لأنها قناة تشخيص بسيطة لا تحتاج شاشة ولا شبكة.
ولا يقتصر دورها على التشخيص: ففي مشروع الروبوت الأرضي متعدد الاتصالات تصل وحدة Bluetooth HC-05 بمتحكم Arduino UNO عبر واجهة UART، لتنقل أوامر التحكم اللاسلكية إلى الروبوت. وفي تنفيذنا الفعلي لهذا المشروع كان استقرار الوصلة اللاسلكية وتنسيق عمل عدة وحدات إلكترونية على منصة واحدة من أبرز التحديات، وهو ما يجعل فهم طبقة UART نفسها خطوة أولى في تشخيص أي خلل في الأوامر.
متى لا تكون UART مناسبة؟
حين تحتاج عدة أجهزة على Bus واحد دون Hardware إضافي، أو عرض نطاق مرتفعًا جدًا بين الدوائر المتكاملة، أو نقلًا حتميًا مضبوطًا بالساعة (Clocked deterministic transfers)، أو عنونة مدمجة. عندها يتجه النظر غالبًا إلى I²C أو SPI أو غيرهما.
RS‑232: ليست UART بجهد أعلى فحسب
لماذا يستمر الخلط؟
RS‑232 معيار تاريخي للاتصال التسلسلي من نقطة إلى نقطة (Point-to-Point). ويستمر خلطه بـUART لأن كثيرًا من الأنظمة الصناعية تستخدم المزيج نفسه: إطارات UART بروتوكولًا منطقيًا، وTransceiver كهربائي من نوع RS-232 وسيطًا فيزيائيًا يحملها عبر مسافات أطول مما يحتمله منطق 3.3 فولت. والفصل بين المستويين ضروري للفهم والتشخيص معًا؛ فمشكلة صيغة الإطارات تُحل في الطبقة المنطقية، ومشكلة مستويات الجهد أو الضوضاء تُحل في الطبقة الكهربائية، وخلطهما يضيّع وقت البحث عن العطل.
مستويات الجهد على الطرفين
قد يعمل جانب UART بمستويين هما 0 V و3.3 V، أما جانب RS‑232 فيستخدم مستويات موجبة وسالبة، مع عكس دلالة المنطق مقارنة بكثير من دوائر UART. فبحسب شروحات RS‑232 القياسية، يكون المنطق 1 (Mark) بجهد سالب، والمنطق 0 (Space) بجهد موجب، مع منطقة غير معرّفة حول الصفر في عتبات المستقبل.
ولهذا لا تصل طرف UART مباشرة إلى موصل RS‑232، فجهد RS‑232 قد يتلف منافذ GPIO.
وظيفة Transceiver من فئة MAX232
يؤدي هذا الـTransceiver وظيفتين أساسيتين: تحويل مستويات الجهد، وعكس الإشارة حسب الحاجة. فالـUART في المتحكم يولّد إشارة بمنطق 3.3 أو 5 فولت، يلتقطها الـTransceiver RS-232 ويحولها إلى مستويات ثنائية القطبية مطابقة للمعيار، وهذه الإشارة المحوّلة وحدها هي التي تسافر عبر كابل RS-232 نحو الطرف الآخر. وتضم بعض الـTransceivers دائرة Charge Pump تولّد الجهود المطلوبة من مصدر تغذية واحد منخفض، فتغني التصميم عن مصدر سالب مخصص.
الموصلات: هل يلزم DB‑25؟
لا. صحيح أن تاريخ المعيار يتضمن DB‑25، لكن DB‑9 شائع جدًا، وقد تستخدم المنتجات موصلات أخرى؛ فالمعيار أوسع من شكل موصل واحد. وفي أبسط اتصال تكفي خطوط TX وRX وGND، بينما تستخدم تطبيقات أخرى التحكم في التدفق بالعتاد (Hardware Flow Control) عبر خطي RTS وCTS.
DTE وDCE
طُوّر RS‑232 في الأصل لربط DTE — Data Terminal Equipment بـDCE — Data Communication Equipment، كربط طرفية أو حاسب بمودم، وهو ما أثر تاريخيًا في اتجاه الأطراف. لكن ما يهمك عمليًا في الأنظمة المدمجة الحديثة قد يقتصر على أسئلة محددة: من يرسل على أي طرف؟ وما توزيع أطراف الموصل (pinout)؟ وهل نحتاج كابل Null-modem/crossover؟ وهل توجد RTS/CTS؟ فلا تعتمد على تسمية "TX" وحدها قبل مراجعة الـPinout.
RTS وCTS
في التحكم التقليدي بالتدفق عبر العتاد، تعني RTS طلب الإرسال (Request To Send)، وتعني CTS السماح بالإرسال (Clear To Send). لكن تنفيذ المصافحة ووظيفة الأطراف قد يختلفان بين العتاد والـDrivers والأنماط الحديثة، فلا تبنِ دائرة من رسم عام فقط، بل راجع دليل UART في المتحكم، والـDatasheet الخاصة بالـTransceiver، ومواصفات الطرف المقابل، وإعدادات المنفذ التسلسلي في نظام التشغيل.
هل طول كابل RS‑232 ثابت عند 15 مترًا؟
ليست قاعدة صلبة. فالمواصفات انتقلت تاريخيًا من طول ثابت إلى قيود كهربائية مثل السعة (Capacitance)، والمسافة الفعلية رهن بسعة الكابل ومعدل البيانات والضوضاء والتأريض والـTransceiver والبيئة. والقاعدة الهندسية هنا:
كلما زادت المسافة أو البيئة الصناعية والضوضاء، فكر أيضًا في واجهات Differential مثل RS‑485 أو CAN بدل دفع RS‑232 خارج ظروفها.
I²C: سلكان فقط وعدة أجهزة على Bus واحد
الفكرة: العناوين بدل الأسلاك
Inter-Integrated Circuit واجهة طورتها Philips Semiconductors، المعروفة اليوم باسم NXP، وتستخدم خطين فقط: SDA للبيانات التسلسلية، وSCL للساعة التسلسلية. وميزتها الجوهرية:
عدة Targets يمكن أن تشترك على Bus نفسها عبر Addresses.
ففي ناقل I²C يتصل المتحكم الرئيسي بعدة أجهزة على السلكين نفسيهما، ويميّز بينها بالعناوين لا بالأسلاك: حساس الحرارة يجيب على العنوان 0x48، وذاكرة EEPROM على 0x50، وساعة RTC على 0x68، ووحدة IMU على 0x6A. وحين يبدأ المتحكم عملية قراءة أو كتابة، يفتتح الإطار بالعنوان المستهدف، فتنصت الأجهزة كلها لكن المستهدف وحده يستجيب. وبهذا تُبنى منظومة كاملة من الحساسات والذواكر على سلكين فقط، مع متحكم واحد هو مصدر الساعة.
لماذا تحتاج I²C مقاومات Pull-up؟
تعمل خطوط I²C تقليديًا بسلوك Open-drain / open-collector: الجهاز يسحب الخط إلى LOW، لكنه لا يدفعه إلى HIGH بالطريقة المعتادة، بل ترفعه مقاومة Pull-up حين لا يسحبه أي جهاز.
فكل خط في I²C يقوم على مقاومة Pull-up تربطه بمصدر VDD، بينما يستطيع أي جهاز على الناقل سحبه إلى الأرضي عبر ترانزستور Open-Drain. في حالة السكون يبقى الخط مرتفعًا بفعل المقاومة، وحين يريد جهاز الإرسال يسحبه صراحة. وهذا الترتيب هو ما يتيح لعدة أجهزة مشاركة الخط دون صراع Push-pull مباشر؛ فإذا حاول جهازان السحب في آن واحد فلن يحدث قصر كهربائي بين قطبيتين متعارضتين، بل يجتمعان ببساطة على مستوى منخفض واحد، ويظل كشف التعارض ممكنًا حين يقرأ جهاز على الخط قيمة غير التي أراد وضعها.
هل قيمة Pull-up دائمًا 4.7 kΩ؟
لا. فالقيمة تتحدد بسعة الناقل، وجهد التغذية، وسرعة I²C، ومتطلبات زمن الصعود (Rise time)، وقدرة الأجهزة على سحب التيار. وقيمة 4.7 kΩ شائعة في الأمثلة، لكنها ليست قانونًا. فإذا كانت المقاومة كبيرة جدًا أصبح زمن الصعود بطيئًا، وإذا كانت صغيرة جدًا زاد التيار عند LOW وقد يتجاوز قدرة الجهاز على السحب.
سرعات I²C الحالية
وفق مواصفة NXP UM10204 Rev. 7، تتدرج أوضاع I²C كالتالي:
| الوضع | السرعة القصوى |
|---|---|
| Standard-mode | 100 kbit/s |
| Fast-mode | 400 kbit/s |
| Fast-mode Plus | 1 Mbit/s |
| High-speed mode | 3.4 Mbit/s |
كما تعرّف المواصفة نمط Ultra Fast-mode أحادي الاتجاه حتى 5 Mbit/s، وهو نمط مختلف لا بديل شائع للاستخدام التقليدي ثنائي الاتجاه. ولذلك فالمقولة القديمة إن الحد الأقصى لـI²C هو 400 kbps غير صحيحة كقاعدة عامة.
كيف تجري معاملة I²C؟
في النموذج البسيط، يرسل المتحكم إشارة START، ثم العنوان مع بت القراءة أو الكتابة (R/W)، فيرد الجهاز المستهدف بـACK، ثم تتوالى بايتات البيانات يتبع كلًا منها ACK، حتى تُختم المعاملة بإشارة STOP. وإلى جانب ذلك توجد آليات أخرى مثل Repeated START، وNACK، والعنونة بسبعة بتات أو بعشرة، والتحكيم بين عدة متحكمات (multi-controller arbitration)، ومد الساعة (Clock stretching) في السيناريوهات المدعومة.
هل تعيّن Philips عنوانًا لكل جهاز؟
ليس بهذه الصورة. فعنوان الجهاز قد يكون ثابتًا في الـDatasheet، أو قابلًا للتغيير عبر أطراف (Pins)، أو قابلًا للتهيئة برمجيًا، أو ضمن نطاق محدد، كما توجد عناوين محجوزة لأغراض خاصة. ولذلك اسأل دائمًا عند اختيار عدة حساسات من النوع نفسه: هل تستطيع تغيير العنوان؟ فإذا حملت ثلاثة حساسات العنوان نفسه دون إمكانية تغييره، فقد تحتاج إلى I²C multiplexer، أو Bus switch، أو عدة متحكمات، أو واجهة أخرى.
ACK وNACK
بعد كل بايت تأتي مرحلة الإقرار (Acknowledge)، التي تساعد في معرفة ما إذا كان الطرف المقابل قد استجاب. لكن ACK ليست CRC، ولا ضمانًا لسلامة الحمولة كاملة، ولا مصادقة (Authentication)، ولا تأكيدًا من طرف إلى طرف. فإذا كان الجهاز حساسًا للأخطاء، فراجع ما إذا كان بروتوكوله الخاص يوفر checksum أو PEC أو CRC.
تعدد المتحكمات والتحكيم
I²C ليست محصورة نظريًا بمتحكم واحد؛ فالمواصفة تدعم تعدد المتحكمات (Multi-controller)، وتستخدم التحكيم (Arbitration) لمنع تلف البيانات حين يحاول أكثر من متحكم البدء في الوقت نفسه. لكن ليس كل Driver في متحكم أو حزمة RTOS يتعامل بسهولة مع كل سيناريو من هذا النوع؛ فدعم المعيار لا يعني سهولة التنفيذ على منصتك.
مد الساعة (Clock Stretching)
قد تُبقي بعض الأجهزة الطرفية خط SCL منخفضًا لإبطاء المتحكم حين تحتاج وقتًا إضافيًا. لكن عمليًا لا تتعامل كل تطبيقات المتحكمات معه بالطريقة نفسها، وبعض الأنظمة تضع مهلًا زمنية (Timeouts)، وبعض الأجهزة لا تستخدمه أصلًا، فراجع الـDatasheet بدل افتراض السلوك.
لماذا طول I²C محدود عمليًا؟
لا يوجد "متر واحد" يصلح قاعدة لكل I²C. فالتحدي الأساسي يكمن في سعة الناقل وزمن الصعود والضوضاء ومقاومات الرفع والطوبولوجيا والسرعة. لقد صُممت I²C أساسًا للاتصال بين الدوائر المتكاملة داخل جهاز أو لوحة، وإذا مُدّت عبر كابل طويل فقد تعمل في بعض الظروف بسرعات منخفضة وتصميم جيد، لكنها تصبح أكثر حساسية بكثير، وللكابلات الصناعية الطويلة توجد غالبًا حلول أنسب.
SPI: سرعة وبساطة مقابل أطراف أكثر
الخطوط والتسميات
Serial Peripheral Interface ناقل متزامن يستخدم غالبًا أربعة خطوط: SCK للساعة، وMOSI/SDO وMISO/SDI للبيانات، وCS/SS لاختيار الجهاز. وفي التسمية التقليدية تعني MOSI "Master Out Slave In" وتعني MISO "Master In Slave Out"، بينما تتبنى وثائق حديثة أسماء وظيفية مثل Host/Controller وTarget/Peripheral وSDO/SDI. والفكرة واحدة في كل الأحوال: ساعة، وخط إرسال، وخط استقبال، واختيار جهاز.
لماذا SPI سريعة؟
على عكس I²C التقليدية، تكون خطوط SPI غالبًا Push-pull، ولكل اتجاه خط بيانات مستقل، ولا توجد مرحلة عنونة موحدة لكل بايت، فيبقى حمل البروتوكول منخفضًا. ولهذا تتفوق مع المكونات التي تحتاج إنتاجية أعلى، مثل ذاكرات SPI NOR Flash والشاشات ومحولات ADC/DAC والحساسات عالية المعدل وFPGAs والطرفيات المشابهة.
هل سرعة SPI القصوى 10 MHz؟
لا توجد قيمة عالمية واحدة لـSPI. فبعض الأجهزة يعمل عند 1 MHz، وبعضها عند 10 MHz، وبعضها عند عشرات الميغاهرتز أو أكثر بحسب الجهاز والوضع واللوحة. والحد الحقيقي يأتي من المتحكم، والجهاز الطرفي، وتوقيتات setup/hold، وطول المسارات، والتحميل، والجهد، وسلامة الإشارة، وتخطيط اللوحة. والقاعدة المهمة:
سرعة SPI يحددها أبطأ عنصر في الرابط وتوقيت اللوحة، لا اسم SPI نفسه.
الاتصال ثنائي الاتجاه الكامل
لوجود خطين منفصلين، أحدهما من المتحكم إلى الطرفية والآخر بالعكس، يمكن نقل البتات في الاتجاهين خلال دورة الساعة نفسها. لكن هذا لا يعني أن بروتوكول التطبيق يستفيد دائمًا من ذلك؛ فكثير من الشرائح تستخدم معاملة يرسل فيها المتحكم أمرًا أو عنوانًا أولًا ثم يستقبل البيانات بعده، فيكون الاتصال Full Duplex كهربائيًا بينما يبدو الاستخدام الفعلي Half-duplex منطقيًا.
عدة أجهزة طرفية على SPI
قد تصف المصادر القديمة SPI بأنها اتصال من نقطة إلى نقطة، لكن من الشائع جدًا أن تشترك عدة أجهزة في خطوط SCK وMOSI وMISO، بينما يحصل كل منها على خط اختيار خاص: CS0 لذاكرة Flash، وCS1 لمحول ADC، وCS2 للشاشة.
المشكلة أن كل جهاز طرفي يحتاج تقليديًا Chip Select خاصًا، فكلما زاد عدد الأجهزة زادت الأطراف والمسارات وتعقيد إدارة الـFirmware. وهنا قد تكون I²C أنسب للحساسات الكثيرة منخفضة البيانات.
CPOL وCPHA: فخ SPI الشهير
لـSPI أوضاع تعتمد على قطبية الساعة (CPOL) وطورها (CPHA)، فتنشأ أربعة أوضاع شائعة هي Mode 0 وMode 1 وMode 2 وMode 3. وإذا لم يتفق المتحكم والجهاز الطرفي على الوضع، فسترى الساعة والبيانات على الخطوط، لكن البايتات ستكون خاطئة. ولهذا فأول ما تراجعه حين لا تعمل SPI:
CPOL/CPHA + bit order + CS timing.
SPI بلا ACK ولا عنونة
على خلاف I²C، لا تقدم SPI الأساسية إقرارًا أو عنونة موحدين على مستوى الناقل، بل لكل شريحة بروتوكول أوامر خاص في الـDatasheet. فذاكرة Flash مثلًا قد تستخدم الأوامر التالية:
| الأمر | الوظيفة |
|---|---|
| 0x03 | Read |
| 0x02 | Page Program |
| 0x9F | Read JEDEC ID |
بينما يستخدم حساس آخر أوامر مختلفة تمامًا. فالخلاصة:
"SPI" تخبرك كيف تنتقل البتات، لكنها لا تخبرك بالضرورة معنى البايتات.
المقارنات المباشرة
UART أم SPI؟
| اختر UART عندما | اختر SPI عندما |
|---|---|
| يكون الاتصال بين جهازين فقط | تكون الطرفية على الـPCB نفسها |
| تحتاج Debug console | تحتاج إنتاجية مرتفعة |
| تتعامل مع Modem أو GNSS أو Bluetooth module | تتعامل مع Flash أو Display أو ADC |
| لا تريد خط Clock | تكون الأطراف الإضافية مقبولة |
| لا تكون البيانات هائلة | تستطيع التحكم بتوقيت الساعة بدقة |
| تحتاج كابلًا بسيطًا ضمن مستويات كهربائية مناسبة |
I²C أم SPI؟ المقارنة الأشهر
تكون I²C أفضل عادة حين توجد عدة حساسات، وتريد خطين فقط، ويكون عرض النطاق المطلوب متوسطًا أو منخفضًا، وتكون العنونة مفيدة. أما SPI فأفضل حين تكون السرعة أهم، وعدد الأجهزة صغيرًا، وزمن الاستجابة قليلًا، والاتصال ثنائي الاتجاه الكامل مفيدًا، والأطراف متوفرة.
ولا مانع من استخدام الاثنين في المشروع نفسه. فلوحة Sensor Hub نموذجية قد تضع حساسات الحرارة والرطوبة وساعة RTC على I²C، بينما تضع وحدة IMU عالية السرعة وذاكرة Flash والشاشة على SPI.
UART أم RS‑232؟ المقارنة الصحيحة
يشبه سؤال «UART أم RS‑232؟» جزئيًا سؤالًا آخر: «هل أريد شكل إطار أم طبقة كهربائية للكابل؟». فيمكن استخدام UART من المتحكم ثم تحويلها إلى RS‑232، أو RS‑485، أو USB عبر جسر، أو استخدامها مباشرة بمستويات منطقية. ولذلك ليست RS‑232 منافسًا مباشرًا لـUART في كل حالة.
كيف تختار البروتوكول؟
مسار القرار
ابدأ بسؤال أول: هل الطرف المقابل على الـPCB نفسها؟
إذا كانت الإجابة نعم، فالسؤال التالي هو عدد الأجهزة. فجهاز أو اثنان مع إنتاجية مرتفعة يقودانك إلى SPI، وعدة حساسات مع أطراف قليلة تقودك إلى I²C، وموديول بسيط أو حاجة إلى التصحيح تقودك إلى UART.
أما إذا كان هناك كابل، فالسؤال يصبح عن المسافة والضوضاء. فالمسافة القصيرة في بيئة هادئة قد تسمح بـUART بمستويات منطقية حسب التصميم، والمعدات القديمة أو الصناعية من نقطة إلى نقطة قد يناسبها RS‑232، أما المسافات الأطول والبيئات المزعجة والربط متعدد النقاط فتستدعي النظر أيضًا إلى RS‑485 أو CAN.
لا تختر حسب السرعة وحدها
السرعة معيار واحد بين معايير أهم كثيرًا، يجمعها الجدول التالي:
| المعيار | ما الذي يعنيه عمليًا |
|---|---|
| عدد الأجهزة | I²C ممتازة للعديد من الأجهزة، وSPI تحتاج CS لكل جهاز غالبًا، وUART من نقطة إلى نقطة عادةً |
| الأطراف | مع متحكم صغير توفر I²C الأطراف، بينما قد تستهلك SPI عدة Chip Selects |
| عرض النطاق | الشاشة وذاكرة Flash تذهبان عادة إلى SPI، وحساس الحرارة تكفيه I²C غالبًا |
| زمن الاستجابة | SPI مباشرة وسريعة، وI²C تحمل حمل العنونة والإقرار، وUART تحمل إطار Start/Stop |
| الطاقة | لا تحكم من اسم البروتوكول؛ فهي تعتمد على التردد ومقاومات الرفع ونسبة التشغيل وأوضاع السكون وتنفيذ الطرفية |
| منظومة البرمجيات | هل يوجد Driver؟ هل يدعمه Linux أو الـRTOS؟ هل حزمة SDK ناضجة؟ هل DMA متاح؟ |
| سهولة التصحيح | UART الأسهل غالبًا في التصحيح اليدوي، بينما تحتاج I²C وSPI غالبًا Logic Analyzer لفهم التوقيت |
| التداخل وسلامة الإشارة | الساعة السريعة مع المسارات الطويلة قد تسبب مشكلات |
الطبقة الكهربائية أهم من اسم البروتوكول
افحص الجهد قبل التوصيل
قبل وصل أي جهازين، افحص جهد التغذية VDD، وعتبتي VIH/VIL، ونوع المخرج، وتحمّل جهد 5 فولت، ومقاومات الرفع، والحدود القصوى المطلقة. خذ مثلًا متحكمًا يعمل بجهد 1.8 V وحساس I²C يعمل بجهد 3.3 V: حتى لو كان كلاهما "I²C"، فقد تحتاج bidirectional level shifter بحسب العتبات والدوائر. فالبروتوكول المتوافق لا يعني جهدًا متوافقًا.
Open-drain مقابل Push-pull
| النمط | أين يُستخدم | خصائصه |
|---|---|---|
| Open-drain + Pull-up | I²C | عدة أجهزة تشترك في الخط، وزمن الصعود محدود بثابت RC، والتحكيم السلكي ممكن |
| Push-pull | SPI وUART غالبًا | حواف أسرع، ودفع مباشر إلى HIGH وLOW، ولا يجوز ربط مخرجين متعارضين معًا دون تصميم مناسب |
وتفسر هذه الفروق الكهربائية كثيرًا من الاختلاف في السرعة والطوبولوجيا بين الواجهات.
التصحيح وسلامة الإشارة
لماذا تعمل على Breadboard ثم تفشل في المنتج؟
قد تعمل SPI عند 20 MHz على أسلاك قصيرة، ثم تفشل مع كابل شريطي (Ribbon cable). والمشكلة ليست في الـFirmware دائمًا، بل قد تكون في الرنين (ringing)، أو التجاوز (overshoot)، أو التداخل بين المسارات (crosstalk)، أو ارتداد الأرضي (ground bounce)، أو ضعف مسار العودة، أو التفرعات الطويلة (long stubs)، أو عدم انتظام الممانعة.
أعراض مشكلات SPI
من علاماتها تغير البتات عشوائيًا عند رفع الساعة، وعمل الرابط عند 1 MHz وفشله عند 20 MHz، وقراءة Flash ID خاطئة أحيانًا، ووصول البايت الأول صحيحًا وتلف ما بعده. وقد تشمل الحلول مسارات أقصر، ومسار عودة أرضي أفضل، وخفض الساعة، ومقاومة على التوالي قرب المرسل، وتخطيطًا أفضل للوحة، والقياس بالـScope.
أعراض مشكلات I²C
من علاماتها بطء ارتفاع SDA إلى HIGH، وانحباس الناقل عند LOW، وظهور NACK عشوائية، وعمل الناقل مع حساس واحد وفشله عند إضافة آخر. وحينها افحص قيمة مقاومات الرفع، والسعة، وتعارض العناوين، والجهد، ومد الساعة، والطوبولوجيا.
المحلل المنطقي: أداة لا غنى عنها
يستطيع الـLogic Analyzer فك ترميز UART وI²C وSPI بدل الاكتفاء بالنظر إلى الموجة الخام. ففي معاملة I²C مثلًا قد يعرض: START، ثم العنوان 0x68 مع W وACK، ثم 0x1B مع ACK، ثم 0x00 مع ACK، ثم STOP. ومن قراءة كهذه يمكن فورًا اكتشاف عنوان خاطئ، أو NACK، أو STOP مفقودة، أو سجل خاطئ.
لكن المحلل المنطقي لا يكشف دائمًا مشكلات جودة الحواف التناظرية، ولهذا عند المشكلات الكهربائية استخدم Oscilloscope.
Logic Analyzer أم Oscilloscope؟
| الأداة | تتفوق في |
|---|---|
| Logic Analyzer | فك ترميز البايتات، والالتقاط الطويل، وتسلسل البروتوكول، والتوقيت المنطقي |
| Oscilloscope | زمن الصعود والهبوط، والتجاوز، والرنين، والضوضاء، وعتبات الجهد |
وأفضل جلسات التصحيح تستخدم الأداتين معًا أحيانًا.
أخطاء تصميم شائعة
| الخطأ | النتيجة أو التصحيح |
|---|---|
| توصيل UART مباشرة إلى RS‑232 | قد يتلف المدخل أو لا يعمل الرابط بسبب مستويات الجهد |
| I²C بدون Pull-ups | لن تعمل الخطوط كما هو متوقع |
| Pull-up غير مناسبة | زمن صعود بطيء أو تيار مرتفع |
| SPI Mode خاطئة | عدم توافق CPOL/CPHA |
| افتراض سرعة ثابتة للبروتوكول | لا يوجد "SPI = 10 MHz" أو "UART = 115200 max" كقانون |
| Ground غير مشترك في واجهة بمستويات منطقية | كثير من الروابط Single-ended تحتاج مرجعًا مشتركًا |
| ربط جهدين مختلفين | Protocol-compatible ≠ electrically compatible |
| نفس عنوان I²C لجهازين | تعارض على الناقل على مستوى الاستجابة |
| طول كابل دون حساب | ناقل صُمم للوحة قد لا يصلح لمسار طويل |
| Parity كبديل عن CRC | Parity ليست حماية شاملة للرسائل |
ما وراء الواجهات الأربع: RS‑485 وCAN وUSB وI3C
RS‑485
عند تصميم نظام صناعي أو مركبة أو كابل طويل، لا تحصر نفسك في البروتوكولات الأربعة. فـRS‑485 مفيدة حين نحتاج إشارات تفاضلية (Differential signaling)، ومسافة أطول، وربطًا متعدد النقاط (multi-drop)، وتحملًا أكبر للضوضاء. لكنها تحدد الطبقة الكهربائية أساسًا، وقد تحتاج بروتوكولًا أعلى مثل Modbus RTU.
CAN
يناسب CAN الحالات التي تحتاج ناقلًا متعدد العقد، وتحكيمًا، وكشفًا للأخطاء، في بيئات صناعية أو في المركبات. فاختيار UART/I²C/SPI/RS‑232 ليس دائمًا القائمة الكاملة.
USB
لربط منتج حديث بحاسب، قد تكون USB أفضل من RS‑232 الأصلي. لكن ما يبدو منفذًا تسلسليًا من الخارج قد يكون شيئًا آخر تمامًا من الداخل: فالـUART في المتحكم يتصل بـجسر USB-UART يحوّل تدفق الإطارات إلى حزم USB، فيرى الحاسوب على الطرف الآخر Virtual COM Port يتعامل معه كمنفذ تسلسلي عادي، بينما يجري النقل الفيزيائي على ناقل USB بسرعته وبروتوكوله الخاصين. وهذا مثال آخر على أهمية الفصل بين الطبقات: بروتوكول منطقي واحد قد يسافر داخل وسائط فيزيائية مختلفة تمامًا.
I3C: التوجه الحديث
مع تزايد عدد الحساسات، ظهرت الحاجة إلى ناقل يحافظ على بساطة I²C ويقدم أداءً وميزات أحدث، فطورت MIPI واجهة I3C، وأصبح الإصداران الحاليان في 2025 هما MIPI I3C v1.2 وMIPI I3C Basic v1.2.
تستخدم I3C واجهة ثنائية الأسلاك، وتقدم العنونة الديناميكية (Dynamic addressing)، والمقاطعات داخل النطاق (In-band interrupts)، وأداءً أعلى، وإدارة أفضل للطاقة، مع إمكانية التعايش مع عدد من أجهزة I²C القديمة على الناقل نفسه ضمن الشروط المدعومة. وتصف MIPI واجهة I3C بأنها خليفة لـI²C في فئات من التطبيقات، لا إلغاءً فوريًا لها، وتذكر معدلًا نموذجيًا يبلغ 11.1 Mbit/s، مع أوضاع High Data Rate تصل إلى نحو 100 Mbit/s في الخيارات المدعومة.
هل ستحل I3C محل SPI؟
ليس بالضرورة. فما تزال SPI ممتازة حين نحتاج مسار بيانات بسيطًا، وإنتاجية عالية، ومنظومة واسعة من ذاكرات Flash والشاشات والطرفيات. أما I3C فتستهدف خصوصًا تحسين نواقل التحكم والحساسات، وتقليل الأطراف والطاقة، مع ميزات إدارة متقدمة. وقد يجمع المشروع الواحد I3C للحساسات، وSPI لذاكرة Flash، وUART للتصحيح.
المصطلحات الحديثة: Controller وTarget
ستجد في الوثائق القديمة مصطلحي Master وSlave، بينما تنتقل وثائق ومعايير حديثة عديدة إلى مصطلحات أكثر وصفًا للوظيفة، مثل Controller/Target وHost/Client وPeripheral. وفي هذا المقال نستخدم Controller/Target كلما أمكن، ونذكر المصطلحات القديمة فقط حين تساعد على فهم الـDatasheets القديمة.
الأداء الحقيقي: لا تكتفِ بتردد الساعة
إذا كانت SPI تعمل عند 20 MHz، فهذا لا يعني حمولة فعلية مقدارها 20 Mbit/s دائمًا. فالمعاملة قد تحتوي أمرًا وعنوانًا ودورات فارغة (dummy cycles) وفجوات بين تفعيلات Chip Select وحملًا بروتوكوليًا آخر. وكذلك تحمل I²C إشارات START والعنوان وبت R/W وACK وSTOP، وتحمل UART بتات البداية والتوقف والتكافؤ. ولذلك قِس الإنتاجية الفعلية على مستوى التطبيق (Effective application throughput)، لا الساعة وحدها.
أمثلة تطبيقية
تتضح منهجية الاختيار حين نطبقها على حالات ملموسة:
| المثال | المتطلبات | الاختيار المنطقي |
|---|---|---|
| حساس حرارة | 2 bytes كل ثانية، عدة حساسات، السرعة غير مهمة، أطراف قليلة | I²C غالبًا |
| ذاكرة NOR Flash خارجية | قراءة كتل كبيرة، سرعة، عدد أجهزة محدود | واجهة من فئة SPI/QSPI حسب الجهاز |
| موديول GPS/GNSS | رسائل نصية أو ثنائية دورية، رابط مباشر، تصحيح سهل | UART غالبًا |
| جهاز قياس صناعي قديم | كابل، منفذ موجود أصلًا، من نقطة إلى نقطة، التوافق أهم من السرعة | RS‑232 قد يناسب |
| عشرات الحساسات الحديثة | سلكان، عنونة ديناميكية، مقاطعات داخل النطاق، عرض نطاق أعلى من I²C التقليدية | I3C إذا دعمتها المنصة والأجهزة |
مصفوفة اختيار عملية
| الحاجة | الخيار الذي تبدأ بفحصه |
|---|---|
| Debug Console | UART |
| Sensor بسيط | I²C |
| عدة Sensors على خطين | I²C / I3C |
| Flash عالية السرعة | SPI |
| Display | SPI |
| ADC عالي البيانات | SPI |
| MCU↔Module بسيط | UART |
| Legacy industrial point-to-point | RS‑232 |
| Cable طويل noisy | RS‑485 / CAN غالبًا |
| Automotive multi-node | CAN / LIN حسب المتطلبات |
| Modern sensor aggregation | I3C عند توافر الدعم |
هذه المصفوفة ليست حكمًا نهائيًا؛ فالـDatasheets والمتطلبات هي الفيصل.
قوائم التحقق
قبل اختيار الواجهة
دوّن القيم التالية لمشروعك، ثم قارن الخيارات على أساسها:
| البند | ما الذي تدوّنه |
|---|---|
| Number of devices | عدد الأجهزة |
| Required payload bandwidth | عرض النطاق المطلوب للحمولة |
| Maximum latency | أقصى زمن استجابة مقبول |
| Cable/trace length | طول الكابل أو المسار |
| Supply voltages | جهود التغذية |
| Available GPIO pins | الأطراف المتاحة |
| Need addressing? | هل تحتاج عنونة؟ |
| Need full duplex? | هل تحتاج اتصالًا ثنائي الاتجاه كاملًا؟ |
| Need hot-plug? | هل تحتاج التوصيل أثناء التشغيل؟ |
| Noise environment | بيئة الضوضاء |
| Power budget | ميزانية الطاقة |
| MCU peripheral availability | توافر الطرفيات في المتحكم |
| DMA required? | هل تحتاج DMA؟ |
| OS/driver support | دعم نظام التشغيل والـDrivers |
| Expected product lifetime | العمر المتوقع للمنتج |
قبل تشغيل أول نموذج أولي
| الواجهة | ما يجب التحقق منه |
|---|---|
| UART | تقاطع TX ↔ RX صحيح، والأرضي مشترك، والطرفان متفقان على الـbaud وعدد بتات البيانات والـparity وبتات التوقف، والجهد متوافق، ولا يوجد جهد RS‑232 دخل بالخطأ |
| I²C | توصيل SDA/SCL صحيح، ومقاومات الرفع مركبة وموصولة بالجهد الصحيح، والعنوان صحيح وخالٍ من التعارض، وسرعة الناقل يدعمها كل جهاز، وزمن الصعود مقبول |
| SPI | توصيل SCK وMOSI/SDO وMISO/SDI وطرف CS صحيح، وCPOL وCPHA وترتيب البتات صحيحة، وأقصى SCK ضمن توقيت الجهاز الطرفي، وتوقيتات setup/hold لـCS محترمة |
| RS‑232 | يوجد Transceiver بين UART المنطقية والكابل، وتوزيع أطراف TX/RX مُراجع، وافتراضات DTE/DCE مُراجعة، وRTS/CTS مهيأة عند الحاجة، وتوزيع أطراف الموصل مؤكد |
الأمن: هذه الواجهات لا تشفّر بياناتك تلقائيًا
UART وI²C وSPI وRS‑232 ليست بروتوكولات أمنية. فإذا استطاع مهاجم الوصول ماديًا إلى منفذ تصحيح UART، أو ذاكرة SPI flash، أو ناقل I²C، فقد يتمكن من قراءة البيانات، والتقاط الـFirmware، وإرسال الأوامر، والعبث بالطرفيات.
ولذلك ينبغي في المنتجات الحساسة إغلاق واجهات التصحيح عند الإنتاج حسب الحاجة، واستخدام Secure Boot، وتفعيل حماية ذاكرة Flash، والتحقق من تواقيع الـFirmware، وعدم تخزين الأسرار نصًا خامًا في الذاكرة الخارجية، ووضع نموذج تهديد (Threat Model) للوصول الفيزيائي.
الخلاصة
لا يحسم الاختيار بين UART وI²C وSPI وRS‑232 جدول سرعة واحد، بل فهم كل واجهة بوصفها أداة مختلفة لغرض مختلف:
| الواجهة | جوهرها | أفضل استخداماتها |
|---|---|---|
| UART | رابط تسلسلي بسيط وغير متزامن | التصحيح والموديولات |
| I²C | ناقل ثنائي الأسلاك بعنونة | الحساسات والأجهزة المتعددة على PCB |
| SPI | ناقل متزامن سريع منخفض الحمل | الذاكرة والشاشات والمكونات عالية البيانات |
| RS‑232 | واجهة كهربائية من نقطة إلى نقطة، تحتاج غالبًا Transceiver بين UART المنطقية والخط | الكابلات والأنظمة التقليدية والصناعية |
| I3C | تطور حديث لنواقل الحساسات والتحكم يجمع البنية ثنائية الأسلاك مع العنونة الديناميكية | تجميع الحساسات الحديثة بميزات أداء وإدارة متقدمة |
فبدل السؤال «أي بروتوكول أسرع؟»، اسأل:
ما أقل واجهة تعقيدًا تحقق Bandwidth والمسافة وعدد الأجهزة والطاقة والموثوقية المطلوبة ضمن القيود الكهربائية الفعلية للتصميم؟
المصادر والمراجع
NXP Semiconductors — UM10204, I2C-bus specification and user manual, Rev. 7.0
https://www.nxp.com/docs/en/user-guide/UM10204.pdfMIPI Alliance — I3C and I3C Basic
https://www.mipi.org/specifications/i3c-sensor-specificationMIPI Alliance — I3C Basic v1.2
https://www.mipi.org/mipi-i3c-basic-downloadMicrochip — SPI Mode Overview
https://onlinedocs.microchip.com/Texas Instruments — UART protocol and error overview
https://www.ti.com/video/6313217959112Texas Instruments — Universal Asynchronous Receiver/Transmitter user documentation
https://www.ti.com/lit/ug/sprugp1/sprugp1.pdfAnalog Devices — Fundamentals of RS-232 Serial Communications
https://www.analog.com/en/resources/technical-articles/fundamentals-of-rs232-serial-communications.htmlAnalog Devices — RS232 Quick Guide
https://www.analog.com/media/en/technical-documentation/product-selector-card/rs232%20quick%20guide.pdf
وثائق رسمية ومعايير إضافية
الأسئلة الشائعة حول المقال
ما الفرق بين UART وRS‑232؟
UART تنظم الإرسال التسلسلي غير المتزامن داخل المتحكم، بينما RS‑232 تحدد طبقة كهربائية ووظيفية Point-to-point بمستويات جهد مختلفة. يمكن استخدام UART مع RS‑232 عبر Transceiver.
هل يمكن توصيل UART 3.3 V مباشرة بمنفذ RS‑232؟
لا. مستويات RS‑232 مختلفة وقد تكون موجبة وسالبة. استخدم RS‑232 transceiver مناسبًا.
هل 115200 أعلى سرعة لـUART؟
لا. السرعة القصوى تعتمد على Hardware والClock والطرفين وجودة الرابط. 115200 مجرد قيمة شائعة.
هل I²C محدودة بـ400 kbit/s؟
لا. المواصفة تتضمن Fast-mode Plus حتى 1 Mbit/s وHigh-speed mode حتى 3.4 Mbit/s، إضافة إلى أوضاع أخرى.
لماذا تحتاج I²C مقاومات Pull-up؟
لأن SDA وSCL تعملان بأسلوب open-drain، فتحتاج الخطوط إلى Pull-up كي تعود إلى الحالة HIGH عندما لا يسحبها جهاز إلى LOW.
هل يمكن وصل عدة أجهزة على SPI؟
نعم. يمكن مشاركة Clock/Data واستخدام Chip Select منفصل لكل Target في التصميم التقليدي.
هل SPI لها سرعة قصوى موحدة؟
لا. السرعة تعتمد على Controller وTarget والتوقيت والـPCB والـSignal Integrity.
ما الفرق الرئيسي بين I²C وSPI؟
I²C تستخدم خطين وعناوين وتناسب عدة أجهزة، بينما SPI تستخدم عادة خطوطًا أكثر لكنها أبسط وأسرع وتوفر Full-duplex كهربائيًا.
هل Parity في UART تمنع فساد البيانات؟
لا. يمكنها كشف بعض الأخطاء فقط. للحماية الأقوى استخدم CRC وآليات ACK/Retry في Protocol أعلى إذا احتاج التطبيق.
هل Baud Rate هي نفسها Bit Rate؟
ليس دائمًا في الاتصالات. في UART الثنائية التقليدية غالبًا يتطابق الرقم على مستوى الخط لأن الرمز يحمل Bit واحدة، لكن Payload الفعلية أقل بسبب Framing.
النقاش الهندسي والملاحظات (0)
سجّل الدخول للمشاركة في النقاش والرد على التعليقات والإعجاب بها.
