Реализация уровня протокола CAN в программном обеспечении

12

Фон

Я разрабатываю проект, который потребует скромных спецификаций микроконтроллера:

  • 8 12-битных, 10 кГц АЦП
  • 1 КБ ОЗУ
  • 48-QFN или меньше
  • Устойчивый к помехам и защищающий от ошибок протокол связи со скоростью 20 кбит / с

Требования к обработке сигналов довольно низкие, и большинство из них можно экспортировать в главный процессор в системе. Первые три спецификации легко встретить, и их можно сделать менее чем за 2 доллара. Тем не менее, связь будет происходить в очень электрически шумной среде, поэтому уязвимые к шуму сети, такие как LIN и I2C, отсутствуют. Дополнительным аргументом против LIN является то, что я хотел бы использовать все это при 5 В или 3,3 В, а для приемопередатчиков LIN требуется 12 В, и поэтому потребовался бы дополнительный регулятор или провод на плату датчика. Я изначально выбрал CAN для этой задачи. Тем не менее, CAN-контроллеры требуют значительных затрат, и мне любопытно, можно ли это сделать программно.

CAN физический уровень

Спецификация CAN определяет Канальный и Физический уровни эталонной модели сети OSI. Существует множество недорогих 8-контактных ИС, таких как NXP TJA1040 / 50 , Maxim MAX3058 / 59 , Microchip MCP2551 и TI SN65HVD1050, для реализации физического уровня. Реализация физического уровня с помощью цифро-аналоговых преобразователей или операционных усилителей была бы сложной, если не невозможной, поэтому эти микросхемы вполне стоят $ 1 или около того, что они стоят.

Канал передачи данных / уровень протокола

Для уровня Data Link некоторые микроконтроллеры добавляют модули протокола CAN на базовые уровни связи UART, I2C и SPI. Однако они значительно дороже, чем базовые чипы.

Исследование стоимости модулей протокола CAN

Чтобы подтвердить это утверждение, вот несколько популярных микросхем в версиях CAN и не-CAN, из:

  • ATmega16 - ATMEGA16M1 (с CAN): 3,87 долл. США, ATMEGA168A (без CAN): 3,23 долл. США
  • dsPIC - DSPIC33FJ64MC802 (с CAN): 6,14 $, DSPIC33FJ64GP202 (без CAN): 5,48 $
  • PIC18 - PIC18F2480 (с CAN): $ 6,80, PIC18F24J10 (без CAN): 2,10 $
  • Cortex-M3 - STM32F103C4T6A (с CAN): $ 6,50, STM32F100C4T6B (без CAN): $ 2,73

Честно говоря, я сравнивал только микроконтроллеры с эквивалентными объемами памяти, однако многие версии, отличные от CAN, доступны с меньшим объемом памяти за меньшие деньги. Внешние CAN-контроллеры, такие как Microchip MCP2515 , стоят почти 2 доллара, поэтому, если у вас есть такая возможность, очевидно, что экономически выгоднее интегрировать CAN в микроконтроллер.

Интересно, что часть ATmega на сегодняшний день является самой дешевой, оснащенной CAN частью в инвентаре Digikey.

Функция уровня протокола CAN

Модуль CAN, обнаруженный в микроконтроллерах dsPIC, выполняет следующие действия:

Модуль шины CAN состоит из механизма протоколов и буферизации / управления сообщениями. Механизм протокола CAN обрабатывает все функции для приема и передачи сообщений по шине CAN. Сообщения передаются при первой загрузке соответствующих регистров данных. Состояние и ошибки можно проверить, прочитав соответствующие регистры. Любое сообщение, обнаруженное на шине CAN, проверяется на наличие ошибок, а затем сопоставляется с фильтрами, чтобы определить, должно ли оно быть получено и сохранено в одном из регистров приема.

Это кажется вполне выполнимым в программном обеспечении.

Вопрос

Можно ли использовать уровень программного протокола для реализации спецификации CAN только с недорогим микроконтроллером, оборудованным UART, и с трансивером CAN? Если да, существуют ли какие-либо реализации с открытым исходным кодом?

В качестве альтернативы, могут ли трансиверы CAN использоваться с UART для реализации собственного протокола? Я в порядке с топологией с одним мастером; Я понимаю, что арбитраж может быть трудно получить право в пользовательском протоколе.

Кевин Вермеер
источник
CAN тоже 12В, так как он был разработан для автомобильного использования.
Кенни
@Kenny - уровни напряжения, используемые на вышеприведенных трансиверах, составляют 5 В.
Кевин Вермеер
Если вы собираетесь рассмотреть серию STM32F, могу ли я также предложить эту часть NXP? Это ядро ​​Cortex-M0. search.digikey.com/scripts/DkSearch/…
Джон Л
@Jon - Это не обязательно рассматривалось, и M0 был бы идеальным для этого случая использования. Однако, рассмотрим части Nuvoton M052LAN , также Cortex-M0, и примерно половину цены в количестве ($ 1,21 против $ 2,35), но не имеет модуля CAN. Такая разница в цене - моя мотивация.
Кевин Вермеер
Вы можете также рассмотреть операционный рейтинг. Большинство деталей с поддержкой CAN будет промышленным или автомобильным, а не коммерческим вариантом.
Марк

Ответы:

11

Я думаю, что реализация протокола CAN в микропрограммном обеспечении будет сложной и займет некоторое время, чтобы получить права. Это не очень хорошая идея.

Тем не менее, ваши цены высоки. Я только что проверил, и dsPIC 33FJ64GP802 в пакете QFN продается за 3,68 доллара США на microchipdirect за 1000 штук. Цена будет ниже для реальных объемов производства.

Аппаратная периферия CAN делает некоторые реальные вещи для вас, и прирост цены на нее далеко не соответствует тому, на что вы претендуете.

Добавлено:

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

Вы хотите сделать CAN на скорости 20 кбит / с. Это очень медленная скорость для CAN, которая достигает 1 Мбит / с как минимум на 10 секунд. Чтобы дать вам одно назначение данных, стандарт передачи сигналов на борту судна NMEA 2000 наложен на CAN со скоростью 200 кбит / с, и он предназначен для перехода от одного конца большого корабля к другому.

Вы можете думать, что все, что вам нужно, это одно прерывание на бит, и вы можете делать все, что вам нужно, в этом прерывании. Это не сработает, потому что в каждый бит CAN происходит несколько вещей. Две вещи, в частности, должны быть выполнены на суббитовом уровне. Первый - обнаружение столкновения, а второй - регулировка скорости передачи данных на лету.

На шине CAN имеется два сигнальных состояния: рецессивное и доминантное. Рецессивный - это то, что происходит, когда в автобусе ничего не водится. Обе линии собраны вместе на 60 Ом. Обычная шина CAN, реализованная обычными микросхемами, такими как MCP2551, должна иметь терминаторы 120 Ом на обоих концах, следовательно, в общей сложности 60 Ом пассивно объединяет две дифференциальные линии. Доминирующее состояние - когда обе линии активно разрываются, где-то в 900 мВ от рецессивного состояния, если я правильно помню. По сути, это похоже на шину с открытым коллектором, за исключением того, что она реализована с помощью дифференциальной пары. Шина находится в рецессивном состоянии, если CANH-CANL <900 мВ, и доминирует, когда CANH-CANL> 900 мВ. Доминирующее состояние сигнализирует 0, а рецессивный - 1.

Всякий раз, когда узел «записывает» 1 в шину (отпускает), он проверяет, записывает ли какой-либо другой узел значение 0. Когда вы находите шину в доминирующем состоянии (0), когда вы думаете, что отправляете, и текущий бит, который вы отправляете, равен 1, то это означает, что кто-то другой отправляет тоже. Столкновения имеют значение только тогда, когда два отправителя не согласны, и правило заключается в том, что отправитель рецессивного состояния отменяет и прерывает свое сообщение. Узел, отправляющий доминирующее состояние, даже не знает, что это произошло. Так работает арбитраж на шине CAN.

Правила арбитража по шине CAN означают, что вы должны наблюдать за шиной на полпути через каждый бит, который вы отправляете как 1, чтобы убедиться, что кто-то еще не отправляет 0. Этот тест обычно выполняется на 2/3 пути в бит. и является основным ограничением длины шины CAN. Чем медленнее скорость передачи битов, тем больше времени для распространения в худшем случае от одного конца шины к другому, и, следовательно, тем длиннее может быть шина. Эта проверка должна выполняться каждый раз, когда вы думаете, что владеете шиной и отправляете 1 бит.

Другая проблема - регулировка скорости передачи. Все узлы на шине должны согласовывать скорость передачи данных, более тесно, чем с RS-232. Чтобы небольшие разности тактовых импульсов не накапливались в значительные ошибки, каждый узел должен иметь возможность делать бит немного длиннее или короче своего номинала. В аппаратном плане это реализуется путем запуска тактовой частоты примерно в 9–20 раз быстрее, чем скорость передачи данных. Циклы этих быстрых часов называются квантами времени. Есть способы обнаружить, что начало новых битов зависит от того, где вы думаете, что они должны быть. Затем аппаратные реализации добавляют или пропускают один раз кванты для повторной синхронизации. Есть и другие способы реализовать это, если вы можете настроить на небольшие различия в фазе между ожидаемым битовым временем и фактическим измеренным битовым временем.

В любом случае, эти механизмы требуют, чтобы разные вещи выполнялись в разное время в течение некоторого времени. Такой тип синхронизации будет очень сложным в прошивке или потребует очень медленной работы шины. Допустим, в прошивке реализована система временных квантов со скоростью 20 кбит / с. Как минимум 9 временных квантов на бит, для этого потребуется прерывание 180 кГц. Это, конечно, возможно с чем-то вроде dsPIC 33F, но потребляет значительную часть процессора. При максимальной частоте инструкций 40 МГц вы получаете 222 цикла инструкций за прерывание. Это не займет много времени, чтобы выполнить всю проверку, но, вероятно, 50-100 циклов, то есть 25-50% процессора будет использоваться для CAN, и что ему нужно будет выгружать все остальное, что работает. Это мешает многим приложениям, которые эти процессоры часто запускают, как импульсное управление импульсным источником питания или драйвером двигателя. Задержка цикла 50-100 на каждом другом прерывании была бы полной остановкой показа для многих вещей, которые я сделал с подобными чипами.

Таким образом, вы собираетесь потратить деньги, чтобы сделать CAN как-то. Если не в выделенном аппаратном периферийном устройстве, предназначенном для этой цели, то при получении более крупного процессора для обработки значительных накладных расходов микропрограммного обеспечения, а затем устранения непредсказуемой и возможной большой задержки прерывания для всего остального.

Тогда есть передовая разработка. Периферийное устройство CAN просто работает. Из вашего комментария кажется, что дополнительная стоимость этого периферийного устройства составляет $ .56. Это похоже на сделку для меня. Если у вас нет продукта с очень большими объемами, вы не сможете вернуть значительные затраты времени и средств, которые потребуются для внедрения CAN только в прошивку. Если ваши объемы настолько высоки, цены, о которых мы говорили, в любом случае нереалистичны, и разница в добавлении оборудования CAN будет ниже.

Я действительно не вижу в этом смысла.

Олин Латроп
источник
Я ценю ваше мнение, но мне любопытно, почему никто не пытался обойти трудности - у каждого проекта будут такие проблемы! Я дам вам знать, как это получится, если я в итоге попробую.
Кевин Вермеер
В количестве 1000 я нахожу цену $ 3,12 для dsPIC33FJ64GP202 от microchipdirect - общая разница в стоимости составляет 560 долларов! По крайней мере, стоит попробовать. Я указывал цены на каждую из них просто потому, что было проще получить номера для отдельных изделий, не беспокоясь о размотке, стандартном количестве упаковки и т. Д.
Кевин Вермеер,
2
@Kevin, низкие цены не всегда пропорциональны высоким ценам. Я не знаю, сколько из этих вещей вы планируете сделать, но 560 долларов не начнут платить за разработку CAN в прошивке. Я добавлю, чтобы ответить, объясняя некоторые трудности, с которыми вы столкнетесь.
Олин Латроп
WTF !? Я просто добавил кое-что к своему ответу, и большая часть разрыва абзаца ушла. В окне редактирования, в котором я печатал, были определенно пустые строки.
Олин Латроп
1
Ответ - да, вы можете, но я полностью согласен с Олином здесь. Я на самом деле работаю полный рабочий день в этой области. Я использую чип dsPIC33FJ256. Время, затрачиваемое на то, чтобы писать вещи, используя подход «бит-бэнг», сводит на нет ценовое преимущество, заключающееся в том, что аппаратное обеспечение делает это за вас, а вы заново изобретаете колесо. Не говоря уже о том, что все, что вы делаете в оборудовании, должно быть тщательно спланировано. Кроме того, мне интересно, ищете ли вы другие высокоуровневые протоколы, такие как ISO14229 или OSEK / Autosar NetworkManagement?
Эрик М
2

Мы используем PIC18F25K80 . Хотя у него нет DSP, его количество составляет около $ 2. Это почти прямая замена упомянутого вами PIC18F2480. Мы используем компилятор CCS и их программный стек для CAN, который, вероятно, перенесен с Microchip. Это хорошо работает для всего, что мне нужно и пытался.

Kenny
источник
Не искал ECAN. Глупое имя Микрочипа, но в следующий раз мне придется более внимательно прочитать! Как я уже сказал, мои потребности в обработке сигналов низкие, поэтому я не думаю, что мне нужен настоящий DSP.
Кевин Вермеер
2

Если я правильно понял, это звучит так, как будто вы хотите использовать битовую функциональность CAN, используя только UART и некоторые умные прошивки. Поверьте мне, это никогда не сработает - я предлагаю прочитать хороший текст о тонкостях CAN или CANopen. Пройдя по этому маршруту, вы искорените любую экономию средств, которую вы ищете.

Я бы либо использовал микроконтроллер с модулем CAN и передал лишние 2 доллара, либо вы думали о другом протоколе, совместимом с UART, таком как Modbus через RS-485 ?

BullBoyShoes
источник
Вы читаете это правильно. Я полностью прочитал учебный буклет Vector по CAN. Похоже, что каждое сообщение будет нуждаться в некоторой предварительной обработке для CRC, но остальная часть пакета должна быть одинаковой, и мне просто нужно будет постоянно проверять строку приема на наличие конфликта. Это на самом деле не так сложно, как думают люди, но я обязательно приму к сведению ваш совет.
Кевин Вермеер
Мне все же нравится идея Modbus поверх RS485. Похоже, что большинство из этих трансиверов также питаются от 5В; У меня сложилось впечатление, что для него требуется входное напряжение +/-, как у RS232. Придется разобраться в этом.
Кевин Вермеер
немного ударяется, безусловно, будет работать! Это не тривиально, как упоминает Олин выше, но может быть сделано. Я лично справился с этим как на серии PIC18F, так и на серии dsPIC33 micro. Я могу загрузить исходный код PIC18F, если вы действительно хотите его увидеть. Однако я не могу выдать исходный код dsPIC, поскольку он является частью коммерческого проекта, над которым я работаю. В обоих случаях мы используем MCP2551, и у меня также есть код LIN. LIN немного проще на уровне протокола, но реализация расписаний LIN немного сложнее ...
Эрик М
1
@EricM - Какова была скорость передачи данных, и удалось ли вам реализовать полную спецификацию CAN в программном обеспечении? Я люблю , чтобы увидеть код PIC18F для этого.
Ракетный магнит
Да, реализована полная спецификация CAN, чтобы не дублировать модуль ECAN в dsPIC, который заботится о многих аспектах. В реализации PIC18 я разбил шину на полную спецификацию и позже, и этот код будет работать на dsPIC, использующем линии GPIO. Я обновлю через несколько дней ссылку на код.
Eric M
0

Я также думаю о битовом протоколе CAN на PIC µC, поэтому, пожалуйста, EricM, если вы действительно это сделали, ответьте и, по крайней мере, скажите, какой битрейт на какой частоте ядра у PIC18F или DSPic вы получили. Спасибо!

В целом: RS 485 будет решением основной заданной проблемы, но также будет возможно использовать приемопередатчики CAN (или даже FlexRay) с не полнодуплексной связью UART (точка 2) в качестве всех этих протоколов. используйте NRZ-кодирование.

Но в UART / V24 / RS232 полнодуплексный режим в основном используется, не задумываясь о деталях, поэтому, возможно, вам понадобится приложить некоторые усилия к суперциклу или машине состояний вашего приложения ...

Но вернемся к CAN-bitbanging: я работаю с CAN в течение многих лет и никогда не видел реализации bitbanging, но, насколько я могу судить, это должно работать для синхронизации битов до 100kBit с современными микроконтроллерами, такими как DSPic или ARM и т. Д. (с ядрами на 80 МГц или выше ...)

По крайней мере, если рассматривается только обратное чтение ... Отправка будет означать некоторые издержки при подготовке битовых структур, так что не будет достигнута 100% -ная нагрузка на шину, но в CAN более 65% встречается редко ...

roby111
источник
2
Добро пожаловать в Электротехнику StackExchange. Первая часть вашего ответа на самом деле совсем не является ответом, поэтому вы задаете новый вопрос, если вы этого хотите. ОП спросил конкретно о программной реализации протокола CAN, и ваш ответ, кажется, блуждает без ответа на этот вопрос; пожалуйста, попробуйте остаться в теме вопроса.
Джо Хасс