1.1 حکمیت یا داوری باس CAN

شکل 1: داوری باس

1.1.1

در ارسال فریم اطلاعات بر روی باس CAN، حکمیت Arbitration با فریم اطلاعاتی است که پایین ترین آدرس شناسه، Identifier، را دارد.
یعنی یک فریم اطلاعات استاندارد با شناسه 000 0000 0000 دارای بالاترین اولویت انتشار بر روی باس CAN است و فریم اطلاعات با شناسه 111 1111 1111 دارای پایین ترین اولویت انتشار.

1.1.2

هر گره، Nod، هنگامی که یک فریم اطلاعات را بر روی باس قرار می‌دهد بر اساس پروتکل ارتباطی CAN، باس را شنود می‌کند
(Node A در شکل 1).
به عبارت دیگر اگر یک گره، Nod، دیتایی را روی پین CAN_Tx خود قرار دهد، با پین CAN_Rx خود وضعیت باس را تحت نظر می‌گیرد. این عمل منجر به مشخص شدن حکمیت باس می‌شود.

1.1.3 چگونگی مشخص شدن حکمیت باس CAN

اگر دو گره، Nod، بطور همزمان اقدام به ارسال اطلاعات بر روی باس CAN کنند، دیتاهای ارسالی خود را که بر روی باس قرار می‌دهند، شنود هم می‌کنند.
اگر یک بیت با سطح منطقی صفر (Dominant) با یک بیت با سطح منطقی یک (Recessive) همزمان بر روی خط قرار بگیرند، اولویت با بیت با سطح منطقی صفر (Dominant) بوده و آنچه که بر روی باس اعمال می‌شود، بیت با سطح منطقی صفر (Dominant)است.

مثال: در شکل 1، Node A در بیت 6 ام، یک بیت با سطح منطقی صفر (Dominant) را بر روی باس قرار می‌دهد و Node B نیز در بیت 6 ام یک بیت با سطح منطقی یک (Recessive). با توجه به آنچه که در بالا گفته شد، نهایتا بیت با سطح منطقی صفر (Dominant) بر بیت با سطح منطقی یک (Recessive) غالب می‌شود و بر روی باس قرار می‌گیرد.
Node B وقتی اطلاعات ارسالی خود را با اطلاعات دریافتی مقایسه می‌کند و در بیت 6 ام تفاوت می‌بیند یعنی یک بیت سطح منطقی یک (Recessive) فرستاده اما یک بیت با سطح منطقی صفر (Dominant)دریافت کرده، در نتیجه حکمیت باس را به Node A واگذار می‌کند.

1.2 روش‌های شناسایی خطاها در پروتکل ارتباطی CAN_BUS

1.2.1 خطاهای دریافت

خطاهای دریافت شامل:

1.2.1.1 CRC :Cyclic Redundancy Check

توضیح CRC: فرستنده پیام، همراه پیام یک کد CRC می‌فرستد. این کد مربوط به محاسبه CRC از شروع فریم اطلاعات ارسالی تا پایان فیلد داده می‌باشد.

شکل 2: درمحاسبه CRC برای هر فریم اطلاعات از SOF تا انتهای DATA

در طرف گیرنده، CRC مجددا از شروع فریم اطلاعات ارسالی تا پایان فیلد داده (با همان فرمول محاسبه CRC طرف فرستنده) محاسبه می‌شود و سپس با CRC ارسالی از طرف فرستنده مقایسه می‌گردد. اگر عدم تطابق شناسائی شود، خطای CRC رخ داده، پیام دریافتی دور ریخته می‌‍شود و یک Frame Error تولید می‌شود.

پیام دوباره ارسال می‌شود و شمارنده وقفه وقوع خطای دریافت یکی افزایش می‌یابد.

1.2.1.2 Bit Stuffing Bit Error

شکل 3: در Bit Stuffing، از شروع فریم ارسالی تا پایان CRC تمامی بیت‌ها چک می‌شوند.

فریم ارسالی در CAN اطلاعات همگام سازی (synchronization) ندارد. Nod ها با تغییر در سطح بیت، خودشان را همگام سازی (synchronization) می‌کنند. بدین صورت که بر اساس قانون کد گذاری NRZ-5، اطلاعات ارسالی در پروتکل CAN نمی‌توانند بیش از 5 بیت یکسان داشته باشند (یعنی بیش از 5 بیت متوالی 0 یا بیش از 5 بیت متوالی 1).

اگر 5 بیت متوالی یکسان در فریم اطلاعات ارسالی وجود داشته باشد، کنترلر فرستنده بصورت خودکار یک بیت با مقدار مخالف به فریم اطلاعات ارسالی اضافه می کند.

به عبارت دیگر اگر در فریم اطلاعات ارسالی 5 بیت متوالی 0 بود کنترلر فرستنده بصورت خودکار یک بیت با مقدار 1 به فریم اطلاعات ارسالی اضافه می‌کند و اگر در فریم اطلاعات ارسالی 5 بیت متوالی 1 بود کنترل کننده بصورت خودکار یک بیت با مقدار 0 به فریم اطلاعات ارسالی اضافه می‌شود.

در طرف گیرنده توالیِ بیت‌هایِ فریمِ اطلاعاتِ ارسالیِ فرستنده چک می‌شود، اگر 5 بیت یکسان در یک توالی وجود داشت (یعنی 5 بیت 1 یا 0 پشت سر هم) و بیت ششم مخالف آن‌‎ها بود، بیت ششم را در نظر نمی‌گیرد و اطلاعات 5 بیت را در نظر می‌گیرد.

شکل 4: چگونگی اضافه کردن و جداسازی Stuff Bit به فریم اطلاعات ارسالی در CAN_BUS

اگر 6 بیت یکسان در یک توالی وجود داشت خطای Bit Stuff رخ می‌دهد و Error Frame ساخته می‌شود. فریم اطلاعات مجدد ارسال می‌شود و وقفه ای رخ نمی‌دهد.

نکته Invalid Message Received Error

در صورت وقوع هر گونه خطا در هنگام دریافت، بیت هفتم (IVRIF) از رجیستر CiINTF برابر 1 می‌شود.

از این بیت برای تنظیم خودکار باوود ریت هنگامی که CAN_BUS در مد گوش دادن است، نیز استفاده می‌شود. (در صورت نیاز با تنظیم وقوع وقفه)

در صورت یک شدن این بیت نیاز به انجام عمل خاصی نیست و فقط بیانگر اینست که در CAN_BUS یک خطا رخ داده است.

1.3 خطاهای ارسال

1.3.1 Acknowledge Error

بیت Ack در فریم استاندارد CAN_BUS

شکل 5

فرستنده هنگامی که یک فریم اطلاعات را بر روی باس CAN قرار می‌دهد، بیت ACK Slot آن را برابر سطح منطقی یک (Recessive) می‌گذارد و پس از پایان ارسال مجدد آن را چک می‌کند اگر حداقل یک NOD پیام را دریافت کند این بیت به سطح منطقی صفر (Dominant) تغییر پیدا می‌کند.

اگر هیچ گره‌ای این پیام را دریافت نکند، این بیت با سطح منطقی یک (Recessive) به فرستنده پیام باز گرداننده می‌شود.

در این حالت خطای Acknowledge Error رخ داده و ارسال پیام باید تکرار شود. نیازی به ساخت فریم خطا نمی‌باشد.

شکل 6 : توضیح Recessive , Dominant

1.3.2 Form Error

اگر فرستنده پیام یک بیت با سطح منطقی صفر (Dominant) در یکی از 4 قسمت End-Of-Frame, lnterframe Space, Acknowledge Delimiter یا CRC Delimiter تشخیص دهد، خطای Form Error رخ می‌دهد و یک فریم خطا ساخته می‌شود.

پیام باید دوباره ارسال شود.

شکل 7 : وقوع خطای Form Error در بیت های End-Of-Frame, lnterframe Space, Acknowledge Delimiter ، CRC Delimiter

1.3.3 Bit Error

فرستنده پیام روی باس CAN بعد از ارسال پیام، باس را مانیتور می‌کند (یعنی بیت به بیت، بیت‌های ارسالی به روی باس CAN را با بیت‌های خوانده شده از روی باس مقایسه می‌کند) تا در صورت از دست دادن حکمیت (arbitration) باس در ارتباط CAN، ارسال پیام را متوقف کند.

اگر فرستنده یک بیت با سطح منطقی صفر (Dominant) ارسال کند اما یک بیت با سطح منطقی یک (Recessive) روی باس CAN شناسایی شود (شکل زیر) یا یک بیت با سطح منطقی یک (Recessive) ارسال کند اما یک بیت با سطح منطقی صفر(Dominant) شناسایی شود، خطای Bit Error رخ می‌دهد اما به دلیل وجود داوری Arbitration گزارش خطایی ساخته نمی‌شود.

شکل 8 :Error Bit

نکته: در یک فریم اطلاعات خطای Error Bit در 2 بخش Arbitration Field ,ACK Field رخ نمی‌دهد.

شکل 9 : خطای Error Bit

شکل 9: خطای Error Bit: فرستنده پیام، بعد از ارسال باس را شنود می‌کند. روی خط یک فرستاده اما صفر می‌خواند.

شکل 10 : Bit Error

شکل 10: Bit Error: وقوع Bit Error فقط برای قسمت‌های رنگی فریم استاندارد اطلاعات ارسالی در CAN چک می‌شود.

1.4 وضعیت خطاها

تمام خطاهای شناسایی شده در طول باس CAN برای تک تک NOD های متصل به باس CAN ارسال می‌شود.

ارسال فریم اطلاعات دارای خطا متوقف می‌شود و فریم اطلاعات مجددا ارسال می‌شود.

برای هر گره CAN_BUS سه حالت خطا وجود دارد.

بسته به نوع خطای رخ داده بر روی باس، شمارنده خطای هر گره، Nod، بین 1 تا 8 واحد افزایش پیدا می‌کند. هر گره متصل به باس دارای یک شمارنده خطاهای دریافتی و یک شمارنده خطاهای ارسالی می‌باشد.

با تجمیع دو عبارت فوق به این نتیجه می‌رسیم که برای هر ارسال فریم اطلاعات منجر به خطا بر روی باس، شمارنده خطا برای گره فرستنده 8 واحد افزایش می‌یابد و برای شمارنده خطا در گره گیرنده یک واحد افزایش می‌یابد.

رجیستر CiEC در DSpic30F5011 تعداد خطاها در دریافت (RERRCNT) و تعداد خطاها در ارسال (TERRCNT) را در خود ذخیره می‌کند.

اگر تعداد خطاها در شمارنده وقوع خطا در ارسال (TERRCNT)یا شمارنده وقوع خطا در دریافت(RERRCNT) برابر 96 یا بیشتر از آن شود بیت 8 ام(EWARN) از رجیستر CiINTF برابر یک می‌شود و اگر تعداد خطای شمارش شده کمتر از 96 شود این بیت ریست می‌گردد.

نکته: به ازاء هر دریافت یا ارسال صحیح، شمارنده خطای ارسال یا خطای دریافت یکی کاهش می‌یابد. این ویژگی این امکان را به گره‌ها می‌دهد تا در ازاء ارسال و دریافت صحیح در صورتیکه در مد غیرفعال بودند، به مد عملکرد عادی بازگردند.

نکته: یک گره، Nod، به 2 روش از حالت Bus off به حالت Passive Error باز می‌گردد.

روش اول: پس از دریافت 128 رخداد بصورت 11 بیت متوالی با سطح منطقی یک (Recessive)

روش دوم: پس از دریافت 128 رخداد بصورت Data Frame یا Error Frame

رخداد Data Frame:

11 bits = 1 bit ACK Delimiter + 7 bits End Of Frame + 3 bits Inter Frame Spacing (شکل 5)

رخداد Error Frame:

11 bits = 8 bits Error Delimiter + 3 bits Inter Frame Spacing (شکل 5)

1.4.1

مدت زمان لازم برای اینکه یک گره، Nod، با نرخ انتقال 1Mbps (معادل انتقال یک بیت در یک میکرو ثانیه) از حالت Bus off به حالت Passive Error باز می‌گردد بصورت زیر محاسبه می‌شود:

128 رخداد *11 بیت * 1میکرو ثانیه = 1408 میکرو ثانیه

1.4.2

زمانی که یک گره، Nod، خطای باس را شناسائی می‌کند، یک فریم خطا که شامل 5 بیت با سطح منطقی صفر (Dominant) و در ادامه آن 8 بیت با سطح منطقی یک (Recessive) است را بر روی باس قرار می‌دهد. بقیه گره‌ها نیز در هنگام شناسائی خطای باس همین کار را می‌کنند. ارسال فریم خطا توسط گره‌های روی باس، منجر به وقوع اشکال نمی‌شود. چون بیت‌های سطح منطقی صفر (Dominant) با بیت‌های سطح منطقی یک (Recessive) جایگزین می‌شوند. حاصل این عمل، ریست بدون خطر باس قبل از برقراری مجدد ارتباط می‌باشد.

تنظیم بیت‌های وقوع وقفه در پروتکل ارتباطی CAN_BUS

بیت‌های 1 تا 3 از رجیستر CiCTRL: ICODE 2:0

لیست رجیسترهای مربوط به بافر ارسال CAN_BUS

CiTXnCON :Transmit Buffer Status and Control Register

رجیستر کنترل و وضعیت بافر ارسال در CAN_BUS

CiTXnBq

i می‌تواند 1 یا 2 وابسته به تعداد ماژول‌های CAN_BUS داخل میکرو باشد.

n می‌تواند 1، 2 یا 3 باشد. n تعداد بافرهای ارسال dspic30f5011 می‌باشد.

q می‌تواند 1، 2، 3 یا 4 باشد. هر بافر ارسال شامل 4 رجیستر 16 بیتی می‌باشد. q شماره رجیستر 16 بیتی است.

CiTXnSID :Transmit Buffer n Standard Identifier

توسط این رجیستر شناسه استاندارد برای بافر ارسال ماژول CAN، قابل تنظیم می‌باشد.

یعنی دیتای ارسالی مورد نظر ما که در رجیسترهای CiTXnBq قرار گرفته اند، با مقداردهی این رجیستر (CiTXnBq) دارای

شناسه استاندارد می‌شوند.

CiTXnEID :Transmit Buffer n Extended Identifier

توسط این رجیستر شناسه گسترش یافته برای بافر ارسال ماژول CAN، قابل تنظیم می‌باشد.

CiTXnDLC :Transmit Buffer n Data Length Control

توسط این رجیستر طول داده بافر ارسال ماژول CAN، قابل تنظیم می‌باشد.

Reference:

1. http://ww1.microchip.com/downloads/en/DeviceDoc/70070D.pdf
2. http://esd.cs.ucr.edu/webres/can20.pdf
3. http://www.ti.com/lit/an/slla123/slla123.pdf
4. http://www.dsrminc.com/whitepaper/bus_error_management_in_controller_area_nework__rev_1_.pdf
5. https://www.youtube.com/watch?v=o7ROYqO8TbY
6. https://www.youtube.com/watch?v=vOWhr0mH5HI
7. https://training.ti.com/zh-tw/automotive-can-overview
8. https://www.youtube.com/watch?v=ZSlPa1AN-LA

انتشار مطالب با ذکر نام و آدرس وب سایت سیسوگ، بلامانع است.

شما نیز میتوانید یکی از نویسندگان سیسوگ باشید.  همکاری با سیسوگ