MCP2551 перетворювач UART в CAN?

Я хочу зробити нюхальник шини CAN на 250 кбіт / с за допомогою комп'ютера. Після деяких досліджень я виявив, що MCP2551 - це якийсь регулятор рівня напруги для фізичного шару CAN. Маючи це на увазі, мені цікаво, чи може ця установка спрацювати. Я просто хочу записувати обмінювані повідомлення для автоматизованих тестових цілей, а не бути частиною спілкування:

ПК <-> USB-UART (можливо CP2102, тому що у мене вже є) <-> MCP2551 <-> CAN шина

Якщо ні, то які сигнали повинні вводити MCP2551 для того, щоб я став частиною шини?

usb microchip can

— рнуни
джерело

Відповіді:

Ви можете це зробити, але те, що ви отримаєте на шині CAN, буде UART, використовуючи рівні напруги CAN. Вам потрібно надати MCP2551 повідомлення протоколу CAN, якщо ви хочете спілкуватися з пристроями CAN на своїй шині. Те саме для прослуховування: повідомлення CAN настільки відрізняються від формату UART, що UART не знатиме, що з ними робити. Ви будете мати принаймні помилки в кадрі весь час, і ви не отримаєте вміст повідомлення.
Це зображення показує структуру повідомлення CAN:

введіть тут опис зображення

Навколо є багато мікроконтролерів, які мають CAN-інтерфейс, не приймаючи приймач. Саме для них був розроблений MCP2551. Раніше ми використовували NXP LPC2294, який має 4 CAN-інтерфейси. Кожен з них потребує MCP2551 для підключення до шини CAN. Більш недавні контролери від NXP включають сімейство LPC1800 , з яких усі члени підтримують CAN.

— stevenvh
джерело

Я повністю забув про біти запуску / зупинки UART і, ймовірно, деякі ситуації з МОЖНОМУ "стартовим / топ бітом". Я, мабуть, спробую знайти рішення, використовуючи стек CAN на ПК, використовуючи FTDI як gpio, який в кінцевому підсумку передасть на MCP2551

— rnunes

@rnunes - це не лише біти старту / зупинки. Без таких передач UART - це лише 8-бітний байт. Повідомлення CAN набагато складніше: адресація, пріоритетність та перевірка помилок. Ви не можете порівняти два.

— stevenvh

Але використовуючи FTDI, я працюю побіжно (в основному це дуже швидкий USB <-> GPIO), а не байт за байтом, як у UART. Я вже шукаю ці CAN MCU, але я вважаю за краще витратити будь-які гроші зараз (це проект хобі студентів), і я вже маю FTDI. Якщо я закінчу з моїми дослідженнями, що FTDI не зможе цього зробити, я спробую використовувати CAN MCU.

— rnunes

Стек буде відповідати за обробку всього (наприклад, начинку бітів) та передавати його побітно в MCP2551. Єдина проблема, яка у мене зараз є, це затримка FTDI, тому що мені це потрібно, щоб вона була швидкою і регулярною, але я її виміряю пізніше.

— rnunes

@rnunes - Але те, що виходить із CP2102 (SiLabs, а не FTDI) - це байти , а не біти. Ви не можете зупинити його після одного шматочка. Вам знадобиться як CP2102 для інтерфейсу мікроконтролера з USB, так і мікроконтролера, який підтримує CAN + MCP2551. Або мікроконтролер, який також може виконувати роль USB-пристрою. Тоді вам не потрібен CP2102.

— stevenvh

Я зробив інтерфейс USB / CAN, використовуючи FT2232H в режимі MPSSE (забудьте UART), MCP2515 та MCP2551. MCP2515 - це ключовий твір, якого вам тут не вистачає. Навчіться добре, що це робить. Це власне контролер CAN, який робить обрамлення, ACK, генерацію і перевірку контрольної суми, фільтрацію повідомлень та інші менш очевидні речі, які потрібно зробити вузлом CAN стандартом. Якщо ви хочете sniffer, MCP2515 має режим лише прослуховування, який гарантує відсутність передач по шині. MCP2551 - це просто тупий адаптер фізичного рівня, подібний до MAX232 для RS-232 або ADM485 для RS-485.

Тепер ця архітектура далеко не досконала, оскільки технологія FTDI MPSSE по суті не підтримує перебоїв (я вважаю, що вона використовує лише масові USB-передачі за кадром), тому мені доводиться часто опитувати контролер на нові повідомлення. Це спричиняє велике навантаження на хост-контролер USB, але все ще не гарантує, що жодне повідомлення не буде втрачено (MCP2515 може зберігати до 2 отриманих повідомлень внутрішньо, якщо ввімкнути "режим переповнення", лише одне, якщо ви цього не зробите). Набагато кращим рішенням буде правильний мікроконтролер із вбудованою CAN та USB периферійними пристроями, такими як STM32F105 (103 не можуть одночасно використовувати USB та CAN). Дивіться у цьому проекті для робочої реалізації саме цієї ідеї. LPC18xx, як пропонує Stevenh, також буде працювати, але LPC17xx, ймовірно, дешевше і простіше знайти.

— Шип
джерело

У цьому випадку об'єднання об'єднань не є проблемою, але так, ідеальним рішенням буде використання MCU з контролером CAN, який працює як буфер повідомлення CAN. Відтепер я спробую використовувати першу установку, яку ви написали. Спасибі

— рнуни

+1 Використання мікросхеми FTDI для прямого спілкування з контролером CAN без ЦК є акуратним. Очевидно, FTDI вийшов FT221X, який є виділеним USB-мостом SPI. (Існує і інша модель для USB для I2C.)

— Нік Алексєєв

Оскільки ви хочете слухати наявну шину CAN, наскільки я розумію питання, ви дійсно не можете використовувати UART. CAN і UART підписання абсолютно різні.

Теоретично можна подивитися на лінію прийому CAN, що виходить з MCP2551, і декодувати трафік CAN. Це буде непросто, але теоретично це можливо. Без спеціалізованих апаратних засобів CAN вам доведеться вибирати вибірку в кілька разів швидше, ніж швидкість передачі бітів CAN, і пізніше декодувати цей потік бітів у програмному забезпеченні. Можливо, вам потрібно буде записати зі швидкістю близько 1 Мбіт / с, щоб декодувати CAN 250 кбіт / с.

Використовувати мікроконтролер буде набагато простіше. У процесорах PIC 18F2580 та інших подібних процесорах є вбудована периферія CAN. Апаратне забезпечення робить розрядний розрядний рівень і отримує цілі кадри CAN. Потім процесор може надсилати отримані кадри CAN через UART на ваш ПК.

— Олін Латроп
джерело