Arduino.ru

не совсем ясно что вы хотите прошивать... MCP2515 через Ардуино или Ардуино через MCP2515 ? 

MCP2515 сложно прошить... разве что парой киловольт наскрозь.

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

Хочет по доступному каналу (CAN) прошивку в ардуине обновлять.

Обновлять можно по любому интерфейсу. Для этого нужно ДВЕ вещи:

1. написать соотв. бутлоадер (как вариант - заказать одному из програмистов форума, можно и мне, но я всегда предупреждаю о собственной ненадежности: мне может стать лень)

2. сделать доступным Ресет. Мега переходит в режим бутлоадера только по ресет. Это уже зависит от фантазии автора,: провод или саморесет аппаратный ;).

дак вот поэтому я и предложил рядом ещё одну атмегу. Она и ресет сделает и основную дуню прошьет. (только как прроще ISP или UART?) Прошивку в данном варианте лучше наверное промежуточно на СД карту писать?

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

со стороны компа тоже беда, Дуня должна прикинуться как будто её прошивают. а на самом деле всё в CAN отправлять. (возможно также через промежуточную СД). Просто не хотелось бы , конечно, своё ПО на компе для этого писать , да и не умею. В таком варианте вроде как из под ИДЕ можно. 

Мда, Огород конечно ещё тот 

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

А от узлов до центра большое расстояние? Нет вариантов просто по отдельному хвосту для перепрошивки вывести?

5 объектов на расстоянии по 5-20 метров (загородный дом с баней ,  гаражом, гостевым (старым) домом). В каждом объекте тоже планируется по нескольку модулей на разных этажах и комнатах. 

провода уже в общемто прокинуты. Добавить очень сложно будет, а Wi-Fi НЕ очень хорошо на таких расстояниях, повторители надо ставить и т.д.

Тут уже всплывала тема про перешивку по GPRS-каналу. Суть та же: принятые данные типа "прошивка" надо где-то накопить (хоть в I2C епромке), научить бутлоадер смотреть в EEPROM и если там что-то есть новое - шить. 

не знаю что проще, освоить написание бутлоадера или поставиить дополнительный МК на узле для обновления ПО

заказал три адаптера SD карты.

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

2. буду учиться получать доступ (хотя бы записывать файл на карту) к файлам, карты памяти, подключеной к ардуино, которая по усб подключена к компу 

3. Буду учиться пересылать  файл с одной ардуино с сд картой на другую с сд картой по CAN  шине. 

У кого есть опыт в этих вопросах, буду признателен любой инфе или ссылкам. 

Тему забросил. Но недавно научился обновлять прошивку атмеги по rs485. Хочу все же научиться и по CAN прошивать. Немного разобрался как вообще происходит заливка прошивки по протоколу stk500 и как работает bootloader. И пришло понимание, что, действительно, самое здравое решение по теме это написание своего загрузчика, чтобы без всякого промежуточного хранения прошивки на SD карте - просто нажал "залить прошивку" из под arduino IDE и по CAN в онлайне прям заливать. Естественно перед этим выбрав через терминал номер прошиваемого контроллера на шине. Ну я конечно не осилю полностью написать загрузчик. Хочу сделать на базе оптибута.
Там всего то придётся поменять две функции getch () и putch(), с помощью которых обмен байтами будет происходить не по UART, а по CAN.
Собственно вопрос. Компилятор оптибута даёт собрать размер загрузчика максимум 1кб. У меня же с настройкой CAN модуля будет больше. Максимальный загрузчик на атмегу 328, я так понял 4кб, что выставляется в highFuse. В каком компиляторе я могу собрать загрузчик 4кб? Атмел студию ещё не юзал, там есть такая возможность?

Жаль никто не отвечает. Для начала (без правки бутлоадера)  попробовал просто через CAN залить прошивку через две ардуины через два шлюза: UART в CAN и обратно.  Думаю если скорость загрузчика сделать 19200, то скорости CAN 125 кбит/с хватит.

USB<->UART------------UART<->CAN--------CAN<->UART---------UART

   СH340                      PROMINI(шлюз)          UNO(шлюз)         PROMINI   

Всё работает, но скорость бутлоадера если 57600 бод, то CAN должен быть на скорости 500кбит/с. Полный скетч 32 кБ десять раз из десяти отлично загружается. При CAN 250кбит/с уже не заливается. Пробовал по схеме каждый байт это отдельный фрейм и по другой схеме -   8 байт накапливает и только тогда фрейм по 8 байт отправляет, и так и так при 250 кбит/с  НЕ работает. На 500кбит/с и так и так работает.

скетч шлюзов 

#include <SPI.h>
#include <mcp2515.h>

struct can_frame canMsg;
struct can_frame canMsg1;
MCP2515 mcp2515(10);


void setup() {
  Serial.begin(57600);
  SPI.begin();
  canMsg1.can_dlc = 8; 
  canMsg1.can_id = 05;
  
  mcp2515.reset();
  mcp2515.setBitrate(CAN_500KBPS, MCP_8MHZ);
  mcp2515.setNormalMode();
  
  
}

void loop() {
  byte count = 0; 
  while (Serial.available()) {count++; if (count>8) break; canMsg1.data[count-1] = Serial.read(); }
  if (count!=0) {canMsg1.can_dlc = count; mcp2515.sendMessage(&canMsg1);}
  
  
  if (mcp2515.readMessage(&canMsg) == MCP2515::ERROR_OK) {
    if (canMsg.can_id==5) Serial.write(canMsg.data, canMsg.can_dlc); 

}}

а ниже скетч той ардуины которую прошиваем

void setup() 
{
Serial.begin (57600);
Serial.println ("Start");
pinMode(13, OUTPUT);
}

void loop() 
{
  if (Serial.available() && Serial.read()==' '){cli(); ((void (*)(void)) 0x3F00)();} // переход на bootloader (вместо сигнала DTR и аппаратного ресета)
  static uint32_t prev = 0;
  if (millis() - prev >500) {prev = millis(); digitalWrite(13, !digitalRead(13));}
}

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

Не броадкастом не будут все прошиваться, исключено. Все прописано в id будет. Ну вот и хотел совета получить как лучше сделать. Буфер в каком месте делать?

Классический вариант - на стороне приемника. Посмотрим, например, как OTA реализован в ESPxx - часть флеш-памяти отдается под временный буфер. Туда аплоадится прошивка. После аплоада система делает вывод - удачно ли произошла загрузка. По хешу или как-то иначе - не знаю, но триггер есть - OK/FAIL. Если OK, то запускается процесс переноса данных из области временного буфера в область, где хранится программный код. После этого ребут и выполнение новой FW.

Вот, например, со временным хранилищем в I2C: https://github.com/mihaigalos/miniboot

Насколько я понял - достаточно из работающей прошивки (с поддержкой CAN) правильно заполнить EEPROM-ку, далее бутлоадер сам перешьет МК  при старте. 

К сожалению, никаких примеров там нет и быстропоиск тоже на них не выводит.

Ок пасиб, гляну

Ну, ты это... выкладывай потом результат.

Т.е. получается эмулятор загрузчика для дудки пишем в основной программе, который вместо флеша будет писать на внеш еепром, а уже настоящий загрузчик правим для обновления  fw с и2с еепромки. 

Насколько я понимаю твою концепцию, в сети есть обновляющая сторона (source) и обновляемая (target).

Стало быть, примерный алгоритм таков:
- target информирует source о том, что есть обновление определенного размера;
- source переходит в режим приема (возможно подтверждая готовность);
- target отсылает фрагмент данных (возможно с его сквозным номером);
- source принимает фрагмент и пишет его в I2C EEPROM (возможно с подтверждением получения, если номера фрагментов последовательны или извещением о необходимости перепосылки);
- target и source повторяют всё до окончательной загрузки FW в I2C EEPROM;
- source правит заголовок для того, чтобы miniboot понял, что при следующем ребуте необходимо поменять прошивку МК;
- source ребутит МК.

...но я как представлю уровень гемора с написанием кода и его отладкой ради разового проекта - мне немедленно хочется накатить.

И то правда))  ладно я пока с онлайн заливкой попробую. Не покатит, посмотрим. Разочек если че можно и вскрыть девайс, главное чтоб не часты такие явления были с фейлами. 

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

Макс, если честно - я только в прикладной части могу помочь.

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

Atmel Studio ставил разок, ужаснулся монстрообразности и снес.
Но пока я читал про эти загрузчики, у меня сложилось мнение, что в 328-мк все стремятся залезть в 2кб.

Ок, понято. 

MaksVV, попробуйте из \optiboot в cmd набрать make atmega328. ОС какая?

Оптибут не компилируется каким-то особенным компилятором или еще каким бредом. Все ограничения и настройки написаны в каком-нибудь конфиге. Его нужно найти и отредактировать. Хотя если уже этот этап вызывает затруднения, то можно сразу забросить.

Green, ОС win7. В командной строке и собираю оптибут, но настройкой BIGBOOT=1 можно сделать размер максимум 1кб. Я искал конфиг где поправить, пока не нашёл.  Просто если кто уже с этим разбирался, есть вероятность что напишет.

Rkit по вашей логике так можно всю жись забросить. В любом случае любые советы и мнения приветствуются. 

А тогда зачем вы спрашиваете?

atmega328: LDSECTIONS  = -Wl,--section-start=.text=0x7c00 -Wl,--section-start=.version=0x7ffe

Ну и фьюзы нужно выставить соответственно.

Тоесть просто джамп на бутлоадер нипракатит?

да прокатит, но нужно это отловить в бутлоадере. Штатный проверяет причину ресета и если НЕ внешний, то запускает код, а не себя, ОК? Тут народ баисся компилировать бутлоадер, а вопросы неудобные задаешь! ;)))

я разбирался. Легче стало? ;)))  Правь Makefile, компилируется не "в ИДЕ", а просто из командной строки тем компилятором, который УЖЕ есть в Ардуино ИДЕ. Или поставить mingw и необходимые Линуксовые средства разработчика под АВР.

И что Вы все в оптибут уперлись? Он написан ради мааа-ленького размера, если "размер не имеет значения", но переписывать под себя проще классику. Тот, который не опти.

Помогать не хочу. По мне - загружать код по КАН шине - бред какой-то. А бредом только за деньги готов заниматься ;))) Смотри, ЭБУ автомобиля не прошивается по КАНу, почему так разработчик решил? Написать такой загрузчик - ничего не стоит, но не стали. А почему?

ЭБУ не знаю. А периферийные модули очень даже прошиваются, у вага например. Но полностью согласен с тем, что прошивка по кан шине - бред. В авто деваться некуда, а тут то в чем проблема. И опять же нужно отметить, что задача не так сложна как кажется. 

Да она вообще никак не сложна. В размер бутлоадера чорт лысый влезет.

Тут нужно концепцию определить: мы рассчитываем на работоспособность контроллера? Если да, то тут только фантазия ограничивает способ переведения в режим загрузки. Если же мы предполагаем прошивку "кирпича", то нужен внешний Ресет. От этого решения и плясать.

Всем респект за советы! Пока еще не было времени поковыряться. Но, думаю, вы мне сэкономили много времени. Благодарствую.
В современных авто блоки как раз по CANу шьются. Не пойму почему большинству пользователей этого форума так ненавистна CAN шина. Но если такой канал связи уже есть, зачем ещё какие то, хоть бы даже и для прошивки?
И да, мы рассчитываем на прошивку действующего МК. В режим бутлоадера планируется способ как переход по адресу загрузчика, это я вроде научилсо.

Блин!!! Ты меня заразил. ;)) Проснулся, взял тилипон и заказал 4 модуля MCP2515 на Али. Придут, напишу такой бутлоадер. ;)))

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

Я заморачиваться особо пока не буду. Хочу для начала попробовать таким образом: сделать скорость бутлоадера что нибудь типа 19200 (мне не в лом немного подождать, лучше чтоб надежнее). А программатор(шлюз uart <-> CAN) будет получать байты от дуды и просто записывать их в ID CAN, каждый байт отдельным фреймом. Причём у этих фреймов dlc будет =0, т.е. Без поля данных, чтобы лишнюю инфу не прогонять. Т. Е. Полученный от дудки байт записывается прямо в тело идентификатора фрейма. Так проще будет и бутлоадер поправить. CAN планируется на скорости 125 кбит/с. Думаю будет успевать.

Пишется всё и в вагах и в мерседесах и даже в_жигулях хоть по к-линии, хоть по кану, хоть через бут и даже "напрямую" прям к процу.

И шо, ежли пересылать "пачки" по 8/16/32/64 байт каном и потом с них формировать "страницу" , например, в 64 байта в ОЗУ религия не позволяет? Классическая скорость кана в авто=500кбпс и ничо, работает ))) Посчитай, за сколько "просвистит" прошивка=32кб ???

Патамушта она только с виду простая, как валенок, а будешь "глубже копать" --- поймёшь.

А зачем мне глубже копать. Меня как юзера этот продукт устраивает. Арбитраж и контроль ошибок с моих обязанностей кан контроллер снимает , я работаю сразу с более высоким уровнем. Мне все время твердят про короткие фреймы в 8 байт. А где нужны длинные пакеты? мне че-то на ум не приходит (ну может разве что как раз с аплоадом fw) Я рассматриваю CAN для домашней автоматизации и как альтернативу rs485. По стоимости модуля связи отличается не значительно.
И вообще не хотелось бы тему опять свалить в срач хорош CAN или нет. Тема о другом

Кто мешает "собрать" из 8-ми байт мегаБайт???   )))

Дык это два-брата-акробата, как двое из ларца - одинаковы с лица )))

скетчи из #15 не работают как задумывалось, все равно во фрейм не собирается более одного байта данных. Т.е. по одному байту на фрейм, поэтому более стабильно работает такой скетч, 20 из 20 раз залил прошиву без проблем . 

#include <SPI.h>
#include <mcp2515.h>
struct can_frame rx;
struct can_frame tx;
MCP2515 mcp2515(10);

void setup() 
{
  Serial.begin(57600);
  SPI.begin();
  tx.can_dlc = 1; 
  tx.can_id = 001;
    mcp2515.reset();
  mcp2515.setBitrate(CAN_500KBPS, MCP_8MHZ);
  mcp2515.setNormalMode();
}

void loop() 
{
  while (Serial.available()) {tx.data[0] = Serial.read(); mcp2515.sendMessage(&tx);}
  if (mcp2515.readMessage(&rx) == MCP2515::ERROR_OK) {if (rx.can_id==1) Serial.write(rx.data[0]);}
}

Если все же копить байты во фреймы по 8 или сколько успеет, то штатный загрузчик уже рассинхронизируется с avrdude и прошива не заливается. 

И да. Переход на адрес загрузчика нормально работает на версии оптибут 6.2. На поздних там по другому MCUSR проверяется.

А причем тут скорость ? Про проверки целостности данных не забыл ? 

А моя религия мне позволяет больше чем тебе твоя :) Мне только свинину есть нельзя, остальное все можно.

Хрена себе утвержденице.....  Они даже близко не лежали. Что в них похожего ?

Ой ли ? Что именно гарантирует, что клиент получил пакет ?