Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: STM32F103. DMA Mem-to-Mem
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
ViKo
Правильно ли я понимаю, что во время работы DMA нельзя программе залазить в память, с которой работает DMA?
Вот такую функцию исследую, пока не дожусь конца передачи, дальше не иду. (Не показана установка режима работы, и разрешение тактирования, это делается однократно в начальной установке). Тогда все работает. Иначе, если программа пишет туда, откуда читает DMA, появляется прерывание TEIFx Channel x transfer error flag. А прерывания, что дошло до конца, уже нет.
Если все так, то ценность такого DMA уменьшается. Почти то же можно реализовать, как у меня в закомментированном коде.
Код
void ExtDpy2LCD_copy(uint32_t Offset, uint32_t Size)
{
  LED_On();
  DMA2->IFCR |= DMA_IFCR_CTCIF1;
  DMA2_Channel1->CCR &= ~0x00000001;  // запретить пересылку
  DMA2_Channel1->CPAR = EXTDPY + Offset; // начальный адрес буфера экрана
  DMA2_Channel1->CMAR = 0x6c020000 + Offset; // начальный адрес памяти ЖКИ
  DMA2_Channel1->CNDTR = Size;   // 16-битовые пересылки  
  DMA2_Channel1->CCR |= 0x00000001;  // разрешить пересылку
  while (!(DMA2->ISR & DMA_ISR_TCIF1));
  LED_Off();
/*
  uint16_t *pSour = (uint16_t *)(EXTDPY + Offset);
  uint16_t *pDist = (uint16_t *)(0x6c020000 + Offset);
  LED_On();
  for (uint32_t i=Size; i--; ) {
    *pDist++ = *pSour++;
  }
  LED_Off();
*/
}


Еще один факт для размышлений. Измерил осциллографом время работы показанной выше функции. Для Size = 320*240/2.
С DMA имею 20ms, без DMA 21.5ms.
Естественно, польза от DMA будет, если, пока байты перекидываются с места на место, процессор будет занят чем-нибудь другим. Например, принимать данные по другим интерфейсам и складывать во внутреннее ОЗУ. Надеюсь, это не притормозит работу DMA.
AlexandrY
Цитата(ViKo @ Feb 17 2011, 10:55) *
Еще один факт для размышлений. Измерил время работы показанной выше функции. С DMA имею 20ms, без DMA 21.5ms.
Естественно, польза от DMA будет, если, пока байты перекидываются с места на место, процессор будет занят чем-нибудь другим. Например, принимать данные по другим интерфейсам и складывать во внутреннее ОЗУ. Надеюсь, это не притормозит работу DMA.


Такие факты вырванные из контекста и без описания аппаратуры не более чем трата времени.
Приведите схему и весь проект как например здесь: Тесты DMA на STM32
тогда можно о чем-то думать.
У вас может просто конфликт по целостности сигналов на плате из-за скверной трассировки.
На вашем месте надо было бы провести тщательнее тестирование памяти с сообщить хотя бы какая у вас в целом пропускная способность к памяти.
ViKo
Цитата(AlexandrY @ Feb 17 2011, 11:04) *
Такие факты вырванные из контекста и без описания аппаратуры не более чем трата времени.
У вас может просто конфликт по целостности сигналов на плате из-за скверной трассировки.
На вашем месте надо было бы провести тщательнее тестирование памяти с сообщить хотя бы какая у вас в целом пропускная способность к памяти.

Ну какой конфликт, если работает?
Частота процессора 72MHz. ОЗУ статическое IS62WV26516BLL-55. Контроллер ЖКИ S1D13706, работает от тактовой частоты 36MHz, старался настроить на наиболее быструю работу. Настройки работы с памятью:
Код
// -- Bank1 NE2 - RAM 256K x 16 --
  FSMC_Bank1->BTCR[2] = 0x00001011; // 16-bit,NoMux,SRAM,En
  FSMC_Bank1->BTCR[3] = 0x000f0300; // Mode1 0(+1)\_3_/(+1)
// -- Bank1 NE4 - LCD 128K + 128K(80K) --
// Читать-писать 16-битовыми или 8-битовыми словами
  FSMC_Bank1->BTCR[6] = 0x00009011; // ASWait,WrEn,WrapDis,FlashAccDis,16-bit,SRAM,NoMux,En
  FSMC_Bank1->BTCR[7] = 0x000f1200; // Mode1 0(+1)\_18_____ _/(+1)

Да и не при чем это все. Качественное соотношение останется тем же, независимо от быстродействия устройств.
Заглянул на вашу ссылку. Читаю... У меня контроллер ЖКИ медленный до безобразия. И память -55
Еще я не сказал - код выполняется из ОЗУ микроконтроллера. Тоже понижает быстродействие.

У меня скорость пересылки по DMA получилась 3750 KB/s. Контроллер ЖКИ тормозит.
scifi
Цитата(ViKo @ Feb 17 2011, 13:13) *
Контроллер ЖКИ тормозит.

Я правильно понял, что у Вас есть экранный буфер во внешнем ОЗУ, и Вы копируете из него данные в видеопамять графического контроллера? Если да, то зачем?
ViKo
Цитата(scifi @ Feb 17 2011, 12:26) *
Я правильно понял, что у Вас есть экранный буфер во внешнем ОЗУ, и Вы копируете из него данные в видеопамять графического контроллера? Если да, то зачем?

Правильно. На вопрос, зачем, отсылаю вас в эту тему
http://electronix.ru/forum/index.php?showtopic=85989
о как ссылками перекрестными обложился sm.gif
scifi
Цитата(ViKo @ Feb 17 2011, 13:32) *
На вопрос, зачем, отсылаю вас в эту тему

Ползущие картинки? Если бы у Вас была возможность выбирать графический контроллер, у Epson есть контроллеры с функциями 2D-ускорения. Там двигать картинку в видеопамяти было бы легко...
А может быть, снова рассмотреть вариант с double buffer, 4bpp?
ViKo
Цитата(scifi @ Feb 17 2011, 12:42) *
1. Ползущие картинки? Если бы у Вас была возможность выбирать графический контроллер, у Epson есть контроллеры с функциями 2D-ускорения. Там двигать картинку в видеопамяти было бы легко...
А может быть, снова рассмотреть вариант с double buffer, 4bpp?

1. Нет, это я упрощенно назвал "двигать картинку". Там меняется изображение. У меня Epson и есть, но не поможет.
2. Нет, то, что сделал - классическое решение. По скорости устраивает. Вопрос был про DMA. Нельзя одновременно обращаться к памяти по DMA и программно.
scifi
Цитата(ViKo @ Feb 17 2011, 15:03) *
Вопрос был про DMA. Нельзя одновременно обращаться к памяти по DMA и программно.

Ну да, выглядит странно. Согласно руководству, всё должно работать:
Цитата
The DMA controller performs direct memory transfer by sharing the system bus with the Cortex™-M3 core. The DMA request may stop the CPU access to the system bus for some bus cycles, when the CPU and DMA are targeting the same destination (memory or peripheral). The bus matrix implements round-robin scheduling, thus ensuring at least half of the system bus bandwidth (both to memory and peripheral) for the CPU.

Цитата
A DMA transfer error can be generated by reading from or writing to a reserved address space. When a DMA transfer error occurs during a DMA read or a write access, the faulty channel is automatically disabled through a hardware clear of its EN bit in the corresponding Channel configuration register (DMA_CCRx). The channel's transfer error interrupt flag (TEIF) in the DMA_IFR register is set and an interrupt is generated if the transfer error interrupt enable bit (TEIE) in the DMA_CCRx register is set.

В качестве workaround, наверное, можно просто перезапускать DMA после манипуляций с буфером. Или даже в обработчике прерывания TEI.
ViKo
Попытал счастья с кодом, выполняемым из Flash. Показываю время в ms для пересылки с помощью DMA и программной, для кода из Flash и RAM
Код
     DMA   Program
RAM  19.5    21.5
ROM  19.75   21.0

Смотрел осциллографом, за точность до 1% не поручусь. Можно сказать, цифры остались примерно теми же. Подозреваю, что все дело во временах работы контроллера ЖКИ. Попробую в будущем уменьшить до предела допустимого.
Еще у меня SysTick таймер раз в 1ms выполняет несколько команд. Пустое...
При работе из Flash попробовал не делать проверку, что установлен флаг TCIF. То есть, записывать в буфер ОЗУ, когда из него читает DMA. Результат - по-прежнему вылазят ошибки.
HardEgor
Цитата(ViKo @ Feb 18 2011, 14:43) *
То есть, записывать в буфер ОЗУ, когда из него читает DMA. Результат - по-прежнему вылазят ошибки.

Может быть организовать двухстраничный буфер - пока в 1-й пишет DMA, со 2-м работаем, потом меняем местами.
ViKo
Цитата(HardEgor @ Feb 18 2011, 11:38) *
Может быть организовать двухстраничный буфер - пока в 1-й пишет DMA, со 2-м работаем, потом меняем местами.

Боюсь, тоже будут конфликты. Надо попробовать поработать с внешней памятью (с другой областью), когда идет процесс DMA.
HardEgor
И еще, может быть ты попадаешь на момент когда совпадают адреса RAM у DMA и программы? попробуй проверять флаг HTIFx: Channel x half transfer flag
Кстати, такты DMA можно глянуть в http://easyelectronics.ru/img/ARM_kurs/CMSIS/stm32.pdf пишут что "что модуль DMA поребляет максимум 40% пропускной способности шины данных, даже в момент непрерывной передачи данных"
ViKo
Цитата(HardEgor @ Feb 18 2011, 11:50) *
пишут что "что модуль DMA поребляет максимум 40% пропускной способности шины данных, даже в момент непрерывной передачи данных"

Это пишут про внутреннюю шину.
Заметил странное явление. Добавил код , обращающийся к внешнему ОЗУ, к области, не используемой для буфера ЖКИ.
Код
    uint8_t *pExtTest = (uint8_t *)EXTRAM;
    for (uint32_t i=16; i--; ) {
      *pExtTest++ = (uint8_t)pExtTest;
    }

Когда запускаю программу, она работает, если в Keil не включаю окно с Memory 3, где смотрю EXTRAM (0x64000000). Как только переключаюсь, флаги DMA (0x40020400) становятся 0x0D (ошибка). Т.е. средства отладки отбирают пропускную способность шины.
Если же смотреть, например, окно Memory 2, с адресами 0x40020400, вижу флаги 0x05, изредка 0x07. В-общем, программа работает.
HardEgor
Так проверить просто - выведи TEIFx на внешний порт на светодиод и запусти программу без отладчика.
ViKo
Цитата(HardEgor @ Feb 18 2011, 17:18) *
Так проверить просто - выведи TEIFx на внешний порт на светодиод и запусти программу без отладчика.

Что вы предлагаете мне проверить таким образом?
HardEgor
Появляется ошибка при передаче DMA или нет, при отсуствии внешних факторов типа отладчика.
ViKo
Проверил работу программы из Flash без отладчика.
Вот такой код из Flash работает (в самой программе ExtDpy2LCD_copy проверку TCIF убрал).
Причем, независимо, с отладчиком или без.
Код
  while (1) {
    ExtDpy2LCD_copy(0, 320*240/2);
    if (FPI.FP_Rdy) {
      FPI.FP_Rdy = 0;
      FPI_Process();    // здесь пишу в EXTDPY
    }
    while (!(DMA2->ISR & DMA_ISR_TCIF1));     // ждать флаг прерывания
  }

А из RAM (внутренней, естественно) такой код не работает. Независимо от того, вывожу в окне содержимое памяти, или нет. Если проверку TCIF поставить сразу после ExtDpy2LCD_copy, тогда работает и из RAM.
ViKo
После того, как переписал все свои программы для работы с буфером ЖКИ во внешней памяти, вышеприведенный код перестал работать.
Какие-то чудеса творятся. Решил плюнуть на эту затею, проверять бит TCIF сразу после запуска процедуры DMA. А то и совсем буду программно перекидывать, разница во времени по сравнению с DMA очень невелика.
scifi
Цитата(ViKo @ Feb 25 2011, 11:25) *
А то и совсем буду программно перекидывать, разница во времени по сравнению с DMA очень невелика.

Ещё можно пооптимизировать программное копирование, используя инструкции LDM/STM.
ViKo
Цитата(scifi @ Feb 25 2011, 11:00) *
Ещё можно пооптимизировать программное копирование, используя инструкции LDM/STM.

Заменил пересылки на 32-битовые
Код
// Программная пересылка буфера в контроллер ЖКИ 32-битовыми словами
  uint32_t *pSour = (uint32_t *)(DPYBUF + Offset);
  uint32_t *pDist = (uint32_t *)(LCDRAM + Offset);
  LED_On();
  for (uint32_t i=Size/4; i--; ) {
    *pDist++ = *pSour++;
  }
  LED_Off();

Время пересылки уменьшилось с 18ms до 14ms.
(До этого я еще уменьшил время доступа к контроллеру ЖКИ, поэтому время и для 16-битовых пересылок уменьшилось).
Компилятор в этом случае использует LDM/STM, но только один регистр использует.
Вот кабы он знал, что количество пересылок кратно 8, 16... байтам...
Код
;;;415        *pDist++ = *pSour++;
0003d2  ca20              LDM      r2!,{r5}
0003d4  c020              STM      r0!,{r5}

Пробовал заменить указатели на uint64_t *, но быстрее не стало, а размер кода увеличился.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.