Все больше прощаюсь с IAR.

Разбираюсь с компановщиком. Документация на него не впечатлила . Есть ли у кого готовый пример скрипта размещения констант по указанному адресу во Flash LPC2xxx или другого арма?

может тут? http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/

Много полезне вместо демонстративного прощания с IAR тихо и навсегда попрощаться с дурной привычкой "размещения констант по указанному адресу во Flash". Ну а инструментарий у V5 IAR суть есть GNU-тый....

А если это настроечные константы прибора хранящиеся в флеш и требуется возможность
их изменения/записи с помощью спец процедуры ? Как обойтись без абсолютных адресов ?
Как сделать кратность записи странице флеш ?

Если у Вас флеши слишком много, что Вы можете отдать целый сегмент, то и отдайте его в конце. И пишите и пользуйте на здоровье. А если нет, то по любому считать->отпатчитть-стереть->записать придется. Процедура занимающаяся этим изнутри и так знает где что лежит. А наружные патчеры и по сигнатуре найдут без проблем. А втыкать некий кусок в фиксированное место это значит платить кусками неиспользуемого Flash, ибо линкер не сможет идально заполнить зачем-то созданые по Вашей прихоти пустоты.

Флеши много не бывает.
Ну конечно в конце, но это не всегда конец флеши, иногда
это конец некоторого логического куска, ну там всякие бутлоадеры итд...
А вот это очень может быть ненадежно..., там ведь с кодом может пересекаться и при
аппаратном сбое умрет все...
Это плата за надежность, поэтому ИМХО, фиксированное размещение данных(для отделения
от всего остального) может быть очень даже оправданно.

Тогда зачем спрашивали о выравниванию на границу..

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

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

+10
Еще дополнительно полезно при старте изделия "об-assert-ить" нужные адреса/смещения - у меня окончательную сборку проекта проводят коллеги и иногда ухитряются криво это сделать даже по предоставленным готовым скриптам.

Это Вы кому?

Когда это НУЖНО, типа bootloader-a, то это несомненнно ДЕЛАЕТСЯ. Вопрос в том, что этого незачем делать без всякой на то надобности, как в заявленном случае.

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

Сообщение отредактировал Vitaliy_ARM - Dec 10 2008, 13:44

Примерно в аналогичных случаях в фиксированном месте boot (сразу после векторов) размещаю УКАЗАТЕЛЬ на находящийся в произвольном месте блок общих данных. Boot, естественно, линкуется в конкретное место, но это единственная по любому необходимая привязка к адресам - сущности более не плодятся.

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

вот примерчик из моего проекта под atmel :

scripts.ld:
.....
MEMORY
{
FLASH (rxx) : ORIGIN = 0x00100000, LENGTH = 0x00005F80
BOARD ® : ORIGIN = 0x00105F80, LENGTH = 0x80
DATA (rw) : ORIGIN = 0x00200000, LENGTH = 0x00007000
STACK (rw) : ORIGIN = 0x00207000, LENGTH = 0x00001000
}
.....
.board : {

*(.board)

} > BOARD

. = ALIGN(4);

_etext = . ;
PROVIDE (etext = .);
......

Использование, например серийный номер устройства, файл sn.c:

....
u32 sn __attribute__ ((section(".board"))) = 12345678;
....

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

Как-то так. Выделяете регион памяти(CONFIG), потом складываете в него нужные сегменты (*.config)
Harbour: стоило подождать сутки, чтобы выложить одновременно Но у меня оформлено тегами [ code ], [ /code ]