klen (14.02.2021 14:19, просмотров: 468) ответил Kceния на Всегда считала, что внутри какой-то арбитраж есть, т.к. СPU и DMA -
конкуренты за доступ к памяти. Думаю, что так оно не только у AVR,
но и у ARM. Вот только поведение STM32H7 (мое последнее
приобретение) вызывает сомнения, т.к. у него есть кеширование ОЗУ,
при котором доступ СPU к памяти кешируется, а DMA продолжает
работать с ОЗУ напрямую. Из-за этого я уже в историю влипла, когда
СPU не видит того, что DMA от АЦП в память пишет.-
- Речь сейчас о другом - совместимы ли одновременно транзакции, когда DMA обращается к ОЗУ напрямую, а CPU обращается
к кешу? Формально это возможно, т.к. кеш находится в другом месте,
но сомнительно по причине того, что "адресный коммутатор" у них
один и тот же. Или нет? - Kceния(14.02.2021 14:30)
- У STM32F4 (я их лучше всего знаю) ОЗУ разбито на несколько блоков.
Например у F407 таких блоков три: CCM, SRAM1, SRAM2. CCM доступен
только процессору, потому туда хорошо помещать стеки и всякие
переменные. SRAM1 и SRAM2 доступны и процессору и всем
DMA-способным устройствам (DMA, Ethernet, USB). Если обращения
нескольких из этих устройств одновременно попадают в один блок - то
осуществляется арбитраж. Подробного описания арбитража не видел, но
скорее всего round robin. LightElf(60 знак., 14.02.2021 14:57)
- У STM32 ничего понять нельзя :), а у AVR вся память одним куском
(разве что еще кусок появляется у тех, где объем больше 128 байт).
И по ощущениям CPU начинает притормаживать, когда DMA что-то
интенсивно качает. Однако на STM32 у меня такие же ощущения :). - Kceния(14.02.2021 17:21)
- Чудес не бывает. Если память однопортовая - то два обращения в нее
одновременно невозможны. AVR естественно будет притормаживать.
STM32 притормаживает, если процессор обращается в один блок с DMA.
Потому и делают несколько раздельных блоков ОЗУ. - LightElf(14.02.2021 17:43)
- Тут может быть арбитраж по циклам доступа к шине ОЗУ. Процессор-же не постоянно туда лазит. У него должны быть машинные цыклы без доступа в память вообще. Даже с конвейером. - mse homjak(14.02.2021 19:25)
- Во! Теперь мне стало понятнее, зачем они там так много накуролесили
с блоками памяти непонятного назначения :). Я-то плюнула и всё в
один блок загнала - в самый большой по объему, а кеширование ОЗУ
отключила, видимо от этого и тормоза. - Kceния(14.02.2021 18:00)
- А не проще при чтении из периферии SCB_InvalidateDCache_by_Addr,
при записи - SCB_CleanDCache_by_Addr. И блоки памяти выравнивать по
странице кеша. И тормоза меньше будут. - Andreas(14.02.2021 18:25)
- Это полный барьер памяти типа SC, его бездумное использование
вызовет просадку производительности. Корректное решение - выделить
через MPU отдельный некешируемый регион под буферы DMA. - evgeniy1294(17.02.2021 10:46)
- Не всегда это удобно, да еще потом эти буфера могут еще по
программе гулять и обрабатываться. А просадки я не заметил, выводил
на пины в контрольных точках и значимых изменений длительностей не
заметил. - Andreas(17.02.2021 11:12)
- При работе с GUI и сетью будет заметно - evgeniy1294(17.02.2021 11:15)
- SCB_InvalidateDCache_by_Addr на 16кб заняло 10мкс на 480МГц,
сначала показалось меньше. Но я читаю СД карту, а там задержки по
150..300мкс до начала чтения блока. И деваться мне некуда, оська с
только динамическим распределением памяти и чтобы использовать
заданный регион, надо ОЧЕНЬ много переписывать и некрасиво логику
работы менять. - Andreas(17.02.2021 11:45)
- Понятно, что нужно изходить из особенностей окружения, и переписывать уж точно ничего не надо. Работет - не трогай. - evgeniy1294(17.02.2021 11:49)
- С другой стороны, пишут что при двойной буферизации изображения с инвалидацией работает быстрее - evgeniy1294(17.02.2021 11:23, ссылка, ссылка)
- SCB_InvalidateDCache_by_Addr на 16кб заняло 10мкс на 480МГц,
сначала показалось меньше. Но я читаю СД карту, а там задержки по
150..300мкс до начала чтения блока. И деваться мне некуда, оська с
только динамическим распределением памяти и чтобы использовать
заданный регион, надо ОЧЕНЬ много переписывать и некрасиво логику
работы менять. - Andreas(17.02.2021 11:45)
- При работе с GUI и сетью будет заметно - evgeniy1294(17.02.2021 11:15)
- Не всегда это удобно, да еще потом эти буфера могут еще по
программе гулять и обрабатываться. А просадки я не заметил, выводил
на пины в контрольных точках и значимых изменений длительностей не
заметил. - Andreas(17.02.2021 11:12)
- Я таких и команд не знаю :), на CubeMX пока тренируюсь. - Kceния(14.02.2021 18:46)
- Хоть не на кошках ) Это из стандартного CMSIS core_cm7.h - Andreas(14.02.2021 18:56, ссылка)
- Вот не надо Ксении такое давать. Результатом будет перманентно сброшенный кэш и куча тем "ваш stm32 тормозит". - evgeniy1294(17.02.2021 10:53)
- Хоть не на кошках ) Это из стандартного CMSIS core_cm7.h - Andreas(14.02.2021 18:56, ссылка)
- Это полный барьер памяти типа SC, его бездумное использование
вызовет просадку производительности. Корректное решение - выделить
через MPU отдельный некешируемый регион под буферы DMA. - evgeniy1294(17.02.2021 10:46)
- всем спасибо, чето сам не догадался - действительно два куска SRAM1
SRAM2 на двух сосках висят отдельно - AXI коммутатор может запросы
развести. исправить, дописать и закомитить в sdk, теперь я осознано
куски sram буду использовать. позитифчик. - klen(14.02.2021 18:23)
- В F427 и выше - три куска (SRAM1, SRAM2, SRAM3). И CCM еще. Все, к чему не требуется обращаться по DMA - лучше класть в CCM (если конечно лезет). SRAM2 на 16КБ удобен для буферов Ethernet. Большой SRAM1 - для всякой прочей фигни. У меня там либо буфер экрана лежит, либо буфер видимокамеры. - LightElf(14.02.2021 18:32)
- А не проще при чтении из периферии SCB_InvalidateDCache_by_Addr,
при записи - SCB_CleanDCache_by_Addr. И блоки памяти выравнивать по
странице кеша. И тормоза меньше будут. - Andreas(14.02.2021 18:25)
- Чудес не бывает. Если память однопортовая - то два обращения в нее
одновременно невозможны. AVR естественно будет притормаживать.
STM32 притормаживает, если процессор обращается в один блок с DMA.
Потому и делают несколько раздельных блоков ОЗУ. - LightElf(14.02.2021 17:43)
- У STM32 ничего понять нельзя :), а у AVR вся память одним куском
(разве что еще кусок появляется у тех, где объем больше 128 байт).
И по ощущениям CPU начинает притормаживать, когда DMA что-то
интенсивно качает. Однако на STM32 у меня такие же ощущения :). - Kceния(14.02.2021 17:21)
- если смотреть на картинки h7 тот там несколько уровней шин и и еще путями разными пропихнуть можно, даже в доках это нарисовано, подозреваю что все параллельно, если только не пресекутся запрсы на одном хабе - тут тогда локальный арбитраж по приоритету. если кеши отключить то все тупить начинает именно из-за этого. флешь параллельно качает инструкции поэтому она тут не причем. я так эти картинки понимаю. - klen(14.02.2021 14:38)
- У STM32F4 (я их лучше всего знаю) ОЗУ разбито на несколько блоков.
Например у F407 таких блоков три: CCM, SRAM1, SRAM2. CCM доступен
только процессору, потому туда хорошо помещать стеки и всякие
переменные. SRAM1 и SRAM2 доступны и процессору и всем
DMA-способным устройствам (DMA, Ethernet, USB). Если обращения
нескольких из этих устройств одновременно попадают в один блок - то
осуществляется арбитраж. Подробного описания арбитража не видел, но
скорее всего round robin. LightElf(60 знак., 14.02.2021 14:57)
- а я в таком случае писал функцию чистящую кэш, относящийся к куску
памяти, который DMA "освежает". - Mahagam(14.02.2021 14:23)
- А зачем ее писать, в CMSIS все есть и более того. - Andreas(14.02.2021 14:55)
- для ARM9 оно там есть? - Mahagam(14.02.2021 15:44)
- О кортексе разговор, про такую окаменелость и не вспомнилось. - Andreas(14.02.2021 16:31)
- для ARM9 оно там есть? - Mahagam(14.02.2021 15:44)
- А зачем ее писать, в CMSIS все есть и более того. - Andreas(14.02.2021 14:55)
- Речь сейчас о другом - совместимы ли одновременно транзакции, когда DMA обращается к ОЗУ напрямую, а CPU обращается
к кешу? Формально это возможно, т.к. кеш находится в другом месте,
но сомнительно по причине того, что "адресный коммутатор" у них
один и тот же. Или нет? - Kceния(14.02.2021 14:30)
