Друзья. Сомнения мучают меня.
Хотя начну попорядку.
Появилась задумка сделать bootloader под Мегу48. В качестве среды програмирования выбрал IAR. Особенность 48 в том, что у нее нет bootsection. Приходится все описывать вручную. Для начала определяем местоположение загрузчика для чего в линкере прописываем

Все вроде бы в порядке и в выходном файле появляется в нужном месте содержание загрузчика. И все вроде бы хорошо. Загрузчиком начинаю стирать память контроллера, и вроде бы даже хорошо получается, но когда дохожу до определенного положения стирание прекращается и цикл стирания страниц памяти вылетает. Под пристальным взглядом дизассемблера выясняется, что напоролся на инициализацию секции MYSEGMENT.
Загрузчик начинается с адреса 0x0800, а инициализация секции загрузчика с 0x01C0. Кстати на этом месте заканчивается основная программа.
Могу ли я расположить код инициализации секции MYSEGMENT уже после самого bootloadera.

Вы б еще бутлоадер для tiny13 на IAR начали писать.
или на elab-pascal.

РоманО, у Вас бутлоадер и приложение в одном проекте?
Сделайте бутлоадер отдельным проектом.
В Вашем случае надо править адреса расположения всех кодовых сегментов в xcl файле.

Почему бы автору топика просто не взять совместимый по ножкам ATmega168?

Можно подсмотреть, как делать bootloader для ATmega48 в Megaload http://www.microsyl.com/

Действительно, а зачем 100% аппаратно-зависимые вещи писАть на "С" ? Вопрос отнюдь не религиозный - просто не могу себе представить ситуацию, когда это нужно. Даже если DES прикрутить, асмом целесообразнее, потому что портировать эту часть внутри AVR не надо. Isn't it ?

IMHO, именно религиозный. Я, например, с некоторым моральным усилием рихтую стартап. А в остальном компилятор делает отнюдь не худший по объёму код, если, конечно, бережно относиться к ресурсам. Зато делается это недолго. Вот на днях делал STK500v2-совместимый загрузчик с шифрованием - посмотрел пару ассемблерных реализаций кодера/декодера и увидел, что по сравнению с ассемблерным листингом ничем не лучше. А проект брал чужой (перебрал не один), написанный на Си. Для ужатия объёма (было после добавления шифрования актуально) кое-где ввёл локальные переменные, десяток функций сделал static inline, поправил пару прототипов функций, дабы вызовы были менее ресурсоёмкими - в результате за 10 минут затолкал исходные почти 4 кБ + шифрование (около 400 байт) в чуть больше 3.5 кБ кода. Да это на меге128, да там можно разгуляться - можно было выделить 8кБ загрузчику и забыть, но главное - время написания минимально - сам загрузчик взял в одном месте, функции шифрования в другом (исходно на пуре Си в аппликухе для PIC, правда их тоже быстренько оптимизировать пришлось), а если нужно будет поменять чего, то чтобы вспомнить будет нужно совсем мало времени. Я и на Си поначалу запутался с чехардой long-адресов при записи, а на асме так уж подавно потерялся бы. Так что случаи бывают разные. В мегу48 пихать загрузчик-то можно пытаться, только вряд ли оно того стОит, хоть на асме, хоть на Си. А в ту же 88-ю на Си спокойно ложится.

Это не в счет, поскольку здесь - в чем исходник, в том и работаем.
Я к тому, что к программе добавляется стартап, прописывается линкер, и в итоге, имхо писанины не меньше, к тому же все равно ведь чем меньше размер бута - тем лучше, и все это не портируется на другие семейства МК. А может, и вправду религиозный вопрос. Только я тоже на атмеловском асме ужЕ давненько не пишу. Все больше winavr...

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

хм... никто не мешает ему жирок обрезать

это, извините, не понял насчёт размера почти согласен - бут не должен быть больше отведенного размера, а вот со вторым пунктом уже бы согласился, но - будете смеяться - на днях возможно буду занят загрузчиком для C8051F120, совместимым с STK500v2 - буду перегонять с WinAVR на Keil для С51 - сегодня утречком уже рихтанул стартап (там прерывания перемапить нужно, покромсать и прочая - нет как такового отдельного бутсектора, как в AVR) и соорудил "рыбу" для аппликейшена, ну и проверил, что всё ложится на свои места и оттуда запускается. Как будет нужно - пропишу все отличия и подтяну сам код на keil

Секции описАть в скрипте.


Скорее, апплодировать. Потому как это следствие хорошего системного подхода, направленного на обеспечение портабельности. Чего мне, как Вы заметили, недостает. Добираем...

Ок, тогда затолкните эти 3.5k в 1k.
для (m8/88/16/162/168)


Это разве аргумент?
Когда закончите и будет точно известно сколько времени ушло на доведение порта до устойчивой и правильной работы тогда можно о чем-то говорить.

Блин, я так и не увидел ответа. Может просто какой-нибудь специалист скажет, что просто невозможно линкеру сказать куда писать инициализацию секции.
Идея бутлоадера заключается в следующем. Работать с устройством собираюсь по UART с дальнейшим использованием FT232. Заказчику отправляется программа, а далее в момент появления новой версии софта, новый софт должен прописываться из этой программы коммутации с устройством. При этом не подразумевается перезагрузка устройства, а использование FTDI вобще делает очень не юзабельным загрузку бутлодыря по ресету. Хочется, зарезервировать команду, которая будет запускать процесс перезаливки программы. Поскольку стратегия загрузчика выбрана таким образом, то не важно на чем отрабатывать процесс залавки, потому как стандартная область бутлодыря не используется.
Задам вопрос снова. Можно ли указывать линкеру IAR место куда прописывать инициализацию нового сектора

Это стандартная идея.

Такая стратерия загрузки прекрасно уживается с бутлоадером в отдельной секции.
По команде запуска процесса обновления прошивки - записать в eeprom запрос на смену прошивки и ребутнуть МК по WDT. Далее стартует бутлоадер из штатной секции, проверяет запрос в eeprom, начинает процесс общения с вашей программой и прошивает все что надо. Но должен быть камень с соотв. секцией (m8/m88)


см. #pragma segment
и файл lnkm48s.xcl

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

Затолкните сами и мы Вам поаплодируем.

АРГУМЕНТ. Сомневаюсь, что где-то нынче ещё платят за переписывание распаковщика протокола при переходе с одного семейства на другое только потому, что кто-то неплохо знает ассемблер (скорее оба ассемблера) или на примерах времён, когда компиляторы были никакие, пытается доказывать, что ассемблер обязательно приведёт к лучшему результату (от Вас такого не слышал, но примеры встречаются). А time-to-market, а поддержка? - разработчик должен уважать не только свои умения. Если нет целесообразности писать на ассемблере, то писать на нём только из "любви к искусству" я себе позволить не могу.

Если Вам такой загрузчик нужен, то пишите в личку - авось сторгуемся

Затолкнул. ровно в 1k под жвак (1024). Аплодируйте.


ПОжалуй так и есть.

Даже с современными мощными компиляторами приведет, особенно в мелких задачах каковым является бутлоадер. Выиграет за счет усечения прологов/эпилогов функций, использования регистров для глобальный переменных, размещения кода в таблице векторов и прочих непозволительных для ЯВУ тонкостей (JMP вместо RET и пр.).


Для крупных проектов asm это зло. Для мелких и не требующих развития - очень полезная штука.

На любом ассемблере bootloader написать отсилы день-два, отладить - еще два-три (worst case).
Сопровождение: кому придет в голову править бутлоадер? и зачем если он свою функцию выполняет.


Целесообразность - втиснуться в заданный объем памяти. Экономия места для основной программы. Ведь печально когда 14.5k программа не влазит в МК с 16kb из-за того что съэкономили время на бутлоадере.

Мне только затраты времени интересно знать. Т.к. на ASM с нуля 512 слов программы больше 1-2х дней просто не получится писать. Сопостовимы ли будут Ваши затраты?

Ооо, каких только занятных дырок не бывает в секурных бутлоадерах

Так что бывает и правят.

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

Ассемблерный вариант из AN109 (родной от Атмел) занимал 369 байт Сишный - уже почти в 2 раза больше (родной), а потом розросся до примерно 1к плюс-минус трамвайная остановка.
Но я говорил не о загрузчике вообще, а о конкретном - STK500v2-совместимом с XTEA-шифрованием. Апплодировать?
Иногда приходится. Классический случай - способ входа поправить (когда пин сменить, когда Break по UART прописать), кварц, UART и скорость поменять - это хоть и косметика, но править - часть через конфигурацию, а часть ручками.

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

Врядли больше. На вариант для ATmega128 ушло сначала пол дня. Потом появились пожелания и их пришлось добивать следующим утром. Тяжело говорить - столько готовых наработок, что говорить о написании с нуля несколько некорректно. Для того же C8051F120 есть практически готовый бутлоадер для F020 из аппликухи от Silabs - его подправить - только функции стирания/записи из другой аппликухи подтянуть - грубо до получаса с глупостями. Но мне он не подходит;( STK500 переделать - только с ограничением адресов снизу разобраться, индейцев кое-где сменить, опять же функции стирания/записи подтянуть, расстановку локов, ну и не забыть getchar/putchar и иниты. Работы, не напрягаясь, на день с перекурами.

Если не критично для программы, то поменяйте местами секции загрузчика и основной программы.
Вначале загрузик, а потом основную программу. Типа так.
-Z(CODE)BOOTLOADER=0-87F
-Z(CODE)APLICATION=880-FFD
Работает без проблем.

2PomanO
Короче

Здесь лежит готовый загрузчик под 48мегу ( ProgLoader.nm.ru ) вместе с консолью.
Загрузчик хитрый ,он подменяет нулевой адресс переходом на секцию ,а в секции сохраняет и высчитывает переход на начало проги ,так что ваши проблемы с размещением загрузчика в памяти - это только начало ваших проблем

ЗЫ Прикручивать кодирование к такому камню нереально ,хотя бы потому ,что на саму прогу останется мало памяти
Удачи.

От чего же, 2k под загрузчик, 2k под прогу - 2k достаточно для очень интересного.

Во-первых, совершенно непонятно, как можно инициализировать сегмент бутлодыря, если сегмент бутлодыря содержит код. Во-вторых, если вы сгенерите .map, вы в конце его обнаружите список всех сегментов с их адресами. По адресам сможете понять, какой именно сегмент линкер расположил по интересующим вас адресам и поправив .xcl положить сегменты куда надо.