[jcxz 195]

Во-первых:

3 часа назад, RusikOk сказал:

MEMORY
{
	FLASH(rx)		: ORIGIN = 0x08040000, LENGTH = 256K
	RAM(xrw)        	: ORIGIN = 0x20000000, LENGTH = 128K 	/* DTCM (64k) SRAM1 (240k) SRAM2 (16k) */
	RAM_ETH_DMA_RX(xrw)	: ORIGIN = 0x20018000, LENGTH = 0x100	/* Ethernet Rx DMA Descriptors */
	RAM_ETH_DMA_TX(xrw)	: ORIGIN = 0x20018100, LENGTH = 0x100	/* Ethernet Tx DMA Descriptors */
	RAM_ETH_RX(xrw)   	: ORIGIN = 0x20018200, LENGTH = 1524 * 8	/* Ethernet Receive Buffers */
	RAM_ETH_TX(xrw)   	: ORIGIN = 0x2001B1A0, LENGTH = 1524 * 8	/* Ethernet Transmit Buffers */
	RAM_SPI_DMA(xrw)	: ORIGIN = 0x20020000, LENGTH = 192K - _Min_Heap_Size - _Min_Stack_Size 	/* участок для данных от SPI */
}

определения региона RAM и последующих RAM_ETH_DMA_RX, ... - перекрываются. Разве такое допустимо?

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

У вас же всё сделано через одно небезъизвестное место. Теперь пытаетесь бороться с проблемами, которые сами же и создали.

[RusikOk 1]

3 минуты назад, jcxz сказал:

У вас же всё сделано через одно небезъизвестное место.

ну так скажите спасибо кубу. я ж не виноват, что у них все через ж.. сделано

[jcxz 195]

8 минут назад, RusikOk сказал:

ну так скажите спасибо кубу. я ж не виноват, что у них все через ж.. сделано

Причём тут куб, если это ваш командный файл?

Почему не описать один единый регион ОЗУ:

RAM(xrw)        	: ORIGIN = 0x20010000, LENGTH = 192K 	/* SRAM1 (192k) */

И скомпоновать все RW-секции данных в него? И для Ethernet и для DMA и пр.

DTCM - отдельный регион:

RAM(xrw)        	: ORIGIN = 0x20000000, LENGTH = 64K 	/* DTCM (64k) */

В DTCM-регион можно скомпоновать стеки задач.

[x893 40]

14 minutes ago, RusikOk said:

ну так скажите спасибо кубу. я ж не виноват, что у них все через ж.. сделано

При чем тут куб ? Изучайте arm-none-eabi-gcc и будет счастье

[EdgeAligned 58]

Так вот я о том и говорю - "закат солнца вручную" делать не обязательно. Размер кучи и стека не влияет на размер статически определенного массива. Статические массивы выделяются линкером на этапе компиляции. И если этот массив нужен для DMA, то его размер не должен зависеть от размера кучи. Не сделайте выстрел себе в ногу.

[RusikOk 1]

https://community.st.com/t5/stm32-mcus/how-to-create-project-for-stm32h7-with-ethernet-and-lwip-stack/ta-p/49308
вот инструкция от индийских специалистов по костылям. я так и сделал, оно еле завелось. как я еще должен это делать?

[tonyk_av 36]

8 hours ago, RusikOk said:

https://community.st.com/t5/stm32-mcus/how-to-create-project-for-stm32h7-with-ethernet-and-lwip-stack/ta-p/49308
вот инструкция от индийских специалистов по костылям. я так и сделал, оно еле завелось. как я еще должен это делать?

Так тут совсем другое описывается.

По ссылке описывается выделение буферов по нужным адресам, потому что сетевой контроллер работает с ними. Или я чё-то не так понял в хотелках вопрошающего?

[RusikOk 1]

7 часов назад, tonyk_av сказал:

По ссылке описывается выделение буферов по нужным адресам, потому что сетевой контроллер работает с ними.

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

и как я понял большинство людей которые хвалят куб сами им не пользуются. или максимум запустили блинк и на этом все

ну и по существу: есть ли возможность определить размер участка памяти определенного в *.ld из сишного кода при чем на этапе компиляции, чтоб я мог создать статический массив?

17 часов назад, EdgeAligned сказал:

Не сделайте выстрел себе в ногу.

массив в дальнейшем разбивается на меньшие части в зависимости от внешних факторов. но очень желательно, чтобы массив был как можно большим

[jcxz 195]

31 минуту назад, RusikOk сказал:

дело не в том, что сетевой контроллер не умеет работать с произвольными адресами а в том, что при включении кэширования памяти контроллер DMA не сможет правильно работать с такой памятью

Какое "кеширование памяти" для внутреннего ОЗУ МК? На кой оно сдалось в STM32? И как вы его собрались включать?

И о каком STM32 вообще речь?

31 минуту назад, RusikOk сказал:

и для этого нужно выделять участок с определенного адреса, чтобы этот же адрес подсунуть MPU через который нужно установить флаги MPU_ACCESS_NOT_BUFFERABLE MPU_ACCESS_NOT_CACHEABLE и главный MPU_ACCESS_SHAREABLE для участка памяти.

В каком STM32 это необходимо?

[EdgeAligned 58]

То есть как это? Статически объявленный массив не может быть изменен. То есть, если вы написали в сишном исходнике int array[100], компиль (линкер) назначил ему место в ОЗУ и связал адрес ммасива с его именем.  Если вы напишите снова int array[50], у вас будет либо конфликт имени (если в одной области видимости), либо для нового array[50] будет назначен другой участок в ОЗУ.
Если же вы создаете массив в виде указателя int *pArray = 0x.... , то это будет просто указатель на начальный адрес без определения размера массива.

34 минуты назад, RusikOk сказал:

куб сами им не пользуются. или максимум запустили блинк и на этом все

Это про меня 🙂 Я как раз в Кубе тыщщу лет назад запускал блинк просто посмотреть, че это такое сделали. Понравилась визуальная схема тактирования МК и подбора коэффициентов для PLL.

[x893 40]

19 minutes ago, jcxz said:

В каком STM32 это необходимо?

Например STM32H747

[EdgeAligned 58]

Который двухядерный то? У меня уже лет 5 лежит плата Дискавери с дисплеем на этом H747, и я чето так и не занимался им. Кстати, эта двухъядерная тема чето не получила распространения у ST.

[RusikOk 1]

использование кэширования актуально для всех М7 ядер. в моем конкретном случае stm32f756 после включения кэша скорость передачи данных по ethernet выросла с 2,5 до 4 МБ/с
зачем нужны 2 ядра я даже не представляю. может в качестве видеоадаптера)))

[tonyk_av 36]

1 hour ago, RusikOk said:

и все это можно сделать без костылей с файлом линковщика, но только не в кубИДЕ.

Причём тут Куб? Вы работаете с GCC, и я пока не сталкивался с тем, что в нём что-то нельзя было сделать.

3 minutes ago, RusikOk said:

зачем нужны 2 ядра я даже не представляю

Очень хорошо представляю. Давно хочу попробовать, но времени нет. Например, в ПЛК, когда на одной голове крутится программа пользователя, а на другая голова обслуживает коммуникационные интерфейсы и/или встроенную панель ЧМИ.

[RusikOk 1]

4 минуты назад, tonyk_av сказал:

что в нём что-то нельзя было сделать.

расположите переменную по определенному адресу оперативки без танцев с файлом линкера

5 минут назад, tonyk_av сказал:

другая голова обслуживает коммуникационные интерфейсы

подрядите на работу с интерфейсами DMA и не понадобится второе ядро