Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Все о ARM GCC4.3
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > GNU/OpenSource средства разработки
Vitaliy_ARM
Все больше прощаюсь с IAR.

Разбираюсь с компановщиком. Документация на него не впечатлила 07.gif . Есть ли у кого готовый пример скрипта размещения констант по указанному адресу во Flash LPC2xxx или другого арма?
oll
Цитата(Vitaliy_ARM @ Dec 9 2008, 16:12) *
Все больше прощаюсь с IAR.

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


может тут? http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/
zltigo
Цитата(Vitaliy_ARM @ Dec 9 2008, 13:12) *
Все больше прощаюсь с IAR.

Много полезне вместо демонстративного прощания с IAR тихо и навсегда попрощаться с дурной привычкой "размещения констант по указанному адресу во Flash". Ну а инструментарий у V5 IAR суть есть GNU-тый....
singlskv
Цитата(zltigo @ Dec 9 2008, 19:38) *
Много полезне вместо демонстративного прощания с IAR тихо и навсегда попрощаться с дурной привычкой "размещения констант по указанному адресу во Flash". Ну а инструментарий у V5 IAR суть есть GNU-тый....
А если это настроечные константы прибора хранящиеся в флеш и требуется возможность
их изменения/записи с помощью спец процедуры ? Как обойтись без абсолютных адресов ?
Как сделать кратность записи странице флеш ?
zltigo
Цитата(singlskv @ Dec 9 2008, 21:35) *
А если это настроечные константы прибора хранящиеся в флеш и требуется возможность
их изменения/записи с помощью спец процедуры ? Как обойтись без абсолютных адресов ?
Как сделать кратность записи странице флеш ?

Если у Вас флеши слишком много, что Вы можете отдать целый сегмент, то и отдайте его в конце. И пишите и пользуйте на здоровье. А если нет, то по любому считать->отпатчитть-стереть->записать придется. Процедура занимающаяся этим изнутри и так знает где что лежит. А наружные патчеры и по сигнатуре найдут без проблем. А втыкать некий кусок в фиксированное место это значит платить кусками неиспользуемого Flash, ибо линкер не сможет идально заполнить зачем-то созданые по Вашей прихоти пустоты.
singlskv
Цитата(zltigo @ Dec 9 2008, 21:47) *
Если у Вас флеши слишком много, что Вы можете отдать целый сегмент, то и отдайте его в конце.
Флеши много не бывает.
Ну конечно в конце, но это не всегда конец флеши, иногда
это конец некоторого логического куска, ну там всякие бутлоадеры итд...
Цитата
А если нет, то по любому считать->отпатчитть-стереть->записать придется. Процедура занимающаяся этим изнутри и так знает где что лежит. А наружные патчеры и по сигнатуре найдут без проблем.
А вот это очень может быть ненадежно..., там ведь с кодом может пересекаться и при
аппаратном сбое умрет все...
Цитата
А втыкать некий кусок в фиксированное место это значит платить кусками неиспользуемого Flash, ибо линкер не сможет идально заполнить зачем-то созданые по Вашей прихоти пустоты.
Это плата за надежность, поэтому ИМХО, фиксированное размещение данных(для отделения
от всего остального) может быть очень даже оправданно.
zltigo
Цитата(singlskv @ Dec 9 2008, 22:28) *
Флеши много не бывает.

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

Вы уж как-то определитесь, либо отдельный сегмент,либо будет с чем-то пересекаться.
smile.gif. Но в любом случае нет ни малейшей необходимости заставлять линкер размещать Ваши данные по пришедшему Вам в голову произвольному адресу.
Harbour
не надо думать узкими категориями только своей задачи. мне for ex. часто приходится размещать код и данные в определенных адресах - иначе таки да получится не приложение, а какая-то каша.
корректно это делается выделением отдельной секции (в моем случае .bootloader) и ее описанием в линкер-файле - имеем определенную гарантию, так как при налезании границ сегментов ругаться будет линкер, что много лучше вылетающего в неопределенный момент приложения
VslavX
Цитата(Harbour @ Dec 10 2008, 08:39) *
корректно это делается выделением отдельной секции (в моем случае .bootloader) и ее описанием в линкер-файле - имеем определенную гарантию, так как при налезании границ сегментов ругаться будет линкер, что много лучше вылетающего в неопределенный момент приложения

+10
Еще дополнительно полезно при старте изделия "об-assert-ить" нужные адреса/смещения - у меня окончательную сборку проекта проводят коллеги и иногда ухитряются криво это сделать даже по предоставленным готовым скриптам.
zltigo
Цитата(Harbour @ Dec 10 2008, 09:39) *
не надо думать узкими категориями только своей задачи

Это Вы кому?
Цитата
корректно это делается...

Когда это НУЖНО, типа bootloader-a, то это несомненнно ДЕЛАЕТСЯ. Вопрос в том, что этого незачем делать без всякой на то надобности, как в заявленном случае.
Vitaliy_ARM
Цитата(zltigo @ Dec 9 2008, 19:38) *
Много полезне вместо демонстративного прощания с IAR тихо и навсегда попрощаться с дурной привычкой "размещения констант по указанному адресу во Flash". Ну а инструментарий у V5 IAR суть есть GNU-тый....


В моей задаче это просто не возможно. Бутлодер + Программа имеют две константы - мак адрес и ай пи адрес, строго расположенные в указанных местах. И то и то должно иметь доступ к этим ячейкам. Прощание с "дурной привычкой" не позволить сделать программу и бутлодер независымыми sad.gif .
zltigo
Цитата(Vitaliy_ARM @ Dec 10 2008, 16:43) *
Прощание с "дурной привычкой" не позволить сделать программу и бутлодер независымыми sad.gif .

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


Ага, а как тогда с ай пи адресами и маками? Вместе с загрузчиком зашиваются адреса по умолчанию. Программа должна перешивать и то и другое. А загрузчик должен это использовать, так как абгрейд должен осуществляться по одним и тем же адресам.
Harbour
вот примерчик из моего проекта под 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;
....

отдавать под обновляемые данные придется целый сектор или страничку, в зависимости от того как стирается флеш
Сергей Борщ
Цитата(Vitaliy_ARM @ Dec 10 2008, 15:43) *
В моей задаче это просто не возможно. Бутлодер + Программа имеют две константы - мак адрес и ай пи адрес, строго расположенные в указанных местах.
Как-то так. Выделяете регион памяти(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: стоило подождать сутки, чтобы выложить одновременно smile.gif Но у меня оформлено тегами [ code ], [ /code ] biggrin.gif
Harbour
Sorry, если что wink.gif
zltigo
Цитата(Vitaliy_ARM @ Dec 10 2008, 17:10) *
Ага, а как тогда....

C точностью до наоборот, в этом случае расположите указатель в самом начале загружаемого кода.
Vitaliy_ARM
Цитата(zltigo @ Dec 10 2008, 17:51) *
C точностью до наоборот, в этом случае расположите указатель в самом начале загружаемого кода.


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


Цитата(Сергей Борщ @ Dec 10 2008, 17:16) *
Как-то так. Выделяете регион памяти(CONFIG), потом складываете в него нужные сегменты (*.config)[code]/* memory layout */


Вроде бы прояснилось. smile.gif
Vitaliy_ARM
Генерирование отладочной информации в коде процессора - подскажите, что это такое и с чем его едят?
Где можно почитать об этом (строчки в скрипте компоновщика)?
Код
/* Stabs debugging sections.  */
  .stab          0 : { *(.stab) }
  .stabstr       0 : { *(.stabstr) }
  .stab.excl     0 : { *(.stab.excl) }
  .stab.exclstr  0 : { *(.stab.exclstr) }
  .stab.index    0 : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment       0 : { *(.comment) }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug           0 : { *(.debug) }
  .line            0 : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo   0 : { *(.debug_srcinfo) }
  .debug_sfnames   0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges   0 : { *(.debug_aranges) }
  .debug_pubnames  0 : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info      0 : { *(.debug_info .gnu.linkonce.wi.*) }
  .debug_abbrev    0 : { *(.debug_abbrev) }
  .debug_line      0 : { *(.debug_line) }
  .debug_frame     0 : { *(.debug_frame) }
  .debug_str       0 : { *(.debug_str) }
  .debug_loc       0 : { *(.debug_loc) }
  .debug_macinfo   0 : { *(.debug_macinfo) }
  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }
  .debug_varnames  0 : { *(.debug_varnames) }
amw
Цитата(Vitaliy_ARM @ Jan 19 2009, 13:25) *
Генерирование отладочной информации в коде процессора - подскажите, что это такое и с чем его едят?
Где можно почитать об этом (строчки в скрипте компоновщика)?
Код
/* Stabs debugging sections.  */
  .stab          0 : { *(.stab) }
  .stabstr       0 : { *(.stabstr) }
  .stab.excl     0 : { *(.stab.excl) }
  .stab.exclstr  0 : { *(.stab.exclstr) }
  .stab.index    0 : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment       0 : { *(.comment) }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug           0 : { *(.debug) }
  .line            0 : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo   0 : { *(.debug_srcinfo) }
  .debug_sfnames   0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges   0 : { *(.debug_aranges) }
  .debug_pubnames  0 : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info      0 : { *(.debug_info .gnu.linkonce.wi.*) }
  .debug_abbrev    0 : { *(.debug_abbrev) }
  .debug_line      0 : { *(.debug_line) }
  .debug_frame     0 : { *(.debug_frame) }
  .debug_str       0 : { *(.debug_str) }
  .debug_loc       0 : { *(.debug_loc) }
  .debug_macinfo   0 : { *(.debug_macinfo) }
  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }
  .debug_varnames  0 : { *(.debug_varnames) }

Это отрывок скрипта линкера. Он указывает, куда линкер будет ложить отладочную информацию в исполняемый файл.
Генерируется она компилятором, при использовании ключа -g с опциями. Например (варианты)
Код
gcc -g main .o main.c
gcc -g3 main .o main.c
gcc -ggdb main .o main.c
gcc -gdwarf-2 main .o main.c

Линкуется потом обычным способом (линкеру не имеет особых флагов для отладочной информации).
После этого можно спокойно отлаживать программу с помощью gdb.
Vitaliy_ARM
Цитата(amw @ Jan 20 2009, 10:35) *
Это отрывок скрипта линкера. Он указывает, куда линкер будет ложить отладочную информацию в исполняемый файл.
Генерируется она компилятором, при использовании ключа -g с опциями. Например (варианты)
Код
gcc -g main .o main.c
gcc -g3 main .o main.c
gcc -ggdb main .o main.c
gcc -gdwarf-2 main .o main.c

Линкуется потом обычным способом (линкеру не имеет особых флагов для отладочной информации).
После этого можно спокойно отлаживать программу с помощью gdb.


Да, уже разобрался. Есть еще некоторые непонятности.
Как я понимаю OpenOCD уже научился поддерживать J-Link и еще кучу всяких Jtag. Но для этого надо ли его пересобрать? Кто-нибудь пользуется связкой Eclipse+GCC+OpenOCD+J-Link?
Doka
Цитата(Vitaliy_ARM @ Jan 20 2009, 13:38) *
Как я понимаю OpenOCD уже научился поддерживать J-Link и еще кучу всяких Jtag. Но для этого надо ли его пересобрать? Кто-нибудь пользуется связкой Eclipse+GCC+OpenOCD+J-Link?

ну, пока непонятно.. мой опыт с OpenOCD + MT-link закончился вот чем: http://electronix.ru/forum/index.php?showtopic=58123
и трудно понять что не так - толи VID&PID не распознаёт/не нравится - толи еще что не так.. не было времени после этого разбираться
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.