Внедрение уровня протокола CAN в программном обеспечении

Фон

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

  • 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 доллара или около того, что они стоят.

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

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

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

Чтобы обосновать это утверждение, вот несколько популярных микрофонов в версиях CAN и non-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 для реализации пользовательского протокола? Я в порядке с топологией с одним мастером; Я понимаю, что арбитраж может оказаться трудным для правильного использования в пользовательском протоколе.

12 голосов | спросил Kevin Vermeer 12 PM00000090000000631 2011, 21:26:06

4 ответа


11

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

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

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

Добавлено:

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

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

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

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

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

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

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

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

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

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

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

ответил Olin Lathrop 12 PM000000100000004231 2011, 22:19:42
2

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

ответил kenny 12 PM00000090000004531 2011, 21:43:45
2

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

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

ответил BullBoyShoes 12 PM000000110000004831 2011, 23:57:48
0

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

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

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

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

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

ответил roby111 30 62013vEurope/Moscow11bEurope/MoscowSat, 30 Nov 2013 23:27:30 +0400 2013, 23:27:30

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132