https: // github.com/rogerclarkmelbourne/ ... 2/тяга/238

Изменения в максимальном размере и т. Д. В досках.TXT на платах F4. Наверное, хорошо, но у меня не было времени проверить

Кажется, работает нормально: Sketch uses 21,548 bytes (4%) of program storage space. Maximum is 514,288 bytes. Global variables use 12,064 bytes (6%) of dynamic memory, leaving 184,544 bytes for local variables. Maximum is 196,608 bytes.

Это просто информация, взятая из досок.TXT или вы действительно можете выделить 192 КБ ОЗУ??

Просто информация, взятая из досок.текст.
Используется (теоретически) 128 КБ нормальная ОЗУ + 64 КБ CCMRAM.

Я почти уверен, что это разделено 128 тыс & CCRAM - 64 тыс., По крайней мере, один чип имеет 4K -кусок из 196K зарезервирована и зарезервирована

Из моей коллекции разных файлов линкеров F4, Grep для -i ccmram | grep -i Origin
Debug_STM32F407VG_FLASH.ld: CCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K Debug_STM32F407VG_RAM.ld: CCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K STM32F407VETx_FLASH.ld:CCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K STM32F407VG_FLASH.ld:CCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K STM32F407VGTx_FLASH.ld:CCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K STM32F407ZGTx_FLASH.ld:CCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K STM32F417ZGTx_FLASH.ld:CCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K STM32F429ZI_FLASH.ld:CCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K STM32F429ZITx_FLASH.ld:CCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K stm32f4_flash.ld: CCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K stm32f4zgt.ld:CCMRAM (rw) : ORIGIN = 0x10000000, LENGTH = 64K

Большинство наших сценариев линкера не объявлены CCM. Я сделал это для нескольких досок только для тестирования, но вы не можете использовать все это в качестве единого блока, так как адреса не выстраиваются в очередь, а на Top CCC в F4 нельзя использовать для кода или DMA, в то время как это может быть используется для кода в F3...
Но баран есть, поскольку эти изменения только влияют на IDE, сообщающий об размере, а что нет, и не вызывают никаких изменений в сценарии линкера, я думаю, не нормально, чтобы держать их так.
Если мы решим добавить CCC в сценарии линкеров в будущем, то мы действительно можем использовать этот ОЗУ.

Другой вариант заключается в том, чтобы изменить эти значения на то, что у нас в настоящее время есть в сценариях линкеров (например, 112 КБ для некоторого F4 и так далее) и оставить количество CCM общей суммы, поскольку мы в настоящее время не используем его.

Кстати, если кто -то заинтересован в использовании CCM, я изменил сценарии либмапл -линкеров для F3 и F4 для тестирования и могу их пройти на.
Я думаю, что однажды я поместил буферы USB F4 в CCM, поскольку USB не использует DMA, это хороший способ получить большой буфер с 0 стоимостью в оперативной памяти и более быстрая скорость из -за того, что он не обменивается.

Если в файле линкера нет соответствующих изменений такого, он действительно выделяет 192 КБ, я бы остался с 128 КБ в информации, взятой из досок.текст..

Пост Стива показывает более 128 тыс. Доступно.
Следите за подходящим значением «памяти, доступной непосредственно», в досках.текст
Стивен

[ZMEMW16 - Пн, 3 июля 2017 г. 11:17 вечера] - Пост Стива показывает более 128 тыс. Доступно.
Следите за подходящим значением «памяти, доступной непосредственно», в досках.текст
Стивен

Память, установленная в досках.TXT - это тот, который IDE использует, чтобы показать, сколько оперативной памяти у вас есть всего и осталось, но не используется сценарием линкера для распределения памяти. То, что показывает пост Стива, это то, что IDE читает с досок.текст.
Вы можете установить доски на 512 МБ ОЗУ, и линкер все равно не заботится об этом и использовать то, что в сценариях линкера.

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

Я вроде согласен с Пито, что, если мы не решим продолжить изменения в сценариях и стартапе для использования, было бы лучше сообщить только о основной оперативной памяти в досках.текст.
Побочные эффекты отчетности 192 КБ, в то время как линкер выделяет только 128 КБ заключается в том, что IDE может сообщать вам, что вы выделяете 128 КБ оперативной памяти и при этом есть 64 КБ доступны для локальных переменных (и стека), в то время как в реальности ваш код будет разбит, потому что нет свободное место для даже стека.

[Пито - Пн, 3 июля 2017 г. 9:09 вечера] - Если в файле линкера нет соответствующих изменений такого, он действительно выделяет 192 КБ, я бы остался с 128 КБ в информации, взятой из досок.текст..

Я тоже.
Но давайте включим эту функцию, приятно иметь ее.

Долгое время назад я встретился с Elua, и мне удалось (с помощью экспертов сообщества) распределить полный 192 КБ для Elua на F4. Это было сделано с помощью директивы «Allocator = несколько» и, возможно, 2 строки в сценарии, определяющего настройку памяти. И это сработало. Быть не талантливым программистом, я должен копаться в старые темы, чтобы узнать, как это работает..

PS: http: // elua-development.2368040.н2.наб ... 82063.HTML
PPS: Elua использует Scons вместо создания..
Allocator = Newlib | несколько | Простой: выберите между Allocator Newlib по умолчанию (NewLib), который является более старой версией DLMALLOC, распределителя с несколькими пространствами памяти (несколько), которая является более новой версией DLMALLOC, который может обрабатывать несколько пространств памяти и очень простой распределитель памяти (просто) это медленно и не’T -обрабатывать фрагментацию очень хорошо, но это требует очень мало ресурсов (Flash/Ram). Вам следует использовать многочисленные выплаты только в том случае, если вам нужно поддерживать несколько пространств памяти (например, платы с внешней ОЗУ). Вы должны использовать просто только в очень ограниченных системах. Таким образом, освоение множественных фрагментированных пространств SRAM было бы здесь большим достижением - подумайте о предстоящем STM32H7 может 4 6 (Обновление: 128+64+512+288+64+4) внутренние рассеянные пространства SRAM плюс внешнее пространство SRAM/SDRAM также также

[Пито - Вторник 04 июля 2017 г. 8:48 утра] - Долгое время назад я встретился с Elua, и мне удалось (с помощью экспертов сообщества) распределить полный 192 КБ для Elua на F4. Это было сделано с помощью директивы «Allocator = несколько» и, возможно, 2 строки в сценарии, определяющего настройку памяти. И это сработало. Быть не талантливым программистом, я должен копаться в старые темы, чтобы узнать, как это работает..

PS: http: // elua-development.2368040.н2.наб ... 82063.HTML
PPS: Elua использует Scons вместо создания..
Allocator = Newlib | несколько | Простой: выберите между Allocator Newlib по умолчанию (NewLib), который является более старой версией DLMALLOC, распределителя с несколькими пространствами памяти (несколько), которая является более новой версией DLMALLOC, который может обрабатывать несколько пространств памяти и очень простой распределитель памяти (просто) это медленно и не’T -обрабатывать фрагментацию очень хорошо, но это требует очень мало ресурсов (Flash/Ram). Вам следует использовать многочисленные выплаты только в том случае, если вам нужно поддерживать несколько пространств памяти (например, платы с внешней ОЗУ). Вы должны использовать просто только в очень ограниченных системах. Таким образом, освоение множественных фрагментированных пространств SRAM было бы здесь большим достижением - подумайте о предстоящем STM32H7 может 4 6 (Обновление: 128+64+512+288+64+4) внутренние рассеянные пространства SRAM плюс внешнее пространство SRAM/SDRAM также также

Я знаю, как разместить стек, кучу или что -то еще, что мы хотим в CCM Ram. Я не знаю, как заставить линкера поместить что -либо в той или иной. Я проверил этот поток, но кажется, что выделение - это функция, а не что -то в сценарии линкера, это правильно?

Принуждение стека и кучи там не сложно, проблематичная часть заключается в том, что код пользователя создает буфер во время выполнения, который переходит в стек или кучу, и пытается использовать его для DMA, он будет сбой.
Кроме этого, отлично подходит для этих использования и оставляет основную часть оперативной памяти, которая будет использоваться для глобальных переменных пользователей, буферизации и т. Д. Но хотим ли мы этот риск?
Возможно, мы сможем использовать опцию компиляции, чтобы сказать, хотим ли мы стека и куча или что -то еще, в CCM, поэтому, если мы знаем, что нам нужно сделать DMA в локальной переменной или на Malloc, мы выбираем параметры платы, чтобы избежать ее?

но кажется, что выделитель - это функция, а не что -то в сценарии линкера, это правильно? Elua создает Scons, Allocator = Multy - это параметр Scons, основанный на том, что он включает Dlmalloc.C (130 КБ большой источник) в сборку. Сам компилятор был CodeSourcery. Честно говоря, подробности не известны мне, так как сборка Elua - довольно сложное упражнение.
Я думаю, что решение о доступных переменных DMA должно быть оставлено на пользователе (через некоторые атрибуты) в качестве создания системы сборки, которая будет рассмотреть все нюансы, связанные с MCU..

Я думаю, что на данный момент хорошо, исключите оперативную память CCM из информации, полученной в конце компиляции, поэтому пользователь знает, сколько реальных возможностей для управления оперативной памятью в реальной версии ядра.

Если в будущем, если будет реализовано использование RAM CCM, я думаю, что лучше объяснить, что также на доске.txt и не просто увеличить отображаемое значение, например, должно быть: Sketch uses 21,548 bytes (4%) of program storage space. Maximum is 514,288 bytes. Global variables use 12,064 bytes (9%) of dynamic memory CCM Ram use xxx bytes. Maximum is xxx bytes

Добавление к обсуждению CCM в этой теме:
В MCU F4 у нас есть 64 КБ памяти CCM.
Есть 2 ограничения с использованием CCM:

• Память CCM может использоваться для данных, код не может быть запущен из нее.
• Контроллеры DMA не могут получить доступ

Преимущество заключается в том, что CCM используется исключительно MCU в отдельной шине, поэтому не разделяет пропускную способность с любой другой памятью или периферийной.
Теоретически у вас может быть быстрый DMA, продолжающийся в обычной оперативной памяти, в то время как процессор работает из Flash, используя данные CCM без штрафа в процессоре или производительности DMA.

Имея это в виду, есть 3 возможных применения для CCM:

• Куча
• Куча
• Нормальные пользовательские переменные.

Пока мы не используем эти переменные, выделенные в этих блоках для DMA, все это хорошо.
В прошлом в качестве доказательства концепции я изменил код USB от Стива, чтобы выделить свои буферы в CCM. Было не так много проблем, и дает возможность использовать большие буферы, не взявшись с обычного ОЗУ.
Я также выделил кучу и стек на CCM, и это обеспечило небольшое усиление скорости в одном из контрольных показателей ЦП.
Я не тестировал, как Racemaniac, чтобы подтолкнуть CPU+DMA, но должен разрешить более параллельные операции без штрафа.

Теперь распределение всех обычных данных на CCM очень рискованно, потому что, если пользователь выделяет буфер для использования DMA там, код будет сбой.
Куча и стек могут использоваться и для переменных, так что это несколько рискованно, но большинство людей, использующих DMA.

Имея в виду все эти условия, я думал, что хороший компромисс по использованию CCM, не причиняя большой боли, заключается в том, чтобы позволить ему в качестве варианта доски. Подобно выбору между загрузкой STLINK или загрузкой загрузчика заставляет лингер использовать другой сценарий линкера с различными адресами, мы могли бы добавить опцию, в которой используется стек сценария и куча в CCM.
Мы также можем добавить #define в ядро, аналогично тому, как __flash__ определяется, чтобы позволить пользователю заставлять переменную вспышку (это не часто используется, поскольку линкер в любом случае будет помещать данные RO во Flash, но это в ядре):
#define __attr_flash __attribute__((section (".USER_FLASH"))) #define __FLASH__ __attr_flash

Я бы приветствовал кучу и стек в CCM.
Я бы сделал это по умолчанию.

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

Одним из специальных случаев будет написание того же данных с DMA (без приращения указателя источника), но для этого мы могли бы адаптировать функции SPI DMA для преобразования в глобальный буфер (в нормальном ОЗУ) входные данные передаваемого буфера [0 ].

[Стивестронг - Сб 29 июля 2017 г. 15:02] - Я бы приветствовал кучу и стек в CCM.
Я бы сделал это по умолчанию.

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

Одним из специальных случаев будет написание того же данных с DMA (без приращения указателя источника), но для этого мы могли бы адаптировать функции SPI DMA для преобразования в глобальный буфер (в нормальном ОЗУ) входные данные передаваемого буфера [0 ].

Это хороший вариант, надеюсь, не будет стоить много циклов. Что -то, что сравнивает адрес указателя с диапазоном CCM, если он соответствует, сделайте копию.
Или, возможно, добавить утверждение, которое не удается во время компиляции, если использует адрес CCM?

Немного не по теме, но из тестов @Racememaniac DMA Speed, я не думаю, что этот баран находится в отдельном автобусе.глин. Память в память DMA в то же время, что и DMA TO SPI.

[Rogerclark - Сб 29 июля 2017 г. 9:59 вечера] - Немного не по теме, но из тестов @Racememaniac DMA Speed, я не думаю, что этот баран находится в отдельном автобусе.глин. Память в память DMA в то же время, что и DMA TO SPI.

Все зависит, для некоторых применений может быть улучшение производительности, для других может быть приятно использовать дополнительные 64 КБ.
Что вы думаете о предложении Стива переместить кучу и стека в CCM?

Что такое преимущество для перемещения как стека, так и кучи в CCM ?

Конечно, было бы лучше перемещать только стек или кучу, чтобы оба получили больше места.

Я считаю, что, поскольку мы обычно не используем «новое», куча не сильно растет, но мое понимание того, для чего используется куча ограничена.
Стек растет, но 64 КБ - это много для обоих.
На своих тестах я переместил область BSS, PINMAP и USB -буферы в разное время.

Я только что отправил пиар для вилки Стива с изменениями, чтобы переехать кучу, стека и pinmap в CCMRAM, и добавить новый флаг __CCMRAM__, чтобы любая переменная могла быть перемещена к ней.
https: // github.com/stevstrong/arduino_stm32/pull/5

Я думаю, что изменения в основном пояснятельны, поэтому легко изменить, чтобы оставить любого из тех, кто из CCMRAM, но приведен пример, охватывающий эти использование

BSS может быть успешно перемещен из моих тестов, но любая переменная, объявленная атрибутами по умолчанию (не вынуждена нормальной оперативной памяти), вызовет сбой, если используется для DMA, поскольку контроллеры DMA не могут получить доступ к CCMRAM.

Я думаю, что наилучшим использованием причина является вручную добавлять __CCMRAM__ к ​​объявлению любой переменной, которую знает пользователь, не будет использоваться для DMA, и в то же время требуется частый доступ, поскольку CCMRAM может быть быстрее, чем обычная оперативная память только из -за доступа к доступу ЦП.
PINMAP - просто хороший пример из -за того, что он большой и не используется в качестве указателя для DMA.

Я думал, что PIN_MAP находится в вспышке и будет там.
Я лично не вижу никакой выгоды, поместив его в CCMRAM, за исключением сохранения некоторых циклов процессора, которые для F4 не так критичны, как в любом случае...

[Стивестронг - Вторник 8 августа 2017 г. 11:21] - Я думал, что PIN_MAP находится в вспышке и будет там.
Я лично не вижу никакой выгоды, поместив его в CCMRAM, за исключением сохранения некоторых циклов процессора, которые для F4 не так критичны, как в любом случае...

В версии ядра, где я использовал CCMRAM PIN_MAP все еще в оперативной памяти, поэтому я проверил перемещение его в CCMRAM. Согласился, что вспышка - лучшее место для этого. Но это приводит пример того, что нужно для того, чтобы что -то перенести в CCM.
С тем же атрибутом я переместил USB -буферы, и почти все, что не будет использоваться во время DMA, и мы хотим, чтобы там можно было перенести высокую производительность.

Да, может быть.

Это только для записи: куча и стек, в целом

Стив, я только что прокомментировал в PR.
/*, Который отсутствовал, сейчас исправлено, но этикетка __CCM_END__, возможно, мы должны изменить его на что -то другое. Он использовался правильным способом, но смысл не то, что вы думали, он должен указать на конец переменных, выделенных для CCMRAM, поэтому куча может начаться после последней переменной, выделенной там.

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

Кажется, что я неправильно понял функциональность из -за использования именования.
Вот что я думаю, я понял:

CCM начинается с 0x10000000. Это должно быть называться __CCMRAM_START__.
CCM заканчивается 64 КБ после __CCMRAM_START__. Это следует называться __CCMRAM_END__. Это значение, которое указатель стека должен быть инициализирован, справа? В этом случае __msp_init расчет имеет не слишком большой смысл для меня и должен быть прикреплен к __CCMRAM_END__.

Возвращаясь к началу CCM, распределяются некоторые переменные, скажем, до 0x10001234. Это тогда начало кучи, справа? Если так, то это должно быть названо __CCMRAM__HEAP_START__. Тогда куча может подняться до __CCMRAM_END__?

Стек: начинается с __CCMRAM_END__ и теоретически переживает до __CCMRAM__HEAP_START__, верно?

Я знаю, голова и стек могут перекрываться в этих условиях, но 64 КБ - это много места для кучи и стека вместе.

[Стивестронг - Вторник 8 августа 2017 г. 16:48] - Кажется, что я неправильно понял функциональность из -за использования именования.
Вот что я думаю, я понял:

CCM начинается с 0x10000000. Это должно быть называться __CCMRAM_START__.
CCM заканчивается 64 КБ после __CCMRAM_START__. Это следует называться __CCMRAM_END__. Это значение, которое указатель стека должен быть инициализирован, справа? В этом случае __msp_init расчет имеет не слишком большой смысл для меня и должен быть прикреплен к __CCMRAM_END__.

Возвращаясь к началу CCM, распределяются некоторые переменные, скажем, до 0x10001234. Это тогда начало кучи, справа? Если так, то это должно быть названо __CCMRAM__HEAP_START__. Тогда куча может подняться до __CCMRAM_END__?

Стек: начинается с __CCMRAM_END__ и теоретически переживает до __CCMRAM__HEAP_START__, верно?

Я знаю, голова и стек могут перекрываться в этих условиях, но 64 КБ - это много места для кучи и стека вместе.

Так работает.
Теперь, __CCMRAM_END__ все еще необходимо рассчитать, как то, как мы объявляем блоки памяти в JTAG.LD (и остальные из них) - по началу и длине, поэтому линкер должен рассчитывать конечный адрес. Ничего страшного, это часть всех сценариев линкеров, которые мы используем для разных досок. Я оставлю его под названием MSP_INIT, так как это же имя используется в других сценариях линкера для всех других досок, поэтому пытаясь сохранить как можно больше.

Что я сделаю, так это изменить имя __CCMRAM_END__ на __CCMRAM_HEAP_START__

Если мы не получим переполнение стека с помощью MINI с 20 КБ, 64 КБ обязательно не должно вызывать никаких проблем. Каждый должен в любом случае избегать использования Malloc и нового как можно больше, так что куча обычно не должна расти. Но я помню, что где -то читали некоторые встроенные компиляторы, помещают несколько локальных больших переменных в кучу вместо стека, и это то, что меня немного смутило в том, насколько вероятно, что куча поднимется,

Я читал больше на нем, и один из способов выяснить, было ли столкновение между кучей и стеком, вызвавшее сбой Образец исчез.
Freertos использует аналогичную систему (метод 2):
http: // www.Freertos.org/stacks и stac ... кокринг.HTML

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

РЕДАКТИРОВАТЬ:
Чтобы соответствовать тому, каким образом этикетки сценариев LD до сих пор, я внося следующие изменения:
1.- .Секция CCMRAM переименован в .CCMDATA. Этот раздел состоит в том, чтобы хранить данные (переменные), выделенные на CCMRAM.
2.- Метка для начала раздела переименована в __CCMDATA_START__, чтобы соответствовать нормальной метке секции данных (__DATA_START__).
3.- Конец секции помечен __CCMDATA_END__, чтобы соответствовать нормальному разделу ОЗУ (__DATA_END__)
4.- Запуск кучи находится по адресу __ccmdata_end__, поэтому четко указывает на то, что она начинается, где заканчиваются данные.