Flash vs SRAM

[Z_h_e]

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

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

[Oxford]

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

Добавлено after 2 minutes 26 seconds:

Z_h_e писал(а):

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

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

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

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.

Последний раз редактировалось Oxford Пт дек 29, 2017 15:08:39, всего редактировалось 1 раз.

[jcxz]

Oxford писал(а):

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

Чтобы так утверждать, нужно указывать о каком МК идёт речь. Так как это несправедливо для всех ARM.
Для XMC4700:

Спойлер

Для LPC1778/LPC1788:

Спойлер

Спойлер

Вложения

bus-lpc17xx-2.gif

(170.95 KiB) Скачиваний: 400

bus-lpc17xx-1.gif

(136.09 KiB) Скачиваний: 401

bus.gif

(145.03 KiB) Скачиваний: 425

Последний раз редактировалось jcxz Пт дек 29, 2017 15:18:28, всего редактировалось 1 раз.

[Z_h_e]

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

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

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

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

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

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

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

[Oxford]

jcxz писал(а):

Oxford писал(а):

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

Чтобы так утверждать, нужно указывать о каком МК идёт речь. Так как это несправедливо для всех ARM.
Для XMC4700:

Спойлер

Для LPC1778/LPC1788:

Спойлер

Спойлер

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

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

Добавлено after 16 minutes 36 seconds:

Z_h_e писал(а):

Лучше всего конечно это поправить файл линковщика. Но мне было лень, я не очень с ним на "ты" и надо тихонько скрипеть мозгами.

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

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

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

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

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

[Z_h_e]

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

[Oxford]

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

[Z_h_e]

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

[Oxford]

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

[Z_h_e]

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

[Oxford]

Про функцию

Screenshot_15.png

(66.5 KiB) Скачиваний: 241

[Z_h_e]

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

[Oxford]

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

Последний раз редактировалось Oxford Пт дек 29, 2017 16:11:28, всего редактировалось 2 раз(а).

[Z_h_e]

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

[Oxford]

Z_h_e писал(а):

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

Это не секция в ОЗУ. Это секция в IMAGE

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

[jcxz]

Oxford писал(а):

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

Не пользуюсь Кейлом и такими конструкциями, но, раз данная строка находится в исходнике (*.c или *.cpp), то очевидно что она переносит не в ОЗУ, а в секцию ".data" объектного файла. А уж куда какие объектные секции в какие области памяти линковать - за это командный файл компоновщика отвечает, а не компилятор.

Последний раз редактировалось jcxz Пт дек 29, 2017 16:38:50, всего редактировалось 1 раз.

[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 в образе. Но с чего вы думаете что она от этого начнется исполняться в ОЗУ, если код находиться во флеш? Вы что физически переключили шины? Я уже показал что код не переноситься в ОЗУ, а исполняется из флеш.

Последний раз редактировалось Oxford Пт дек 29, 2017 16:52:58, всего редактировалось 1 раз.

[Z_h_e]

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

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

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

[Oxford]

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