|
|
  |
STM32F4 ADC DMA ? |
|
|
|
Jul 24 2012, 19:57
|
Гуру
     
Группа: Свой
Сообщений: 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)  Конечно их можно и нужно заменить на шаблоны при переходе на с++ Теоритически можно, и наверное нужно. Но как-то руки не доходят.
|
|
|
|
|
Jul 25 2012, 05:24
|
Профессионал
    
Группа: Свой
Сообщений: 1 047
Регистрация: 28-06-07
Из: Israel
Пользователь №: 28 763

|
Цитата(_Артём_ @ Jul 24 2012, 21:57)  Да какие обиды... Вопрос в их прогрессивности. Чем такой варинт хуже Код __INLINE void TestPinOn(void) { GPIOD->BSRRL = GPIO_Pin_15; } ? ДА ничем. ТЕм более, что я показал самый простой вариант. В общем виде порт и пин задаются дефайнами а не в явном виде. А при наличии __INLINE это считай тот-же макрос.
|
|
|
|
|
Jul 25 2012, 05:47
|

неотягощённый злом
     
Группа: Свой
Сообщений: 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)  В общем виде порт и пин задаются дефайнами а не в явном виде. А потом вдруг требуется инвертировать один из сигналов по какой-либо причине. И? Сели в лужу?
--------------------
“Будьте внимательны к своим мыслям - они начало поступков” (Лао-Цзы)
|
|
|
|
|
Jul 25 2012, 07:18
|
Профессионал
    
Группа: Свой
Сообщений: 1 047
Регистрация: 28-06-07
Из: Israel
Пользователь №: 28 763

|
Цитата(demiurg_spb @ Jul 25 2012, 07:47)  А потом вдруг требуется инвертировать один из сигналов по какой-либо причине. И? Сели в лужу? Ну так я потрачу 5 минут своего драгоценного времени, на то чтобы поменять в одном месте местами BSRRL и BSRRH, только и всего. Все равно 99.999% времени занимает основная задача, а не настройка портов и т.п. Я даже на PIC16 таким не заморачивался, хотя понятное дело что сложность решаемых задач там пониже. Помнить все флаги и биты регистров это конечно хорошо, но я предпочитаю их посмотреть в букваре когда пишу настройки и работу с периферией, а после этого сразу поскорее забыть
|
|
|
|
|
Jul 25 2012, 11:48
|
Профессионал
    
Группа: Свой
Сообщений: 1 047
Регистрация: 28-06-07
Из: Israel
Пользователь №: 28 763

|
Цитата(ViKo @ Jul 25 2012, 09:30)  Но, видимо, на регистры и биты ADC, DMA у вас аллергия? Такой стиль называется "эклектика". У меня не аллергия, но делая прибор на процессорах типа Кортексов, я хочу сосредатачиваться на основной задаче, а не на побочных, типа настойки периферии. Т.е. если у меня идет прием ЭКГ (электрокардиограммы) с АЦП, обработка и выдача результатов на дисплей и в УАРТ, то 99.99% времени я предпочитаю тратить не на настройку АЦП, дисплея и УАРТа, и копание в их битах, а на прикладные вопросы, связанные с ЭКГ и ее обработкой и отображением. Что поверьте мне, гораздо более трудоемко и наукоемко. (тем более, что кроме программы я еще и все железо делаю).
|
|
|
|
|
Jul 25 2012, 11:57
|

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

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

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

|
Цитата(kan35 @ Jul 25 2012, 15:26)  никто не отрицает, что работа через библиотеки менее эффективна, чем прямая работа с регистрами - это очевидно и ни для кого не секрет. Но следует здраво оценивать баланс между потерями и преимуществами. Наверное в 99% задач пофиг - как будет управляться периферия. Возможно, у некоторых (может быть у вас, кстати), задач критичных к этому будет 100%, а у некоторых как у меня - 0% и таких как я - большинство я уверен :-) . Для абсолютных противников библиотек они все же могут быть полезны как учебник по работе с периферией. Из этого я делаю вывод, что библиотеки - это хорошо. Еще недавно вы утверждали, что это использование библиотек - это абсолютно правильный путь. Надо думать, что сейчас у вас уже нет такой 100% уверенности?  Я не считаю себя противником того, что кто-то сделал до меня. Наоборот, всегда полезно посмотреть. Например, когда подберусь к USB, буду смотреть и в библиотеку. Но, например, когда хотел разобраться с SPI, быстро задвинул библиотеку подальше. Разбираться с ней мне показалось бессмысленной тратой времени. Невозможно понять работу железа, пользуясь готовыми функциями. Думаю, то же произойдет и с USB. Мне казалось, что на 72 MHz все будет летать. Ан нет...
|
|
|
|
|
Jul 25 2012, 14:46
|
Профессионал
    
Группа: Свой
Сообщений: 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 так у меня точно без не то что библиотк, а вообще драйверов, никакого желания ковыряться не возникнет.
|
|
|
|
|
Jul 26 2012, 05:52
|
Знающий
   
Группа: Участник
Сообщений: 537
Регистрация: 22-02-06
Пользователь №: 14 594

|
Цитата(ViKo @ Jul 25 2012, 16:50)  Еще недавно вы утверждали, что это использование библиотек - это абсолютно правильный путь. Надо думать, что сейчас у вас уже нет такой 100% уверенности?  Я не считаю себя противником того, что кто-то сделал до меня. Наоборот, всегда полезно посмотреть. Например, когда подберусь к USB, буду смотреть и в библиотеку. Но, например, когда хотел разобраться с SPI, быстро задвинул библиотеку подальше. Разбираться с ней мне показалось бессмысленной тратой времени. Невозможно понять работу железа, пользуясь готовыми функциями. Думаю, то же произойдет и с USB. Мне казалось, что на 72 MHz все будет летать. Ан нет...  Viko, вы любите передергивать  Если у вас "не летает" на 72 МГц, то стоит задуматься над тем как вы работаете с периферией. Как правило упомянутая вами работа с битами-флагами это подход который стоит применять в исключительных случаях. Вся основная работа должна происходить по DMA. У меня напрмер прекрасно уживаются mp3 плеер с tcp/ip, usb-msd и пользовательским интерфейсом и при этом проц в самом худшем случае 50% времени бездельничает. Я пользуюсь периферийной библиотекой (в том числе usb от st) :-) Но если тот же SPI или ADC обслуживать поллингом битов, то никакого быстродействия не хватит (даже напрямую обращаясь к регистрам), не говоря уже о том, что нужно данные готовить или обрабатывать.
Сообщение отредактировал kan35 - Jul 26 2012, 05:55
|
|
|
|
|
Jul 26 2012, 07:58
|

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

|
Цитата(kan35 @ Jul 26 2012, 08:52)  Viko, вы любите передергивать  Да ну. Так, по мелочам придирки. Шутки. Цитата Вся основная работа должна происходить по 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(); }
|
|
|
|
|
Jul 26 2012, 08:36
|
Знающий
   
Группа: Участник
Сообщений: 537
Регистрация: 22-02-06
Пользователь №: 14 594

|
То, что по DMA работа (пусть даже внешняя память--внешняя память) оказалась медленнее - сюрприз. Ваши версии - почему этот нелогичный эффект получился, может быть DMA перегружен другой задачей?
Мы немного отклонились от темы, но у раз речь зашла, из своей практики скажу. В свое время делал драйвер для LCD контроллера на SPI, так благодаря DMA получилось даже сделать аналог графического ускорителя - рисование гор/верт линий было аппаратным, что очень ускорило работу того же ucGUI 320*240*16бит на SPI. Когда патался оптимизировать программный способ передачи, то работало в 2-4 раза медленнее, не говоря о том, что CPU только дисплеем и занимался.
|
|
|
|
|
Jul 26 2012, 08:45
|

Универсальный солдатик
     
Группа: Модераторы
Сообщений: 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, там таких тормозов уже не будет, наверное.
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|