Я думаю, что реализовать протокол 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. текущий бит, который вы отправляете, равен 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 просто работает. Судя по вашему комментарию, дополнительная стоимость этого периферийного устройства составляет 0,56 доллара США. Мне это кажется выгодной сделкой. Если у вас нет продукта очень большого объема, вы не сможете вернуть значительное время и затраты, которые потребуются для реализации CAN только в прошивке. Если ваши объемы настолько высоки, цены, которые мы упоминали, в любом случае нереалистичны, и разница в добавлении оборудования CAN будет ниже.

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

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

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

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

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

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

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

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

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