Перейти к содержанию
    

STM32L082 в спячке ест больше, чем на всем скаку

1 час назад, Integro сказал:

Без WFI и пин TEST2 не дергается? Там случайно нет каких подтяжек которые могут чтото потреблять?

Дык в том-то и дело, что у него при одинаковых условиях магия... Влияет только WFI().

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

7 minutes ago, Arlleex said:

Дык в том-то и дело, что у него при одинаковых условиях магия... Влияет только WFI(). 

Я понимаю что условия одинаковые а еще нужно понимать что без WFI пин TEST2 будет практически всегда находиться в нуле, это единственное отличие(для приведенного кода) которое может повлиять на потребление,например не верной конфигурацией пина или наличием внешних подтяжек.
Хотя логично предположить что TEST2 уже появился в момент дебага, после обнаружения проблемы но уточнить этот момент думаю стоит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Это потребление всей схемы с датчиками. Датчики в обоих случаях опрашиваются идентично плюс-минус десяток микросекунд. Дерганье или не дерганье ноги TEST в обоих случаях на потребление влияет ниже порога разрешения моего микроамперметра. Дерганье было добавлено уже после обнаружения эффекта - чтобы убедиться, что программа действительно останавливается в одном случае и выполняется во втором.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

50 minutes ago, Сергей Борщ said:

Это потребление всей схемы с датчиками.

А как ведет себя WFI без инита датчиков и всего остального, что показывают такие примитивные тесты?
 

//Test run
int main() {
 
  for(;;) {    
  }
}

//Test sleep
int main() {
 
  for(;;) {
      __WFI();   
  }
}



Вообще, ооочень странная ситуация, может методику или оборудования измерения сменить?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А вобще ктонибудь доки читает? Я нет и потому не сразу узнал что в stn32f3..4...7...h7 в LP регистрах RCC установлены биты всех устройств?

Изменено пользователем GenaSPB

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

41 минуту назад, GenaSPB сказал:

в LP регистрах RCC установлены биты всех устройств

И в описании каждого бита написано, что тактирование включается только для тех модулей, которые включены битом EN в регистрах самой периферии. Я решил, что "у нас принято джентельменам верить на слово". Может и врут, надо проверить. Исключений очень мало, SYSCFG, DBG и порты я выключал - не помогло, ПДП я во сне использую. Из остального в регистрах периферии включаю только I2C и TIM6. Да и сильно маловероятно, что даже вся периферия в сумме будет кушать в несколько раз больше ядра (оно по моим прикидкам должно есть 6 мА / 32 МГц = .188 мкА/МГц, каждая периферия в среднем 10 мкА/МГц). 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 часа назад, Integro сказал:

А как ведет себя WFI без инита датчиков и всего остального, что показывают такие примитивные тесты?

Мне проще было сделать бесконечный цикл вместо опроса датчика. Пустой цикл с ногодрыгом ноги  - 8.85 мА. Пустой цикл с WFI - 3.05 мА. Хм. Тут тенденция с теорией сходится - с WFI потребеление меньше. Откуда такие огромные цифры - буду копать. В общем - чуда нет, надо трясти. Спасибо за подсказку. Надо разбираться, что там Semtech на пару с кубом в своем стеке наворотили: этот глубокий сон - часть их реализации стека LoRaWAN и что-то они там еще творят перед засыпанием и после просыпания. Просто поскольку в глубоком сне потребеление было вполне адекватное - я туда и не лез. Похоже, надо не датчики к стеку прикручивать, а стек понемногу к датчикам добавлять и смотреть, на каком этапе начнутся чудеса.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Может быть при использововании WFI увеличивается общее время активной работы? Ведь на пробуждение после WFI ядру требуется время, не знаю точно сколько мкс. А если это повторяется в цикле...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

13 часов назад, piroman сказал:

Ведь на пробуждение после WFI ядру требуется время, не знаю точно сколько мкс. А если это повторяется в цикле...

Из Idle (когда спит только ядро) - не требуется.

 

Можно попробовать:

1. Заменить WFI на WFE.

2. Убрать проверку таймаута (по TIM6).

3. Построить работу как советует мануал на инструкции WFI/WFE: выполнять их в отдельном цикле ожидания, а не вместе с полезным кодом. Или вообще - вынести всю полезную работу в обработчики прерывания, а в фоновом процессе крутить только одну инструкцию WFI/WFE. Или вообще использовать режим работы с SCR.SLEEPONEXIT=1.

PS: Да - и какое у Вас состояние регистра SCR ядра?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

13 часов назад, piroman сказал:

Может быть при использововании WFI увеличивается общее время активной работы?

Буквально на доли процента. Если диаграмма (с WFI) в первом сообщении занимает 1.22 мс, то такая же без WFI - 1.15 мс

1 минуту назад, jcxz сказал:

2. Убрать проверку таймаута (по TIM6).

на потребеление оно не влияет, проверял.

3 минуты назад, jcxz сказал:

Реализовать всю работу как советуют в мануале на WFI/WFE: выполнять их в отдельном цикле ожидания, а не вместе с кодом.

Что-то не видел я такого в документации. В какой именно документации это описано?

6 минут назад, jcxz сказал:

Или вообще - вынести всю полезную работу в обработчики прерывания, а в фоновом процессе крутить только одну инструкцию WFI/WFE.

Это мне не подходит.

12 минут назад, jcxz сказал:

PS: Да - и какое у Вас состояние регистра SCR ядра?

По нулям.

 

Беру паузу разобраться, кто же на плате жрет 3 мА во время сна в пустом цикле без опроса датчика.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

7 минут назад, Сергей Борщ сказал:

Что-то не видел я такого в документации. В какой именно документации это описано?

"ARMv6-M Architecture Reference Manual":

Because debug entry is one of the WFI wake-up events, ARM recommends that software uses Wait For 
Interrupt as part of an idle loop rather than waiting for a single specific interrupt event to occur and then 
moving forward. This ensures the intervention of debug while waiting does not significantly change the 
operation of the program being debugged.

 

Даже не касательно Debug в реализации WFI могут быть какие-то особенности оптимизированные на именно такой стиль работы. Там есть ещё про "IMPLEMENTATION DEFINED", допускаю что от исполнения WFI может идти какой-то сигнал контроллеру питания, что и может влиять на потребление.

 

Цитата

Это мне не подходит.

Почему?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 минуту назад, jcxz сказал:

Почему?

Потому что сейчас кроме опроса датчика программа иногда выполняет кубовый стек lorawan, а когда я напишу вместо него свой - программа будет работать под управлением ОС.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

10 минут назад, Сергей Борщ сказал:

Беру паузу разобраться, кто же на плате жрет 3 мА во время сна в пустом цикле без опроса датчика.

Хммм.... А мы тут все думали что Вы потребление только МК измеряете....  :wink:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

4 минуты назад, jcxz сказал:

Because debug entry

Ясно. В програмах под управлением ОС у меня так и сделано. Как это реализовать без ОС я слабо представляю.

Только что, jcxz сказал:

А мы тут все думали

"Отучаемся говорить за других". Это раз. Второе - как добавление WFI в цикл ожидания завершения прерывания может повлиять на потребеление чего-то за пределеами МК?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

7 минут назад, Сергей Борщ сказал:

Ясно. В програмах под управлением ОС у меня так и сделано. Как это реализовать без ОС я слабо представляю.

Не сложно:

Взять какое-нить прерывание от периферии (не используемое); назначить ему приоритет ниже приоритета любого прерывания от периферии; поместить полезную работу в его ISR; когда нужно выполнить полезную работу - активизировать это прерывание программно (через регистры NVIC); по исчерпании полезной работы - выходить из этого ISR (выход будет в фоновый процесс - в цикл while (1) __WFE(); или использовать SCR.SLEEPONEXIT=1).

Собственно этот программно-активизируемый ISR будет эмуляцией задачи РТОС. Можно даже всё делать на одном стеке так как вытеснение задач не нужно.

10 минут назад, Сергей Борщ сказал:

Потому что сейчас кроме опроса датчика программа иногда выполняет кубовый стек lorawan, а когда я напишу вместо него свой - программа будет работать под управлением ОС.

Ну так SCR.SLEEPONEXIT=1 не мешает РТОС. У меня например в РТОС фоновый процесс только WFE выполняет, да иногда ещё загрузку CPU считает. Если загрузку CPU считать не надо, то элементарно вместо фонового цикла 

while (1) __WFE(); поставить SCR.SLEEPONEXIT=1 и всё будет работать точно так же.

Да и стеку мне кажется - не должно мешать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...