Мерси Миро, но търся LDO.

ето едно наше ново м4:
http://www.analog.com/en/products/proce ... t-overview
и едно старо ама м3:
http://www.analog.com/en/products/proce ... t-overview

И двете ви са напред в ulpbench-а, макар старото да е по-напред.
Гледам че пише че са го пробвали в hibernate на заспало - това го дават да пази SRAM-а. Какво става след излизането от хибернейт - ресетоподобно ли е поведението или продължава от следваща инструкция? Ако имаш информация де, ако не ще ровя из чаршафите.
Ицо, ако ще реагираш само на външен сигнал (цифров) дали не е по-логично да спираш изцяло тока - с външен ключ, със самозадръжка от изхода на контролерчето докато си свършиш работата и после пак да умира (а не да спи). Те повечето при излизане от дълбок сън все едно си ги ресетнал, така че разлика няма голяма. В твоя случай изглежда че ще имаш много дълги периоди на спане, което е различно от това периодично да трябва да събираш данни. Т.е. пикоамперите в заспало ще са важни.
Предполагам не забравяш че в тези приложения винаги трябва да се съобразиш с химията на батерията - да не се окаже че саморазряда и е много повече от твоята консумация...

Стигаме и до логичния въпрос - голяма част от препоръчаните чипове са ARM базирани. Останал съм впечатление, че в общия случай, на тях се търкаля и някаква ОС. Това което ще правя, не се нуждае от подобни усложнения. Би работило и по класическия начин - полиране или прекъсване от вход, таймер или друго събитие.
Та, доколко "армовете" са удачни за подобен стил на работа? Имам чувството, че по-голяма част от кода ще е за сетване на периферията - тръгни, спри, заспи, смени клока, направи нещо със н'амси кое захранване, и т.н...

Не съм работил с ARM, и още се стряскам от "сложността" им.
Прегледах някакъв по диагонал. Само регистрите им са дълги към декар, декар и малко...

След дълги мъчения ще слагаме и на проца да се изключва захранването. Явно все някаква периферия остава включена и църка. За в този ни случай включването е рядко и възможно.

А бе като ви чете човек се чуди как може да има електронни часовници
Спомних си една джаджа в градината: имаше дисплей с термометър, влага на почвата и още нещо, а при засушаване пискаше няколко пъти в минута. Изкара две години и умря от удавяне. Батерията беше CR, леко несиметрична, с размер около две CR2032, забравих коя. Като я извадих още имаше хляб в нея, но после ръждяса.

E- някой докопвал ли се е до прочутото Apollo?
Edit:
IAR имат дебъгер с ампермер. Можеш да следиш в дебъг прозореца всяка инструкция и действие как влияят на консумацията.

Не е все едно...
Контролерчетата с LP режими могат да си дърпат и пускат шалтера сами, но когато си го пуснат знаеш защо са си го пуснали. Отвън каквото и да правиш пак ще отидеш на някакви си наноампери. За тая консумация контролера ти дава няколко weakup пина плюс евентуално събуждане от RTC/таймер плюс темпер плюс някаква памет (поне няколко регистъра).
При 1-2uA вече може да имаш и някаква периферия от сорта UART, анологови компаратори, GPIO-та вече работят и т.н. Казвам го понеже това е консумацията която би имал само от един единствен пулъп със стойност 1M. Да, процът не е захранен, ама информацията от перифериите не се губи. С външна логика това няма как да го направиш.



Така е... ТО не се нуждае изобщо, ама въпросът е ТИ дали се нуждаеш?
Вариантите са два - или ползваш нещо готово, или сядаш и четеш и четеш и четеш и евентуално подкарваш нещо си твое...
За съжаление наличните библиотечки и ос-чета не са върха на сладоледа. Това не е свързано със самото ядро, колкото със сложността на целия чеп в съчетание с липсата на идея в драскачите...
Ти не веднъж си казвал, че не искаш да се жениш... така че изключваме варианта сам директно да управляваш периферии и т.н. Просто забравяме тоя вариант и стигаме до варианта в който ти подкарваш някакъв примерен код (с всичките му кусури). И това че тоя код, който ще ползваш ще е раздут, повярвай ми ще ти е най-най-най-малкия проблем.

Ако все пак някой се реши да подкарва Ambiq Micro, нека се обади. Имам познат който е при тях и би могъл да удари едно рамо ако се наложи.

Другата седмица излиза Apollo2 dev board-a за 55 EUR

http://shop.feeu.com/epages/es966226.sf ... s/AMAPHEVK
http://ambiqmicro.com/apollo-ultra-low- ... ollo2-mcu/

Това че има подобни устройства, за никакви пари, не значи че са правени както им падне или през пръсти, и въпреки това те изкарват на батерии с години.
Вероятно е точно обратното - за да изкарват толкова, е отделено не малко време за развой и натъкмяване...
В мрежата има куп калкулатори за живота на батерията при съответната консумация. Разцъкай ги и виж какво ще са резултатите без оптимизация на консумацията...

Редакция:

Тръгна да подсказваш, но не довърши... Ясно е че ще има мотики. Най-общо, какво да очаквам като такива?
Едната за която се сещам, ще е тестването на подобна система.

Гичо, нещо не фатям въпроса ти....
бъркаш нещо мезетата hibernate със shutdown.
при hibernate имаш области от паметта(2к , 4, 8, 32) дето може да си ги запазиш по време на повердоун мода (SRAM retention) програм каунтера и стакпойнера също може да са ти в тази срам, демек като се събуди - все едно не е спало.
при shutdown моде е все едно хардуерен ресет срама е забърсан демек нищо не се пази ...

Ми най-голямата е мотика е, че навлизането се оказва невероятно бавен процес. Трудно ми е да кажа, но не е само по-голямата сложност на нещата. Специално при АРМ няма еднозначно решение кое как да се прави. Съответно варианти много и като почнеш да се бъзикаш с нещо, докато схванеш логиката кое, защо как е направено и времето си минава...
По принцип аз на всички давам един и същ акъл, тъй като нещата не са особено интуитивни (меко казано) и има и различни подходи, то затова най-добре е някой да те въведе. И тъй като трудно един и същ човек ще ти покаже всички подходи, то просто тръгваш от познат на познат и за по 2-3 часа искаш да ти покаже как той работи, какви инструменти, какви библиотеки, каква организация и т.н. Аз с удоволствие бих ти отделил няколко часа, но тъй като моя подход е меко казано странен, желателно е да видиш и други, пък после да избираш

Първо трябва да си харесам някакво контролерче, а след това да се занимавам с конкретните му особености...

Не се връзвай че били сложни. Отваряш сайта на Mbed и си избираш платка - примерно discovery или nucleo с някое L-че на STM.
Регистрираш се там, и преглеждаш примерите - всичко е ниво ардуино - цялата инициализация и абстракция е готова и описана подробно.
Ако онлайн компилатора те дразни си експортираш към офлайн IDE.
Разбира се има особености по инструментариума, но ако откровено си говорим, майкрочипските неща не са по-лесни за подкарваме (ако не говорим за "само 33 инструкции" асемблер).
Ако дадеш повече информация ще помагаме с избора:
- ще има ли някакъв интерфейс - било то потребителски или дори само сервизен (usb, сериен)?
- нещо радио ще ти трябва ли?
- каква периферия е нужна - дотук разбрах за един вход който ще трябва да може да буди; някакви АЦП-та, монитор на батерията, ... ?
Предполагам че някакъв вид "изход" ще трябва да има - лампа, пищялка, интерфейс, дисплей ?

itso.t, с какъв тип батерии ще се храни дивайса - първични (тионил-хлорид?) или акумулатор (Li_Ion?).


Кое пък име е трудното?