Jump to content

    
Sign in to follow this  
SapegoAL

stm32f767. MPU, DTCM, кэш и прочее...

Recommended Posts

Начинаю проект на 767 камне. Образец будет только через месяца 1.5 - 2. Не работал ни с MPU ни с кэш.
Почитал - вроде бы всё понятно. Загрузил cube - смотрю пример. Есть вопросы.
В примере st буфера ETH размещают по фиксированному адресу, расположенному в конце ОЗУ. И отключают кэш на этот регион.
Хотелось бы услышать тех кто с этим разбирался.
А может целесообразнее буфера в DTCM разместить? Вроде бы как работать будет побыстрее. DMA функционирует.
Или я чего-то не учитываю?
Кто как делал?
Можно, наверное и драйвер ETH поправить, на предмет синхронизации работы с памятью. Вроде бы как там не очень много должно быть.
Думаю, они этого не сделали, чтобы драйвер был независимым от камня.
Конечно тестировать много. Наверное проще пойти по их пути... ))

Какие соображения по этому вопросу?

Share this post


Link to post
Share on other sites
On 8/9/2019 at 4:44 PM, SapegoAL said:

И отключают кэш на этот регион.

Да, все верно, так и нужно делать. Нельзя включать cache на память которая работает с периферией и содержимое которой вылетает или залетает из внешнего мира. Так как при включенном cache при обновлении содержимого памяти часть данных может остаться в cache и наружу может вылететь битый фрейм. Да, в данном случае можно конечно обложить код работы с буфером flush\invalidate, но смысла в этом мало, cache будет использоваться не эффективно.
 

On 8/9/2019 at 4:44 PM, SapegoAL said:

А может целесообразнее буфера в DTCM разместить?

ИМХО, Прирост будет но не существенный так как в данном случае DMA к DTCM подключена по тойже AHB, то-есть прирост будет только за счет близости TCM к ядру. Судя из этой доки выигрыш перед SRAM порядка 5%.
P.S. Они приводят это значение с включенным cache, без cache должно быть больше, но опять же не думаю что он будет существенный.

Share this post


Link to post
Share on other sites
В 09.08.2019 в 16:44, SapegoAL сказал:

А может целесообразнее буфера в DTCM разместить? Вроде бы как работать будет побыстрее. DMA функционирует.

Имхо: в TCM лучше размещать те элементы данных, которые часто модифицируются процессором (чтение/запись). Например там полезно разместить стеки задач, видеобуфер (особенно если пиксели занимают не целое число байт) и т.п.

Share this post


Link to post
Share on other sites

Всем спасибо за ответы. Про DTCM понял.
А что по видеоОЗУ? Там же тоже и LTDC и DMA2D?
Хотя по сути LTDC только читает, а по DMA2D после записи можно делать очистку кэша.
Или я что-то не так понимаю?

 

Share this post


Link to post
Share on other sites

Да я и не собираюсь рекорды ставить. Думал немного разгрузить шину.
Просто видеоозу, естественно, во внешней микрухе расположено. Понятно, что обращение к ней будет медленное.
Ясно, что проц значительную часть своего процессорного времени будет на гуёвину тратить.
При этом в видеопамять писать и простаивать. И из-за работы LTDC и из-за дополнительных тактов ожидания. Если кэш и нужен, то как раз при обращении к внешней ОЗУ.
А если сквозную запись включить?
Или пойдут косяки и я впустую потрачу кучу времени? У меня такое ощущение, что мне что-то недоговаривают. )) Скрывают правду от меня. ))
Не может быть, чтобы никто с этим не возился.
На мой взгляд выглядит примерно так:
1. LTDC работает только на чтение и данные берёт прямо с памяти.
2. Когда я отрисовываю какой-то виджет, то я делаю flush\invalidate по завершению.
3. Аналогичная картина когда я отрисовываю виджет с использованием DMA2D.
Если что-то будет в процессе не одновременно отображаться, это не критично, как при работе с ethernet, хотя может резать глаз. И по факту придётся от этого отказаться.

Share this post


Link to post
Share on other sites

Если процессору нужно читать область видеопамяти, имеет смысл включить режим кэширования WT, а при внешних изменениях (DMA) выполнять invalidate. В противном случае достаточно буфера записи.

 

Share this post


Link to post
Share on other sites

Если честно, то и не подумал об этом. Собственно всё правильно. Проц туда только пишет, и радости от кэша будет немного.
Спасибо.

Share this post


Link to post
Share on other sites

А с какой точностью в f7  можно отменять кешируемостть памяти? Ведь фреймбуфер не занимает всю память, а терять скорость отключив на все не хочется... 

Share this post


Link to post
Share on other sites

Спрошу здесь, чтобы темы не плодить.
Просматривал HAL библиотеки работы с внешней SDRAM.
Они ставят программную блокировку от доступа.
Не совсем понятно... Ну, допустим, они хотят разрулить, попытку из разных задач одновременного доступа по одному и тому же каналу DMA. Ну или доступ и конфигурирование контроллера.
Но они блокируют и доступ самому CPU. Это зачем?
Я что не могу прочитать произвольные данные, пока у меня идёт DMA операция? Зачем вообще делать процедуру доступа к внешней ОЗУ? Насколько я понимаю, она в общем адресном пространстве.
Ну я не знаю. Может они на воду дуют или от дурака пытаются защититься?
Обычно инициализация делается до запуска ОС, а доступ разруливается правильным построением задач. Если это невозможно, то устанавливаются семафоры.
Или я что-то упускаю?

Share this post


Link to post
Share on other sites
2 часа назад, SapegoAL сказал:

Спрошу здесь, чтобы темы не плодить.
Просматривал HAL библиотеки работы с внешней SDRAM.
Они ставят программную блокировку от доступа.
Не совсем понятно... Ну, допустим, они хотят разрулить, попытку из разных задач одновременного доступа по одному и тому же каналу DMA. Ну или доступ и конфигурирование контроллера.
Но они блокируют и доступ самому CPU. Это зачем?
Я что не могу прочитать произвольные данные, пока у меня идёт DMA операция? Зачем вообще делать процедуру доступа к внешней ОЗУ? Насколько я понимаю, она в общем адресном пространстве.
Ну я не знаю. Может они на воду дуют или от дурака пытаются защититься?
Обычно инициализация делается до запуска ОС, а доступ разруливается правильным построением задач. Если это невозможно, то устанавливаются семафоры.
Или я что-то упускаю?

Да упустили самое главное: Сформулировать вопрос. Просто какой-то поток сознания не понятно о чём... :wacko2:

Кто "они"? Почему то, что "они" делают так Вас беспокоит? Что за блокировка? чего и от кого? и при чём тут DMA вообще?  :wacko2:

Share this post


Link to post
Share on other sites
/**
  * @brief  Writes 8-bit data buffer to SDRAM memory.
  * @param  hsdram pointer to a SDRAM_HandleTypeDef structure that contains
  *                the configuration information for SDRAM module.
  * @param  pAddress Pointer to write start address
  * @param  pSrcBuffer Pointer to source buffer to write  
  * @param  BufferSize Size of the buffer to write to memory
  * @retval HAL status
  */
HAL_StatusTypeDef HAL_SDRAM_Write_8b(SDRAM_HandleTypeDef *hsdram, uint32_t *pAddress, uint8_t *pSrcBuffer, uint32_t BufferSize)
{
  __IO uint8_t *pSdramAddress = (uint8_t *)pAddress;
  uint32_t tmp = 0;
  
  /* Process Locked */
  __HAL_LOCK(hsdram);
  
  /* Check the SDRAM controller state */
  tmp = hsdram->State;
  
  if(tmp == HAL_SDRAM_STATE_BUSY)
  {
    return HAL_BUSY;
  }
  else if((tmp == HAL_SDRAM_STATE_PRECHARGED) || (tmp == HAL_SDRAM_STATE_WRITE_PROTECTED))
  {
    return  HAL_ERROR; 
  }
  
  /* Write data to memory */
  for(; BufferSize != 0; BufferSize--)
  {
    *(__IO uint8_t *)pSdramAddress = *pSrcBuffer;
    pSrcBuffer++;
    pSdramAddress++;
  }
  
  /* Process Unlocked */
  __HAL_UNLOCK(hsdram);    
  
  return HAL_OK;   
}

Собственно так весь HAL написан. По моему комментировать не требуется. 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this