Вся информация про проекту тут
Всех приветствую! Наконец-то получилось написать загрузчик (бутлоадер) для узлов сети CAN для удаленной их прошивки. Узлы представляют собой МК Атмега + CAN модуль MCP2515. Строилась данная схема и тестировалась на связке атмега 328P с китайским модулем MCP2515. В контексте сети нужно понимать, что для осуществления удаленной прошивки узла по CAN сети нужно написать не только загрузчик , но и прошивку адаптера-прошивальщика USB<->UART<->CAN и часть пользовательской программы (скетч-заготовку) на узлах, отвечающую за обновление прошивки по сети.
Лет 5 назад уже получилось сделать подобное, но для сети RS485 , надеюсь найду время и создам тему по RS485 отдельно. Сейчас речь про CAN.
Программист из меня так себе , поэтому загрузчик пилился не с нуля , а переделывался из Optiboot 6.2
Работа всей этой городьбы происходит следующим образом. Заливка прошивки по протоколу STK500 из Arduino IDE это результат двустороннего обмена данными мастера и слейва . Поэтому в момент прошивки в CAN сети имеется “мастер” - это адаптер-прошивальщик, временно или постоянно подключенный к сети CAN, и “слейв” - целевой прошиваемый узел в сети, ну и ,само собой, остальные узлы сети, не участвующие в процессе. Адаптер-прошивальщик представляет собой ардуино проМини + конвертер USB<->UART + китайский CAN модуль MCP2515. про мини + USB<->UART_TTL взята связка не случайно, так как в такой схеме есть возможность поставить тумблер в разрыв линии DTR между конвертером USB-UART и пином DTR ардуины (ресет). То есть когда тумблер замкнут - мы можем обновить прошивку самого адаптера-прошивальщика, когда тумблер разомкнут - в момент нажатия прошивки с ардуино ИДЕ - ресет адаптера-прошивальщика не происходит, и его скетч транслирует байты протокола STK500 arduino IDE в CAN. То есть взаимодействие с адаптером-прошивальщиком со стороны ПК происходит через терминал ардуино IDE. Собственно, вся схема и строилась так , чтобы привычным образом прошивать нужный узел сети из под родной среды ардуино IDE “на лету”. В терминале выбираем нужный узел сети, этот узел переходит в режим ожидания прошивки и возвращает “систем-инфо”, в соответствии с этой информацией (частота кварца, модель МК) мы сверяемся при выборе типа платы в ардуино IDE, также “систем инфо” говорит нам, что нужный нам узел готов к прошивке, что, в свою очередь, переводит уже адаптер-прошивальщик в режим прошивки. Далее мы выбираем соответствующий скетч и нажимаем привычную кнопку “прошить” в IDE, после чего нужный нам узел прошивается по сети CAN. Если прошивка не начинается, узел и адаптер-прошивальщик по таймауту выходят из режима ожидания прошивки. Таким образом, у адаптера-прошвальщика два режима “SettingMode” и “ReflashingMode”. В “SettingMode” адаптер позволяет общаться через терминал , выполняя предварительные настройки. В режиме “ReflashingMode” любые данные из терминала будут транслироваться в CAN, поэтому в этом режиме через терминал уже ничего не работает, а адаптер ждет начала протокола обмена прошивки от Arduino IDE. если в этот момент не нажали кнопку прошить, а продолжили что-то настративать через терминал, адаптер это распознает и выйдет из режима “ReflashingMode”, включив режим “SettingMode” . Также режим “ReflashingMode” можно принудительно включить (без получения отчета от узла ,что он готов к прошивке), например это нужно, когда скетч в узел ещё не залит. но CAN-бутлоадер уже там есть.
Рабочий протокол обмена в вашей CAN сети может быть как c расширенными 29-битными ID так и со стандартными 11-битными. Удаленная прошивка по сети же происходит по 11-битным CAN сообщениям. Мастер имеет ID 0x000. Слейв 0x001. эти ID можно поменять , но такие выбраны не случайно. чем меньше ID по значению, тем больше у него приоритет , также 11-битные имеют бОльший приоритет чем 29-битные. Поэтому даже в рабочем трафике CAN сети прошивка будет происходить стабильно.
Сама логика до ужаса простая. В процессе прошивки адаптер-прошивальщик получает из UART данные от Arduino IDE в соответствии с ее родным протоколом STK500, никак их не обрабатывая, просто транслирует в CAN. То есть каждый байт протокола STK500 в шине CAN - это отдельный CAN фрейм с ID 0x000 (если это адаптер-прошивальщик) или с 0х001 (если это ответ прошиваемого пациента “слейва”). поле данных этих фреймов (DLC) имеет 2 байта . Нулевой байт в этих CAN фреймах и мастера и слейва - это целевой адрес узла. То есть в сообщениях и мастера и слейва этот байт одинаковый - адрес прошиваемого узла. ну и еще один байт - первый (а всего их ,соответственно, два) - это сам очередной байт протокола STK500. В момент прошивки аппаратные фильтры приёма CAN фреймов мастера и слейва настроены друг на друга , таким образом, остальные прилетающие из шины сообщения отсекаются и рабочий трафик сети поэтому не мешает процессу прошивки.
До начала прошивки, само собой, через терминал мастера-прошивальщика выбирается адрес прошиваемого узла (таргет). выбор сделан дружелюбно. Перед вами в терминале список всех узлов сети, копипастом вы вбиваете ИМЯ узла в строку терминала и отправляете мастеру прошивальщику и на экране терминала видите реакцию целевого узла о готовности начать прошивку. Скетч узла рекомендовано называть также как имя узла. Тем самым не нужно будет каждый раз сверяться правильно ли я выбрал адрес узла и/или скетч, работа с именем узла сильно упрощает эту процедуру и минимизирует ошибки. Само собой адрес узла тоже на экране будет присутствовать.
Также через терминал настраивается скорость CAN самого мастера-прошивальщика, частота кварца его CAN модуля, ну и настраивается режим “тихого окна” узлов в сети на момент прошивки. При выборе этого режима , все узлы сети отчитываются, что режим включен/выключен, (это видно в терминале мастера адаптера-прошивальщика) и сохраняют эту настройку у себя в еепром , так что каждый раз включать не нужно, эта настройка энергонезависима и сохранится после перевключения питания узлов . Само “тихое окно” (при включенном этом режиме) автоматически активируется только в момент непосредственно прошивки и деактивируется по ее окончании . В режиме “тихого окна” все узлы сети, кроме мастера(адаптера-прошивальщика) и слейва (прошиваемого узла) , не обмениваются никакими CAN сообщениями, сообщения они не отправляют, а принимают аппаратно только одно сообщение от прошиваемого узла - “конец прошивки”. Как только такое сообщение получено - “тихое окно” деактивируется (но настройка его опять активировать при следующей прошивке какого-либо узла сохранена). Если же в режиме “тихого окна” не получено сообщения “конец прошивки”, оно деактивируется по таймауту.
Скетчи-заготовки всех узлов сети имеют часть кода, отвечающую за функционирование такой схемы удаленной прошивки, в состав скетча прилагается файл NodesDetails.h который необходимо заполнить в соответствии с вашей схемой CAN сети, и скопировать этот файл в папки скетчей всех узлов сети (заменить имеющиеся в них файлы NodesDetails.h). этот файл должен быть одинаковый для всех участников сети. В файле пишется список узлов сети, их адреса и имена. Скорость CAN сети , ну и некоторые другие настройки.
По поводу скорости CAN и UART. Я протестировал на скорости CAN 125, 200, 250, 500. Скорость UART должна коррелировать со скоростью CAN. Например на скорости CAN 125кбит/с прошивка не зальется при скорости UART 115200. Вообще при UART выше 38400 уже не стабильно прошивка заливается даже на 500кбит/с CAN. Самое оптимальное CAN 200кбит/с UART 19200 . да, не очень быстро, но куда спешить, зато стабильно. CAN делать выше 200кбит/с тоже такое себе, все таки у вас вряд ли это будет автомобиль, и расстояния будут побольше , поэтому 500кбит/с точно не катит. 125кбит/с уже маловато для стабильного залития прошивки, хотя при 9600 UART, думаю, будет стабильно.
Свой адрес узла скетч и бутлоадер каждого узла считывает из ЕЕПРОМ. Поэтому после заливки бутлоадера в узел, нужно в соответствующую ячейку ЕЕПРОМ положить соответствующий адрес этого узла. Я делаю это программатором, который и флеш и еепром заливает. поэтому заливаю бутлоадер , потом еепром с адресом. Бутлоадер можно взять готовый хекс, я скомпилирую разные варианты и положу в папку , либо же собрать под себя какой нужно . по поводу сборки потом отдельно напишу.
Бутлодадер имеет размер 4кб, поэтому нужно в ваших узлах фьюзами это настроить.
Оставлю в этом сообщении вверху ссылку на облачную папку, в ней будет актуальная информация по проекту, позже это сообщение будет отредактировать уже нельзя, поэтому читайте актуальную информацию и описание по ссылке (в эту облачную папку). Также в облачной папке присутствуют, скетчи, бутлоадер, схема прошивальщика , а чуть позже будет видео процесса.
Достойная работа, поправить бы описание, читать сложно, отступы, абзацы не более 5-7 строк.
Бутлоадер в чём компилировал?
По компиляции бутлоадера подробно позже напишу. Если кратко - делал компилятором gcc Ардуино Иде через командную строку. Потом скину уже настроенную на это дело портабл Иде.
По поводу красных строк , чето да , копипастом из текстового файла они не перенеслись. А щас уже не даёт поправить . (
А на гит нет возможность запостить?
может админы поправят
Можно узнать цель данного проекта. Как известно данная шина используется в автомобилях. Сеть узлов в метре друг от друга. Обновлять эти узлы по сети у вас просто нет для них пошивок, да м зачем, если это не сервис производителя. А на сервисе свои инструменты. Делать собственные изделия с обменом по шине CAN ну так себе идея, учитывая что уже аппаратно сейчас по СОМ порту можно передавать со скоростью 2 мбит на расстояние до 100 метров (тоже самое с конвертором 485 до километра). А у CAN на 1мбит до 40 метров всего то. Хочется спросить у ТС зачем все эти мытарства с “удалённой” прошивкой? Лучше бы вы потратили своё время (если у вас его дохрена) и разжевали так проект с автоматической удалённой прошивкой для ESP32, которая была бы выложена на общедоступном севаке, к которому стучатся ваши девайсы и если находят обновления, то автоматом обновляют своё ПО, а после перезагружаются. Вот это была бы польза общественности (с тестовыми примерами конечно). А так вы запилили проект, который похоже нужен только вам и возможно заказчику (которому совсем не важно как вы будете обновлять прошивки) Так скажите где будет работать данный проект лично у вас, или это просто захотелось?
классный проект, особенно если устройств много, к примеру миллион, тогда точно найдутся желающие заломать сайт, закинуть туда прошивку и,
миллион устройств превратить в …тыкву…
Вопрос безопасности всегда будет на 1 месте, но ни кто не сломал например производителей банковских терминалов. Как то они работают и обновляются автоматом.
это вы не владеете информацией, на каком-то хакерском форуме притащили банкомат и показали
Да, и преимущественно в “жигулях”
автотаз “родил” лимузин длиной 40 удавов?
Опять все сваливается к вопросам почему CAN. Цель такая: CAN шина нормально работает на расстояниях больше чем в автомобилях. Преимущество CAN шины для меня в том, что она надежная (я не очень люблю по радиоканалу). сначала использовал RS485, но это геморройный вариант в плане, что надо кучу стека писать для организации протокола обмена (канальный уровень) . К тому же на RS485 в обычном варианте приходится делать один мастер, остальные слейвы и постоянно их опрашивать. CAN сеть мультимастерная , когда хочешь - плюнул сообщение в шину . Формирование кадров , арбитраж - аппаратно делается, так что не тратим на это время и работаем сразу с протоколом более высокого уровня. Но вот был минус, что проблема была прошить узел по CAN. Таким образом , я попытался решить эту проблему. Если проект никому не будет интересен - сделал нормальное описание в т.ч. для себя , так как иногда приходится к этому возвращаться , а через некоторое время уже сам ничего не помнишь. Вот теперь в облаке это будет , и не зависеть от потери данных на ПК.
Про банкоматы я не говорил. Я говорил про терминалы (карты), именно их, производители, обновляют дистанционно, размещая прошивку на своих серверах. Естественно, владелец должен поставить галочку в настройке терминала - обновлять автоматически.
в папку добавил кино. Ну то есть видеоописание проекта (лучше скачивать видео), а то если из папки открываешь, качество так себе
Это единственное, для чего CAN и был придуман.
И используется он не только в “жигулях” )))
Опять же, присоединюсь к вопросу:
Тем более, что яндекс-диск скоро станет совсем платным ))
про гит. блин я деревянный в этом вопросе. пока так. Позже изучу , наверное выложу. Или если кто готов с этим посодействовать, пишите
Или хотя-бы гугл диск.
Сейчас все плавно деградирует в плане IT в РФ.
да, позже закину на гугл.
Отлично, что довел до конца.
Добавлю, что стандартных скоростей две: 125 в автоиндустрии и 250 в морской (NMEA 2000).
Только один вопрос о форме публикации - почему не гитХабе не выложить? С readme.md на двух языках. Такие вещи весьма востребованы, уверен, что будет много благодарных.
одна простая причина - я не умею)) . надо, да , с этим гит разобраться и выложить. Может это и не сложно, но время надо потратить все равно. найду время - сделаю обязательно