У меня есть АЦП, которые начинает работать одновременно по таймеру и я хочу замерить время конвертации всех выбранных каналов с помощью таймера dwt (поднимается флаг, к примеру, TC и я меряю полученный DWT->CYCCNT) но вот какое дело, если я засовываю проверку флага в бесконечный цикл (__HAL_ADC_GET_FLAG) то получается одно значение CYCCNT, а если засовываю DWT->CYCCNT в прерывание по TC то получается совсем другое значение счётчика, гораздо большее, у меня вопрос, можно ли в принципе в отладчике засовывать счётчик dwt в обработчик прерывания? Если да, то почему получаются на столько разные значения, на порядки. Спасибо

Какие порядки? Этот счётчик считает такты. Их можно пересчитать в наносекунды. Приведите уже конкретные цифры. Кто знает, может быть, разница объясняется задержкой на входе в обработчик прерывания? Как знать, может быть оно у вас сделано очень-очень медленно?

Лучше вообще ничего не куда не засовывать не зная куда суёшь.
И что значит "в отладчике засовывать"? Вы DWT->CYCCNT где читаете - в своём коде или в окне "Watch" отладчика?
И да - как уже сказали - конкретные цифры в студию. А то 1 и 10 - тоже имеют разный порядок....

конкретные цифры в цикле while CCYNCT = 530, в десятичной, в обработчике CCYNCT = 27157, вот на такие порядки и отличается))в десятки раз



считаю в коде и засовывал в watch отладчика)

ацп у меня обрабатывает максимально 8 каналов, включаются они одновременно в режиме multimode, ацп тактируется 72МГц, такая же частота и у SYSCLK, поэтому вариант в CCYNCT=530 тактов лично мне видится более логичным, при 12 разрядном разрешении + 19 тактов ацп клока, выбранных в качестве времени сэмлирования, получаем кол-во тактов необходимое для конвертации всех каналов в ацп (12+19)*8 = 248, конечно чисто теоретически, но это ближе к 530 чем к 27157

Сообщение отредактировал Connor - Feb 28 2018, 09:12

В отладчике у Вас в это время входит ещё и время остановки на брекпоинте. Оно очень даже не маленькое.
Считывать нужно в коде. И убедиться что вход в ISR ничего не тормозит (запреты прерываний, другие ISR и т.п.). Да и поубирать чтение регистров периферии из окон Watch отладчика.

Модель МК не указана. Вы уверены, что АЦП можно тактировать с частотой 72 МГц? Есть подозрение, что он у вас будет туфту показывать или даже просто жёстко глючить.
Ну и опять же, кто сказал, что ожидание в цикле и прерывание срабатывают по одному и тому же условию? Я верю, что замысел именно таков, но как там вышло на деле - надо ещё разобраться.

Спасибо! учту



это stm32f303ve,в нём ацп можно тактировать с частотой в 72 мгц, туфут не показывает))проверял с помощью источника питания, показывает те значения, которые подаю ему на входы

Сообщение отредактировал Connor - Feb 28 2018, 10:23

На каждый вызов подпрограммы, возврат, переход и прерывание, процессор вынужден аппаратно очистить конвейер команд. Это может быть 5 циклов про 5-ти ступенчатом конвейере. Плюс к этому в стек пишется адрес возврата. А еще там должна быть смена состояяний регистров, которые должны записываться в стек... Контроллеру прерываний тоже может потребоваться несколько клоков на выработку запроса прерывания...

понимаете к чему я веду, мне надо укладываться в 20 мкс, это 1440 тактов для 72мгц клока, и тут получается что в одном случае я укладываюсь, а в другом нет, так чему мне верить и на что опираться?

Даже если-б у автора был CM4 и писались/читались в стек все регистры FPU, то всё равно указанное им время слишком велико, чтобы это были затраты по указанным причинам.


Найти в своём коде все места, где есть длинные запреты прерывания. Или длинные ISR с приоритетом выше чем у ISR АЦП.

stm32f303 использует сortex m4


Спасибо, посмотрю, я тоже считаю что слишком много тактов в сумме получается для таких затрат

Сообщение отредактировал Connor - Feb 28 2018, 10:52

Померить маленькое время очень непросто. Гораздо проще прокрутить интересующий процесс миллион раз или около того и померить время секундомером (в ведроиде такое есть). Ну и разделить на миллион, естественно.

Чтобы потешить внутреннего перфекциониста и заведомо избавиться от влияния всяких задержек входа в ISR, то можно попробовать использовать таймер+DMA:
запускаете приём первого блока преобразованных данных с АЦП через DMA; DMA работает связным списком:
первый блок транзакции - пересылка таймер->память, 2-й блок - пересылка АЦП->память, 3-й блок - пересылка память->регистры конфигурации DMA, чтобы запрограммировать его для следующей транзакции. Следующая транзакция: 1)пересылка таймер->память; 2)пересылка АЦП->память.
Обе транзакции должны запускаться от одного события АЦП, и выполнять всю цепочку пересылок без дополнительных сигналов-триггеров до конца транзакции.

PS: А вообще - не знаю как в STM32, но в моём Infineon XMC4700 таймера можно запрограммировать на capture счётчика таймера по сигналу готовности от АЦП. Вот такой способ будет самым точным. Может так можно сделать и в Вашем STM (если он внутри позволяет пробросить сигнал готовности АЦП до таймера). Или если этот сигнал готовности можно вывести на внешнюю ногу МК, то завести его обратно на вход захвата таймера.

Спасибо, попробую)

Чего уж муд(р)ить, на тестовую ножку выдать импульс, начинающийся по старту события и заканчивающийся по стопу. И измерить осциллографом.