[SapegoAL 0]

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

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

[Integro 0]

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 должно быть больше, но опять же не думаю что он будет существенный.

[jcxz 184]

В 09.08.2019 в 16:44, SapegoAL сказал:

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

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

[SapegoAL 0]

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

 

[scifi 1]

Рекорды скорости требуются редко. Поэтому обычно лучше стремиться к простоте и удобству.

[SapegoAL 0]

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

[aaarrr 63]

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

 

[SapegoAL 0]

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

[GenaSPB 11]

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

[SapegoAL 0]

Там несколько зон есть. Причём можно с перекрытием работать. Лучше документ почитать

 

[SapegoAL 0]

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

[Integro 0]

2 hours ago, SapegoAL said:

Они ставят программную блокировку от доступа.

О какой блокировке речь? Тут лучше код показать

[jcxz 184]

2 часа назад, SapegoAL сказал:

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

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

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

[SapegoAL 0]

/**
  * @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 написан. По моему комментировать не требуется.