[Vitaliy_ARM 0]

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

 

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

[oll 0]

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

 

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

 

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

[zltigo 1]

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

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

[singlskv 0]

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

А если это настроечные константы прибора хранящиеся в флеш и требуется возможность

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

Как сделать кратность записи странице флеш ?

[zltigo 1]

А если это настроечные константы прибора хранящиеся в флеш и требуется возможность

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

Как сделать кратность записи странице флеш ?

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

[singlskv 0]

Если у Вас флеши слишком много, что Вы можете отдать целый сегмент, то и отдайте его в конце.

Флеши много не бывает.

Ну конечно в конце, но это не всегда конец флеши, иногда

это конец некоторого логического куска, ну там всякие бутлоадеры итд...

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

А вот это очень может быть ненадежно..., там ведь с кодом может пересекаться и при

аппаратном сбое умрет все...

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

Это плата за надежность, поэтому ИМХО, фиксированное размещение данных(для отделения

от всего остального) может быть очень даже оправданно.

[zltigo 1]

Флеши много не бывает.

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

А вот это очень может быть ненадежно..., там ведь с кодом может пересекаться и при

аппаратном сбое умрет все...

Вы уж как-то определитесь, либо отдельный сегмент,либо будет с чем-то пересекаться.

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

[Harbour 0]

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

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

[VslavX 0]

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

+10

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

[zltigo 1]

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

Это Вы кому?

корректно это делается...

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

[Vitaliy_ARM 0]

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

 

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

Изменено 10 декабря, 2008 пользователем Vitaliy_ARM

[zltigo 1]

Прощание с "дурной привычкой" не позволить сделать программу и бутлодер независымыми :( .

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

[Vitaliy_ARM 0]

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

 

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

[Harbour 0]

вот примерчик из моего проекта под 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;

....

 

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

[Сергей Борщ 134]

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

Как-то так. Выделяете регион памяти(CONFIG), потом складываете в него нужные сегменты (*.config)

/* memory layout */
MEMORY
{
  REMAP (rx)   : ORIGIN = 0x00000000, LENGTH = 0x00000040
  ROM (rx)     : ORIGIN = 0x00000000, LENGTH = 128K - 8K
  CONFIG (rx)     : ORIGIN = 128K - 8K, LENGTH = 8K
  RAM (rw)     : ORIGIN = 0x40000000, LENGTH = 16K
}

SECTIONS
{
.............
  .config :
  {
    KEEP(*(.config))
  } > CONFIG
...........

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