Flash vs SRAM

[Z_h_e]

Дело в том что ICODE шина подключена к флешу, а DCODE к ОЗУ. Инструкции быстрее идут из флеш, а данные из ОЗУ.

Самый первый пост и самая первая ссылка. Там тест опровергает и это утверждение. Код то наоборот сработал. Еще раз говорю, пришел к выводу что нельзя говорить что-то однозначно. Может вывод и неверный, но пока так думать оснований нет.

[Oxford]

А там BusMatrix использует алгоритм Round Robin для арбитража. Ну пофантазировать можно конечно, а что если... Но здесь сейчас обсуждаем STM32 конкретный МК.

Добавлено after 2 minutes 26 seconds:
[uquote="Z_h_e",url="/forum/viewtopic.php?p=3271546#p3271546"]

Дело в том что ICODE шина подключена к флешу, а DCODE к ОЗУ. Инструкции быстрее идут из флеш, а данные из ОЗУ.

Самый первый пост и самая первая ссылка. Там тест опровергает и это утверждение. Код то наоборот сработал. Еще раз говорю, пришел к выводу что нельзя говорить что-то однозначно. Может вывод и неверный, но пока так думать оснований нет.[/uquote]

Что у вас там сработало я не разбирался.
Это из референса я говорю:

ICode bus
This bus connects the Instruction bus of the Cortex
®
-M3 core to the Flash memory
instruction interface. Prefetching is performed on this bus.

DCode bus
This bus connects the DCode bus (literalload and debug access) of the Cortex
®
-M3 core to
the Flash memory Data interface.

[jcxz]

[uquote="Oxford",url="/forum/viewtopic.php?p=3271535#p3271535"]Дело в том что ICODE шина подключена к флешу, а DCODE к ОЗУ. Инструкции быстрее идут из флеш, а данные из ОЗУ.[/uquote]
Чтобы так утверждать, нужно указывать о каком МК идёт речь. Так как это несправедливо для всех ARM.
Для XMC4700:

Спойлер

Для LPC1778/LPC1788:

Спойлер

Спойлер

[Z_h_e]

А я и не опровергаю архитектуру МК. Однако код в ОЗУ сработал быстрее. Вы сказали

Инструкции быстрее идут из флеш, а данные из ОЗУ.

, в том тесте это было наоборот. В других последующих соответствовало этому.

Сейчас то мы о чем говорим? Я создал топик, чтобы выяснить откуда код работает быстрее. Инфы об этом было мало и противоречива. Теперь ее больше и понятно почему была противоречива эта инфа. И вроде как вопрос выяснен.

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

-----
З.Ы. Само собой не было цели проверить это именно для f103, просто он был под рукой у меня. А более навороченные я не планирую приобретать, мне пока этого хватает.

З.З.Ы. Пойду винца накачу , выходной блин завтра сорвался, жаль.

[Oxford]

[uquote="jcxz",url="/forum/viewtopic.php?p=3271553#p3271553"][uquote="Oxford",url="/forum/viewtopic.php?p=3271535#p3271535"]Дело в том что ICODE шина подключена к флешу, а DCODE к ОЗУ. Инструкции быстрее идут из флеш, а данные из ОЗУ.[/uquote]
Чтобы так утверждать, нужно указывать о каком МК идёт речь. Так как это несправедливо для всех ARM.
Для XMC4700:

Спойлер

Для LPC1778/LPC1788:

Спойлер

Спойлер

[/uquote]

Так он и в стм32 может выбирать инструкции из ОЗУ через BusMatrix. В чем смысл?
В XMC4700 Cortex-M4 и так же через BusMatrix
Архитектуры то идентичные. Это все справедливо для всех практически кортексов с гарвардской архитектурой. Конвеер, две шины для инструкций и данных, параллельная выборка.

Просто прикол в том как из ОЗУ например параллельно выборку данных и инструкций делать по двум шинам сразу? В этом и суть гарвардской архитектуры что хранилище инструкций и данных это два разных физически устройства и позволяют делать параллельную выборку.
Выбрали операнды, выбрали инструкцию, выполнили, выгрузили результат. Именно параллельная выборка ускоряет исполнение за меньшее количество тактов + конвеер еще ускоряет.

Добавлено after 16 minutes 36 seconds:
[uquote="Z_h_e",url="/forum/viewtopic.php?p=3271101#p3271101"]Лучше всего конечно это поправить файл линковщика. Но мне было лень, я не очень с ним на "ты" и надо тихонько скрипеть мозгами.

Делал так.
Атрибуты массива закоментарьте, не сработали. Но мой компилятор массив констант (const) сам определяет во флеш без дополнительного указания. Убрав const - массив перебирается в ОЗУ.

Чтобы зарядить foo в озу в прототип добавлял атрибут __attribute__((section(".data")));.
В коде что я Вам скинул он закоментарен, что означает фу во флеше.

Перед тестом обязательно запускал отладку и проверял кто куда попал на случай "вдруг затупил" и только после этого перезапускал МК и считывал частоту.

Добавлено after 2 minutes 13 seconds:
Компилятор GCC. У Вас может как-то по другому.[/uquote]

С чего вы взяли что __attribute__((section(".data"))); функцию переносит в ОЗУ?

[Z_h_e]

1.Потому что эта секция в ОЗУ.
2."Перед тестом обязательно запускал отладку и проверял кто куда попал на случай "вдруг затупил" и только после этого перезапускал МК и считывал частоту."
3. Вы просили выложить дизассеблер зачем то, я выложил, адреса там есть.

[Oxford]

Как понять секция в ОЗУ?

[Z_h_e]

Адресное пространство для этой секции в линковщике определено в области ОЗУ.

[Oxford]

А почему у меня из флеш исполняется?

[Z_h_e]

Вы про весь код или про функцию foo?

[Oxford]

Про функцию

Screenshot_15.png

(66.5 КБ) 309 скачиваний

[Z_h_e]

Нечего не могу ответить. Прототип не забыли разкоментарить?
Я проверял в отладке по шагам куда идет прыжок, в окне watch смотрел адрес массива и адрес функции. Ну и сами дизасеблерные коды подтверждали.
У меня нет никаких сомнений в правильности расположения кода в моих тестах.

[Oxford]

ну на фото что не видно расскоментирован или нет? У меня массив во флеш лежит.
Const переносит массив во флеш. Вы видать этого не знали.
const убрал переполз в ОЗУ.

[Z_h_e]

Это Keil? У него компилятор GCC?

[Oxford]

[uquote="Z_h_e",url="/forum/viewtopic.php?p=3271584#p3271584"]1.Потому что эта секция в ОЗУ.
2."Перед тестом обязательно запускал отладку и проверял кто куда попал на случай "вдруг затупил" и только после этого перезапускал МК и считывал частоту."
3. Вы просили выложить дизассеблер зачем то, я выложил, адреса там есть.[/uquote]
Это не секция в ОЗУ. Это секция в IMAGE

Сдается мне вы нас нае...ываете.

[jcxz]

[uquote="Oxford",url="/forum/viewtopic.php?p=3271569#p3271569"]С чего вы взяли что __attribute__((section(".data"))); функцию переносит в ОЗУ?[/uquote]
Не пользуюсь Кейлом и такими конструкциями, но, раз данная строка находится в исходнике (*.c или *.cpp), то очевидно что она переносит не в ОЗУ, а в секцию ".data" объектного файла. А уж куда какие объектные секции в какие области памяти линковать - за это командный файл компоновщика отвечает, а не компилятор.

[Z_h_e]

Я тут никому ничего доказывать и убеждать в чем то не собираюсь и не делаю этого.
Все что тут я напостил делал для себя и для обсуждения. Если есть желание. Найдите мне секцию image для компилятора GCC, я ее не нашел. Вот файл линкера.

Спойлер

Код: Выделить всё

OUTPUT_FORMAT ("elf32-littlearm", "elf32-bigarm", "elf32-littlearm")
/* Internal Memory Map*/
MEMORY
{
	rom (rx)  : ORIGIN = 0x08000000, LENGTH = 0x00010000
	ram (rwx) : ORIGIN = 0x20000000, LENGTH = 0x00005000
}

_eram = 0x20000000 + 0x00005000;
SECTIONS
{
	.text :
	{
		
		KEEP(*(.isr_vector))
		*(.text*)
		
		KEEP(*(.init))
		KEEP(*(.fini))
		
		/* .ctors */
		*crtbegin.o(.ctors)
		*crtbegin?.o(.ctors)
		*(EXCLUDE_FILE(*crtend?.o *crtend.o) .ctors)
		*(SORT(.ctors.*))
		*(.ctors)
		
		/* .dtors */
		*crtbegin.o(.dtors)
		*crtbegin?.o(.dtors)
		*(EXCLUDE_FILE(*crtend?.o *crtend.o) .dtors)
		*(SORT(.dtors.*))
		*(.dtors)
		
		*(.rodata*)
		
		KEEP(*(.eh_fram e*))
	} > rom 
	
	.ARM.extab : 
	{
		*(.ARM.extab* .gnu.linkonce.armextab.*)
	} > rom 
	
	__exidx_start = .;
	.ARM.exidx :
	{
		*(.ARM.exidx* .gnu.linkonce.armexidx.*)
	} > rom 
	__exidx_end = .;
	__etext = .;
	
	/* _sidata is used in coide startup code */
	_sidata = __etext;
	
	.data : AT (__etext)
	{
		__data_start__ = .;
		
		/* _sdata is used in coide startup code */
		_sdata = __data_start__;
		
		*(vtable)
		*(.data*)
		
		. = ALIGN(4);
		/* preinit data */
		PROVIDE_HIDDEN (__preinit_array_start = .);
		KEEP(*(.preinit_array))
		PROVIDE_HIDDEN (__preinit_array_end = .);
		
		. = ALIGN(4);
		/* init data */
		PROVIDE_HIDDEN (__init_array_start = .);
		KEEP(*(SORT(.init_array.*)))
		KEEP(*(.init_array))
		PROVIDE_HIDDEN (__init_array_end = .);
		
		. = ALIGN(4);
		/* finit data */
		PROVIDE_HIDDEN (__fini_array_start = .);
		KEEP(*(SORT(.fini_array.*)))
		KEEP(*(.fini_array))
		PROVIDE_HIDDEN (__fini_array_end = .);
		
		KEEP(*(.jcr*))
		. = ALIGN(4);
		/* All data end */
		__data_end__ = .;
		
		/* _edata is used in coide startup code */
		_edata = __data_end__;
	} > ram 
	
	.bss :
	{
		. = ALIGN(4);
		__bss_start__ = .;
		_sbss = __bss_start__;
		*(.bss*)
		*(COMMON)
		. = ALIGN(4);
		__bss_end__ = .;
		_ebss = __bss_end__;
	} > ram 
		
	.heap (COPY):
	{
		__end__ = .;
		_end = __end__;
		end = __end__;
		*(.heap*)
		__HeapLimit = .;
	} > ram 
	
	/* .stack_dummy section doesn't contains any symbols. It is only
	* used for linker to calculate size of stack sections, and assign
	* values to stack symbols later */
	.co_stack (NOLOAD):
	{
		. = ALIGN(8);
		*(.co_stack .co_stack.*)
	} > ram 
	
	/* Set stack top to end of ram , and stack limit move down by
	* size of stack_dummy section */
	__StackTop = ORIGIN(ram ) + LENGTH(ram );
	__StackLimit = __StackTop - SIZEOF(.co_stack);
	PROVIDE(__stack = __StackTop);
	
	/* Check if data + heap + stack exceeds ram  limit */
	ASSERT(__StackLimit >= __HeapLimit, "region ram  overflowed with stack")
}

Сдается мне вы нас нае...ываете.

Но если все же Вы так считаете, то ради бога. Данное Ваше мнение мне абсолютно фиолетово.

[Oxford]

скиньте Map файл. Вы просто функцию свою обьявили в секции data в образе. Но с чего вы думаете что она от этого начнется исполняться в ОЗУ, если код находиться во флеш? Вы что физически переключили шины? Я уже показал что код не переноситься в ОЗУ, а исполняется из флеш.

[Z_h_e]

Зачем? Я так понимаю Вы решили, что я адреса в коде дизассеблера отредактировал. Несомненно чтобы Вас дезоинформировать (это мечта всей моей жизни была). Неужели Вы думаете что я разрушу свою мечту и в мапе такого не сделаю?
Или может видео записать затем нужно будет?

Я уже сказал , мне фиолетово что Вы думаете обо мне и доказывать ничего не собираюсь.

З.Ы. Все частоты я придумал, тоже специально для Вас.

[Oxford]

Посмотреть карту обьектного файла. Я пока лишь разбираюсь и нахожу ошибки.