[dimka76 42]

Уважаемые знатоки !

Есть микроконтроллер LPC18xx, у которого два банка FLASH памяти.

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

Это добавляет некоторые удобство, когда в первом банке находится основная программа, а во втором - всякие шрифты и картинки.

Шрифты и картинки практически постоянны и могут занимать объем больший, чем сама программа. И поэтому их удобней один раз залить

во второй банк, а основную программу переписывать в первом банке. И соответственно, за счет меньшего объема записываемого 

кода будет согращаться время программирования, что особенно важно на этапе разработки и отладки.

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

[AHTOXA 14]

Для этого надо:

* в скрипте линкера создать отдельную секцию для второго банка:

MEMORY
{
	RAM (xrw)	: ORIGIN = 0x20000000, LENGTH =   6K
	BANK1 (rx)	: ORIGIN = 0x08000000, LENGTH =  32K
	BANK2 (rx)	: ORIGIN = 0x08100000, LENGTH =  32K
    ....
}

...
SECTIONS
{
	.bank2_data :
	{
		*(.bank2)
		*(.bank2.*)
	} >BANK2

...

* в исходниках указать для объектов эту секцию:

int foo __attribute__((section(".bank2")));

* собрать проект, проверить работоспособность при заливке целиком

* при помощи утилиты srec_cat сформировать два бинарника для двух банков.

 

[dimka76 42]

8 minutes ago, AHTOXA said:

Для этого надо:

* в скрипте линкера создать отдельную секцию для второго банка:

* в исходниках указать для объектов эту секцию:

* собрать проект, проверить работоспособность при заливке целиком

* при помощи утилиты srec_cat сформировать два бинарника для двух банков.

 

Спасибо.

С первыми тремя пунктами я знаком и это мне понятно.

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

Quote

The srec_cat program is used to assemble the given input files into a single output file

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

[Aaron 1]

Может создать отдельную цель сборки в makefile, и для этой цели сборки подсунуть отдельный ld-файл, где будет только секция BANK2 прописана?

В этом ld-файле указать KEEP для всех данных из объектников, т.к. формально к ним обращений не будет, и оптимизатор может их выпилить при сборке.

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

[dimka76 42]

5 minutes ago, Aaron said:

Может создать отдельную цель сборки в makefile, и для этой цели сборки подсунуть отдельный ld-файл, где будет только секция BANK2 прописана?

В этом ld-файле указать KEEP для всех данных из объектников, т.к. формально к ним обращений не будет, и оптимизатор может их выпилить при сборке.

Я тоже думал над какой-то целью в makefile, но ничего не надумал. Скорее всего из-за недостатка знаний в этой области.

С отдельным файлом линкера интересна ямысль, только вот KEEP вроде наоборот указывает не удалять секцию, даже если она не используется.

Quote

When link-time garbage collection is in use (-gc-sections), it is often useful to mark sections that should not be eliminated. This is accomplished by surrounding an input section's wildcard entry with KEEP(), as in KEEP(*(.init)) or KEEP(SORT(*)(.ctors)).

 

[jcxz 184]

50 минут назад, dimka76 сказал:

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

А зачем получать 2? Получайте один. При прошивке, например IAR, сначала сверяет текущее содержимое флешь с зашиваемым образом и не шьёт те сектора, содержимое которых совпадает с содержимым флешь.

Да и бутлоадеры если по уму - нужно так же строить. Все мои бутлоадеры тоже так делают.

А время считывания (для сверки) - оно незначительно по сравнению со временем записи/стирания.

[dimka76 42]

4 minutes ago, jcxz said:

А зачем получать 2? Получайте один. При прошивке, например IAR, сначала сверяет текущее содержимое флешь с зашиваемым образом и не шьёт те сектора, содержимое которых совпадает с содержимым флешь.

Да и бутлоадеры если по уму - нужно так же строить. Все мои бутлоадеры тоже так делают.

А время считывания (для сверки) - оно незначительно по сравнению со временем записи/стирания.

Я использую FlashMagic и кажется он так не умеет.

И этот раздел форума про GCC, а не про IAR.

[Aaron 1]

По поводу KEEP ещё раз: вы создаёте ld-файл с секцией BANK2. Далее в цели сборки перечисляете только те зависимости, которые должны попасть в BANK2.
Типа такого:
 

bank2.bin: graphics.o constans.o bank2_script.ld

    $(LD) graphics.o constans.o $(LDFLAGS) -Tbank2_script.ld -o "bank2.bin"

Поскольку переменные/константы в привязываемых объектниках из этих же файлов не вызываются никак, то для них в ld-файле должно быть слово KEEP.

SECTIONS
{
	.bank2_data :
	{
		KEEP(*(.bank2))
		KEEP(*(.bank2.*))
	} >BANK2

 

 

[dimka76 42]

1 minute ago, Aaron said:

По поводу KEEP ещё раз: вы создаёте ld-файл с секцией BANK2. Далее в цели сборки перечисляете только те зависимости, которые должны попасть в BANK2.

Понятно. Спасибо.

Попробую.

[jcxz 184]

23 минуты назад, dimka76 сказал:

И этот раздел форума про GCC, а не про IAR.

Мне кажется все современные отладчики должны так уметь. Разве не так?

Насчёт FlashMagic-а не знаю - 100500 лет уж им не пользовался.

[dimka76 42]

13 minutes ago, jcxz said:

Мне кажется все современные отладчики должны так уметь. Разве не так?

Не знаю (((

[AHTOXA 14]

1 час назад, dimka76 сказал:

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

Цитата

The srec_cat program is used to assemble the given input files into a single output file

 

И тем не менее srec_cat умеет вырезать нужные кусочки.

http://srecord.sourceforge.net/man/man1/srec_examples.html#CROPPING THE DATA

Я точно помню, что использовал её для этих целей.

[Aaron 1]

Можно ликбез провести по поводу srec_cat? bin файлы же не обладают встроенной информацией о секциях адресов. Проводится подготовка промежуточных файлов .srec и из них далее из одного файла могут генерироваться несколько bin?

[dimka76 42]

2 minutes ago, Aaron said:

Можно ликбез провести по поводу srec_cat? bin файлы же не обладают встроенной информацией о секциях адресов. Проводится подготовка промежуточных файлов .srec и из них далее из одного файла могут генерироваться несколько bin?

В данном случае, наверное имеется ввиду, что у секции BANK2 будет известное фиксированное смещение относительно начала bin файла.

 

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

[AHTOXA 14]

20 минут назад, Aaron сказал:

Можно ликбез провести по поводу srec_cat? bin файлы же не обладают встроенной информацией о секциях адресов. Проводится подготовка промежуточных файлов .srec и из них далее из одного файла могут генерироваться несколько bin?

Для bin-файлов приходится задавать смещение вручную. Вот, например, как вырезать из двоичного файла app.bin 4 байта по адресу 0x1000 и записать их в файл app_crc.bin:

srec_cat app.bin -binary -crop 0x1000 0x1004 -offset -0x1000 -o app_crc.bin -binary