[Connor 0]

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

[scifi 1]

Если да, то почему получаются на столько разные значения, на порядки.

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

[jcxz 183]

можно ли в принципе в отладчике засовывать счётчик dwt в обработчик прерывания? Если да, то почему получаются на столько разные значения, на порядки. Спасибо

Лучше вообще ничего не куда не засовывать не зная куда суёшь.

И что значит "в отладчике засовывать"? Вы DWT->CYCCNT где читаете - в своём коде или в окне "Watch" отладчика?

И да - как уже сказали - конкретные цифры в студию. А то 1 и 10 - тоже имеют разный порядок....

[Connor 0]

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

 

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

 

Лучше вообще ничего не куда не засовывать не зная куда суёшь.

И что значит "в отладчике засовывать"? Вы DWT->CYCCNT где читаете - в своём коде или в окне "Watch" отладчика?

И да - как уже сказали - конкретные цифры в студию. А то 1 и 10 - тоже имеют разный порядок....

 

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

 

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

Изменено 28 февраля, 2018 пользователем Connor

[jcxz 183]

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

В отладчике у Вас в это время входит ещё и время остановки на брекпоинте. Оно очень даже не маленькое.

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

[scifi 1]

ацп у меня обрабатывает максимально 8 каналов, включаются они одновременно в режиме multimode, ацп тактируется 72МГц, такая же частота и у SYSCLK, поэтому вариант в CCYNCT=530 тактов лично мне видится более логичным

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

Ну и опять же, кто сказал, что ожидание в цикле и прерывание срабатывают по одному и тому же условию? Я верю, что замысел именно таков, но как там вышло на деле - надо ещё разобраться.

[Connor 0]

В отладчике у Вас в это время входит ещё и время остановки на брекпоинте. Оно очень даже не маленькое.

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

 

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

 

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

Ну и опять же, кто сказал, что ожидание в цикле и прерывание срабатывают по одному и тому же условию? Я верю, что замысел именно таков, но как там вышло на деле - надо ещё разобраться.

 

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

Изменено 28 февраля, 2018 пользователем Connor

[iosifk 3]

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

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

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

[Connor 0]

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

[jcxz 183]

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

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

 

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

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

[Connor 0]

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

 

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

 

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

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

Изменено 28 февраля, 2018 пользователем Connor

[scifi 1]

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

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

[jcxz 183]

Чтобы потешить внутреннего перфекциониста и заведомо избавиться от влияния всяких задержек входа в ISR, то можно попробовать использовать таймер+DMA:

запускаете приём первого блока преобразованных данных с АЦП через DMA; DMA работает связным списком:

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

Обе транзакции должны запускаться от одного события АЦП, и выполнять всю цепочку пересылок без дополнительных сигналов-триггеров до конца транзакции.

 

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

[Connor 0]

Чтобы потешить внутреннего перфекциониста и заведомо избавиться от влияния всяких задержек входа в ISR, то можно попробовать использовать таймер+DMA:

запускаете приём первого блока преобразованных данных с АЦП через DMA; DMA работает связным списком:

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

Обе транзакции должны запускаться от одного события АЦП, и выполнять всю цепочку пересылок без дополнительных сигналов-триггеров до конца транзакции.

 

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

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

[ViKo 1]

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