caxapa.ru :: Господа, а расскажите, как в системах на RTOS решается вопрос перехода на низкое энергопотребление от батарейки? Задачи потеряли актуальность, нужно кардинально снизить частоту контроллера, сохранить данные в EEPROM и уснуть глубоко, при появлении обычного питания восстановиться и продолжить работу.

Что мешает остановить ядро планировщика и уснуть, куча то сохранится, оставить только одно прерывании по которому пускать планировщик дальше. А если куча не важна то сохраняем ИРОМ, сбрасываем Ядро хардово, оставляем только одно прерывание по появлению питания, и sleep до появления внешнего питания. - Cyclone(21.12.2020 15:43)

5 секунд? :-O Обычно достаточно десятков миллисекунд для мегагерцев и ~полсекунды для килогерцев. Если кварц не завёлся за несколько (десятков)тысяч своих периодов -- то скорей дефект. И ссылка какая-то левая у тебя. - fk0(21.12.2020 14:13)
- Полсекунды - это, таки, наилучший случай. Высокая добротность * низкая частота = длительный запуск. Toчкa oпopы(347 знак., 21.12.2020 14:52)
- 5 секунд!!! Такое оно:( Ссылку перепроверил в хромом, опере, вивальди, эдже. Огнелис обновляться начал и пока в процессе. Скорее трабла у тебя - Vit(21.12.2020 14:34)

Вот пример, как это может выглядеть со стороны пользователя. - s_h_e(21.12.2020 12:47, ссылка)

В лучшем случае есть "idle task", в котором выполняется инструкция "SLEEP" или "HALT", ожидающая следующего прерывания... Снижать частоту МК скорей смысла не имеет. Имеет смысл останавливать ядро вообще. Но генератор и периферия же при этом продолжают работать! И потреблять десяток мА. Если их выключить -- прерывания возможны только внешние (от ножек, от RTC) и счёт времени только от RTC. Вряд ли остановку счётчика времени стоит увязывать с RTOS. Но и без RTOS, отдельно fk0(84 знак., 21.12.2020 12:34)

Есть реальные цифры по работающем по биглупу дивайсом: ядро потребляет десяток мА на высокой скорости (STM32 L4), сохранение данных происходит сотня мс, в это время питание уже пропало, нужно удержаться ненамного больше 3 мА отдаваемых CR2032, ну а полный сон до 2 мкА. - VLLV(21.12.2020 12:47)
- Если ты хочешь сказать, мол снижение тактовой поможет, то есть и контраргументы: снизив тактовую частоту ты затратишь на вычисления, очевидно, большее время. То на то и выйдет. А если у тебя где-то циклы с ожиданием, то нужно работать по прерываниям и останавливать ядро (SLEEP/HALT) когда ничего не делаешь. Хотя обычно такой параметр как ма/Мгц немного падает с снижением частоты. Но не кардинально. fk0(2498 знак., 21.12.2020 13:13)
  - Не, для такого аварийного выключения сохранение только в EEPROM, у флэш, что внешней, что внутренней слишком большой ток записи. Принципы рапределения данных по типам отработаны на биглупе. Что касается частоты в режиме малого потребления, то оптимум сильно зависит от семейства контроллера из-за особенностей периферии. Например, у freescale I2C становится настольно медленным, что ресурс батареи расходуется впустую на поддержание ядра, которое ждет, пока I2C передаст данные. - VLLV(21.12.2020 15:14)
    - чуток можно в бэкап-памяти сложить. современные FLASH пишут страничку 256 байт порядком 1-3 мс (стирание отдельно). FRAM наверно постеснялись положить. бывают ещё SRAM+EEPROM. у этих STM32L4 ещё есть отдельный блок 32K SRAM --> These 32 Kbyte SRAM can also be retained in Standby mode - Vit(21.12.2020 16:21)
    - Непонятно, зачем вообще менять частоту ядра для единственной задачи сохранения. По идее, оно должно тупо спать и просыпаться по событиям вроде "запись блока данных закончена". При таком сценарии снижение частоты мало что даст, кроме замедления работы этой задачи. Если пиковый ток слишком высокий для таблетки, так и напишите. Но желательно с цифрами. - s_h_e(21.12.2020 15:47)

Теоретически можно всё делать через сброс. Сохранить где-нибудь состояние, сброситься и запуститься в режиме глубокого сна. Потом сброситься, запуститься в нормальном режиме с восстановлением состояния. Тогда RTOS пофиг. - SciFi(21.12.2020 12:33)

ээ. давно не RTOS`ил, но могу предположить последовательность: рассылаем потокам мессагу "готовьтесь ко сну", потоки усыпляют свою периферию или свои внешние подчинённые девайсы, рапортуют что готовы ко сну. в управляющей задаче отрубаем прерывания шедулера (стопорим таймер), настраиваем прерывания для пинов пробуждения и даём WFI (wait for interrupt). после команды WFI запускаем системный таймер, ставим рассылку всем о пробуждении, и пошли в главный цикл. - Mahagam(21.12.2020 12:29)

процесс не двух-ступенчатый, а трех-ступенчатый - высокое потребление, низкое потербление, спячка. Боюсь, что при низком потреблении (малой частоте) RTOS ляжет. - VLLV(21.12.2020 12:58)
- малая частота == 100% загрузка задачами. вы когда комп на 100% напрягаете - он ложится? - Mahagam(21.12.2020 14:30)
  - Хм, комп... Мы не MS, все пишется упрощенно, под какую-то одну производительность. - VLLV(21.12.2020 14:59)
    - а что у MS усложнённого? профессиональный переключатель задач написанный элитными индусами? всё тоже самое - задачи используют 100% машинного времени и выполняются с той скоростью, с которой могут. разве что % который уходит на переключение задач увеличивается. но вы же не собираетесь при работе от часового кварца иметь системный тик в миллисекунду? пришло решение уйти в ультраэконом и сохраниться - снижаем тактовую на внешнюю флешку, семафорим ненужным задачам о том чтобы Mahagam(170 знак., 21.12.2020 15:08)
      - ОК, вариант 4: RTOS работает в штатном режиме. В принципе, от RTOS и нужно всего лишь подключить внешнюю библиотеку. Две задачи, внешнюю затыкаем, вторая - это старый биглуп. - VLLV(21.12.2020 15:21)
        
        уже тыщный раз вещаю - скочайте CTL, почитайте доку и исходники. они там вообще красиво лаконично и понятно написаны. это ни разу не rocket science и не black magic. если проц затыкается с RTOS, то и без RTOS ему тоже будет плохо. - Mahagam(21.12.2020 15:28)

Средства и методы разработки