В итоге рассматриваем несколько вариантов:
1. Простой процессор со своим wakeup механизмом/внешним rtc/таймером на wakeup pin/reset
2. CC2640 в состоянии reset с wakeup от внешнего таймера/rtc
3. процессор с полным выключением питания и внешним rtc/таймером
4. TMS320 с FRAM в качестве промежуточного процессора для периферии со всеми ранее описанными схемами.
Почему столько схем? Практический разбор потребления сильно зависит от применения устройства и особенностей его эксплуатации. Скажем, есть у нас один клиент с совершенно странными хотелками просыпаться раз в 3 секунды и рапортовать о своем состоянии. За 3 секунды холодный запуск сожрет больше энергии, чем мы сэкономи ее полным отключением, здесь первый вариант однозначно. А если время ожидания перед передачей данных составляет несколько часов (или дней), то тут уже практичней гасить все полностью. И есть, конечно, миллион промежуточных вариантов.
Заодно отловили мультиметр неприятный аппаратный баг:
Пара конденсаторов в 10uF стоит за ключом, что при старте аналогично КЗ батарейки. Просадка до 2.7v.
В общем, ловля блох она такая...
Возвращаясь к потенциальным методам снижения потребления. Почему все хотят отправлять сообщения как можно чаще? Естественно, для отзывчивости системы. В 99% случаев оно нахрен не нужно. Модная тенденция нынче в том, чтобы использовать дополнительный wakeup receiver с декодером мака, чтобы начинать двусторонний обмен только тогда, когда этого ждет хост:
Увы, большинство статей на сейчас в состоянии ресерча. Я нашел единственный продукт на рынке, готовый к применению: AS3930. Но, увы, дорого и 1.2uA - многовато. Сравнимых цифр можно получить и поллингом без этого приемника.
Но тенденция есть. Ждем ебилдов. Эх, вот бы детекторный приемник в BGA и чтобы еще схему подзаряжал :)
