Является ли MCP2551 преобразователем UART-to-CAN?

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

ПК <-> USB-UART (возможно, CP2102, потому что у меня уже есть) <-> MCP2551 <-> шина CAN

Если нет, то какие сигналы должны поступить в MCP2551, чтобы я стал частью шины?

usb microchip can rnunes
источник

Ответы:

Вы можете сделать это, но то, что вы получите на своей шине CAN, будет UART с использованием уровней напряжения CAN. Вы должны предоставить MCP2551 сообщения протокола CAN, если вы хотите общаться с устройствами CAN на вашей шине. То же самое для прослушивания: сообщения CAN настолько отличаются от формата UART, что UART не знает, что с ними делать. У вас будут по крайней мере ошибки в кадре все время, и вы не получите содержание сообщения.
Это изображение показывает структуру сообщения CAN:

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

Есть много микроконтроллеров, которые имеют интерфейс CAN, без трансивера. Именно для этого был разработан MCP2551. В прошлом мы использовали NXP LPC2294, который имеет 4 интерфейса CAN. Каждому из них требуется MCP2551 для подключения к шине CAN. Более поздние контроллеры от NXP включают семейство LPC1800 , все члены которого поддерживают CAN.

stevenvh
источник

Я полностью забыл о битах пуска / останова UART и, возможно, о некоторых ситуациях «старта / старших битов» CAN. Я, вероятно, попытаюсь найти решение с использованием стека 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 должен делать по стандарту. Если вам нужен анализатор, MCP2515 имеет режим прослушивания, который гарантирует отсутствие передачи по шине. MCP2551 - это просто тупой адаптер физического уровня, похожий на MAX232 для RS-232 или ADM485 для RS-485.

Сейчас эта архитектура далека от совершенства, поскольку технология FTDI MPSSE практически не поддерживает прерывания (я полагаю, что она использует только массовые передачи USB за кулисами), поэтому мне приходится часто опрашивать контроллер на наличие новых сообщений. Это создает большую нагрузку на хост-контроллер USB, но, тем не менее, не гарантирует, что никакие сообщения не будут потеряны (MCP2515 может хранить до 2 полученных сообщений внутри, если вы включите «режим переполнения», только одно, если вы этого не сделаете). Гораздо лучшим решением был бы надлежащий микроконтроллер со встроенными периферийными устройствами CAN и USB, такими как STM32F105 (103 не может использовать USB и CAN одновременно). Посмотрите этот проект для рабочей реализации именно этой идеи. LPC18xx, предложенный Стивеном, тоже будет работать, но LPC17xx, вероятно, дешевле и его легче найти.

колючка
источник

В этом случае объединение не является проблемой, но да, идеальным решением было бы использование MCU с контроллером CAN, который работает как буфер сообщений CAN. Теперь я попытаюсь использовать первую настройку, которую вы написали. Спасибо

rnunes

+1 Использование чипа FTDI для прямой связи с CAN-контроллером без UC очень удобно. По всей видимости, вышел FTDI FT221X, который является выделенным мостом USB-SPI. (Есть и другая модель для USB к I2C.)

Ник Алексеев

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

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

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

Олин Латроп
источник