Посмотрите таблицы, Flash или SRAM?

Используется платформа STM32F4, которая имеет 192kBytes SRAM, что мне достаточно.

Я пытаюсь создать справочную таблицу. LUT будет использоваться в расчетах несколько раз. И я хочу положить его в SRAM в процессе расчета, вместо FLASH, так как чтение SRAM происходит быстрее, чем чтение FLASH для ядра.

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

И если кто-нибудь знает CCM, стоит ли ставить LUT в CCM во время вычислений?

Насколько велик LUT?
Как размер будет иметь значение? В моем приложении всего 32 числа с плавающей запятой.
Предположительно ( разработчик встраиваемых систем IANA ), если емкость основной связанной памяти используется недостаточно, размещение LUT позволит избежать конфликтов и обеспечит предсказуемое время. Копирование LUT из основной SRAM в CCM при каждом использовании может быть полезным, если другие компоненты будут одновременно активно использовать SRAM, а количество операций поиска достаточно велико (например, если ядру доступна только половина циклов шины SRAM, копирование 32). значения могут добавить 80 циклов [1,5 для загрузки из SRAM, 1 для сохранения в CCM], делая 160 поисковых запросов безубыточными при 1,5 циклах каждый для SRAM по сравнению с 1 циклом для CCM).
Помимо ценового компромисса между SRAM и Flash, есть также небольшой кэш для более крупных устройств STM32 (в отличие, скажем, от AVR). Таким образом, время доступа к SRAM не является полностью предсказуемым — оно будет зависеть от того, находится ли LUT в данный момент в кэше или его нужно сначала извлечь из SRAM в кэш.
@Damien Кэш предназначен для инструкций, а не для данных, я думаю, которые используются вместе с ART для stm32F407. Не могли бы вы проверить это?
@PaulA.Clayton Можно ли загружать данные из Flash в CCM при загрузке напрямую, а не через SRAM? И производительность во время выполнения более важна, загрузку из SRAM в CCM можно рассматривать как инициализацию.
Техническое описание : «Оперативная память доступна (чтение/запись) на тактовой частоте ЦП с 0 состояниями ожидания».
Спецификация : «Чтобы высвободить процессор с полной производительностью 210 DMIPS на этой частоте, ускоритель реализует очередь предварительной выборки инструкций и кеш ветвлений, что увеличивает скорость выполнения программы из 128-битной флэш-памяти».
Итак, мой вывод: если вам нужно получить что-то из LUT, хранящегося только во флеш-памяти, и этой части LUT в данный момент нет в кеше, то вы почти наверняка получите зависание процессора, т.к. полученные акселератором ART. Это очень сильно способствует размещению LUT в SRAM, если (конечно) там достаточно места.
Я согласен с тобой, Дэмиен. Только один комментарий, LUT не может быть загружен кешем, я думаю. Кэш предназначен только для инструкций, а не данных.
Если кеш действительно предназначен только для инструкций, то у нас не будет другого выбора, кроме как сократить циклы ожидания шины для получения LUT из флэш-памяти. Это может привести к тому, что процессор какое-то время будет мало работать, в зависимости от скорости флэш-памяти (и от того, кто еще хочет получить доступ к шине).
Можем ли мы просто загрузить LUT из флэш-памяти в SRAM, и каждый раз, когда выполняется вычисление, данные будут записываться прямо из SRAM?
@Damien Является ли состояние ожидания 0 для ОЗУ при условии отсутствия конкуренции со стороны других доступов (т. Е. Задержка в 1 цикл)? В противном случае он должен быть двухпортовым или всегда отдавать приоритет основному и, возможно, лишать других пользователей возможности (например, DMA). Этот пост в блоге, кажется, указывает на то, что конкуренция является проблемой и причиной для использования CCM.
@richieqianle Если LUT небольшой, попробуйте разместить его в SRAM или, что еще лучше, в CCM. Это позволит избежать зависаний в процессе его загрузки из флэш-памяти в SRAM. Смотрите также ответ ниже.
@PaulA.Clayton, я бы резюмировал этот пост в блоге как ответ и предоставил некоторый контекст. Он отвечает на все в ОП.
@ Дэмиен Ну, тогда сделай это.

Ответы (1)

Простое определение таблицы без ключевого слова const приведет к тому, что таблица будет скопирована из Flash в RAM при запуске вашей программы; например

const short ax [] = { 1, 2, 3, 4 };      // stays in Flash
short bx [] = { 5, 6, 7, 8 };            // starts in Flash, copied to RAM

Вы можете проверить это поведение с помощью следующих двух строк кода:

bx[0] = ax[0];    // allowed, since you are modifying a RAM variable
ax[0] = bx[0];    // not allowed, ax is const

Я проверил это с помощью компилятора IAR для семейства STM32F10. Я не знаю, что такое CCM, извините.

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

CCM — это память, связанная с ядром. «Эта тесная связь памяти CCM с ядром приводит к нулевым состояниям ожидания, другими словами, ядро ​​имеет эксклюзивный доступ к этому блоку памяти, поэтому, например, пока другие мастера шины используют основную SRAM, ядро ​​может получить доступ к СКК». ( источник )
Ключевое слово "const" не гарантирует , что данные будут только в SRAM - поведение будет зависеть от компилятора. См., например, avr-libc .
Примечание также для пользователей C++: относительно константности. const_cast удалит ключевое слово const, поэтому, если вы полагаетесь на ключевое слово const для встраивания данных во флэш-память, будьте осторожны с этим поведением .
Посмотрите таблицы, Flash или SRAM?
СпросиСетьПолитика конфиденциальности1y, 0v