коллеги, а кто как делает логику работы загрузчика? или все на ардуино перешли и в ус не дуют?

вот после сброса загрузчик получил управление - как он должен узнать, надо ли просто перейти на нулевой адрес для старта прошивки или ждать получения новой прошивки?

я вижу несколько вариантов разной степени неудобства:
1. какая-то ножка зажимается внешней перемычкой на землю, и загрузчик так узнает, что надо получать и обновлять прошивку
2. вычисления контрольных сумм памяти обычной (не загрузочной) прошивки - если не совпадают, надо ждать обновления
3. тупое ожидание какое-то время байта по UART (или еще откуда-то - не суть), а потом, если ничего не пришло, стартовать с нуля. если пришло - обновлять

наиболее красивым вариантом мне представляется второй, но я не представляю, как его на самом деле реализовать? как посчитать контрольную сумму прошивки во FLASH, я знаю, вопрос в другом: как узнать контрольную сумму ПЕРВОЙ прошивки, которая уже содержит загрузчик? есть, конечно, вариант прошивать В ПЕРВЫЙ РАЗ только загрузчик... но почему-то мне это кажется каким-то кривым решением.

Optiboot смотрит причину сброса в MCUSR, если он был ТОЛЬКО по пину RESET - ждет 1 секунду активности на USART (попытку залить прошивку).
Кстати, неплохой готовый загрузчик, велосипед можно не изобретать.

в конечном устройстве кнопка сброса обычно не предусматривается, как конечный пользователь будет обновлять прошивку?

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

А тут уже нужно думать применительно к конкретной конструкции, что там у нее есть из обвязки, на что можно воздействовать...
Из более-менее универсальных идей:
Тот же Optiboot можно чуть подправить, что бы он ждал прошивку в течении секунды, не только после ножки RESET, а и после подачи питания.
Или если там будет встроенный конвертер в RS-232C либо USB - завести с него на ножку RESET сигнал DTR.
Можно подключить RESET к RxD через RCD цепочку. Тогда для формирования RESET, нужно будет выдать с хоста сигнал BREAK перед заливкой прошивки.

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

идея с завязкой RESET на RX мне не нравится - при нормальном обмене тоже сбрасываться будет, что ли? хочется сделать в базовом варианте так, чтобы никакие внешние воздействия не были нужны (кроме обычного обмена по UART).

Добавлено after 7 minutes 59 seconds:
я сделал загрузчик без задействования BOOTRST, который сразу встроен в рабочий код, т.е. соединение с компьютером происходит стандартно для устройства, и при получении команды "обновиться" происходит переход на адрес загрузчика, а дальше по схеме... но я не учел, что если вдруг в процессе обновления порвется связь или произойдет сбой, получится кирпич, т.к. "стандартный" вход из рабочей прошивки будет невозможен (ее попросту не будет внутри МК), а иного варианта не предусмотрено... вот и думаю над иным вариантом с использованием BOOTRST.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

отдать 0 байт ЕЕПРОМ под служебную информацию, работаем в основной программе, если пришел спецпакет - заносим туда информацию о перепрошивке и уходим в бутлоадер (сразу или по перезагрузке)
бутлоадер или по совпадению к.с. или по спецпакету завершения программирования стирает этот флаг и запускает основной код
при включении по этому байту бутлоадер может определить необходимость прошивки
также там можно хранить версию (FF - надо прошить, иначе = версия прошивки-1)

Ivanoff-iv, нормальный вариант. уже думал об этом, только не 0-й байт хотел занимать, а последний.

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

я однажды позанимался с загрузчиком с сайта chip45boot. там можно скачать загрузчики под разные МК. я себе скачал конкретно под АТмега8.
он после старта ждет некоторое время связи с комповой программой.
если такая связь по USART не началась, то делается переход на нулевой адрес (на приложение).
комповую программу можно скачать там же.
плохо то, что задержку он делает программно, и время задержки зависит от тактовой частоты.
я его дизассемблировал, и нашел место отработки задержки. соответственно сделал два загрузчика - для частоты 1 МГц и для 8 МГц, чтобы задержка была примерно 2 секунды.

Starichok51, см.п.3 из моего первого поста - это оно. и оно как раз не очень радует ожиданием: пользователь включает девайс, а он молчит, как рыба об лед... аж 2 секунды. как с моей ловкостью, так и 5 секунд мало, чтобы все подключить и соединить/нажать. как запасной вариант в голове держу, но основной скорее по идее Ivanoff-iv сделаю.

При правильном формирователе, обычный обмен не будет вызывать сброса, только длительное непрерывное удержание RxD в нуле (сигнал BREAK).
Прошивальщик и загрузчик будут самописные? Если так, то можно еще проще.
Выставляем прошивальщиком BREAK, включаем девайс, прошивка проверяет состояние линии RxD, если там ноль - переходит на загрузчик.
Еще можно уведомить прошивальщик о готовности, выплюнов в USART любой байт, или даже просто импульс на ножку, по времени равный длительности стартового бита.

я 0 байт бы занял, т.к. он наиболее подвержен стиранию...
и назначил бы его значение FF флагом программирования, 0-неизвестная версия, остальные значения "известная версия"
если бутлоадер обнаружит в этой ячейке FF, то будет ждать прошивки, скажем 5минут, если не дождётся - пишет туда 0 и идёт работать...
если дождётся - пишет прошивку и заносит туда номер её версии

в этом что-то есть...
avr-gcc распределяет EEPROM, начиная с нулевого адреса, если туда вмешиваться, снижается удобство написания самой прошивки...

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

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

у меня созрел такой вариант работы загрузчика:
МК запускается с нулевого адреса, то есть, работает основная программа. и программа постоянно проверяет прием вполне конкретного байта по UART.
если нужно перепрошить, подключаем к компу. комповая программа посылает этот вполне конкретный байт.
по факту приема этого управляющего байта прошивка переходит на загрузчик.
по окончании перепрошивки комповая программа дает команду перейти на нулевой адрес.

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

Что бы вот такого вот не было, надо стартовать в загрузчик (щьем фьюзы), там проверять условие, и если оно не выполнено - прыгать на основную прошивку, которая с нулевого адреса.
Собственно, Optiboot так и работает. Можно взять его за основу, там открытый исходный код, только переделать проверку условия под свой вариант.

а Optiboot сможет работать только с Arduino IDE? я так понимаю, что ТС (как и меня) это вообще не интересует.
и ТС уже высказался, что задержка на ожидание перехода в основную прошивку ему тоже не нравится.

Я его не собирал, готовый пробовал.
Судя по описанию, надо avr-gcc 4.3.2 (можно из состава любой IDE), собирается он make-ом.

Если причина сброса любая иная, кроме воздействия на пин RESET - он запускает основную прошивку без какой либо задержки.
Если RESET - ждет команду по USART одну секунду, если не поступила - сброс по WDT и запуск основной прошивки.
Основная прошивка может быть полностью убита или отсутствовать, устройство удастся прошить, что и хотел ТС.

Проверку MCUSR, будет несложно заменить на проверку любого другого условия, нуля на пине RxD например, или на пине какой то кнопки (если в устройстве они есть).
Задержку то же можно уменьшить, вплоть до 15мс, описание говорит что она через WDT реализована, но смысла я не вижу.

Можно своим приобретенным опытом поделюсь? Может кому пригодиться.
К своему стыду не смотрел внутреннюю организацию bootloader (использую самый короткий Optiboot). Однако при активном фьюзе BootRst кроме адреса входа еще и вектора прерываний попадают в область загрузчика. Их тоже наверное надо будет коммутировать, если есть желание просто передать обратно управление bootloader.
По крайней мере в своих программах на 328p, установленных на Arduino подобных платах, на всякий случай делаю обратное действие - забираю вектора к себе после работы bootloader.
В режиме создания программы активно использую bootloader. Прошиваю прямо из командной сроки без Arduino IDE. На этапе разработки 2 секунды не самое большое зло. На финальном этапе просто один раз отключаю BootRst через USBasp.

Вот еще подумал...
ТС к сожалению не объявил, чем девайс будет подключатся к компу.
Но если там что то вроде MAX232 или USB-TTL адаптера, то можно схитрить:
Подпорку на входе (или пине RxD) ставим так, что бы при отсутствии физического подключения к компу, RxD был в нуле (активный уровень!), и делаем соответствующую проверку в загрузчике.
При подключении к компу - RxD перейдет в единицу, что будет сигналом для загрузчика, о возможной попытке залить прошивку.
Это позволит использовать для прошивки готовый софт, без плясок с бубном для организации подачи в порт BREAK-а.

См. Digispark (ATtiny85). Есть буутлоудер, вкл. через USB без USB-TTL адаптера, время точно можно уменьшить, через WDT. См. файл optiboot.c

А optiboot уже написан для много MCU. Берите то, что нужно. Arduino IDE не требуется. Просто оттуда легко и быстро, как инструмент. Возьмите из папки скомпилированный файл /или скомпилируйте сами/ и пользуйтесь.Например для ATTinyCore:

https://github.com/Optiboot/optiboot