реклама на сайте
подробности

 
 
4 страниц V  < 1 2 3 4 >  
Reply to this topicStart new topic
> STM32F4 ADC DMA ?
_Артём_
сообщение Jul 24 2012, 19:57
Сообщение #31


Гуру
******

Группа: Свой
Сообщений: 2 128
Регистрация: 21-05-06
Пользователь №: 17 322



Цитата(demiurg_spb @ Jul 24 2012, 22:05) *
Тот кто привык щи лаптем хлебать того уже более прогрессивным прибором не заманишь к столу.
Без обид...

Да какие обиды...
Вопрос в их прогрессивности.
Чем такой варинт хуже
Код
__INLINE void TestPinOn(void)    { GPIOD->BSRRL = GPIO_Pin_15; }

?
Тем более при усложнившейся структуре портов.
Не усложнятся ли макросы до полной непонятности?
Получится тоже что "писать в регистры" vs "использовать библиотеку".

Цитата(demiurg_spb @ Jul 24 2012, 22:05) *
Вы внимательнее ознакомьтесь с этими макросами и возможно осознаете всю их прелесть.

Всё возможно...


Цитата(demiurg_spb @ Jul 24 2012, 22:05) *
Конечно их можно и нужно заменить на шаблоны при переходе на с++

Теоритически можно, и наверное нужно. Но как-то руки не доходят.

Go to the top of the page
 
+Quote Post
Allregia
сообщение Jul 25 2012, 05:24
Сообщение #32


Профессионал
*****

Группа: Свой
Сообщений: 1 047
Регистрация: 28-06-07
Из: Israel
Пользователь №: 28 763



Цитата(_Артём_ @ Jul 24 2012, 21:57) *
Да какие обиды...
Вопрос в их прогрессивности.
Чем такой варинт хуже
Код
__INLINE void TestPinOn(void)    { GPIOD->BSRRL = GPIO_Pin_15; }

?


ДА ничем. ТЕм более, что я показал самый простой вариант. В общем виде порт и пин задаются дефайнами а не в явном виде. А при наличии __INLINE это считай тот-же макрос.
Go to the top of the page
 
+Quote Post
demiurg_spb
сообщение Jul 25 2012, 05:47
Сообщение #33


неотягощённый злом
******

Группа: Свой
Сообщений: 2 746
Регистрация: 31-01-08
Из: Санкт-Петербург
Пользователь №: 34 643



Цитата(_Артём_ @ Jul 24 2012, 23:57) *
Чем такой варинт хуже
Код
__INLINE void TestPinOn(void)    { GPIOD->BSRRL = GPIO_Pin_15; }
?

этот теоретически ничем, а вот с инверсией INLINE процедура содержит реальную багу (не обеспечивает атомарного доступа) и при условии что в прерываниях происходит запись в тот же порт будут танцы с бубном. Чтобы пофиксить это нужно работать через bitband или переписать как
Код
if (pin==1) pin=0; else pin=1;

Поищите по форуму, это уже обсуждалось не один раз.

Цитата
Тем более при усложнившейся структуре портов.
Не усложнятся ли макросы до полной непонятности?
Получится тоже что "писать в регистры" vs "использовать библиотеку".

Нет ничего не усложнится. Суть этих макросов в повторном использовании кода с целью сделать проект прозрачным, переносимым и легко модифицируемым.

В случае не использования макросов вам придётся писать для каждого пина снова и снова по 3-4 инлайн процедуры, потом при переразводке платы снова править в 3-4 местах и не дай Бог где-то что-то упустить. Неужели это радостная и продуктивная работа?

Цитата(Allregia @ Jul 25 2012, 09:24) *
В общем виде порт и пин задаются дефайнами а не в явном виде.
А потом вдруг требуется инвертировать один из сигналов по какой-либо причине. И? Сели в лужу?


--------------------
“Будьте внимательны к своим мыслям - они начало поступков” (Лао-Цзы)
Go to the top of the page
 
+Quote Post
Allregia
сообщение Jul 25 2012, 07:18
Сообщение #34


Профессионал
*****

Группа: Свой
Сообщений: 1 047
Регистрация: 28-06-07
Из: Israel
Пользователь №: 28 763



Цитата(demiurg_spb @ Jul 25 2012, 07:47) *
А потом вдруг требуется инвертировать один из сигналов по какой-либо причине. И? Сели в лужу?


Ну так я потрачу 5 минут своего драгоценного времени, на то чтобы поменять в одном месте местами BSRRL и BSRRH, только и всего.
Все равно 99.999% времени занимает основная задача, а не настройка портов и т.п.
Я даже на PIC16 таким не заморачивался, хотя понятное дело что сложность решаемых задач там пониже.

Помнить все флаги и биты регистров это конечно хорошо, но я предпочитаю их посмотреть в букваре когда пишу настройки и работу с периферией, а после этого сразу поскорее забыть sm.gif
Go to the top of the page
 
+Quote Post
ViKo
сообщение Jul 25 2012, 07:30
Сообщение #35


Универсальный солдатик
******

Группа: Модераторы
Сообщений: 8 634
Регистрация: 1-11-05
Из: Минск
Пользователь №: 10 362



Цитата(Allregia @ Jul 25 2012, 10:18) *
Помнить все флаги и биты регистров это конечно хорошо, но я предпочитаю их посмотреть в букваре когда пишу настройки и работу с периферией, а после этого сразу поскорее забыть sm.gif

Но, видимо, на регистры и биты ADC, DMA у вас аллергия? sm.gif
Такой стиль называется "эклектика".
Go to the top of the page
 
+Quote Post
Allregia
сообщение Jul 25 2012, 11:48
Сообщение #36


Профессионал
*****

Группа: Свой
Сообщений: 1 047
Регистрация: 28-06-07
Из: Israel
Пользователь №: 28 763



Цитата(ViKo @ Jul 25 2012, 09:30) *
Но, видимо, на регистры и биты ADC, DMA у вас аллергия? sm.gif
Такой стиль называется "эклектика".


У меня не аллергия, но делая прибор на процессорах типа Кортексов, я хочу сосредатачиваться на основной задаче, а не на побочных, типа настойки периферии.
Т.е. если у меня идет прием ЭКГ (электрокардиограммы) с АЦП, обработка и выдача результатов на дисплей и в УАРТ, то 99.99% времени я предпочитаю тратить не на настройку АЦП, дисплея и УАРТа, и копание в их битах, а на прикладные вопросы, связанные с ЭКГ и ее обработкой и отображением. Что поверьте мне, гораздо более трудоемко и наукоемко.
(тем более, что кроме программы я еще и все железо делаю).
Go to the top of the page
 
+Quote Post
ViKo
сообщение Jul 25 2012, 11:57
Сообщение #37


Универсальный солдатик
******

Группа: Модераторы
Сообщений: 8 634
Регистрация: 1-11-05
Из: Минск
Пользователь №: 10 362



Цитата(Allregia @ Jul 25 2012, 14:48) *
99.99% времени я предпочитаю тратить не на настройку АЦП, дисплея и УАРТа, и копание в их битах, а на прикладные вопросы, связанные с ЭКГ и ее обработкой и отображением. Что поверьте мне, гораздо более трудоемко и наукоемко.

Верю. Достойное дело. Но если использовать библиотечные функции для работы (не инициализации) с периферией, то можно понапрасну растерять производительность микроконтроллера, так, что на фильтрацию и отображение уже и не хватит.
Go to the top of the page
 
+Quote Post
kan35
сообщение Jul 25 2012, 12:26
Сообщение #38


Знающий
****

Группа: Участник
Сообщений: 537
Регистрация: 22-02-06
Пользователь №: 14 594



ViKo,
никто не отрицает, что работа через библиотеки менее эффективна, чем прямая работа с регистрами - это очевидно и ни для кого не секрет. Но следует здраво оценивать баланс между потерями и преимуществами. Наверное в 99% задач пофиг - как будет управляться периферия. Возможно, у некоторых (может быть у вас, кстати), задач критичных к этому будет 100%, а у некоторых как у меня - 0% и таких как я - большинство я уверен :-) .
Для абсолютных противников библиотек они все же могут быть полезны как учебник по работе с периферией.
Из этого я делаю вывод, что библиотеки - это хорошо.
Go to the top of the page
 
+Quote Post
ViKo
сообщение Jul 25 2012, 12:50
Сообщение #39


Универсальный солдатик
******

Группа: Модераторы
Сообщений: 8 634
Регистрация: 1-11-05
Из: Минск
Пользователь №: 10 362



Цитата(kan35 @ Jul 25 2012, 15:26) *
никто не отрицает, что работа через библиотеки менее эффективна, чем прямая работа с регистрами - это очевидно и ни для кого не секрет. Но следует здраво оценивать баланс между потерями и преимуществами. Наверное в 99% задач пофиг - как будет управляться периферия. Возможно, у некоторых (может быть у вас, кстати), задач критичных к этому будет 100%, а у некоторых как у меня - 0% и таких как я - большинство я уверен :-) .
Для абсолютных противников библиотек они все же могут быть полезны как учебник по работе с периферией.
Из этого я делаю вывод, что библиотеки - это хорошо.

Еще недавно вы утверждали, что это использование библиотек - это абсолютно правильный путь. Надо думать, что сейчас у вас уже нет такой 100% уверенности? sm.gif
Я не считаю себя противником того, что кто-то сделал до меня. Наоборот, всегда полезно посмотреть. Например, когда подберусь к USB, буду смотреть и в библиотеку. Но, например, когда хотел разобраться с SPI, быстро задвинул библиотеку подальше. Разбираться с ней мне показалось бессмысленной тратой времени. Невозможно понять работу железа, пользуясь готовыми функциями. Думаю, то же произойдет и с USB.
Мне казалось, что на 72 MHz все будет летать. Ан нет... laughing.gif
Go to the top of the page
 
+Quote Post
Allregia
сообщение Jul 25 2012, 14:46
Сообщение #40


Профессионал
*****

Группа: Свой
Сообщений: 1 047
Регистрация: 28-06-07
Из: Israel
Пользователь №: 28 763



Цитата(ViKo @ Jul 25 2012, 13:57) *
Верю. Достойное дело. Но если использовать библиотечные функции для работы (не инициализации) с периферией, то можно понапрасну растерять производительность микроконтроллера, так, что на фильтрацию и отображение уже и не хватит.


Можно. Но можно также голову иметь, и понимать что когда можно, а что когда нельзя (я ведь выше писал про time critical места).
И смею Вас уверить, за 25+ лет общения с разными МК, я этому чуть-чуть научился.

Цитата
Но, например, когда хотел разобраться с SPI, быстро задвинул библиотеку подальше. Разбираться с ней мне показалось бессмысленной тратой времени.


И совершенно напрасно. К примеру, в одном варианете этого устройства у меня дисплей на SPI сидит (в другом - на FSMC), у меня нет ни малейшего желания разбиратсья как там вычисляются коэффициенты делителей для SPI и UARTов, поэтому мне проще написать Baud=115200; и Init() чем самому соображать.
И для этого библиотеки вполне пригоды.
А про realtime работу - никто не мешает и напрямую с флагами/регистрами, см. выше.

Цитата
Невозможно понять работу железа, пользуясь готовыми функциями. Думаю, то же произойдет и с USB.


Чтобы понять как железо устроено - надо даташит читать, но это вовсе не отменяет пользование бибиотеками.
И вот в USB так у меня точно без не то что библиотк, а вообще драйверов, никакого желания ковыряться не возникнет.
Go to the top of the page
 
+Quote Post
kan35
сообщение Jul 26 2012, 05:52
Сообщение #41


Знающий
****

Группа: Участник
Сообщений: 537
Регистрация: 22-02-06
Пользователь №: 14 594



Цитата(ViKo @ Jul 25 2012, 16:50) *
Еще недавно вы утверждали, что это использование библиотек - это абсолютно правильный путь. Надо думать, что сейчас у вас уже нет такой 100% уверенности? sm.gif
Я не считаю себя противником того, что кто-то сделал до меня. Наоборот, всегда полезно посмотреть. Например, когда подберусь к USB, буду смотреть и в библиотеку. Но, например, когда хотел разобраться с SPI, быстро задвинул библиотеку подальше. Разбираться с ней мне показалось бессмысленной тратой времени. Невозможно понять работу железа, пользуясь готовыми функциями. Думаю, то же произойдет и с USB.
Мне казалось, что на 72 MHz все будет летать. Ан нет... laughing.gif

Viko, вы любите передергиватьwink.gif
Если у вас "не летает" на 72 МГц, то стоит задуматься над тем как вы работаете с периферией. Как правило упомянутая вами работа с битами-флагами это подход который стоит применять в исключительных случаях. Вся основная работа должна происходить по DMA. У меня напрмер прекрасно уживаются mp3 плеер с tcp/ip, usb-msd и пользовательским интерфейсом и при этом проц в самом худшем случае 50% времени бездельничает. Я пользуюсь периферийной библиотекой (в том числе usb от st) :-)
Но если тот же SPI или ADC обслуживать поллингом битов, то никакого быстродействия не хватит (даже напрямую обращаясь к регистрам), не говоря уже о том, что нужно данные готовить или обрабатывать.

Сообщение отредактировал kan35 - Jul 26 2012, 05:55
Go to the top of the page
 
+Quote Post
ViKo
сообщение Jul 26 2012, 07:58
Сообщение #42


Универсальный солдатик
******

Группа: Модераторы
Сообщений: 8 634
Регистрация: 1-11-05
Из: Минск
Пользователь №: 10 362



Цитата(kan35 @ Jul 26 2012, 08:52) *
Viko, вы любите передергиватьwink.gif

Да ну. Так, по мелочам придирки. Шутки.
Цитата
Вся основная работа должна происходить по DMA.

Вот вам мой пример. Пересылаю из внешней ОЗУ в контроллер ЖКИ. По ПДП оказалось медленнее, чем программно.
Код
void DpyBuf2LCD_copy(uint32_t Offset, uint32_t Size)
{
/*
  LED_on();
  DMA2->IFCR |= DMA_IFCR_CTCIF1;        // сбросить флаг прерывания
  DMA2_Channel1->CCR &= ~0x00000001;        // запретить пересылку
  DMA2_Channel1->CPAR = DPYBUF + Offset;    // начальный адрес буфера экрана
  DMA2_Channel1->CMAR = LCDRAM + Offset;    // начальный адрес памяти ЖКИ
  DMA2_Channel1->CNDTR = Size/2;        // 16-битовые пересылки  
  DMA2_Channel1->CCR |= 0x00000001;        // разрешить пересылку
//  while (!(DMA2->ISR & DMA_ISR_TCIF1));    // ждать флаг прерывания
  LED_off();
*/
/*
// Программная пересылка буфера в контроллер ЖКИ
  uint16_t *pSour = (uint16_t *)(DPYBUF + Offset);
  uint16_t *pDist = (uint16_t *)(LCDRAM + Offset);
  LED_on();
  for (uint32_t i=Size/2; i--; ) {
    *pDist++ = *pSour++;
  }
  LED_off();
*/

// Программная пересылка буфера в контроллер ЖКИ 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();  
}
Go to the top of the page
 
+Quote Post
kan35
сообщение Jul 26 2012, 08:36
Сообщение #43


Знающий
****

Группа: Участник
Сообщений: 537
Регистрация: 22-02-06
Пользователь №: 14 594



То, что по DMA работа (пусть даже внешняя память--внешняя память) оказалась медленнее - сюрприз. Ваши версии - почему этот нелогичный эффект получился, может быть DMA перегружен другой задачей?

Мы немного отклонились от темы, но у раз речь зашла, из своей практики скажу. В свое время делал драйвер для LCD контроллера на SPI, так благодаря DMA получилось даже сделать аналог графического ускорителя - рисование гор/верт линий было аппаратным, что очень ускорило работу того же ucGUI 320*240*16бит на SPI. Когда патался оптимизировать программный способ передачи, то работало в 2-4 раза медленнее, не говоря о том, что CPU только дисплеем и занимался.
Go to the top of the page
 
+Quote Post
ViKo
сообщение Jul 26 2012, 08:45
Сообщение #44


Универсальный солдатик
******

Группа: Модераторы
Сообщений: 8 634
Регистрация: 1-11-05
Из: Минск
Пользователь №: 10 362



Цитата(kan35 @ Jul 26 2012, 11:36) *
То, что по DMA работа (пусть даже внешняя память--внешняя память) оказалась медленнее - сюрприз. Ваши версии - почему этот нелогичный эффект получился, может быть DMA перегружен другой задачей?

Все связано с внутренними шинами микроконтроллера. В данном примере был STM32F103. Окончание пересылки проверялось программно. Таким образом, микроконтроллер пытался параллельно выполнять код и пересылать из памяти в память. Еще отладчик Keil uLink-ME висел, он тоже что-то забирал.
Ну, и программные пересылки я сделал 32-битовыми словами. Не помню, можно ли такое сделать по ПДП.

P.S. В STM32F2, F4 есть Bus matrix, там таких тормозов уже не будет, наверное.
Go to the top of the page
 
+Quote Post
kan35
сообщение Jul 26 2012, 08:58
Сообщение #45


Знающий
****

Группа: Участник
Сообщений: 537
Регистрация: 22-02-06
Пользователь №: 14 594



Действитеьлно, флаг ловить лучше в прерывании. DMA с 32 битными словами работает отлично.
Go to the top of the page
 
+Quote Post

4 страниц V  < 1 2 3 4 >
Reply to this topicStart new topic
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 26th August 2025 - 23:57
Рейтинг@Mail.ru


Страница сгенерированна за 0.01506 секунд с 7
ELECTRONIX ©2004-2016