Фон

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

• 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 в микропрограммном обеспечении будет сложной и займет некоторое время, чтобы получить права. Это не очень хорошая идея.

Тем не менее, ваши цены высоки. Я только что проверил, и 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 будет ниже.

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

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

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

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

Я также думаю о битовом протоколе 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% встречается редко ...