Пт авг 26, 2022 20:48:44
Пт авг 26, 2022 21:22:33
MEMORY
{
FLASH (RX) : ORIGIN = 0x08000000, LENGTH = 128K
SRAM (RWX) : ORIGIN = 0x20000000, LENGTH = 20K
}
Пт авг 26, 2022 22:14:18
Пт авг 26, 2022 23:00:43
Сб авг 27, 2022 00:06:23
Потому что 32 бита позволяют адресовать 4 ГБ.ddr4 писал(а):Было непонятно зачем использовать адресное пространство большее чем ОЗУ.
Удобнее. Например передаешь данные в функцию по указателю и не важно они во флеше или в ОЗУ. В AVR так не получится.ddr4 писал(а):Но может быть действительно так удобнее всё держать в одном адресном пространстве
Сб авг 27, 2022 07:16:52
void char2lcd(char x) {volatile char tmp=x; }
void print(const char __generic *str)
{
while(*str) char2lcd(*str++);
}
__flash char str1[] = "FLASH string";
char str2[] = "SRAM string";
int main()
{
print(str1);
print(str2);
}
Сб авг 27, 2022 10:28:25
Сб авг 27, 2022 12:30:05
/*
* Used for validation only, do not allocate anything here!
*
* This is just to check that there is enough RAM left for the Main
* stack. It should generate an error if it's full.
*/
._check_stack : ALIGN(4)
{
. = . + _Minimum_Stack_Size ;
} >RAM
/*
* The FLASH Bank1.
* The C or assembly source must explicitly place the code
* or data there using the "section" attribute.
*/
.b1text : ALIGN(4)
{
*(.b1text) /* remaining code */
*(.b1rodata) /* read-only data (constants) */
*(.b1rodata.*)
} >FLASHB1
/*
* The EXTMEM.
* The C or assembly source must explicitly place the code or data there
* using the "section" attribute.
*/
/* EXTMEM Bank0 */
.eb0text : ALIGN(4)
{
*(.eb0text) /* remaining code */
*(.eb0rodata) /* read-only data (constants) */
*(.eb0rodata.*)
} >EXTMEMB0
/* EXTMEM Bank1 */
.eb1text : ALIGN(4)
{
*(.eb1text) /* remaining code */
*(.eb1rodata) /* read-only data (constants) */
*(.eb1rodata.*)
} >EXTMEMB1
/* EXTMEM Bank2 */
.eb2text : ALIGN(4)
{
*(.eb2text) /* remaining code */
*(.eb2rodata) /* read-only data (constants) */
*(.eb2rodata.*)
} >EXTMEMB2
/* EXTMEM Bank0 */
.eb3text : ALIGN(4)
{
*(.eb3text) /* remaining code */
*(.eb3rodata) /* read-only data (constants) */
*(.eb3rodata.*)
} >EXTMEMB3
.inits : ALIGN(4)
{
/*
* Memory regions initialisation arrays.
*
* Thee are two kinds of arrays for each RAM region, one for
* data and one for bss. Each is iterrated at startup and the
* region initialisation is performed.
*
* The data array includes:
* - from (LOADADDR())
* - region_begin (ADDR())
* - region_end (ADDR()+SIZEOF())
*
* The bss array includes:
* - region_begin (ADDR())
* - region_end (ADDR()+SIZEOF())
*
* WARNING: It is mandatory that the regions are word aligned,
* since the initialisation code works only on words.
*/
__data_regions_array_start = .;
LONG(LOADADDR(.data));
LONG(ADDR(.data));
LONG(ADDR(.data)+SIZEOF(.data));
LONG(LOADADDR(.data_CCMRAM));
LONG(ADDR(.data_CCMRAM));
LONG(ADDR(.data_CCMRAM)+SIZEOF(.data_CCMRAM));
__data_regions_array_end = .;
__bss_regions_array_start = .;
LONG(ADDR(.bss));
LONG(ADDR(.bss)+SIZEOF(.bss));
LONG(ADDR(.bss_CCMRAM));
LONG(ADDR(.bss_CCMRAM)+SIZEOF(.bss_CCMRAM));
__bss_regions_array_end = .;
/* End of memory regions initialisation arrays. */
/*
* These are the old initialisation sections, intended to contain
* naked code, with the prologue/epilogue added by crti.o/crtn.o
* when linking with startup files. The standalone startup code
* currently does not run these, better use the init arrays below.
*/
KEEP(*(.init))
KEEP(*(.fini))
. = ALIGN(4);
/*
* The preinit code, i.e. an array of pointers to initialisation
* functions to be performed before constructors.
*/
PROVIDE_HIDDEN (__preinit_array_start = .);
/*
* Used to run the SystemInit() before anything else.
*/
KEEP(*(.preinit_array_sysinit .preinit_array_sysinit.*))
/*
* Used for other platform inits.
*/
KEEP(*(.preinit_array_platform .preinit_array_platform.*))
/*
* The application inits. If you need to enforce some order in
* execution, create new sections, as before.
*/
KEEP(*(.preinit_array .preinit_array.*))
PROVIDE_HIDDEN (__preinit_array_end = .);
. = ALIGN(4);
/*
* The init code, i.e. an array of pointers to static constructors.
*/
PROVIDE_HIDDEN (__init_array_start = .);
KEEP(*(SORT(.init_array.*)))
KEEP(*(.init_array))
PROVIDE_HIDDEN (__init_array_end = .);
. = ALIGN(4);
/*
* The fini code, i.e. an array of pointers to static destructors.
*/
PROVIDE_HIDDEN (__fini_array_start = .);
KEEP(*(SORT(.fini_array.*)))
KEEP(*(.fini_array))
PROVIDE_HIDDEN (__fini_array_end = .);
} >FLASH
/* The secondary uninitialised data section. */
.bss_CCMRAM (NOLOAD) : ALIGN(4)
{
*(.bss.CCMRAM .bss.CCMRAM.*)
} > CCMRAM
.noinit_CCMRAM (NOLOAD) : ALIGN(4)
{
*(.noinit.CCMRAM .noinit.CCMRAM.*)
} > CCMRAM
Сб авг 27, 2022 13:42:04
Чем мешают эти секции?ddr4 писал(а):Хотелось бы очистить стандартный ld-script Эклипса от очень полезных, но непонятных секций.
Сб авг 27, 2022 13:49:49
Сб авг 27, 2022 14:22:54
VladislavS писал(а):
На какой помойке вы его нашли? Возьмите нормальный скрипт и не мучайтесь.
Вложение: STM32F401CB_flash.zip
.preinit_array :
{ PROVIDE(__preinit_array_start = .);
KEEP(*(.preinit_array*))
PROVIDE(__preinit_array_end = .);
} > FLASH
.init_array :
{ PROVIDE(__init_array_start = .);
KEEP(*(SORT(.init_array.*)))
KEEP(*(.init_array*))
PROVIDE(__init_array_end = .);
} > FLASH
.fini_array :
{ PROVIDE(__fini_array_start = .);
KEEP(*(.fini_array*))
KEEP(*(SORT(.fini_array.*)))
PROVIDE(__fini_array_end = .);
} > FLASH
.reserved_for_stack (NOLOAD) :
{ . = ALIGN(4);
PROVIDE(__reserved_for_stack_start__ = .);
KEEP(*(.reserved_for_stack))
. = ALIGN(4);
PROVIDE(__reserved_for_stack_end__ = .);
} > SRAM
MEMORY
{
FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 256k
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 64k
}
GROUP(
libgcc.a
libg.a
libc.a
libm.a
libnosys.a
)
__stack = ORIGIN(RAM) + LENGTH(RAM);
SECTIONS
{
. = ORIGIN(FLASH);
.isr_vectors : ALIGN(4)
{
FILL(0xFF)
__vectors_start__ = ABSOLUTE(.);
KEEP(*(.vectors))
*(.after_vectors .after_vectors.*)
} > FLASH
/*
* Start of text.
*/
_text = .;
.text : ALIGN(4)
{
*(.text)
*(.text.*)
*(.glue_7t)
*(.glue_7)
*(.gcc*)
} > FLASH
/*
* Arm section unwinding.
* If removed may cause random crashes.
*/
.ARM.extab :
{
*(.ARM.extab* .gnu.linkonce.armextab.*)
} > FLASH
/*
* Arm stack unwinding.
* If removed may cause random crashes.
*/
.ARM.exidx :
{
__exidx_start = .;
*(.ARM.exidx* .gnu.linkonce.armexidx.*)
__exidx_end = .;
} > FLASH
/*
* Read-only data. Consts should also be here.
*/
.rodata : ALIGN(4)
{
. = ALIGN(4);
__rodata_start__ = .;
*(.rodata)
*(.rodata.*)
. = ALIGN(4);
__rodata_end__ = .;
} > FLASH
/*
* End of text.
*/
_etext = .;
/*
* Data section.
*/
.data : ALIGN(4)
{
FILL(0xFF)
. = ALIGN(4);
PROVIDE(__textdata__ = LOADADDR(.data));
PROVIDE(__data_start__ = .);
*(.data)
*(.data.*)
*(.ramtext)
. = ALIGN(4);
PROVIDE(__data_end__ = .);
} > RAM AT > FLASH
/*
* BSS section.
*/
.bss (NOLOAD) : ALIGN(4)
{
. = ALIGN(4);
PROVIDE(_bss_start = .);
__bss_start__ = .;
*(.bss)
*(.bss.*)
*(COMMON)
. = ALIGN(4);
PROVIDE(_bss_end = .);
__bss_end__ = .;
PROVIDE(end = .);
} > RAM
.noinit (NOLOAD) : ALIGN(4)
{
__noinit_start__ = .;
*(.noinit .noinit.*)
. = ALIGN(4) ;
__noinit_end__ = .;
} > RAM
}
Сб авг 27, 2022 14:58:10
Сб авг 27, 2022 16:11:26
У меня нет такого файла.VladislavS писал(а): Посмотрите .map файл, они там есть.
Чтобы оставить только то что нужно, раз STM32 в отличии от AVR-gcc предоставляет возможность управления запуском, то значить это нормально удалять всё что не нужно. Пытаюсь упростить код по максимуму. Для меня этот Blink с кучей файлов выглядит сложно. "Хеллоу Ворлд" будет ещё сложней.VladislavS писал(а):Откуда у вас такое маниакальное желание что-то удалить, даже не понимая зачем это нужно?
Да всё заменено на SRAM, то есть получается в случае замены FLASH на RAM, при запуске программы секции размещаются в оперативке, а до этого размещались во FLASH ?VladislavS писал(а):При отладке программы в SRAM так и делают. Посмотрите приложенный скрипт и сравните с тем что я первым выложил. Вот этот настроен на загрузку кода для отладки в SRAM.
Сб авг 27, 2022 16:35:35
У меня нет такого файла.VladislavS писал(а): Посмотрите .map файл, они там есть.
Сб авг 27, 2022 17:17:01
Сб авг 27, 2022 17:44:23
Я же не знаю как оно в реальности запускается, возможно в линкере указывается куда МК (операционная система) должна разместить секции программы после её запуска. На деле МК размещает секции по адресам в адресном пространстве, желательно чтобы МК размещал секции в ОЗУ, так как во-первых ОЗУ быстрей FLASH'a, а значит скорость программы возрастает, а во-вторых FLASH имеет ограниченный ресурс на число записей. То есть МК с размещением секций в ОЗУ проживёт дольше.VladislavS писал(а):Что такое в вашем понимании скрость запуска приложения? При включении код лежит в флэш и с первых же тактов начинает работать c Reset_Handler. Это и есть приложение.
Спасибо. Действительно интересная информация.VladislavS писал(а):Он создаётся при компиляции при указании соответствующего ключа. Вот это, в отличии от ковыряния скриптов, стоит сделать. Там много интересной информации.
VladislavS писал(а):Да. Только вы должны понимать, что сама по себе программа в оперативке не появится. Кто-то или что-то должны её туда перед запуском поместить.
В коде целый файл sbrk.c под подготовку кучи, + в .map-файле heap'a навалено. Вроде оно всё не мешает, но когда этого всего "не мешает" - много, оно как-то начинает мешать.VladislavS писал(а):Ну и не используйте дальше. От того что вы упомянете её в скрипте линкера она в коде не появится.
Сб авг 27, 2022 17:54:17
Вот вы подключили библиотеку с функциями, струкурами, дефайнами и др. и почти все их не используете. Будете выпиливать не задействованные и без разницы что компиль это сам может сделать?ddr4 писал(а):Тем что я эти секции не использую, зачем они мне?
Если секции действительно не используются то просто зря потратите время, т. к. они все равно в прошивку не попадут (повторюсь, при правильных ключах компиля и линкера).ddr4 писал(а):То есть если я удалю множество неиспользуемых секций
Загружать прошивку как планируете? Обычно прошивку помещают в ОЗУ при отладке (ее загружает отладчик) или необходимости полностью переписать флешь.ddr4 писал(а):а в остальных заменю >FLASH на >RAM, скорость запуска приложения не изменится?
Создается при компиляции.ddr4 писал(а):У меня нет такого файла.
Нормально это когда этим занимается компиль вместе с линкером. Но вы упорно хотите выполнять их работу!ddr4 писал(а):значить это нормально удалять всё что не нужно.
Какая разница сколько файлов в проекте?ddr4 писал(а):Для меня этот Blink с кучей файлов выглядит сложно. "Хеллоу Ворлд" будет ещё сложней.
То есть строками не пользовались, print в любом виде не использовали, классы динамически не создавали и много чего другого не делали что выделяло память из кучи?ddr4 писал(а):В Арудине я malloc() не использовал
Сб авг 27, 2022 18:09:33
VladislavS писал(а):Они нужны не вам, а линкеру.
Сб авг 27, 2022 18:13:03
Сб авг 27, 2022 18:21:54
Мурик писал(а):Вот вы подключили библиотеку с функциями, струкурами, дефайнами и др. и почти все их не используете. Будете выпиливать не задействованные и без разницы что компиль это сам может сделать?
С секциями тоже самое. Если не используются, они не попадут в прошивку (при адекватных ключах компиля и линкера). А если используются, прошивку не соберете.
Мурик писал(а):Если секции действительно не используются то просто зря потратите время, т. к. они все равно в прошивку не попадут (повторюсь, при правильных ключах компиля и линкера). ... Какая разница сколько файлов в проекте?
Мурик писал(а):Загружать прошивку как планируете? Обычно прошивку помещают в ОЗУ при отладке (ее загружает отладчик) или необходимости полностью переписать флешь.
Динамически создавал структуры malloc(), но память быстро кончилась пришлось от этого быстро отказаться ). printf() заменить самодельный uart_print(). Иначе всё в 2 кБ не впихнуть.Мурик писал(а):То есть строками не пользовались, print в любом виде не использовали, классы динамически не создавали и много чего другого не делали что выделяло память из кучи?