راهنمای کوچک کار با کَن‌باس

در این نوشته به طور خلاصه با کَن‌باس CAN bus¹ آشنا می‌شویم و یاد می‌گیریم چطور با آن کار کنیم. طبق معمول ابزارهای بکار رفته همه آزاد هستند.

کن‌باس یک باس یا گذرگاه داده‌ی بسیار ساده و مقاوم و ارزان است که برای ساده‌سازی سیم‌کشی درون خودروها و ارتباط اجزاء مختلف با کنترلرها و کامپیوترهای خودرو در سال ۱۹۸۶ توسط شرکت بوش آلمان به خودروسازان جهان معرفی شده است. مستندات فنی نسخه‌ی ۲ آن به سال ۱۹۹۱ را می‌توانید در این آدرس بخوانید. بعدها در سال ۱۹۹۳ مشخصات فنی کن‌باس به استاندارد ایزو شماره‌ی ۱۱۸۹۸ تبدیل شد.

بدون وجود یک باس، می‌بایست درون خودرو کیلومترها سیم برای اتصال اجزاء مختلف به کنترلرها بکار رود. علاوه بر این بدون یک باس نمی‌توان از سیم‌ها برای مقاصد مختلف استفاده کرد. مثلا تصور کنید چراغ ترمز یک خودرو خراب شده است، اما چراغ خطر اضافی عقب خودرو سالم است. کامپیوتر خودرو می‌تواند خرابی را تشخیص بدهد و از چراغ خطر اضافی عقب بجای چراغ ترمز استفاده کند. بدون یک باس امکان اینکار وجود ندارد. علت اینکه به چنین گذرگاهی «باس» می‌گویند اینست که شبیه یک اتوبوس عمل می‌کند. یعنی داده‌های قطعات مختلف همگی می‌توانند سوار این اتوبوس بشوند و از یک ایستگاه به ایستگاه دیگری بروند.

یک کن‌باس حداقل به دو نود (عضو) برای کار نیاز دارد. همه‌ی اعضا با یک زوج سیم پیچ‌ و تاب خورده به یکدیگر متصل می‌شوند. یکی از این سیم‌ها CAN High و دیگری CAN Low نام دارد. هر دو انتهای این سیم‌ها باید با یک مقاومت ۱۲۰ اهمی به هم بسته بشوند. تصویر زیر از ویکی‌پدیا به خوبی این معماری را نمایش می‌دهد.

By EE JRW - Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=38256600

هر یک از نودهای برای اتصال به کن‌باس به یک مدار ساده احتیاج خواهد داشت. این مدار معمولا حاوی سه جزء است. یکی ترنسیور² و دیگری کنترلر³ و آخری هم میکروکنترلر (پردازنده‌ی میزبان) نام دارد. زوج سیم‌های باس تنها به ترنسیور وصل می‌شود و ترنسیور به نوبه خود به کنترلر. ترنسیور قطعه‌ی بسیار ساده‌ایست. کارش اینست که ولتاژهای الکتریکی CAN Low و CAN High را به سطوح منطقی صفر و یک قابل فهم برای کنترلر تبدیل بکند. از سوی دیگر کنترلر قطعه‌ی مهمی است و کارش پیاده‌سازی قرارداد ارتباطی است که در مستندات فنی کن‌باس قید شده است. کنترلر است که تصمیم می‌گیرد چه زمانی با باس صحبت بکند و اینکه چگونه پیام را ارسال بکند و چه زمانی تنها گوش بکند و چه زمانی کاملا خاموش باشد.

دست آخر هم هر نود باید برای ارسال و دریافت پیام روی باس با کنترلر خودش صحبت بکند. این کار را میکروکنترلر انجام می‌دهد. جایی که کاربر معمولا برنامه‌اش را باید بنویسد و فلش و اجرا کند. میکروکنترلر معمولا از یک طرف به سنسورها یا پمپ‌ها و مانند این متصل است و از سوی دیگر به کنترلر. مثلا در مثال چراغ خطر بالا میکروکنترلر از یک سو به چراغ خطر وصل خواهد بود و از سوی دیگر به کنترلر. به این ترتیب او می‌تواند هم وضعیت چراغ خطر را پیوسته از طریق باس به کامپیوتر خودرو ارسال بکند و از سوی دیگر فرامین کامپیوتر خودرو را دریافت و مثلا کاربری چراغ خطر را تغییر بدهد. امروزه میکروکنترلرهای زیادی حاوی کن کنترلر درونی هستند (اما فاقد ترنسیور مثل برخی پردازنده‌های سری ESP32).

تصویر زیر از ویکی‌پدیا معماری یک نود را به خوبی نمایش می‌دهد.

EE JRW, CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0, via Wikimedia Commons

مشخصاتی که در سال ۱۹۹۱ از طرف بوش برای کن‌باس منتشر شده است حاوی دو بخش A و B است. پیاده‌سازی‌هایی که طبق بخش A ساخته شده‌اند به CAN2.0A و آنهایی که سازگار با بخش B طراحی شده‌اند به نام CAN2.0B (نسخه‌ی توسعه‌یافته) شناخته می‌شوند. هر دو با هم سازگار هستند و می‌توانند در آن واحد در باس مشارکت کنند. تنها تفاوت آنها در طول شناسه‌ی پیام‌هاست. در کن‌باس نودهای باس به یکدیگر پیام (یک فریم) ارسال می‌کنند. هر نود باید پیام‌هایش را با یک شناسه‌ی یکتا ارسال بکند. هر پیام هم به نوبه خود حاوی شناسه‌ی نود فرستنده و یک بدنه است. شناسه می‌تواند طبق CAN2.0A و ۱۱ بیت یا طبق CAN2.0B و ۲۹ بیت باشد. کن‌باس محدودیتی تئوریک برای تعداد نودهای حاضر در باس تعریف نمی‌کند. تمام نودهای حاضر در باس تمام پیام‌ها را دریافت می‌کنند حتی نود فرستنده. تصویر زیر ساختار یک فریم یازده بیتی را نمایش می‌دهد.

Fröstel (S.G.), CC0, via Wikimedia Commons

کن چهار نوع فریم تعریف می‌کند: داده و ریموت و خطا و اوورلود. مهمترین نوع فریم داده است که نودها با آن داده ارسال می‌کنند. هر فریم داده می‌تواند صفر تا ۶۴ بیت (۸ بایت) داده داشته باشد. نودها نیز نیازی به تنظیمات مرکزی ندارند. هر نود به محض اتصال می‌تواند در باس مشارکت بکند. کنترلر وظیفه‌ی ارسال و دریافت پیام‌ها را طبق مشخصات فنی کن‌باس بر عهده می‌گیرد. مثلا ارسال فریم خطا هنگام دریافت فریم ناقص یا سکوت کامل هنگام دریافت خطا بیش از حد مجاز یا خاموش کردن کامل نود (bus-off) در برخورد با خطاهای غیر قابل اصلاح و چشم‌پوشی.

علاوه بر نسخه‌ی‌ای که در بالا معرفی کردیم نسخه‌های سطح بالاتری از کن هم توسط بوش و دیگران ساخته شده است که برای کاربردهای پیچیده‌تر به کار می‌روند. از میان آنها می‌توان به CAN-FD توسط بوش و CANopen اشاره کرد. ویژگی مشترک اغلب آنها اینست که از کن‌باس به عنوان پایین‌ترین لایه‌ی ارتباطی استفاده می‌کنند.

از جایی که کن بسیار ساده و مقاوم و ارزان است، نه تنها در خودروها بلکه به شکل گسترده‌ای در صنایع مختلف راه پیدا کرده است. اگر به مشخصات تجهیزات صنعتی نگاهی بیندازید حتما کن را در میان پروتکل‌های ارتباطی آنها پیدا خواهید کرد. قطعاتی مثل لامپ‌های هشدار چند رنگ رایج در انبارهایی که لیفتراک یا ربات برای حمل و نقل استفاده می‌کنند تا ربات‌های خودکار موجود در خط تولید یا شارژرهای بی‌سیم صنعتی و بسیاری دیگر همگی از کن برای ارتباط استفاده می‌کنند.

از طرفی کن برخلاف پروتکل اترنت (شبکه‌های کامپوتری) شکل فیزیکی پورت اتصال کابل به نود را محدود نمی‌کند. تا آنجا که به کن مربوط است فقط کافیست دو سیم برای اتصال وجود داشته باشد. اینکه چگونه نودها به یکدیگر متصل می‌شوند برای کن مهم نیست. از این رو در بازار روش‌های مختلفی رایج شده است. محبوب‌ترین و ارزانترین پورت اتصالی ترمینال پیچی است:

Phoenix Contact https://www.phoenixcontact.com/

پورت بعدی که گران است ولی در محصولات صنعتی رایج است انواع اتصالات گرد از سری محصولات شرکت فونیکس کانتکت است. هر تولید‌کننده‌ای تصمیم می‌گیرد که چه متصل‌کننده‌ای برایش مناسب‌تر است و اینکه کدام پین‌ها باید برای CAN High و CAN Low بکار برود. این جزئیات هم در دیتاشیت تولید کننده منتشر می‌شود. شکل زیر تعدادی متصل‌کننده را نشان می‌دهد:

Phoenix Contact https://www.phoenixcontact.com/

آخرین پورت رایجی که نام می‌بریم OBD II نام دارد که در خودروها بکار می‌رود. البته این پورت فقط برای کن نیست بلکه کاربرد اصلی آن استاندارد کردن نحوه دسترسی به اطلاعات فنی خودرو بوده است. چرا که خودروسازان مانند بسیاری شرکت‌های دیگر علاقه‌ی شدیدی به انحصاری کردن خدماتشان دارند. بنابراین هر یک برای دسترسی به اطلاعات کامپیوتر خودرو که برای تعمیر و نگهداری خودرو لازم است پروتکل‌های انحصاری خودشان را بکار می‌بردند و به تعمیرگاه‌های مستقل امکان دسترسی نمی‌دادند (مگر مثلا با اخذ مجوز و خرید دستگاه‌های لازم از خودشان). ODB II پاسخ قانونگذاران در آمریکا و اروپا به این وضع بود. از سال ۱۹۹۶ در آمریکا و از سال ۲۰۰۱ در اروپا خودروسازان مجبورند یک پورت ODB II با شکل فیزیکی و پیام‌های تعریف شده در استاندارد در خودرو تعبیه کنند. از این طریق تعمیرکاران مستقل و حتی مصرف‌کنندگان می‌توانند به اطلاعات پایه‌ی خودرو دسترسی پیدا کنند بدون اینکه تولید کننده بتواند مانع آنها بشود و درخواست وجه بکند. این پورت طبق استاندارد باید در فاصله‌ی ۶۱ سانتی‌متری فرمان باشد. اگر به زیر فرمان خودروهای ساخت خارج نگاهی بیندازید حتما این پورت را پیدا می‌کنید:

By M.M.Minderhoud - Own work, Female OBD-II connector on a car, CC BY-SA 4.0, vie Wikimedia Commons

طبق استاندارد دو پین شماره‌ی ۶ و ۱۴ برای کن در نظر گرفته شده است که به رنگ سبز در تصویر زیر مشخص است:

*Xoneca - Own work, CC0, via Wikimedia Commons *

در بازار گیرنده‌های مختلفی وجود دارند که می‌توان به این پورت وصل کرد و اطلاعات خودرو و پیام‌های خطا را خواند و پاک کرد و برخی تنظیمات خودرو را تغییر داد. من یک گیرنده‌ی بلوتوث کوچک دارم که بعد از اتصال به ماشین و بلوتوث یک گوشی می‌توان به کمک یک به اطلاعات خودرو دست یافت. تمام این کارها را هم می‌توان مستقیما با اتصال دو سیم به پین‌های کن انجام داد که از حوصله‌ی این مقاله خارج است.

آداپتور OBD II بلوتوث من

آداپتور OBD II بلوتوث من

آماده‌سازی سخت‌افزار کن در لینوکس

در ادامه شرح می‌دهم که چطور می‌توان روی لینوکس با کن کار کرد. همانطور که در ابتدا دیدیم نودها می‌توانند با کن‌باس ارتباط برقرار کنند و پیام دریافت و ارسال بکنند. دستگاه لینوکسی ما هم باید به باس وصل و تبدیل به یک نود بشود تا بتوانیم پیام‌ها را دریافت و ارسال بکنیم. برای اینکار در درجه اول نیاز به سخت‌افزار کن داریم. در بازار آداپتورهای کن به USB فراوانی وجود دارد که معمولا مبتنی به تراشه‌های ارزان میکروچیپ هستند. مثل ترنسیور MCP2551 و کنترلر MCP2515. من دو نمونه آداپتور از سایت canable.io تهیه کرده‌ام که در زیر می‌بینید:

CANable Pro & CANable

تفاوت مهم نسخه‌ی بزرگتر با نسخه کوچکتر در ایزولاسیون است که از لپ‌تاپ من در صورت اتصالی یا مانند اینها حفاظت می‌کند. به جز این هر دو شبیه هستند، در یک سو پورت میکرو یو‌اس‌بی است که با یک کابل به کامپیوتر وصل می‌شود و در صوی دیگر ترمینال پیجی برای سیم‌های CAN High و CAN Low و در صورت نیاز گراوند قرار گرفته. یک جامپر هم روی هر یک تعبیه شده که مقاومت ۱۲۰ اهمی را فعال و غیرفعال می‌کند. در مورد نحوه‌ی بکارگیری گراوند من نمی‌توانم راهنمایی مفیدی بکنم چرا که از حوزه‌ی تخصص من خارج است. یک مهندس الکترونیک می‌تواند اهمیت آن را بهتر شرح بدهد فقط اضافه کنم که اتصال اشتباه گراوند/زمین می‌تواند منجر خرابی باس بشود و گیرنده هیچ پیامی دریافت نمی‌کند و معمولا نیازی به اتصال آن نیست.

دو روش رایج برای کار با کن در لینوکس عبارت است از slcan و socketcan. هر دو درایور در تنه‌ی اصلی کرنل قرار دارند و بنابراین بدون نصب هیچ گونه نرم‌افزار اضافی در دسترس قرار دارد. هرچند پیش از استفاده باید مطمئن شد که ماژولهای مورد نظر لود شده‌اند:

$ sudo modprobe can
$ sudo modprobe slcan #for slcan

در ادامه من فقط به شرح کار با socketcan می‌پردازم.

کار با SocketCAN در لینوکس

سوکت‌کن از ‌Berkly sockets استفاده می‌کند که همان سوکت یونیکس است که کل اینترنت روی آن بنا شده است. یعنی مثل رابط شبکه رفتار می‌کند. این به معنای اینست که تمام ابزارهای رایج لینوکس مانند دستور ip می‌توانند با آداپتور کن ارتباط برقرار کنند. برای این منظور یک رابط نرم‌افزاری CAN-to-USB هم نیاز است. آداپتورهایی که من دارم از درایور slcan و gs_usb (هردو به لینوکس اضافه شده‌اند) پشتیبانی می‌کنند. من نسخه‌ای بنام CandleLight را فلش کرده‌ام که به کمک آن آداپتور من بی‌واسطه توسط کرنل به عنوان یک سخت‌افزار شبکه مبتنی بر SocketCAN شناخته می‌شود. ناگفته پیداست که اینکه یک سخت‌افزار چگونه خود را به سیستم عامل معرفی کند وابسته به firmware ایست که روی آن فلش شده است.

با اتصال آداپتور به کامپیوترم کرنل براحتی آن را تشخیص می‌دهد:

$ sudo dmesg -w
[21050.404363] usb 3-2.2: new full-speed USB device number 11 using xhci_hcd
[21050.509412] usb 3-2.2: New USB device found, idVendor=1d50, idProduct=606f, bcdDevice= 0.00
[21050.509421] usb 3-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[21050.509424] usb 3-2.2: Product: canable gs_usb
[21050.509426] usb 3-2.2: Manufacturer: canable.io
[21050.509428] usb 3-2.2: SerialNumber: 00238008574D430820333735
[21050.510049] gs_usb 3-2.2:1.0: Configuring for 1 interfaces

شش خط اول از درایور یو‌اس‌بی است و خط آخر از درایور gs_usb که اینترفیس را ایجاد می‌کند. با دستور ip می‌توانیم سخت‌افزارهای واقعی و مجازی شبکه شناخته شده توسط کرنل لینوکس را ببینیم:

$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 04:92:26:da:0a:6b brd ff:ff:ff:ff:ff:ff
3: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
    link/can

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

ساخت یک کن‌باس با دو نود

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

برای اینکار من هر دو آداپتورم را بکار می‌گیرم. جامپرهای ۱۲۰ اهم را در هر دو سو فعال می‌کنم و با دو کابل CAN High را به CAN High و CAN Low را به CAN Low وصل می‌کنم:

ساخت کن باس با دو آداپتور کن به یو‌اس‌بی

به نحوه‌ی اتصال سیم‌ها توجه کنید (جامپرهای مقاومت هم بسته است ولی در عکس پیدا نیست)

حالا هر دو آنها را به دو پورت یو‌اس‌بی متصل می‌کنم:

$ sudo dmesg -w
[24221.741438] usb 3-2.1: new full-speed USB device number 19 using xhci_hcd
[24221.842849] usb 3-2.1: New USB device found, idVendor=1d50, idProduct=606f, bcdDevice= 0.00
[24221.842857] usb 3-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[24221.842860] usb 3-2.1: Product: canable gs_usb
[24221.842863] usb 3-2.1: Manufacturer: canable.io
[24221.842865] usb 3-2.1: SerialNumber: 00238008574D430820333735
[24221.843491] gs_usb 3-2.1:1.0: Configuring for 1 interfaces
[24224.554745] usb 3-2.2: new full-speed USB device number 20 using xhci_hcd
[24224.659402] usb 3-2.2: New USB device found, idVendor=1d50, idProduct=606f, bcdDevice= 0.00
[24224.659407] usb 3-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[24224.659408] usb 3-2.2: Product: canable gs_usb
[24224.659410] usb 3-2.2: Manufacturer: canable.io
[24224.659410] usb 3-2.2: SerialNumber: 00330023574D430820333735
[24224.659961] gs_usb 3-2.2:1.0: Configuring for 1 interfaces

هر دو آداپتور به لیست سخت‌افزارهای شبکه اضافه شده:

$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 04:92:26:da:0a:6b brd ff:ff:ff:ff:ff:ff
3: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
    link/can 
4: can1: <NOARP,ECHO> mtu 16 qdisc noop state DOWN mode DEFAULT group default qlen 10
    link/can 

برای اینکه از یک اینترفیس سوکت‌کن بتوان استفاده کرد باید آن را تنظیم کرد و بالا آورد. فعلا هر دو قطعه پایین هستند (DOWN). با دستور ip آنها را بالا می‌آوریم:

$ sudo ip link set can0 up type can bitrate 500000
$ sudo ip link set can1 up type can bitrate 500000
$ ip link
...
3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
    link/can 
4: can1: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
    link/can 

می‌بینیم که هر دو UP شده‌اند. از جایی که هر کن‌باس یک bitrate یکسان دارد باید مقدار آن را هنگام بالا آوردن آداپتور بدهیم. من پانصد کیلوبیت را انتخاب کردم که رقم رایجی است. اگر فلگ -statistics را به دستور ip بدهیم اطلاعات بیشتری می‌بینیم:

$ ip -statistics link show can0
3: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UP mode DEFAULT group default qlen 10
    link/can 
    RX:  bytes packets errors dropped  missed   mcast           
             0       0      0       0       0       0 
    TX:  bytes packets errors dropped carrier collsns           
             0       0      0       0       0       0 

حالا شبکه‌ی ما آماده است و می‌توانیم برویم سروقت ارسال و دریافت پیام. برای اینکار به ابزارهای موجود در can-utils نیاز خواهیم داشت. پروژه‌ی can-utils حاوی ابزارهای userspace برای SocketCAN است. این پروژه در برخی دیستروها پکیج شده است و در سایرین باید زحمت نصب آن را کشید که از حوصله‌ی این مقاله خارج است. ما از دو ابزار موجود در این پروژه استفاده می‌کنیم: candump و cansend. اولی برای خواندن پیام‌های باس و دیگری برای ارسال پیام روی باس. دو ابزار دیگر هم که برای تمرین خوب است یکی cangen است که پیام‌های رندوم می‌سازد و به باس ارسال می‌کند و دیگری canplayer که می‌تواند پیام‌های ضبط شده با candump را دوباره ارسال کند.

حالا که نرم‌افزار لازم را هم داریم لحظه‌ی امتحان نهایی فرا رسیده است! بیایید پیامی از نود صفر به باس ارسال کنیم و آن را در نود شماره‌ی یک بخوانیم. اول در یک ترمینال candump را باز می‌کنیم و در ترمینال دیگر cansend را اجرا می‌کنیم:

$ candump can1
  can1  1FF   [0] 

...
$ cansend can0 1FF#

در اسکرین‌کست کوتاه زیر می‌توانید پروسه را ببینید. مقدار قبل از # آدرس فریم یا CAN ID است و مقدار بعد از # داده است (که من خالی گذاشتم، تا هشت کاراکتر HEX می‌توان داده پاس داد یعنی FFFFFFFF). توجه کنید که من یکبار با فرمت کوتاه و یکبار دیگر با فرمت بلند CAN ID دلبخواهی می‌سازم و فریم را ارسال می‌کنم.

در زیر هم استفاده از cangen برای ساخت فریم‌های تصادفی را می‌توانید ببینید. باز هم توجه کنید که یکبار فریم‌ها را با فرمت کوتاه (CAN2.0A) و یکبار با فرمت بلند (توسعه‌یافته CAN2.0B) ارسال می‌کنم.

ابزارهای موجود در پروژه‌ی can-utils بسیار ساده و سریع و مفید هستند. یکی از قابلیت‌های مجبوب من ضبط پیام‌های یک باس به کمک candump (candump -l) و پخش آن با canplayer (cat dump.log | canplyer can0=can0) روی یک باس مجازی هنگام برنامه‌نویسی یا بررسی یک مشکل است. اما شاید بپرسید مگر بدون آداپتور هم می‌شود کن‌باس را امتحان کرد؟ در جهان نرم‌افزار آزاد پاسخ اغلب این پرسش‌ها «آری» است! (بد نیست بدانید که شرکت‌های تولیدکننده دستگاه‌های صنعتی اغلب برای بررسی اشکال یک Logger (دستگاهی مشابه آداپتور که پیام‌ها را روی یک کارت حافظه ضبط می‌کند) به مشتری ارسال می‌کنند تا پیام‌ها را ضبط کند و فایل آن را برای بررسی توسط مهندسان ارسال کند.)

کن‌باس مجازی

برای امتحان کن‌باس و پخش لاگ فایل‌های ضبط شده بدون دسترسی به یک آداپتور می‌توان از ماژول vcan لینوکس استفاده کرد. ابتدا باید از لود بودن ماژول vcan مطمئن شد و بعد به کمک دستور ip می‌توان یک اینترفیس مجازی از نوع vcan ساخت:

$ sudo modprobe vcan
$ sudo ip link add type vcan

در اسکرین‌کست مختصر زیر یک اینترفیس مجازی کن می‌سازم و آن را فعال می‌کنم و پیام‌های رندوم روی آن ارسال می‌کنم.

پارس کردن پیام‌ها

آخرین موضوعی که به طور خلاصه به آن می‌پردازیم پارس کردن پیام‌هاست. ابزارهای پروژه‌ی can-utils تنها با فریم‌های خام کار می‌کنند. برای دیکد کردن این اطلاعات به ابزارهای سطح بالاتری نیاز است. آنچه در صنایع و دنیای برنامه‌نویسی توکار رایج است ذخیره‌ی فرمت داده‌ها و ماتریس پیام‌های ارسالی و نیز آدرس‌های آنها در فایل‌هایی با فرمت‌های مختلف از جمله DBC است. (فرمت KCD یک فرمت آزاد است که استفاده نکرده‌ام). استاندارد خاصی در این حوزه وجود ندارد و به طور سنتی تولیدکننده‌های آداپتورها هر یک طبق وزن خودشان در دنیای صنعت فرمت‌های خودشان را ساخته‌اند که اغلب هم انحصاری هستند. از جایی که کمتر تولید‌کننده‌ای ابزارهای آزاد منتشر می‌کند پروژه‌های مختلفی برای دیکد کردن لاگ‌فایل‌ها و نیز فایل‌ها تعریف فرمت فریم‌ها بوجود آمده است. دوپروژه‌ی خوبی که در این حوزه از آن بسیار بهره برده‌ام یکی python-can و دیگری cantools است. اولی می‌تواند با آداپتورهای مختلف ارتباط برقرار کند و دومی هم امکان دیکد کردن داده‌ها با استفاده از فرمت DBC و دیگر فرمت‌ها فراهم می‌کند. یکی از ویژگی‌های جالب پروژه‌ی cantools آن امکان دیکد کردن زنده‌ی پیام‌های ارسالی روی باس است که هنگام بررسی و رفع اشکال توسط تیم‌های پشتیبانی یا برنامه‌نویسان بسیار مفید است. من در اینجا به تکرار آنچه روی سایت پروژه آمده است نمی‌پردازم چرا که مثال‌های مختلف روی ریپازیتوری cantools به تفصیل شرح داده شده است.

1. Computer Area Network ↩

2. CAN Transceiver ↩

3. CAN Controller ↩