Друзья. Сомнения мучают меня.
Хотя начну попорядку.
Появилась задумка сделать 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, а поддержка? - разработчик должен уважать не только свои умения. Если нет целесообразности писать на ассемблере, то писать на нём только из "любви к искусству" я себе позволить не могу.

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