Re: STM32 на батарейках
Пн ноя 16, 2015 20:01:13
Galizin писал(а):Контроллер добавит микроампер 20-30 к 15 микроамперам dc-dc что даст 1,2 года.
Не так надо считать.
- подключаем Step-Up только на 1 секунду во время измерения. Даже если каждую минуту снимать показания, получается очень мало.
- пока STM32 спит, он даже с часами потребляет порядка 2 мкА, типично котроллер можно включать на медленной скорости, и он будет потреблять 0.3-1 мА (как настроишь) во время измерения.
Тут основной вопрос в потреблении передающего модуля.
Re: STM32 на батарейках
Пн ноя 16, 2015 22:35:06
Совершенно верно - среднее потребление безпроводного датчика определатеся радио-модулем. Остальная часть схемы, включая MK, потребляет крохи от этого. Если использовать ТИ-евские СС1101 и их производные, например, то для них выгодно даже понижать напряжение до 1.9-2.1в во время приема/передачи для экономии батареи без потери излучаемой мощности. Экономия по энергетике будет 20-35%. Для этого у них есть высокоэффективные понижающие конвертеры специально для RF приложений с рекордно низким I_q. В этом случае МК и датчики можно запитать непостерственно от литиевой 3.6в батарейки как советовали выше. Конвертер в выключенном состоянии пропускает это напряжение на спящие МК и сенсоры, потребляющие все вместе порядка 1-2мкА. При запуске конвертера напряжение всей схемы на время передачи просаживается до 1.9в, или сколько сенсоры выдержат по минимуму если их не отключать. Я при использовании некоммутируемого Si7021 понижал до 2.1в на TPS62733. При использовании другого радио следует пристально изучить сопутствующие апноуты. У силлабовких, например, картина совершенно иная.
Re: STM32 на батарейках
Вт ноя 17, 2015 02:40:04
balmer писал(а):Не так надо считать.
- подключаем Step-Up только на 1 секунду во время измерения. Даже если каждую минуту снимать показания, получается очень мало.
Так как конфигурация беспроводного сенсора у меня еще целиком не вырисовывается, я попробовал грубо посчитать какое-то абстрактное устройство, состоящее из двух батареек, преобразователя, двух датчиков ds18b20 (два мне и не нужно, но пусть будут имитатором чего-нибудь), NRF24L01 и STM32F030. Измерения я так же прикинул с периодичностью в минуту, но датчики включаются не на секунду, а на 780 миллисекнуд (10мс на инициализацию, 750мс им на раздумья и 20мс на выдачу данных). Потребление датчиков получается 2 * 1,5ма * 0,78с / 60 = 39мка/ч. Передаваемый в эфир пакет состоит из 128 бит, что вроде бы с запасом. Время передачи чуть больше половины миллисекунды, но на то, да на то, пусть будет 1мс. Потребление: 15ма * 0,001с / 60 = 0,25мка/ч. Процессор потребляет в режиме сна 2мка/ч. В режиме работы пусть будет 15ма. После пробуждения каждую минуту он инициализирует и запускает термодатчики за 10мс, потом спит 750мс, потом 20мс забирает данные и еще какое-то время уходит на передачу. Добавим для верности 5мс. Потребление: (15ма * 0,01с + 15ма * 0,025с) / 60 + 0,002ма/ч = 10,75мка/ч. С учетом времени на всю процедуру, получается, что преобразователь должен быть включен 785мс. Ток покоя для него указан 4мка, а в работе, предположим, он бесцельно тянет 2ма. Потребление: 2ма * 0,785с / 60 + 0,004ма/ч = 30,17мка/ч. Ток саморазряда щелочной батарейки АА где-то 90мка. Расчет не учитывает КПД преобразователя, т.к. пока не пойму, какие значения брать. Считаем сумму:
39 + 0,25 + 10,75 + 30,17 + 90 = 170,16 мка/ч.
Емкость обычной щелочной батарейки АА где-то 2000ма/ч. Получается, что прибор с них сможет работать 2000 / 0,17016 = 11753 часа или 489 дней. Урезаем на всякий случай осетра еще на четверть и получаем 367 дней или один год. Я поначалу раздумывал насчет 32L (надо покупать, но неохота) или даже 8L (надо применять, лежат без дела), но и с 32F030 получается вполне терпимо.
Счетовод я порой бываю еще тот, т.ч. жду обоснованную критику, где я тут обмишурился.
пока STM32 спит, он даже с часами потребляет порядка 2 мкА, типично котроллер можно включать на медленной скорости, и он будет потреблять 0.3-1 мА (как настроишь) во время измерения.
У меня больше выходит. Надо уточнить.
Тут основной вопрос в потреблении передающего модуля.
Из за малого времени работы получается совсем низкое усредненное потребление. Самое низкое среди всех. Я тоже сначала бы не подумал.
Re: STM32 на батарейках
Вт ноя 17, 2015 04:35:10
Удалил.
Re: STM32 на батарейках
Вт ноя 17, 2015 06:14:59
Теперь понимаю, почему у Вас сенсоры самые жручие. Зачем 1- wire ? Поставьте нормальный и2с сенсор, токопотребление сразу упадет. И МК незачем на полной скорости гонять. Достаточно на 4 мгс, при этом потребление его должно быть около 250 мка. У Кинетиса так, у 030 не помню. Среднее потребление всей схемы без ДС и саморазряда не должно быть более 20 мка. Один год это очень мало. Нужно эакладываться на 5 лет и не менее. Завтра уменя длинная дорога и весь день в отъезде - отхожу ко сну сейчас.Извините за сумбур.
Re: STM32 на батарейках
Вт ноя 17, 2015 09:41:10
Я так понимаю здесь речь не идет о том как сделать лучше, а о том что получится из готовых комплектующих. Потребление step-up в отключенном состоянии не специфицировано (:. Можно конечно предполагать что оно не больше 4 микроампер, но могут быть и чудные открытия.
Re: STM32 на батарейках
Вт ноя 17, 2015 14:08:30
Кстати про токопотребление. Вот такие штуки все еще стоят, и работают у меня. Правда уже со вторым комплектом батареек. Прошлой весной разбирался, почему батареек хватает на год примерно.
Оказалось, что очень много жрет очистка флеша. Там циклический буфер для данных во флешь памяти. Каждые 6 часов флешь чистится. Пишутся новые 4 КБ . Причем часть проблемы - это высокое потребление тока при очистке флеша. Так бы прибор еще долго проработал при почти севших батарейках, но нет - из за высокого потребления начинает перегружаться и время сбивается. Во флешь естественно при этом ничего не пишется.
Нет, в обычном случае 1000 ма/ч. Причем опять же ньюансы. Не забываем, что со временем сильно растет внутреннее сопротивление батареи. Для микроамперных токов это все равно, а вот для десятков миллиампер уже очень существенно.
Оказалось, что очень много жрет очистка флеша. Там циклический буфер для данных во флешь памяти. Каждые 6 часов флешь чистится. Пишутся новые 4 КБ . Причем часть проблемы - это высокое потребление тока при очистке флеша. Так бы прибор еще долго проработал при почти севших батарейках, но нет - из за высокого потребления начинает перегружаться и время сбивается. Во флешь естественно при этом ничего не пишется.
a5021 писал(а):Емкость обычной щелочной батарейки АА где-то 2000ма/ч.
Нет, в обычном случае 1000 ма/ч. Причем опять же ньюансы. Не забываем, что со временем сильно растет внутреннее сопротивление батареи. Для микроамперных токов это все равно, а вот для десятков миллиампер уже очень существенно.
Лучше полностью отключать, транзистором (если речь про BL8530). Отключал при помощи IRML6302, ток получается сильно меньше 1 мкА. Но тут надо аккуратно паять. У меня один раз таки прошило статикой, после этого минимальный ток в закрытом состоянии стал порядка 10 мкА.Galizin писал(а):Потребление step-up в отключенном состоянии не специфицировано (:.
Re: STM32 на батарейках
Вт ноя 17, 2015 15:57:57
balmer писал(а):Нет, в обычном случае 1000 ма/ч. Причем опять же ньюансы.
В них и дело. Емкость существенно зависит от тока. Вот первый попавший материал по тестированию батареек. Хорошо видно, как, например, у Duracell Coppertop, разница в емкости при разрядном токе в 2А и в 100ма отличается почти в четыре раза и составляет 540ма/ч и 2200ма/ч соответственно. Стоит правда заметить, что там разряжали до 0.1в, но по всем данным после 0.8в в батарейке уже почти не остается энергии, т.ч. этот факт не должен сильно сказываться.
Есть основания предполагать, что том режиме потребления, какой предполагается у обсуждаемого здесь беспроводного сенсора, батарея отдаст даже больше 2000ма/ч, но я делал пессимистический расчет и поэтому загрублял потребление в большую сторону, а емкость в меньшую.
Лучше полностью отключать, транзистором (если речь про BL8530). Отключал при помощи IRML6302, ток получается сильно меньше 1 мкА.
Заказал вчера у китайцев два десяка АО3416, что обошлось в 75 рублей. Они в два раза дешевле 6302 и заметно лучше по параметрам. При -1.8в на затворе сопротивление канала 21 миллиОм, против 0,9 ома при -2.7в на затворе у 6320. Таким ключом можно коммутировать питание даже когда оно уйдет ниже 1.8в. Фактически, пока МК сможет работать.
Re: STM32 на батарейках
Чт ноя 19, 2015 04:43:50
Сенсор: понимаю, что ds18b20 был взят для прикидки, но все-же – сенсор, потребляющий 1мА в активном режиме и требующий не менее 3В питания, безнадежно устарел и неинтересен. Вообще, зачем использовать 1-проводный сенсор если он находится вблизи МК? Ну хорошо, если хочется общение по одному проводу, почему именно 1-wire? В качестве альтернативы 1-wire посмотрите на LMT01 с оригинальным 1-проводным интерфейсом. Или на TMP107 с однопроводным UART интерфейсом. Оба потребляют не более 40 мкА в процессе измерения, которое длится около 50 мс. С ними среднее потребление при цикле измерения 1 мин будет около 40мкА * 50мс / 60000мс = 0.033 мкА. Плюс ещё что-то во время передачи данных, но все-равно копейки. Я-бы поставил I2C сенсор TMP112, потребляющий во время измерения всего 10 мкА (уже использовал несколько раз - рекомендую). Посмотрите ещё здесь сравнение по датчикам. Короче, вклад нормального сенсора в общее среднее потребление схемы можно округлить до 1 мкА. Кстати, вчера на Дне Технологии ТИ узнал про интересный датчик TMP103 без архитектурных излишеств.
МК: этот 030 совсем даже не малопотребляющий. Лучше поставить что-то из STM32L-серии или подобное экономичное. Например, Kinetis KL02 в режиме Low Power Run на 4 мгц потребляет около 300 мкА и не более 2 мкА в Deep Sleep (проверено на многих экземплярах и разных моделях серии KL). Т.е. вклад МК при работе а вктивном режиме как у Вас (50мс – в реальности будет сильно меньше, т.к. во время работы интерфейсов связи с сенсором и радио ядро МК можно выключить) составит 300мкА * 50мс / 60000мс = 0.25 мкА. С учетом 2 мкА во время сна округлим все с запасом до 3 мкА. Вполне возможно, что для данного приложения приемлимый результат по среднему токопотреблению получится и при использовании 030 в качестве МК.
Батарея: про ёмкость я согласен – согласно ДШ, например, на АА от Energizer серии EN92, ее емкость даже при разрядном токе 25мА не менее 2500мАч. А вот оценка тока саморазряда в 90 мкА слишком завышена. Тогда получается, что лежащая на полке батарея полностью саморазрядится за 2500мАЧ/0.09мА ~ 3.17 лет, в то время как их «жизнь на полке» при разряде до 80% от начальной емкости гарантируется не менее 7 лет. Отсюда можно прикинуть ток саморазряда как 7лет/(20%*2500мАч) ~ 8.15 мкА. Я в расчетах беру 10 мкА.
У хороших литиевых батарей (на 3.6В) саморазряд около 1% в год, т.е. грубо говоря, для 20% саморазряда при комнатной температуре потребуется не менее 20 лет. Т.о. ток саморазряда получается порядка 3мкА, т.е. как минимум в 3 раза меньше, чем у алкалиновых. Для сравнения, ток саморазряда у «нормальной» CR2032 около 0.7 мкА. Однако, если-же планируется работа сенсора при низких температурах зимой в средней полосе России, то алкалиновые батарейки не подходят вообще. Лучший вариант, как советовал выше akl, литиевая батарея на 3.6В. Тогда и конвертер не нужен.
Радио: да, у быстрого 2.4ггц модуля энергетика иная, чем у Sub-1G. Однако, соответственно меньше энергии уйдёт в эфир и меньше дойдёт до приёмника. С вычислениями выше я согласен, но следует учесть требуемые 100мс для выхода на рабочий режим всякий раз при подаче питания. Сколько чип в это время потребляет я не нашел в ДШ. Мои модули на 915 мгц тоже потребляют около 15мА и от двух сенсоров передают раз в минуту 80 бит на скорости 1200bps. Таким образом, их среднее потребление за минуту будет (80бит/1200бпс)*15мА/60с = 16.6мкА. В режиме сна потребление наноамперное, но ещё следует добавить немного на время выхода на рабочий режим при пробуждении и на коммуникацию с МК, пусть все будет 20мкА. Поэтому вклад такого модуля в токопотребление является определяющим, как я писал выше.
Суммируя без учета DC/DC, получаем для 2.4ггц модуля среднее потребление 1+3+10+0.25 = 14.25мкА, а для Sub-1G, соответственно, 1+3+10+20 = 34мкА.
Однако, сегодня я экспериментировал с Bluetooth BLE модулями передающими аккурат на скорости 1mbps при мощности 0dBm (в точности как у NRL-ки). Мой Samsung smartphone, находящийся в 3/4 метра от модуля регистрировал уровень RSSI около -60dBm. При чувствительности модуля -96dBm приёмнику остается 36dBm на всё-про-всё (работу на большем расстоянии). Если стандартно принять уменьшение расстояния в 2 раза на каждые 6dBm излучаемой мощности, то дальность связи можно оценить сверху как 0.75м*2^(36dBm/6dBm) = 48 м. При проверке на практике получилось порядка 35-40м даже при оптимальной ориентации антенн приемника и передатчика и отсутствии препятствий между ними в зоне прямой видимости. В то время как Sub-1G модуль за счет большей излучаемой мощности и и большей чувствительности приёмника уверенно принимается на расстоянии порядка 500м.
Насчёт эффективности DC/DC действительно не ясно. По графикам в ДШ определить КПД при малом токе нагрузки не представляется возможным – нужен эксперимент. Отпишитесь, если до этого дело дойдёт. Вообще, по поводу конструирования микроточных беспроводных датчиков почитайте о готовом проекте здесь: http://www.ti.com/lit/ug/tidu995b/tidu995b.pdf
Спойлер
МК: этот 030 совсем даже не малопотребляющий. Лучше поставить что-то из STM32L-серии или подобное экономичное. Например, Kinetis KL02 в режиме Low Power Run на 4 мгц потребляет около 300 мкА и не более 2 мкА в Deep Sleep (проверено на многих экземплярах и разных моделях серии KL). Т.е. вклад МК при работе а вктивном режиме как у Вас (50мс – в реальности будет сильно меньше, т.к. во время работы интерфейсов связи с сенсором и радио ядро МК можно выключить) составит 300мкА * 50мс / 60000мс = 0.25 мкА. С учетом 2 мкА во время сна округлим все с запасом до 3 мкА. Вполне возможно, что для данного приложения приемлимый результат по среднему токопотреблению получится и при использовании 030 в качестве МК.
Батарея: про ёмкость я согласен – согласно ДШ, например, на АА от Energizer серии EN92, ее емкость даже при разрядном токе 25мА не менее 2500мАч. А вот оценка тока саморазряда в 90 мкА слишком завышена. Тогда получается, что лежащая на полке батарея полностью саморазрядится за 2500мАЧ/0.09мА ~ 3.17 лет, в то время как их «жизнь на полке» при разряде до 80% от начальной емкости гарантируется не менее 7 лет. Отсюда можно прикинуть ток саморазряда как 7лет/(20%*2500мАч) ~ 8.15 мкА. Я в расчетах беру 10 мкА.
У хороших литиевых батарей (на 3.6В) саморазряд около 1% в год, т.е. грубо говоря, для 20% саморазряда при комнатной температуре потребуется не менее 20 лет. Т.о. ток саморазряда получается порядка 3мкА, т.е. как минимум в 3 раза меньше, чем у алкалиновых. Для сравнения, ток саморазряда у «нормальной» CR2032 около 0.7 мкА. Однако, если-же планируется работа сенсора при низких температурах зимой в средней полосе России, то алкалиновые батарейки не подходят вообще. Лучший вариант, как советовал выше akl, литиевая батарея на 3.6В. Тогда и конвертер не нужен.
Радио: да, у быстрого 2.4ггц модуля энергетика иная, чем у Sub-1G. Однако, соответственно меньше энергии уйдёт в эфир и меньше дойдёт до приёмника. С вычислениями выше я согласен, но следует учесть требуемые 100мс для выхода на рабочий режим всякий раз при подаче питания. Сколько чип в это время потребляет я не нашел в ДШ. Мои модули на 915 мгц тоже потребляют около 15мА и от двух сенсоров передают раз в минуту 80 бит на скорости 1200bps. Таким образом, их среднее потребление за минуту будет (80бит/1200бпс)*15мА/60с = 16.6мкА. В режиме сна потребление наноамперное, но ещё следует добавить немного на время выхода на рабочий режим при пробуждении и на коммуникацию с МК, пусть все будет 20мкА. Поэтому вклад такого модуля в токопотребление является определяющим, как я писал выше.
Суммируя без учета DC/DC, получаем для 2.4ггц модуля среднее потребление 1+3+10+0.25 = 14.25мкА, а для Sub-1G, соответственно, 1+3+10+20 = 34мкА.
Однако, сегодня я экспериментировал с Bluetooth BLE модулями передающими аккурат на скорости 1mbps при мощности 0dBm (в точности как у NRL-ки). Мой Samsung smartphone, находящийся в 3/4 метра от модуля регистрировал уровень RSSI около -60dBm. При чувствительности модуля -96dBm приёмнику остается 36dBm на всё-про-всё (работу на большем расстоянии). Если стандартно принять уменьшение расстояния в 2 раза на каждые 6dBm излучаемой мощности, то дальность связи можно оценить сверху как 0.75м*2^(36dBm/6dBm) = 48 м. При проверке на практике получилось порядка 35-40м даже при оптимальной ориентации антенн приемника и передатчика и отсутствии препятствий между ними в зоне прямой видимости. В то время как Sub-1G модуль за счет большей излучаемой мощности и и большей чувствительности приёмника уверенно принимается на расстоянии порядка 500м.
Насчёт эффективности DC/DC действительно не ясно. По графикам в ДШ определить КПД при малом токе нагрузки не представляется возможным – нужен эксперимент. Отпишитесь, если до этого дело дойдёт. Вообще, по поводу конструирования микроточных беспроводных датчиков почитайте о готовом проекте здесь: http://www.ti.com/lit/ug/tidu995b/tidu995b.pdf
Re: STM32 на батарейках
Сб ноя 21, 2015 00:15:23
Ser60 писал(а):Сенсор: понимаю, что ds18b20 был взят для прикидки, но все-же – сенсор, потребляющий 1мА в активном режиме и требующий не менее 3В питания, безнадежно устарел и неинтересен.
Вы в общем-то правильно говорите, но есть пара нюансов. Ваша информация о термодатчиках серии TMP1xx оказалась весьма интересной. Единственное, что удержало от того, чтобы немедленно прикупить на али TMP112 (они еще и сравнительно недороги там, от 110 руб/шт при покупке 3шт) -- это тип корпуса. Для применения на улице в выносном варианте они не очень удобны. Те же TO92 проще герметизировать, оставляя под контакт со средой почти всю "головку" отрытой. Одно время пользовал готовые китайские конструкции, где датчик помещается внутрь вытянутого металлического колпачка, но срок жизни у них в районе года. Набирают вовнутрь воды и коррозия делает свое дело. Сейчас усилил конструкцию заполнением внутреннего пространства колпачка теплопроводным герметиком, посмотрим, как зиму переживут.
этот 030 совсем даже не малопотребляющий. Лучше поставить что-то из STM32L-серии или подобное экономичное.
Про 030 я и не говорил, что он эффективен в плане потребления. Наоборот, расчет делался для худшего случая, с загрублением в сторону увеличения. STM32L я навряд ли надумаю покупать, т.к. есть STM8L или даже MSP430, если вдруг какое чудачество найдет.
Но скорее всего, остановлюсь на 030. Кинетис может и обладает интересными параметрами, но это ж надо его покупать и всякими программаторами/отладчиками озабочиваться, да разбираться, как от него добиться чего мне надо. Путь вырисовывается долгий.Саморазряд брал для батарейки самого стремного качества с завышением его значения, чтобы расчеты не выглядели оптимистическими. Здесь еще возник вопрос, возвращается ли емкость батареи, которая сильно деградирует на морозе, если температура повышается? По идее, если начало эксплуатации свежей батарейки пришлось на январь, то даже с учетом пониженной емкости на морозе, ее должно хватить до весны/лета. Летом емкость восстановится (за вычетом уже израсходованного) и влияние холодного периода будет снивелировано. Получается, что морозами можно в определенной степени пренебречь.
в средней полосе России, то алкалиновые батарейки не подходят вообще.
Пробежался поиском, кто что говорит. У кого-то фонарик, лежащий в морозные дни во внешнем кармане куртки, перестает светить после второго включения, а у кого-то всю зиму лежавший в гараже, светит весной. Есть тесты батареек на морозе, но там речь идет о больших токах, если сравнивать с нашим случаем.
Re: STM32 на батарейках
Сб ноя 21, 2015 05:05:35
Насколько я понял, плата передатчика тоже планируется к установле на улице. Если так, то установите сенсор на плате и в корпусе передатчика просверлите дырку для теплообмена. Плату при этом следует покрыть лаком, можно даже вместе с сенсором. Передача тепла к нему происходит в большей степени от платы через выводы корпуса, нежели чем через пластиковый корпус. Об этом написано в ДШ и рекомендуется заливать его термопроводящим герметиком для работы на улице.
А почему-бы вместе с температурой еще не измерять влажность на улице? В этом случае можно поставить сенсор (например Si7021 или кучу подобных). Они и температуру заодно тоже меряют. У них в корпусе уже имеется отверстие для вентиляции и внутри кристалл уже залит как надо лаком для защиты от коррозии. В этом случае его можно будет по периметру обычным лаком обмазать - я так и делаю. Затем корпус девайса в трубу для защиты от дождя/снега/солнца. Дёшево и эффективно.
http://radiokot.ru/circuit/digital/home/207/
MSP430 вовсе не чудачество. Один из наших беспроводных датчиков именно на нем и собран (студенческий проект).
http://mcs.uwsuper.edu/sb/Electronics/Weather/. Это замечательные контроллеры, а простейшие типа серии G ещё и дешевы. Кстати, этот проект запущен летом 2013 и всё ещё работает от той-же литиевой батарейки емкостью 1200мАч, пережив две суровые зимы с морозами под -40, правда не каждый день. Зимой напряжение батареи несколько проседает но к лету восстанавливается. Сейчас все ещё 3.65В по модулю погрешности АЦП. Интересно, что судя по кривым зависимости емкости от температуры (батарея Xeno XL-050F), при токах нагрузки до 0.2мА ёмкость её при -30Ц больше чем при +20Ц ?! А малые токи - именно наш случай. Похоже, морозами действительно можно пренебречь. A судя по раскладу токопотребления, можно и контроллером пренебречь, лишь-бы он во сне потреблял единицы мкА. Уверен, что получите удовлетворительный результат и с 030-м.
Насчет алкалиновых батареек - они нормируются на работу лишь до -20Ц (Energizer, Panasonic, Duracell). Что будет ниже - кому как повезет. Да дело даже не в них - с 3.6В батареей не нужен DC/DC конвертер и среднее потребление схемы сушественно ниже. Раз лет в 5 можно и заказать батарею через Интернет или "разориться" на нее в местных магазинах. Пусть даже несколько дороже получится чем с алкалиновыми. Зато удобно - поставил и забыл про нее на несколько лет. А после этого, наверняка уже и датчик другой собрать захочется.
А почему-бы вместе с температурой еще не измерять влажность на улице? В этом случае можно поставить сенсор (например Si7021 или кучу подобных). Они и температуру заодно тоже меряют. У них в корпусе уже имеется отверстие для вентиляции и внутри кристалл уже залит как надо лаком для защиты от коррозии. В этом случае его можно будет по периметру обычным лаком обмазать - я так и делаю. Затем корпус девайса в трубу для защиты от дождя/снега/солнца. Дёшево и эффективно.
http://radiokot.ru/circuit/digital/home/207/
MSP430 вовсе не чудачество. Один из наших беспроводных датчиков именно на нем и собран (студенческий проект).
http://mcs.uwsuper.edu/sb/Electronics/Weather/. Это замечательные контроллеры, а простейшие типа серии G ещё и дешевы. Кстати, этот проект запущен летом 2013 и всё ещё работает от той-же литиевой батарейки емкостью 1200мАч, пережив две суровые зимы с морозами под -40, правда не каждый день. Зимой напряжение батареи несколько проседает но к лету восстанавливается. Сейчас все ещё 3.65В по модулю погрешности АЦП. Интересно, что судя по кривым зависимости емкости от температуры (батарея Xeno XL-050F), при токах нагрузки до 0.2мА ёмкость её при -30Ц больше чем при +20Ц ?! А малые токи - именно наш случай. Похоже, морозами действительно можно пренебречь. A судя по раскладу токопотребления, можно и контроллером пренебречь, лишь-бы он во сне потреблял единицы мкА. Уверен, что получите удовлетворительный результат и с 030-м.
Насчет алкалиновых батареек - они нормируются на работу лишь до -20Ц (Energizer, Panasonic, Duracell). Что будет ниже - кому как повезет. Да дело даже не в них - с 3.6В батареей не нужен DC/DC конвертер и среднее потребление схемы сушественно ниже. Раз лет в 5 можно и заказать батарею через Интернет или "разориться" на нее в местных магазинах. Пусть даже несколько дороже получится чем с алкалиновыми. Зато удобно - поставил и забыл про нее на несколько лет. А после этого, наверняка уже и датчик другой собрать захочется.
Re: STM32 на батарейках
Вт дек 22, 2015 00:41:19
Ser60 писал(а):Передача тепла к нему происходит в большей степени от платы через выводы корпуса, нежели чем через пластиковый корпус. Об этом написано в ДШ и рекомендуется заливать его термопроводящим герметиком для работы на улице.
Не знал. Спасибо за информацию. Как-то так и буду значит стараться сделать.
А почему-бы вместе с температурой еще не измерять влажность на улице?
По набору датчиков окончательно определился: BMP180 -- давление/температура, SI7021 -- влажность/температура, BH1750 -- освещенность. Все на I2C, микропотребление, работа от 1.8 вольт. Последнее обстоятельство подталкивает к переосмыслению схемы электропитания. Фактически, вся измерительная часть может работать без повышающего преобразователя, а преобразователь нужен только для запитки передатчика на NRF24.
MSP430 вовсе не чудачество. Один из наших беспроводных датчиков именно на нем и собран (студенческий проект)
Я тут думкой богатею
что может вообще ну его нафиг все эти режимы низкого энергопотребления? Самый энергоэффективный режим -- это когда все выключено совсем. Остается вопрос, как все хозяйство включать по расписанию. Так есть же замечательные чипы RTC, которые даже работая с резервного питания (обычно CR2032) умеют в нужное время (два программируемых аларма) дергать ногой с открытым стоком. Данный открытый сток прямо просит, чтобы на него повесить LOAD SWITCH и врубать таким образом питание, если не на всю остальную схему, то на МК, как минимум. Как-то мне эта идея так запала, что сейчас ни о чем другом даже думать не могу. Покритиковал бы кто-нибудь что-ли. Не пойму, где я тут позорно лажаюсь, т.к. сколько ни рыл интернет, ни у кого такого решения не обнаружил. А вот это подозрительно.A судя по раскладу токопотребления, можно и контроллером пренебречь, лишь-бы он во сне потреблял единицы мкА. Уверен, что получите удовлетворительный результат и с 030-м.
Вот как-то я тоже склоняюсь остаться все-таки на 030. С учетом, что датчики быстрые и слаботочные, цикл измерений обещает сократиться по времени чуть ли не на порядок (50-100мс против 750мс, как я это прикидывал для DS18B20), а потребление и того хлеще. С учетом, что основным потребителем, включенным всю дорогу остается чип RTC, с его рабочими токами в дежурном режиме, что-то из расчета 0.5-0.8мка, картина складывается настолько благостная, что в этом ощущается какой-то подвох.
Re: STM32 на батарейках
Вт дек 22, 2015 02:44:42
a5021 писал(а):По набору датчиков окончательно определился ... BH1750 -- освещенность
Недостаток этого датчика в том, что ему нужно 2.4В минимум. Кроме того, без затемняющего стекла у него максимальный уровень измеряемой освещенности 65535 люкс. Для тени этого хватит, но на солнце освещённость летом переваливает через 120000 люкс. Рекомендую посмотерть на MAX44009 свободный от обоих ограничений.
a5021 писал(а):Не пойму, где я тут позорно лажаюсь
Всё правильно Вы думаете. Например, в этой статье ТИ так и сделано с аналоговым таймером TPL5110 если интервал выдержек строго соблюдать не требуется. Однако, потребление у современных МК во сне с работающим RTC около 1 мкА, что в случае питания от батареек АА на порядок ниже их саморазряда. Тогда и микра RTC не нужна.
a5021 писал(а):работа от 1.8 вольт
У 030 минимальное рабочее напряжение также 2.4В, т.е. его придется включать внешним таймером. Если при таком раскладе выбирать между 030 и MSP430, я-бы склонился к последнему. С ним внешний таймер не нужен. В любом случае токопотребление системы во сне порядка 1 мкА никакого подвоха за собой не несёт. Делайте так и Ваша схема будет работать на протяжении долгих лет.
Re: STM32 на батарейках
Вт дек 22, 2015 06:53:51
.
Re: STM32 на батарейках
Вт дек 22, 2015 08:35:49
Ser60 писал(а): Если при таком раскладе выбирать между 030 и MSP430, я-бы склонился к последнему. С ним внешний таймер не нужен. В любом случае токопотребление системы во сне порядка 1 мкА никакого подвоха за собой не несёт. Делайте так и Ваша схема будет работать на протяжении долгих лет.
Тогда уже чем юзать пустой и дорогой MSP проще взять простенький и дешёвый PIC16/18 с XLP и Ultra Low-Power Wake-Up (ULPWU).
Если уж так на наноамперы в слипе тянет.
Re: STM32 на батарейках
Вс дек 27, 2015 05:33:01
Ser60 писал(а):Если при таком раскладе выбирать между 030 и MSP430, я-бы склонился к последнему.
Долго я не решался взяться за MSP430, но в связи с ложным собственным представлением, что 030 сможет работать от 1.8в, теперь таки решился. Пару вечеров поковырял немного и общее представление о том, что оно может, начинает складываться.
Сначала развернул "Энергию". Оказалось, что есть готовые библиотеки и для BMP180 и NRF24L01+. Проверил -- по отдельности работают. Чтобы написать то же самое для 030 мне пришлось потратить довольно много времени, т.к. готовое по тем или иным причинам не подошло, а для MSP430G2553 оно работает почти "из коробки". Но сразу же вылезла и проблема: "Энергия" для SPI разрешает использовать только UCB0 и это забито жестко во все библиотеки. Последствия такого положения дел приводят к печальному итогу -- одновременно использовать SPI и I2C не получится без правки заголовков и определений библиотек, чтобы SPI перенести на UCA0, а освободившимся OCB0 рулить устройствами I2C.
Зашел с другой стороны. На сайте TI масса готовых примеров, типа, ST-шных снайпетов, но мне показалось, что попроще и понагляднее. Отдельно доставил CCS Cloud, где разработку и отладку можно вести прямо в окне браузера, чего я ранее нигде не встречал. В принцпе, досконально не разбирался, но то, как примеры от TI можно сразу затаскивать в среду для изучения под отладчиком или клонировать библиотеки с гитхаба прямо в проект, показалось дико удобным. Правда и тут не обошлось без косяков. Время от времени CCS Cloud перестает пускать к себе и пишет что-то насчет превышения числа попыток залогиниться. Подозреваю, что речь идет скорее о превышении числа пользователей этого облака, но так или иначе, в это время в свои проекты не попасть.
В один из таких вынужденных перекуров обнаружил, что Протеус имеет модели MSP430, в том числе и для 2553. Нарисовал схему, взялся моделировать. Сразу же налетел на необъяснимое поведение UCA0. Стоит только "отдать" пины P1 для UCA0 (через P1SEL и P1SEL2), как на SCK возникает неудержимый клок, который более не прекращается никогда. Самое смешное, что сам UCA0 в это время еще находится в резете и никаких клоков генерировать не может по определению. Сражался с этим протеусом пол-ночи и одолел таки меня этот протеус окаянный.
Не хочет эмулировать примеры с сайта TI.Датчики с Китая так и не пришли. Чипы для повышайки, наоборот пришли, но не понятно понадобятся ли они теперь. Развел пока платку преобразователя для подтыкания на макетку, но вытравить как-то все руки не доходят. Поковыряюсь еще с MSP430, глядишь, повышайка и не потребуется.
Датчики освещенности на MAX44009 у китайцев тоже есть. Подороже, чем на BH1750, но терпимо. Посмотрю, что будет получаться с msp430, а там станет понятнее насколько нужен будет MAX44009. В принципе, не смотря на небольшой диапазон, BH1750 вполне устраивает, т.к. основное предназначение для него планируется в части функционала различения темного времени суток и светлого. На основе этого планируется завязать автоматику включения/выключения дежурной подсветки.
Re: STM32 на батарейках
Вс дек 27, 2015 07:57:34
Мдааа, проблемы Ваши мне незнакомы. Для MSP430 писал пока всё с нуля на АСМе под IAR, включая драйверы SPI/I2C, и т.п. Там драйвер и библиотека слишком громкие слова - всего по нескольку команд. Иное дело если со стеком (протоколов) работать - тогда да. Направление у Вас правильное - использовать UCA0 под связь с радио а UCB0 под I2C. Я тоже так делал, иначе и не выходит. Вот исходник моего старого проекта под 2553, радио CC1101, и сенсор Si7005. Переделки под Ваше радио и Si7021 небольшие. Если заинтересует, могу дать по этому коду любую консультацию.
; the project options in IAR
SCLK EQU BIT4 ; SCLK on P1 (radio interface)
MOSI EQU BIT2 ; MOSI on P1
MISO EQU BIT1 ; MISO on P1
CS EQU BIT3 ; TX enable on P1
GDO0 EQU BIT5 ; GDO0 on P1
GDO2 EQU BIT0 ; GDO2 on P2
SCL EQU BIT6 ; I2C pins on port P1
SDA EQU BIT7
PWR EQU BIT1 ; Si7005 Vdd pin on port 2
DCDC EQU BIT2 ; DC/DC converter enable
SRES EQU 0x30 ; reset chip strobe
SRX EQU 0x34 ; enter RX state
STX EQU 0x35 ; enter TX state
SIDLE EQU 0x36 ; enter IDLE state
SPWD EQU 0x39 ; enter power down mode
SNOP EQU 0x3D ; no operation
BAT_PER EQU 10 ; battery check period
RSEG CSTACK ; pre-declaration of segment
RSEG DATA16_N ; data segment
buf_TX: DS 16 ; transmitting packet buffer
buf_RX: DS 16 ; received packet buffer
i2cb: DS 15 ; I2C data buffer
batCnt: DS 1 ; battery check counter
RSEG CODE ; code segment
reset: mov #SFE(CSTACK), SP ; set up stack
mov.w #WDTPW+WDTHOLD, &WDTCTL ; stop watchdog timer
; I/O ports setup
mov.b #MISO+CS+SCL+SDA, &P1OUT; init port P1
mov.b #~(MISO|GDO0|SCLK), &P1DIR ; input on those pins
mov.b #MISO+SCLK, &P1REN
bis.b #SCL+SDA, &P1SEL ; configure pins for I2C
bis.b #SCL+SDA, &P1SEL2
clr.b &P2OUT ; init port P2
mov.b #~(GDO2|BIT6), &P2DIR ; input on GDO2 pin
bis.b #BIT6+BIT7, &P2SEL ; configure XTAL pins
clr.b &P2SEL2
; clock setup
clr.b &DCOCTL
mov.b &CALBC1_8MHZ, &BCSCTL1 ; set 8 MHz clock
mov.b &CALDCO_8MHZ, &DCOCTL
mov.b #DIVS_1, &BCSCTL2 ; SMCLK=DCO/2
; mov.b #LFXT1S_2, &BCSCTL3 ; select VLO as ACLK
mov.b #XCAP_2, &BCSCTL3 ; select XT1 as ACLK, 10pF caps
osc1: bic.b #OFIFG, &IFG1 ; clear OFIFG
clr.w R15 ; delay
osc2: dec.w R15
jnz osc2
bit.b #OFIFG, &IFG1 ; re-test OFIFG
jnz osc1 ; repeat test if needed
bis.b #DIVA_3, &BCSCTL1 ; set ACLK / 8
; SPI setup for eUSCI_A0
mov.b #UCSSEL_2+UCSWRST, &UCA0CTL1 ; keep SPI module in reset
mov.b #UCMSB+UCCKPH+UCMST+UCSYNC, &UCA0CTL0
mov.b #1, &UCA0BR0 ; clock division factor (1:1)
clr.b &UCA0BR1 ; for baudrate 4 MHz
call #Init_CC1101 ; init radio, leave it in SHDN
; I2C setup for eUSCI_B0
bis.b #UCSSEL_2+UCSWRST, &UCB0CTL1 ; keep I2C module in reset
bis.b #UCMODE_3+UCMST+UCSYNC, &UCB0CTL0 ; I2C master mode
mov.w #0x40, &UCB0I2CSA ; Si7005 slave address
mov.b #40, &UCB0BR0 ; baudrate = 100KHz
clr.b &UCB0BR1
; ADC setup for battery monitoring
mov.w #INCH_11+ADC10SSEL_3, &ADC10CTL1 ; voltage divider, SMCLK
mov.w #SREF_1+ADC10SHT_1+ADC10SR+ADC10IE, &ADC10CTL0
mov.b #BAT_PER, &batCnt ; initialize battery check counter
; Timer_0 setup for regular wake-ups
mov.w #TASSEL_1+MC_1+ID_3+TACLR+TAIE, &TA0CTL ; ACLK, up mode
; mov.w #512, &TA0CCR0 ; setup for 1 sec
mov.w #2560, &TA0CCR0 ; setup for 5 sec
; mov.w #30720, &TA0CCR0 ; setup for 1 min
; Timer_1 setup for short delays
mov.w #TASSEL_1+TACLR+TAIE, &TA1CTL ; ACLK, up mode
; transmitting packet setup
mov.b #0x0A, &buf_TX ; length of data in TX buffer
mov.b #0x7F, &buf_TX+1 ; TX FIFO address
mov.b #0x08, &buf_TX+2 ; packet payload length
mov.b #0x11, &buf_TX+3 ; RX ID
mov.b #0xAA, &buf_TX+4 ; TX ID
mov.b #0x00, &buf_TX+5 ; packet number
mov.w #0x3412, &buf_TX+6 ; payload (temp)
mov.w #0x7856, &buf_TX+8 ; payload (humi)
mov.b #0xFF, &buf_TX+10 ; payload (battery)
loop: ; main program loop
bis.w #LPM3+GIE, SR ; enter LPM3 sleep mode
nop ; wake-up by Timer_0
call #Check_Battery ; measure the battery voltage
call #Get_Temp_Humi ; measure temp and humi
bis.b #DCDC, &P2OUT ; turn on DC/DC converter
inc.b &buf_TX+5 ; update packet number
call #Transmit_Packet ; transmit this packet over air
bic.b #DCDC, &P2OUT ; turn off DC/DC converter
jmp loop
;===PROCEDURES========
Get_Temp_Humi:
bis.b #PWR, &P2OUT ; power-up Si7005 sensor
mov.w #63, &TA1CCR0 ; setup for 15 msec delay
call #delay ; Si7005 power-up delay
mov.w #0x1103, &i2cb ; request temp conversion
call #Request_Conversion
mov.w #164, &TA1CCR0 ; setup for 40 msec delay
call #delay ; for performing the measurements
call #Read_Conversion ; read temp value from sensor
mov.w &i2cb, &buf_TX+6 ; insert temp into payload
mov.w #0x0103, &i2cb ; request humi conversion
call #Request_Conversion
mov.w #164, &TA1CCR0 ; setup for 40 msec delay
call #delay ; for performing the measurements
call #Read_Conversion ; read humi value from sensor
mov.w &i2cb, &buf_TX+8 ; insert humi into payload
bic.b #PWR, &P2OUT ; power off Si7005 sensor
ret
Request_Conversion:
mov.w #i2cb, R11 ; set up pointer to buffer
mov.b #2, R10 ; byte counter
bic.b #UCSWRST, &UCB0CTL1 ; clear I2C reset
bis.b #UCNACKIE, &UCB0I2CIE ; enable NACK interrupt
bis.b #UCB0TXIE, &IE2 ; enable I2C TX interrupt
bis.b #UCTR+UCTXSTT, &UCB0CTL1 ; send start condition and write
bis.b #LPM0+GIE, SR ; enter LPM0
nop ; remain in LPM0
bis.b #UCTXSTP, &UCB0CTL1 ; generate STOP condition
bit.b #UCTXSTP, &UCB0CTL1 ; wait for generating the stop condition
jnz $-4
bis.b #UCSWRST, &UCB0CTL1 ; I2C reset
ret
Read_Conversion:
mov.b #1, &i2cb ; register number
mov.w #i2cb, R11 ; set up pointer to buffer
mov.b #1, R10 ; # of bytes to transmit
bic.b #UCSWRST, &UCB0CTL1 ; clear I2C reset
bis.b #UCNACKIE, &UCB0I2CIE ; enable NACK interrupt
bis.b #UCB0TXIE, &IE2 ; enable I2C TX interrupt
bis.b #UCTR+UCTXSTT, &UCB0CTL1 ; send start condition and write
bis.w #LPM0+GIE, SR ; enter LPM0
nop ; remain in LPM0
bic.b #UCTR, &UCB0CTL1 ; set receiver mode
mov.w #i2cb, R11 ; set up pointer to buffer
mov.b #2, R10 ; # of bytes to receive
bis.b #UCB0RXIE, &IE2 ; enable I2C RX interrupt
bis.b #UCTXSTT, &UCB0CTL1 ; send start condition
bis.w #LPM0+GIE, SR ; enter LPM0
nop ; remain in LPM0
bit.b #UCTXSTP, &UCB0CTL1 ; wait for generating the stop condition
jnz $-4
bis.b #UCSWRST, &UCB0CTL1 ; I2C reset
swpb &i2cb ; reverse the bytes order
ret
delay: ; short delay
bis.w #MC_1+TACLR, &TA1CTL ; start Timer1 in up mode
bis.w #LPM3+GIE, SR ; enter LPM3 sleep mode
nop
bic.w #MC_1, &TA1CTL ; stop Timer1
ret
;----------
Check_Battery:
mov.b #0xFF, R5
dec.b &batCnt ; time to check battery?
jnz ct2 ; NO - exit
mov.b #BAT_PER, &batCnt ; YES - restore counter
bis.w #REF2_5V+REFON+ADC10ON, &ADC10CTL0
mov.w #80, R5 ; 30 mksec delay to set up VREF
ct1: dec.w R5
jnz ct1
bis.w #ENC+ADC10SC, &ADC10CTL0; start temp sampling/conversion
bis.w #LPM0+GIE,SR ; LPM0, ADC10_ISR will force exit
nop
bic.w #ENC, &ADC10CTL0 ; shut down ADC completely
bic.w #ADC10ON, &ADC10CTL0
bic.w #REFON, &ADC10CTL0 ; turn off reference
mov.w &ADC10MEM, R5 ; get conversion result
rra.w R5 ; get rif of 2 lsb
rra.w R5
ct2: mov.b R5, &buf_TX+10 ; insert batt voltage into payload
ret
;----------
Transmit_Packet:
mov.w #buf_TX, R11 ; packet data pointer
call #Send_CC1101 ; load packet into FIFO
mov.b #STX, R11 ; send strobe to enter
call #Send_Strobe ; the TX mode
bic.b #GDO0, &P1IES ; select low-to-high transition
clr.b &P1IFG ; clear interrupt flag
bis.b #GDO0, &P1IE ; enable port interrupt
bis.w #LPM3+GIE, SR ; enter LPM3 sleep mode
nop ; wait for sending the sync word
bis.b #GDO0, &P1IES ; select high-to-low transition
clr.b &P1IFG ; clear interrupt flag
bis.b #GDO0, &P1IE ; enable port interrupt
bis.w #LPM3+GIE, SR ; enter LPM3 sleep mode
nop ; wait for the end of transmission
mov.b #SPWD, R11 ; power down mode
call #Send_Strobe
ret
;====RADIO INTERFACE===================
Init_CC1101:
mov.w #CC1101_setup, R11 ; load CC1101 registers
mov.b @R11+, R10 ; get byte counter
bis.b #MISO+MOSI+SCLK, &P1SEL ; connect P1 pins to SPI
bis.b #MISO+MOSI+SCLK, &P1SEL2
bic.b #SCLK, &P1REN
bis.b #SCLK, &P1DIR
bic.b #UCSWRST, &UCA0CTL1 ; enable SPI module
bis.b #UCA0TXIE, &IE2 ; enable SPI TX interrupt
bic.b #CS, &P1OUT ; enable radio
nop
ic1: bit.b #MISO, &P1IN ; wait for radio interface ready
jnz ic1
bis.w #LPM0+GIE, SR ; enter LPM0 sleep mode
nop
bis.b #CS, &P1OUT ; disable radio
bis.b #UCSWRST, &UCA0CTL1 ; disable SPI module
mov.w #0x3E03, &buf_TX
mov.w #0x39C0, &buf_TX+2 ; set 10dBm output power
mov.w #buf_TX, R11 ; and enter SHDN mode
call #Send_CC1101
ret
Read_CC1101:
bis.b #MISO+MOSI+SCLK, &P1SEL ; connect P1 pins to SPI
bis.b #MISO+MOSI+SCLK, &P1SEL2
bic.b #SCLK, &P1REN
bis.b #SCLK, &P1DIR
bic.b #UCSWRST, &UCA0CTL1 ; enable SPI module
bis.b #UCA0RXIE, &IE2 ; enable SPI RX interrupt
bic.b #CS, &P1OUT ; enable radio
rp1: bit.b #GDO2, &P2IN ; wait for radio interface ready
jnz rp1
mov.b R11, &UCA0TXBUF ; send FIFO address & burst read
bis.w #LPM0+GIE, SR ; enter LPM0 sleep mode
nop
rp2: mov.b #SNOP, &UCA0TXBUF ; SNOP strobe for reading
bis.w #LPM0+GIE, SR ; enter LPM0 sleep mode
nop
mov.b &UCA0RXBUF, R11 ; get reveived byte in buffer
dec.b R10 ; decrement received bytes counter
jnz rp2 ; loop back
rp3: bis.b #CS, &P1OUT ; disable radio interface
bis.b #UCSWRST, &UCA0CTL1 ; disable SPI module
bic.b #SCLK, &P1DIR
bis.b #SCLK, &P1REN
bic.b #MISO+MOSI+SCLK, &P1SEL2; disconnect P1 pins from SPI
bic.b #MISO+MOSI+SCLK, &P1SEL
ret
;----------
Send_CC1101: ; R11 points to data, 1st byte is length
mov.b @R11+, R10 ; get byte counter
bis.b #MISO+MOSI+SCLK, &P1SEL ; connect P1 pins to SPI
bis.b #MISO+MOSI+SCLK, &P1SEL2
bic.b #SCLK, &P1REN
bis.b #SCLK, &P1DIR
bic.b #UCSWRST, &UCA0CTL1 ; enable SPI module
bis.b #UCA0TXIE, &IE2 ; enable SPI TX interrupt
bic.b #CS, &P1OUT ; enable radio
nop
wc1: bit.b #GDO2, &P2IN ; wait for radio interface ready
jnz wc1
bis.w #LPM0+GIE, SR ; enter LPM0 sleep mode
nop
bis.b #CS, &P1OUT ; disable radio
bis.b #UCSWRST, &UCA0CTL1 ; disable SPI module
bic.b #SCLK, &P1DIR
bis.b #SCLK, &P1REN
bic.b #MISO+MOSI+SCLK, &P1SEL2; disconnect P1 pins from SPI
bic.b #MISO+MOSI+SCLK, &P1SEL
ret
Send_Strobe:
bis.b #MISO+MOSI+SCLK, &P1SEL ; connect P1 pins to SPI
bis.b #MISO+MOSI+SCLK, &P1SEL2
bic.b #SCLK, &P1REN
bis.b #SCLK, &P1DIR
bic.b #UCSWRST, &UCA0CTL1 ; enable SPI module
bis.b #UCA0RXIE, &IE2 ; enable SPI RX interrupt
bic.b #CS, &P1OUT ; enable radio
nop
wc2: bit.b #GDO2, &P2IN ; wait for radio interface ready
jnz wc2
mov.b R11, &UCA0TXBUF ; strobe in R11
bis.w #LPM0+GIE, SR ; enter LPM0 sleep mode
nop
bis.b #CS, &P1OUT ; disable radio
bis.b #UCSWRST, &UCA0CTL1 ; disable SPI module
bic.b #SCLK, &P1DIR
bis.b #SCLK, &P1REN
bic.b #MISO+MOSI+SCLK, &P1SEL2; disconnect P1 pins from SPI
bic.b #MISO+MOSI+SCLK, &P1SEL
ret
;====Interrupt Service Routines=========
RX_I2CST_ISR: ; SPI receive/I2C status
bit.b #UCA0RXIFG, &IFG2 ; SPI Receive Interrupt?
jnz SPI_RX ; YES
bit.b #UCSTPIFG, &UCB0STAT ; I2C slave STOP condition?
jnz I2C_STP ; YES
bit.b #UCNACKIFG, &UCB0STAT ; I2C NACK received?
jnz I2C_NACK ; YES
reti
SPI_RX: ; SPI receive processing
bic.b #UCA0RXIFG, &IFG2 ; clear SPI RX interrupt flag
bic.w #LPM0+GIE, 0(SP) ; wake-up CPU
reti
I2C_STP: ; I2C slave stop processing
bic.b #UCSTPIFG, &UCB0STAT ; clear interrupt flag
bic.w #LPM3+GIE, 0(SP) ; wake-up CPU
reti
I2C_NACK: ; I2C NACK received
bic.b #UCNACKIFG, &UCB0STAT ; clear interrupt flag
bis.b #UCTXSTP, &UCB0CTL1 ; generate STOP condition
bic.w #LPM0+GIE, 0(SP) ; wake-up CPU
reti
;----------
TX_I2CRX_ISR: ; SPI transmit/I2C receive&transmit
bit.b #UCSWRST, &UCB0CTL1 ; is USCI_B0 active?
jnz SPI_TX ; NO - process SPI request
bit.b #UCB0RXIFG, &IFG2 ; I2C_RX interrupt?
jnz I2C_RX ; YES
bit.b #UCB0TXIFG, &IFG2 ; I2C TX interrupt?
jnz I2C_TX ; YES
reti
SPI_TX: mov.b @R11+, &UCA0TXBUF ; start SPI transmission
dec.b R10 ; decrement bytes counter
jnz SPI_TX_end ; all data sent?
bic.b #UCA0TXIE, &IE2 ; YES - disable SPI TX interrupt
bis.b #UCA0RXIE, &IE2 ; enable SPI RX interrupt
SPI_TX_end:
reti
I2C_RX: mov.b &UCB0RXBUF, 0(R11) ; get I2C received byte
inc.w R11 ; update pointer
dec.b R10 ; decrement bytes counter
cmp.b #1, R10 ; last byte to receive?
jeq I2C_RX_end1 ; YES
jl I2C_RX_end2 ; all bytes are received
reti
I2C_RX_end1:
bis.b #UCTXNACK+UCTXSTP, &UCB0CTL1 ; generate NACK+STOP condition
reti
I2C_RX_end2:
bic.b #UCB0RXIE, &IE2 ; disable I2C RX interrupt
bic.w #LPM0+GIE, 0(SP) ; wake-up CPU
reti
I2C_TX: tst.b R10 ; all data sent?
jz I2C_TX_end ; YES - exit
mov.b @R11+, &UCB0TXBUF ; NO - start I2C transmission
dec.b R10 ; decrement bytes counter
reti
I2C_TX_end:
bic.b #UCB0TXIE, &IE2 ; disable I2C TX interrupt
bic.w #LPM0+GIE, 0(SP) ; wake-up CPU
reti
;----------
TA0_ISR:
add.w &TA0IV, PC ; Add offset to Jump table
reti ; Vector 0: No interrupt
reti ; Vector 2: TACCR1
reti ; Vector 4: TACCR2
reti ; Vector 6: Reserved
reti ; Vector 8: Reserved
bic.w #LPM3+GIE, 0(SP) ; Vector 10: TAIFG Flag - wake-up CPU
reti
;----------
TA1_ISR:
add.w &TA1IV, PC ; Add offset to Jump table
reti ; Vector 0: No interrupt
reti ; Vector 2: TACCR1
reti ; Vector 4: TACCR2
reti ; Vector 6: Reserved
reti ; Vector 8: Reserved
bic.w #LPM3+GIE, 0(SP) ; Vector 10: TAIFG Flag - wake-up CPU
reti
;----------
ADC10_ISR:
bic.w #LPM0+GIE, 0(SP) ; wake-up CPU
reti
;----------
P1_ISR:
clr.b &P1IFG ; clear interrupt flag
bic.b #GDO0, &P1IE ; disable port interrupt
bic.w #LPM3+GIE, 0(SP) ; wake-up CPU
reti
;----------
CC1101_setup:
DB 47 ;settings array length
DB 0x40 ;burst write to starting address 0
DB 0x29 ;IOCFG2 |0x00|GDO2 Output Pin Configuration
DB 0x2E ;IOCFG1 |0x01|GDO1 Output Pin Configuration
DB 0x06 ;IOCFG0 |0x02|GDO0 Output Pin Configuration
DB 0x47 ;FIFOTHR |0x03|RX FIFO and TX FIFO Thresholds
DB 0xD3 ;SYNC1 |0x04|Sync Word, High Byte
DB 0x91 ;SYNC0 |0x05|Sync Word, Low Byte
DB 0x3D ;PKTLEN |0x06|Packet Length (61)
DB 0x05 ;PKTCTRL1 |0x07|Packet Automation Control
DB 0x05 ;PKTCTRL0 |0x08|Packet Automation Control
DB 0x11 ;ADDR |0x09|Device Address
DB 0x00 ;CHANNR |0x0A|Channel number
DB 0x06 ;FSCTRL1 |0x0B|Frequency Synthesizer Control
DB 0x00 ;FSCTRL0 |0x0C|Frequency Synthesizer Control
DB 0x22 ;FREQ2 |0x0D|Frequency Control Word, High Byte
DB 0xBB ;FREQ1 |0x0E|Frequency Control Word, Middle Byte
DB 0x13 ;FREQ0 |0x0F|Frequency Control Word, Low Byte
DB 0xCA ;MDMCFG4 |0x10|Modem Configuration
DB 0x83 ;MDMCFG3 |0x11|Modem Configuration
DB 0x13 ;MDMCFG2 |0x12|Modem Configuration
DB 0x22 ;MDMCFG1 |0x13|Modem Configuration
DB 0xF8 ;MDMCFG0 |0x14|Modem Configuration
DB 0x35 ;DEVIATN |0x15|Modem Deviation Setting
DB 0x07 ;MCSM2 |0x16|Main Radio Control State Machine Configuration
DB 0x30 ;MCSM1 |0x17|Main Radio Control State Machine Configuration
DB 0x18 ;MCSM0 |0x18|Main Radio Control State Machine Configuration
DB 0x16 ;FOCCFG |0x19|Frequency Offset Compensation Configuration
DB 0x6C ;BSCFG |0x1A|Bit Synchronization Configuration
DB 0x43 ;AGCCTRL2 |0x1B|AGC Control
DB 0x40 ;AGCCTRL1 |0x1C|AGC Control
DB 0x91 ;AGCCTRL0 |0x1D|AGC Control
DB 0x87 ;WOREVT1 |0x1E|High Byte Event0 Timeout
DB 0x6B ;WOREVT0 |0x1F|Low Byte Event0 Timeout
DB 0xFB ;WORCTRL |0x20|Wake on Radio Control
DB 0x56 ;FREND1 |0x21|Front End RX Configuration
DB 0x10 ;FREND0 |0x22|Front End TX Configuration
DB 0xE9 ;FSCAL3 |0x23|Frequency Synthesizer Calibration
DB 0x2A ;FSCAL2 |0x24|Frequency Synthesizer Calibration
DB 0x00 ;FSCAL1 |0x25|Frequency Synthesizer Calibration
DB 0x1F ;FSCAL0 |0x26|Frequency Synthesizer Calibration
DB 0x41 ;RCCTRL1 |0x27|RC Oscillator Configuration
DB 0x00 ;RCCTRL0 |0x28|RC Oscillator Configuration
DB 0x59 ;FSTEST |0x29|Frequency Synthesizer Calibration Control
DB 0x7F ;PTEST |0x2A|Production Test
DB 0x3F ;AGCTEST |0x2B|AGC Test
DB 0x81 ;TEST2 |0x2C|Various Test Settings
DB 0x35 ;TEST1 |0x2D|Various Test Settings
DB 0x09 ;TEST0 |0x2E|Various Test Settings
;----------
COMMON INTVEC ; MSP430 interrupt vectors
ORG RESET_VECTOR ; POR, ext. Reset, Watchdog
DW reset
ORG USCIAB0RX_VECTOR ; SPI/I2C RX ISR
DW RX_I2CST_ISR
ORG USCIAB0TX_VECTOR ; SPI/I2C TX ISR
DW TX_I2CRX_ISR
ORG TIMER1_A1_VECTOR ; TimerA_1 ISR
DW TA1_ISR
ORG TIMER0_A1_VECTOR ; TimerA_0 ISR
DW TA0_ISR
ORG ADC10_VECTOR ; ADC10 Vector
DW ADC10_ISR
ORG PORT1_VECTOR ; Port1 ISR
DW P1_ISR
END
Странное поведение Протеуса - глюк его однозначно. Вообще, зачем он Вам нужен при наличии железного отладчика? Тем более с такими глюками и мало-ли ещё с чем. Полагаю, что у Вас нет логического анализатора и поэтому Протеус. Если-же он есть, тогда причина использовать Протеус мне непонятна. Также как и облачной версии CCS. Даже в бесплатной версии CCS установленной на компе, для этого проекта подойти к ограничению по длине кода нереально. В общем, приятно читать: с каждым сообщением Вы подходите ближе к своей цели создания девайса. Так держать и удачи!
Спойлер
#include "msp430.h" ; the actual CPU model is set in; the project options in IAR
SCLK EQU BIT4 ; SCLK on P1 (radio interface)
MOSI EQU BIT2 ; MOSI on P1
MISO EQU BIT1 ; MISO on P1
CS EQU BIT3 ; TX enable on P1
GDO0 EQU BIT5 ; GDO0 on P1
GDO2 EQU BIT0 ; GDO2 on P2
SCL EQU BIT6 ; I2C pins on port P1
SDA EQU BIT7
PWR EQU BIT1 ; Si7005 Vdd pin on port 2
DCDC EQU BIT2 ; DC/DC converter enable
SRES EQU 0x30 ; reset chip strobe
SRX EQU 0x34 ; enter RX state
STX EQU 0x35 ; enter TX state
SIDLE EQU 0x36 ; enter IDLE state
SPWD EQU 0x39 ; enter power down mode
SNOP EQU 0x3D ; no operation
BAT_PER EQU 10 ; battery check period
RSEG CSTACK ; pre-declaration of segment
RSEG DATA16_N ; data segment
buf_TX: DS 16 ; transmitting packet buffer
buf_RX: DS 16 ; received packet buffer
i2cb: DS 15 ; I2C data buffer
batCnt: DS 1 ; battery check counter
RSEG CODE ; code segment
reset: mov #SFE(CSTACK), SP ; set up stack
mov.w #WDTPW+WDTHOLD, &WDTCTL ; stop watchdog timer
; I/O ports setup
mov.b #MISO+CS+SCL+SDA, &P1OUT; init port P1
mov.b #~(MISO|GDO0|SCLK), &P1DIR ; input on those pins
mov.b #MISO+SCLK, &P1REN
bis.b #SCL+SDA, &P1SEL ; configure pins for I2C
bis.b #SCL+SDA, &P1SEL2
clr.b &P2OUT ; init port P2
mov.b #~(GDO2|BIT6), &P2DIR ; input on GDO2 pin
bis.b #BIT6+BIT7, &P2SEL ; configure XTAL pins
clr.b &P2SEL2
; clock setup
clr.b &DCOCTL
mov.b &CALBC1_8MHZ, &BCSCTL1 ; set 8 MHz clock
mov.b &CALDCO_8MHZ, &DCOCTL
mov.b #DIVS_1, &BCSCTL2 ; SMCLK=DCO/2
; mov.b #LFXT1S_2, &BCSCTL3 ; select VLO as ACLK
mov.b #XCAP_2, &BCSCTL3 ; select XT1 as ACLK, 10pF caps
osc1: bic.b #OFIFG, &IFG1 ; clear OFIFG
clr.w R15 ; delay
osc2: dec.w R15
jnz osc2
bit.b #OFIFG, &IFG1 ; re-test OFIFG
jnz osc1 ; repeat test if needed
bis.b #DIVA_3, &BCSCTL1 ; set ACLK / 8
; SPI setup for eUSCI_A0
mov.b #UCSSEL_2+UCSWRST, &UCA0CTL1 ; keep SPI module in reset
mov.b #UCMSB+UCCKPH+UCMST+UCSYNC, &UCA0CTL0
mov.b #1, &UCA0BR0 ; clock division factor (1:1)
clr.b &UCA0BR1 ; for baudrate 4 MHz
call #Init_CC1101 ; init radio, leave it in SHDN
; I2C setup for eUSCI_B0
bis.b #UCSSEL_2+UCSWRST, &UCB0CTL1 ; keep I2C module in reset
bis.b #UCMODE_3+UCMST+UCSYNC, &UCB0CTL0 ; I2C master mode
mov.w #0x40, &UCB0I2CSA ; Si7005 slave address
mov.b #40, &UCB0BR0 ; baudrate = 100KHz
clr.b &UCB0BR1
; ADC setup for battery monitoring
mov.w #INCH_11+ADC10SSEL_3, &ADC10CTL1 ; voltage divider, SMCLK
mov.w #SREF_1+ADC10SHT_1+ADC10SR+ADC10IE, &ADC10CTL0
mov.b #BAT_PER, &batCnt ; initialize battery check counter
; Timer_0 setup for regular wake-ups
mov.w #TASSEL_1+MC_1+ID_3+TACLR+TAIE, &TA0CTL ; ACLK, up mode
; mov.w #512, &TA0CCR0 ; setup for 1 sec
mov.w #2560, &TA0CCR0 ; setup for 5 sec
; mov.w #30720, &TA0CCR0 ; setup for 1 min
; Timer_1 setup for short delays
mov.w #TASSEL_1+TACLR+TAIE, &TA1CTL ; ACLK, up mode
; transmitting packet setup
mov.b #0x0A, &buf_TX ; length of data in TX buffer
mov.b #0x7F, &buf_TX+1 ; TX FIFO address
mov.b #0x08, &buf_TX+2 ; packet payload length
mov.b #0x11, &buf_TX+3 ; RX ID
mov.b #0xAA, &buf_TX+4 ; TX ID
mov.b #0x00, &buf_TX+5 ; packet number
mov.w #0x3412, &buf_TX+6 ; payload (temp)
mov.w #0x7856, &buf_TX+8 ; payload (humi)
mov.b #0xFF, &buf_TX+10 ; payload (battery)
loop: ; main program loop
bis.w #LPM3+GIE, SR ; enter LPM3 sleep mode
nop ; wake-up by Timer_0
call #Check_Battery ; measure the battery voltage
call #Get_Temp_Humi ; measure temp and humi
bis.b #DCDC, &P2OUT ; turn on DC/DC converter
inc.b &buf_TX+5 ; update packet number
call #Transmit_Packet ; transmit this packet over air
bic.b #DCDC, &P2OUT ; turn off DC/DC converter
jmp loop
;===PROCEDURES========
Get_Temp_Humi:
bis.b #PWR, &P2OUT ; power-up Si7005 sensor
mov.w #63, &TA1CCR0 ; setup for 15 msec delay
call #delay ; Si7005 power-up delay
mov.w #0x1103, &i2cb ; request temp conversion
call #Request_Conversion
mov.w #164, &TA1CCR0 ; setup for 40 msec delay
call #delay ; for performing the measurements
call #Read_Conversion ; read temp value from sensor
mov.w &i2cb, &buf_TX+6 ; insert temp into payload
mov.w #0x0103, &i2cb ; request humi conversion
call #Request_Conversion
mov.w #164, &TA1CCR0 ; setup for 40 msec delay
call #delay ; for performing the measurements
call #Read_Conversion ; read humi value from sensor
mov.w &i2cb, &buf_TX+8 ; insert humi into payload
bic.b #PWR, &P2OUT ; power off Si7005 sensor
ret
Request_Conversion:
mov.w #i2cb, R11 ; set up pointer to buffer
mov.b #2, R10 ; byte counter
bic.b #UCSWRST, &UCB0CTL1 ; clear I2C reset
bis.b #UCNACKIE, &UCB0I2CIE ; enable NACK interrupt
bis.b #UCB0TXIE, &IE2 ; enable I2C TX interrupt
bis.b #UCTR+UCTXSTT, &UCB0CTL1 ; send start condition and write
bis.b #LPM0+GIE, SR ; enter LPM0
nop ; remain in LPM0
bis.b #UCTXSTP, &UCB0CTL1 ; generate STOP condition
bit.b #UCTXSTP, &UCB0CTL1 ; wait for generating the stop condition
jnz $-4
bis.b #UCSWRST, &UCB0CTL1 ; I2C reset
ret
Read_Conversion:
mov.b #1, &i2cb ; register number
mov.w #i2cb, R11 ; set up pointer to buffer
mov.b #1, R10 ; # of bytes to transmit
bic.b #UCSWRST, &UCB0CTL1 ; clear I2C reset
bis.b #UCNACKIE, &UCB0I2CIE ; enable NACK interrupt
bis.b #UCB0TXIE, &IE2 ; enable I2C TX interrupt
bis.b #UCTR+UCTXSTT, &UCB0CTL1 ; send start condition and write
bis.w #LPM0+GIE, SR ; enter LPM0
nop ; remain in LPM0
bic.b #UCTR, &UCB0CTL1 ; set receiver mode
mov.w #i2cb, R11 ; set up pointer to buffer
mov.b #2, R10 ; # of bytes to receive
bis.b #UCB0RXIE, &IE2 ; enable I2C RX interrupt
bis.b #UCTXSTT, &UCB0CTL1 ; send start condition
bis.w #LPM0+GIE, SR ; enter LPM0
nop ; remain in LPM0
bit.b #UCTXSTP, &UCB0CTL1 ; wait for generating the stop condition
jnz $-4
bis.b #UCSWRST, &UCB0CTL1 ; I2C reset
swpb &i2cb ; reverse the bytes order
ret
delay: ; short delay
bis.w #MC_1+TACLR, &TA1CTL ; start Timer1 in up mode
bis.w #LPM3+GIE, SR ; enter LPM3 sleep mode
nop
bic.w #MC_1, &TA1CTL ; stop Timer1
ret
;----------
Check_Battery:
mov.b #0xFF, R5
dec.b &batCnt ; time to check battery?
jnz ct2 ; NO - exit
mov.b #BAT_PER, &batCnt ; YES - restore counter
bis.w #REF2_5V+REFON+ADC10ON, &ADC10CTL0
mov.w #80, R5 ; 30 mksec delay to set up VREF
ct1: dec.w R5
jnz ct1
bis.w #ENC+ADC10SC, &ADC10CTL0; start temp sampling/conversion
bis.w #LPM0+GIE,SR ; LPM0, ADC10_ISR will force exit
nop
bic.w #ENC, &ADC10CTL0 ; shut down ADC completely
bic.w #ADC10ON, &ADC10CTL0
bic.w #REFON, &ADC10CTL0 ; turn off reference
mov.w &ADC10MEM, R5 ; get conversion result
rra.w R5 ; get rif of 2 lsb
rra.w R5
ct2: mov.b R5, &buf_TX+10 ; insert batt voltage into payload
ret
;----------
Transmit_Packet:
mov.w #buf_TX, R11 ; packet data pointer
call #Send_CC1101 ; load packet into FIFO
mov.b #STX, R11 ; send strobe to enter
call #Send_Strobe ; the TX mode
bic.b #GDO0, &P1IES ; select low-to-high transition
clr.b &P1IFG ; clear interrupt flag
bis.b #GDO0, &P1IE ; enable port interrupt
bis.w #LPM3+GIE, SR ; enter LPM3 sleep mode
nop ; wait for sending the sync word
bis.b #GDO0, &P1IES ; select high-to-low transition
clr.b &P1IFG ; clear interrupt flag
bis.b #GDO0, &P1IE ; enable port interrupt
bis.w #LPM3+GIE, SR ; enter LPM3 sleep mode
nop ; wait for the end of transmission
mov.b #SPWD, R11 ; power down mode
call #Send_Strobe
ret
;====RADIO INTERFACE===================
Init_CC1101:
mov.w #CC1101_setup, R11 ; load CC1101 registers
mov.b @R11+, R10 ; get byte counter
bis.b #MISO+MOSI+SCLK, &P1SEL ; connect P1 pins to SPI
bis.b #MISO+MOSI+SCLK, &P1SEL2
bic.b #SCLK, &P1REN
bis.b #SCLK, &P1DIR
bic.b #UCSWRST, &UCA0CTL1 ; enable SPI module
bis.b #UCA0TXIE, &IE2 ; enable SPI TX interrupt
bic.b #CS, &P1OUT ; enable radio
nop
ic1: bit.b #MISO, &P1IN ; wait for radio interface ready
jnz ic1
bis.w #LPM0+GIE, SR ; enter LPM0 sleep mode
nop
bis.b #CS, &P1OUT ; disable radio
bis.b #UCSWRST, &UCA0CTL1 ; disable SPI module
mov.w #0x3E03, &buf_TX
mov.w #0x39C0, &buf_TX+2 ; set 10dBm output power
mov.w #buf_TX, R11 ; and enter SHDN mode
call #Send_CC1101
ret
Read_CC1101:
bis.b #MISO+MOSI+SCLK, &P1SEL ; connect P1 pins to SPI
bis.b #MISO+MOSI+SCLK, &P1SEL2
bic.b #SCLK, &P1REN
bis.b #SCLK, &P1DIR
bic.b #UCSWRST, &UCA0CTL1 ; enable SPI module
bis.b #UCA0RXIE, &IE2 ; enable SPI RX interrupt
bic.b #CS, &P1OUT ; enable radio
rp1: bit.b #GDO2, &P2IN ; wait for radio interface ready
jnz rp1
mov.b R11, &UCA0TXBUF ; send FIFO address & burst read
bis.w #LPM0+GIE, SR ; enter LPM0 sleep mode
nop
rp2: mov.b #SNOP, &UCA0TXBUF ; SNOP strobe for reading
bis.w #LPM0+GIE, SR ; enter LPM0 sleep mode
nop
mov.b &UCA0RXBUF, R11 ; get reveived byte in buffer
dec.b R10 ; decrement received bytes counter
jnz rp2 ; loop back
rp3: bis.b #CS, &P1OUT ; disable radio interface
bis.b #UCSWRST, &UCA0CTL1 ; disable SPI module
bic.b #SCLK, &P1DIR
bis.b #SCLK, &P1REN
bic.b #MISO+MOSI+SCLK, &P1SEL2; disconnect P1 pins from SPI
bic.b #MISO+MOSI+SCLK, &P1SEL
ret
;----------
Send_CC1101: ; R11 points to data, 1st byte is length
mov.b @R11+, R10 ; get byte counter
bis.b #MISO+MOSI+SCLK, &P1SEL ; connect P1 pins to SPI
bis.b #MISO+MOSI+SCLK, &P1SEL2
bic.b #SCLK, &P1REN
bis.b #SCLK, &P1DIR
bic.b #UCSWRST, &UCA0CTL1 ; enable SPI module
bis.b #UCA0TXIE, &IE2 ; enable SPI TX interrupt
bic.b #CS, &P1OUT ; enable radio
nop
wc1: bit.b #GDO2, &P2IN ; wait for radio interface ready
jnz wc1
bis.w #LPM0+GIE, SR ; enter LPM0 sleep mode
nop
bis.b #CS, &P1OUT ; disable radio
bis.b #UCSWRST, &UCA0CTL1 ; disable SPI module
bic.b #SCLK, &P1DIR
bis.b #SCLK, &P1REN
bic.b #MISO+MOSI+SCLK, &P1SEL2; disconnect P1 pins from SPI
bic.b #MISO+MOSI+SCLK, &P1SEL
ret
Send_Strobe:
bis.b #MISO+MOSI+SCLK, &P1SEL ; connect P1 pins to SPI
bis.b #MISO+MOSI+SCLK, &P1SEL2
bic.b #SCLK, &P1REN
bis.b #SCLK, &P1DIR
bic.b #UCSWRST, &UCA0CTL1 ; enable SPI module
bis.b #UCA0RXIE, &IE2 ; enable SPI RX interrupt
bic.b #CS, &P1OUT ; enable radio
nop
wc2: bit.b #GDO2, &P2IN ; wait for radio interface ready
jnz wc2
mov.b R11, &UCA0TXBUF ; strobe in R11
bis.w #LPM0+GIE, SR ; enter LPM0 sleep mode
nop
bis.b #CS, &P1OUT ; disable radio
bis.b #UCSWRST, &UCA0CTL1 ; disable SPI module
bic.b #SCLK, &P1DIR
bis.b #SCLK, &P1REN
bic.b #MISO+MOSI+SCLK, &P1SEL2; disconnect P1 pins from SPI
bic.b #MISO+MOSI+SCLK, &P1SEL
ret
;====Interrupt Service Routines=========
RX_I2CST_ISR: ; SPI receive/I2C status
bit.b #UCA0RXIFG, &IFG2 ; SPI Receive Interrupt?
jnz SPI_RX ; YES
bit.b #UCSTPIFG, &UCB0STAT ; I2C slave STOP condition?
jnz I2C_STP ; YES
bit.b #UCNACKIFG, &UCB0STAT ; I2C NACK received?
jnz I2C_NACK ; YES
reti
SPI_RX: ; SPI receive processing
bic.b #UCA0RXIFG, &IFG2 ; clear SPI RX interrupt flag
bic.w #LPM0+GIE, 0(SP) ; wake-up CPU
reti
I2C_STP: ; I2C slave stop processing
bic.b #UCSTPIFG, &UCB0STAT ; clear interrupt flag
bic.w #LPM3+GIE, 0(SP) ; wake-up CPU
reti
I2C_NACK: ; I2C NACK received
bic.b #UCNACKIFG, &UCB0STAT ; clear interrupt flag
bis.b #UCTXSTP, &UCB0CTL1 ; generate STOP condition
bic.w #LPM0+GIE, 0(SP) ; wake-up CPU
reti
;----------
TX_I2CRX_ISR: ; SPI transmit/I2C receive&transmit
bit.b #UCSWRST, &UCB0CTL1 ; is USCI_B0 active?
jnz SPI_TX ; NO - process SPI request
bit.b #UCB0RXIFG, &IFG2 ; I2C_RX interrupt?
jnz I2C_RX ; YES
bit.b #UCB0TXIFG, &IFG2 ; I2C TX interrupt?
jnz I2C_TX ; YES
reti
SPI_TX: mov.b @R11+, &UCA0TXBUF ; start SPI transmission
dec.b R10 ; decrement bytes counter
jnz SPI_TX_end ; all data sent?
bic.b #UCA0TXIE, &IE2 ; YES - disable SPI TX interrupt
bis.b #UCA0RXIE, &IE2 ; enable SPI RX interrupt
SPI_TX_end:
reti
I2C_RX: mov.b &UCB0RXBUF, 0(R11) ; get I2C received byte
inc.w R11 ; update pointer
dec.b R10 ; decrement bytes counter
cmp.b #1, R10 ; last byte to receive?
jeq I2C_RX_end1 ; YES
jl I2C_RX_end2 ; all bytes are received
reti
I2C_RX_end1:
bis.b #UCTXNACK+UCTXSTP, &UCB0CTL1 ; generate NACK+STOP condition
reti
I2C_RX_end2:
bic.b #UCB0RXIE, &IE2 ; disable I2C RX interrupt
bic.w #LPM0+GIE, 0(SP) ; wake-up CPU
reti
I2C_TX: tst.b R10 ; all data sent?
jz I2C_TX_end ; YES - exit
mov.b @R11+, &UCB0TXBUF ; NO - start I2C transmission
dec.b R10 ; decrement bytes counter
reti
I2C_TX_end:
bic.b #UCB0TXIE, &IE2 ; disable I2C TX interrupt
bic.w #LPM0+GIE, 0(SP) ; wake-up CPU
reti
;----------
TA0_ISR:
add.w &TA0IV, PC ; Add offset to Jump table
reti ; Vector 0: No interrupt
reti ; Vector 2: TACCR1
reti ; Vector 4: TACCR2
reti ; Vector 6: Reserved
reti ; Vector 8: Reserved
bic.w #LPM3+GIE, 0(SP) ; Vector 10: TAIFG Flag - wake-up CPU
reti
;----------
TA1_ISR:
add.w &TA1IV, PC ; Add offset to Jump table
reti ; Vector 0: No interrupt
reti ; Vector 2: TACCR1
reti ; Vector 4: TACCR2
reti ; Vector 6: Reserved
reti ; Vector 8: Reserved
bic.w #LPM3+GIE, 0(SP) ; Vector 10: TAIFG Flag - wake-up CPU
reti
;----------
ADC10_ISR:
bic.w #LPM0+GIE, 0(SP) ; wake-up CPU
reti
;----------
P1_ISR:
clr.b &P1IFG ; clear interrupt flag
bic.b #GDO0, &P1IE ; disable port interrupt
bic.w #LPM3+GIE, 0(SP) ; wake-up CPU
reti
;----------
CC1101_setup:
DB 47 ;settings array length
DB 0x40 ;burst write to starting address 0
DB 0x29 ;IOCFG2 |0x00|GDO2 Output Pin Configuration
DB 0x2E ;IOCFG1 |0x01|GDO1 Output Pin Configuration
DB 0x06 ;IOCFG0 |0x02|GDO0 Output Pin Configuration
DB 0x47 ;FIFOTHR |0x03|RX FIFO and TX FIFO Thresholds
DB 0xD3 ;SYNC1 |0x04|Sync Word, High Byte
DB 0x91 ;SYNC0 |0x05|Sync Word, Low Byte
DB 0x3D ;PKTLEN |0x06|Packet Length (61)
DB 0x05 ;PKTCTRL1 |0x07|Packet Automation Control
DB 0x05 ;PKTCTRL0 |0x08|Packet Automation Control
DB 0x11 ;ADDR |0x09|Device Address
DB 0x00 ;CHANNR |0x0A|Channel number
DB 0x06 ;FSCTRL1 |0x0B|Frequency Synthesizer Control
DB 0x00 ;FSCTRL0 |0x0C|Frequency Synthesizer Control
DB 0x22 ;FREQ2 |0x0D|Frequency Control Word, High Byte
DB 0xBB ;FREQ1 |0x0E|Frequency Control Word, Middle Byte
DB 0x13 ;FREQ0 |0x0F|Frequency Control Word, Low Byte
DB 0xCA ;MDMCFG4 |0x10|Modem Configuration
DB 0x83 ;MDMCFG3 |0x11|Modem Configuration
DB 0x13 ;MDMCFG2 |0x12|Modem Configuration
DB 0x22 ;MDMCFG1 |0x13|Modem Configuration
DB 0xF8 ;MDMCFG0 |0x14|Modem Configuration
DB 0x35 ;DEVIATN |0x15|Modem Deviation Setting
DB 0x07 ;MCSM2 |0x16|Main Radio Control State Machine Configuration
DB 0x30 ;MCSM1 |0x17|Main Radio Control State Machine Configuration
DB 0x18 ;MCSM0 |0x18|Main Radio Control State Machine Configuration
DB 0x16 ;FOCCFG |0x19|Frequency Offset Compensation Configuration
DB 0x6C ;BSCFG |0x1A|Bit Synchronization Configuration
DB 0x43 ;AGCCTRL2 |0x1B|AGC Control
DB 0x40 ;AGCCTRL1 |0x1C|AGC Control
DB 0x91 ;AGCCTRL0 |0x1D|AGC Control
DB 0x87 ;WOREVT1 |0x1E|High Byte Event0 Timeout
DB 0x6B ;WOREVT0 |0x1F|Low Byte Event0 Timeout
DB 0xFB ;WORCTRL |0x20|Wake on Radio Control
DB 0x56 ;FREND1 |0x21|Front End RX Configuration
DB 0x10 ;FREND0 |0x22|Front End TX Configuration
DB 0xE9 ;FSCAL3 |0x23|Frequency Synthesizer Calibration
DB 0x2A ;FSCAL2 |0x24|Frequency Synthesizer Calibration
DB 0x00 ;FSCAL1 |0x25|Frequency Synthesizer Calibration
DB 0x1F ;FSCAL0 |0x26|Frequency Synthesizer Calibration
DB 0x41 ;RCCTRL1 |0x27|RC Oscillator Configuration
DB 0x00 ;RCCTRL0 |0x28|RC Oscillator Configuration
DB 0x59 ;FSTEST |0x29|Frequency Synthesizer Calibration Control
DB 0x7F ;PTEST |0x2A|Production Test
DB 0x3F ;AGCTEST |0x2B|AGC Test
DB 0x81 ;TEST2 |0x2C|Various Test Settings
DB 0x35 ;TEST1 |0x2D|Various Test Settings
DB 0x09 ;TEST0 |0x2E|Various Test Settings
;----------
COMMON INTVEC ; MSP430 interrupt vectors
ORG RESET_VECTOR ; POR, ext. Reset, Watchdog
DW reset
ORG USCIAB0RX_VECTOR ; SPI/I2C RX ISR
DW RX_I2CST_ISR
ORG USCIAB0TX_VECTOR ; SPI/I2C TX ISR
DW TX_I2CRX_ISR
ORG TIMER1_A1_VECTOR ; TimerA_1 ISR
DW TA1_ISR
ORG TIMER0_A1_VECTOR ; TimerA_0 ISR
DW TA0_ISR
ORG ADC10_VECTOR ; ADC10 Vector
DW ADC10_ISR
ORG PORT1_VECTOR ; Port1 ISR
DW P1_ISR
END
Странное поведение Протеуса - глюк его однозначно. Вообще, зачем он Вам нужен при наличии железного отладчика? Тем более с такими глюками и мало-ли ещё с чем. Полагаю, что у Вас нет логического анализатора и поэтому Протеус. Если-же он есть, тогда причина использовать Протеус мне непонятна. Также как и облачной версии CCS. Даже в бесплатной версии CCS установленной на компе, для этого проекта подойти к ограничению по длине кода нереально. В общем, приятно читать: с каждым сообщением Вы подходите ближе к своей цели создания девайса. Так держать и удачи!
Re: STM32 на батарейках
Пн янв 11, 2016 13:56:08
Попытки с ходу переиначить все под msp430 ни к чему не привели. Помыкавшись с тем, что сначала не работает одно, а потом другое, вернулся опять к STM32F030F4. Разработка пошла быстрее.
На данный момент написан код для работы со всеми датчиками, а это BMP180 (давление + температура), Si7021 (влажность + температура) и BH1750 (освещенность), плюс почти вся логика (управление режимами сна, питанием и т.п.). Недостает только функционала передачи через NRF24L01. На данный момент все собранные данные складываются в пакет для отправки, а так же в отладочных целях содержимое этого пакета выводятся через последовательный порт в терминал в удобочитаемом виде.
Текущая версия отладочной прошивки занимает в МК 26 килобайт флеша. Подобная тучность проистекает из-за значительного объема отладочного кода, использующего всякие жирные функции, на вроде printf(). В том, что в МК, имеющем по паспорту 16кб флеша влезает 26кб прошивка, нет ничего удивительного. Флеша в STM32F030F4 на самом деле 32кб, только производитель не особо это афиширует.
Некоторые мысли о том, с чем пришлось столкнуться. Внутренние часы (RTC) STM32F030 врут безбожно даже в условиях комнатной температуры. Все попытки откалибровать LSI у меня с треском провались. После одной попытки калибровки часы отстают, после другой спешат, а после третьей и то и другое в разное время. В общем, без внешнего кварца это больше похоже на баловство и я смирился с мыслью, что набортных часов у меня не будет. В принципе, оно может и не очень нужно, т.к. все, что требуется от RTC в данном случае -- это будить МК через определенные промежутки времени. С этим оно справляется с приемлемой точностью.
Внутренний термодатчик STM32 выдает показания весьма приблизительные. Если для 3.3 вольт питающего напряжения оно еще как-то напоминает правду, то со снижением VCC уходят вниз и показания с датчика. Это при том, что перед каждым измерением производится калибровка АЦП, измеряется питающее напряжение МК и данные датчика нормализуются на основании калибровочных констант зашитых в самом МК.
При комнатной температуре МК устойчиво работает при снижении питания до 1.95 вольт. Разумеется, это при отключенном мониторе VDDA. Датчики, за исключением BH1750, переносят такие напряжения так же без видимого беспокойства. С BH1750 ситуация чуть отличается. Если его сразу запустить при напряжении питания ниже двух с чем-то вольт, то он отвечает по I2C, но в качестве результатов измерений возвращает всегда нули. Если изначально запустить его при напряжении питания в рамках паспортных значений, то потом он без проблем работает и на пониженном напряжении. У этого датчика так же обнаружилось свойство, что для него критична величина питающего напряжения в момент включения. Если в момент включения напряжение было ниже рабочих границ, то потом датчик не будет работать даже если напряжение поднимется.
По поводу электропитания. После того, как получил BL8530, спаял простенькую платку для проверки.
Схема (если можно назвать это схемой) из даташита, добавил только нагрузочные резисторы для замеров эффективности. С помощью джамперов можно выставить нагрузку в 1ма, 5ма и 10ма -- токи, при которых эффективность преобразователя для меня представляет наибольший интерес. Курьез же здесь заключается в том, что к измерениям так и не приступил, т.к. увлекся разработкой функционала самого сенсора.
При подборе компонентов решил схитрить. Производитель рекомендует использовать одноамперные диоды шоттки, навроде 1N5817. Подумалось, что 1А здесь будет выглядеть явным перебором при потреблении нагрузки в полтора десятка миллиампер максимум, т.ч. рискнул попробовать 200ма BAT54, который является скорее сигнальным диодом, чем силовым. Ничего страшного не случилось и диод чувствует себя нормально во всех режимах.
Пол вечера занимался поисками самой маленькой катушки индуктивности нужного номинала под печатный монтаж. Нашел. Размеры 4мм на 2мм.
Вопрос, которым я задавался с самого начала, о том, может ли МК поднимать себе питание, управляя преобразователем, разрешился точно так, как здесь мне уже и говорили. МК, подавая единицу или ноль на разрешающий вход BL8530, без всяких затруднений переходит с батарей на 3.3в и обратно. После того, как выяснилось, что схема может работать и при подсевших батареях, т.е. при более низком питающем напряжении, чем требуется по даташитам для датчиков и МК, возникла мысль совсем отказаться от DC-DC, но подумалось, что так не получится высосать батарейки полностью и потому преобразователь в схеме решил оставить. Логика работы при этом планируется такая: сенсор со свежими батареями работает до момента, когда питающее напряжение не снизится до двух вольт, после чего включает преобразователь и переходит на питание с него. Пока не понятно, правда, как отнесется к низким напряжениям NRF24L01, но это не должно являться большой проблемой, т.к. преобразователь можно включать и выключать по потребности и в крайнем случае его можно включать лишь на время работы модуля связи.
Наблюдая за манерами BH1750, решил обособить линии питания всей группы датчиков, добавив к ним отдельный коммутатор. Такое решение продиктовано простой мыслью -- если какой-то из датчиков начнет чудить, то МК всегда сможет передернуть им питание в надежде, что это приведет их в чувство. И здесь опять возникает потребность в повышайке, которая обусловлена спецификой BH1750. Если батареи подсели, скажем, до 2.2 вольта, то сколько не передергивай питание, BH1750 уже не поднимется. Ему тупо нужно более высокое напряжение для начального запуска. Имея же в наличии управляемый DC-DC, старт капризного датчика возможен при любом состоянии батарей, главное, чтобы хватило для работы преобразователя. Выключаем питание датчиков, поднимаем DC-DC, включаем датчики, выключаем DC-DC и продолжаем эксплуатацию на пониженном напряжении.
К чему все эти сложности и почему-бы не врубить преобразователь с самого начала и работать всегда от него? Против такого решения работают соображения, что потребляемый устройством ток зависит от величины питающих напряжений. Чисто из желания беречь батареи по максимуму, возникают мысли о более сложном управлении питанием. Есть даже идея прикрутить отдельный коммутатор питания, который будет пускать напряжение в обход преобразователя, когда тот выключен. Идея эта имеет то обоснование, что потери на открытом полевом транзисторе гораздо меньше, чем на диоде, пусть и шоттки. Простейший расчет показывает, что при работе от двух вольт с батарей и током в нагрузку 7-10ма (примерно столько жрет сенсор в активном состоянии) потери энергии на диоде составят около трех милливатт. Оно вроде и пустячок, но зачем же зря добру пропадать.
Понаписал я здесь обильно, сбивчиво и сумбурно, но мне хотелось совсем не похвастаться, а поделиться своими мыслями и сомнениями в поисках подтверждения правильности или, наоборот, ошибочности моих действий. Буду весьма признателен, если кому-нибудь захочется прокомментировать мои изыскания и поделиться своими соображениями по данному вопросу.
На данный момент написан код для работы со всеми датчиками, а это BMP180 (давление + температура), Si7021 (влажность + температура) и BH1750 (освещенность), плюс почти вся логика (управление режимами сна, питанием и т.п.). Недостает только функционала передачи через NRF24L01. На данный момент все собранные данные складываются в пакет для отправки, а так же в отладочных целях содержимое этого пакета выводятся через последовательный порт в терминал в удобочитаемом виде.
Текущая версия отладочной прошивки занимает в МК 26 килобайт флеша. Подобная тучность проистекает из-за значительного объема отладочного кода, использующего всякие жирные функции, на вроде printf(). В том, что в МК, имеющем по паспорту 16кб флеша влезает 26кб прошивка, нет ничего удивительного. Флеша в STM32F030F4 на самом деле 32кб, только производитель не особо это афиширует.
Некоторые мысли о том, с чем пришлось столкнуться. Внутренние часы (RTC) STM32F030 врут безбожно даже в условиях комнатной температуры. Все попытки откалибровать LSI у меня с треском провались. После одной попытки калибровки часы отстают, после другой спешат, а после третьей и то и другое в разное время. В общем, без внешнего кварца это больше похоже на баловство и я смирился с мыслью, что набортных часов у меня не будет. В принципе, оно может и не очень нужно, т.к. все, что требуется от RTC в данном случае -- это будить МК через определенные промежутки времени. С этим оно справляется с приемлемой точностью.
Внутренний термодатчик STM32 выдает показания весьма приблизительные. Если для 3.3 вольт питающего напряжения оно еще как-то напоминает правду, то со снижением VCC уходят вниз и показания с датчика. Это при том, что перед каждым измерением производится калибровка АЦП, измеряется питающее напряжение МК и данные датчика нормализуются на основании калибровочных констант зашитых в самом МК.
При комнатной температуре МК устойчиво работает при снижении питания до 1.95 вольт. Разумеется, это при отключенном мониторе VDDA. Датчики, за исключением BH1750, переносят такие напряжения так же без видимого беспокойства. С BH1750 ситуация чуть отличается. Если его сразу запустить при напряжении питания ниже двух с чем-то вольт, то он отвечает по I2C, но в качестве результатов измерений возвращает всегда нули. Если изначально запустить его при напряжении питания в рамках паспортных значений, то потом он без проблем работает и на пониженном напряжении. У этого датчика так же обнаружилось свойство, что для него критична величина питающего напряжения в момент включения. Если в момент включения напряжение было ниже рабочих границ, то потом датчик не будет работать даже если напряжение поднимется.
По поводу электропитания. После того, как получил BL8530, спаял простенькую платку для проверки.
Схема (если можно назвать это схемой) из даташита, добавил только нагрузочные резисторы для замеров эффективности. С помощью джамперов можно выставить нагрузку в 1ма, 5ма и 10ма -- токи, при которых эффективность преобразователя для меня представляет наибольший интерес. Курьез же здесь заключается в том, что к измерениям так и не приступил, т.к. увлекся разработкой функционала самого сенсора.
При подборе компонентов решил схитрить. Производитель рекомендует использовать одноамперные диоды шоттки, навроде 1N5817. Подумалось, что 1А здесь будет выглядеть явным перебором при потреблении нагрузки в полтора десятка миллиампер максимум, т.ч. рискнул попробовать 200ма BAT54, который является скорее сигнальным диодом, чем силовым. Ничего страшного не случилось и диод чувствует себя нормально во всех режимах.
Пол вечера занимался поисками самой маленькой катушки индуктивности нужного номинала под печатный монтаж. Нашел. Размеры 4мм на 2мм.
Вопрос, которым я задавался с самого начала, о том, может ли МК поднимать себе питание, управляя преобразователем, разрешился точно так, как здесь мне уже и говорили. МК, подавая единицу или ноль на разрешающий вход BL8530, без всяких затруднений переходит с батарей на 3.3в и обратно. После того, как выяснилось, что схема может работать и при подсевших батареях, т.е. при более низком питающем напряжении, чем требуется по даташитам для датчиков и МК, возникла мысль совсем отказаться от DC-DC, но подумалось, что так не получится высосать батарейки полностью и потому преобразователь в схеме решил оставить. Логика работы при этом планируется такая: сенсор со свежими батареями работает до момента, когда питающее напряжение не снизится до двух вольт, после чего включает преобразователь и переходит на питание с него. Пока не понятно, правда, как отнесется к низким напряжениям NRF24L01, но это не должно являться большой проблемой, т.к. преобразователь можно включать и выключать по потребности и в крайнем случае его можно включать лишь на время работы модуля связи.
Наблюдая за манерами BH1750, решил обособить линии питания всей группы датчиков, добавив к ним отдельный коммутатор. Такое решение продиктовано простой мыслью -- если какой-то из датчиков начнет чудить, то МК всегда сможет передернуть им питание в надежде, что это приведет их в чувство. И здесь опять возникает потребность в повышайке, которая обусловлена спецификой BH1750. Если батареи подсели, скажем, до 2.2 вольта, то сколько не передергивай питание, BH1750 уже не поднимется. Ему тупо нужно более высокое напряжение для начального запуска. Имея же в наличии управляемый DC-DC, старт капризного датчика возможен при любом состоянии батарей, главное, чтобы хватило для работы преобразователя. Выключаем питание датчиков, поднимаем DC-DC, включаем датчики, выключаем DC-DC и продолжаем эксплуатацию на пониженном напряжении.
К чему все эти сложности и почему-бы не врубить преобразователь с самого начала и работать всегда от него? Против такого решения работают соображения, что потребляемый устройством ток зависит от величины питающих напряжений. Чисто из желания беречь батареи по максимуму, возникают мысли о более сложном управлении питанием. Есть даже идея прикрутить отдельный коммутатор питания, который будет пускать напряжение в обход преобразователя, когда тот выключен. Идея эта имеет то обоснование, что потери на открытом полевом транзисторе гораздо меньше, чем на диоде, пусть и шоттки. Простейший расчет показывает, что при работе от двух вольт с батарей и током в нагрузку 7-10ма (примерно столько жрет сенсор в активном состоянии) потери энергии на диоде составят около трех милливатт. Оно вроде и пустячок, но зачем же зря добру пропадать.
Понаписал я здесь обильно, сбивчиво и сумбурно, но мне хотелось совсем не похвастаться, а поделиться своими мыслями и сомнениями в поисках подтверждения правильности или, наоборот, ошибочности моих действий. Буду весьма признателен, если кому-нибудь захочется прокомментировать мои изыскания и поделиться своими соображениями по данному вопросу.
- Вложения
-
- 2016-01-11_112524.jpg
- (150.91 KiB) Скачиваний: 3234
Re: STM32 на батарейках
Пн янв 11, 2016 20:04:33
Прогресс налицо, замечательно!
По датчикам: передергивать питание у Si7021 и BMP180 не вижу смысла. Они, сделав измерение, уходят в глугокий сон, а потом при пробуждении в них можно послать команды на внутренний soft reset. Когда передергиваете питание, наверное делаете это сразу у всех датчиков и вместе с резисторами I2C(?) Учтите, что датчикам нужно какое-то время на инициализацию после передергивания питания. Например, Si7021 нужно 18мс, у остальных не помню.
А зачем ставить BMP180 в выносной модуль? Давление на улице и в (жилом) доме одинаковое. У Вас-же будет и приемный конец. Поставьте BMP туда. Там самым уменьшите время на производство, вычисление, и передачу его показаний на радость батареям.
Диод: у 1N5817 меньше прямое падение напряжения при малых токах. Именно, про 0.1А оно около 0.3В против аж 0.8 у BAT54. При меньших токах разница тоже имеется. Работать конвертер, конечно, будет, но эффективность его
может быть ниже. Кстати, при малых напряжениях батарей, при запуске конвертера от них отбирается больший ток, чем в стационарном режиме. В результате их напряжение может просесть настолько, что преобразователь не
запустится. Т.е. выигрыш по высасыванию всей энергии из них будет под вопросом в сравнении с безконверторным вариантом. Это, конечно, только мысли вслух, нужен эксперимент. В плане эффективности лучше-бы использовать
конвертер с синхронным выпрямлением.
BH1750: как вижу он вносит наибольшие проблемы со своим питанием. Если все, что от него требуется - это распознать день или ночь на дворе, то почену-бы не поставить просто фото-резистор? Я вообще не очень понимаю зачем он Вам нужен. Через окна и так видно. А для логгирования показаний на приемном конце все равно будет RTC. Кстати, в чем проблема поставить часовой кварц и на передающем конце?
Я-бы не стал жадничать с батареями и при питании от 2хАА/ААА давал-бы схеме работать пока их напряжение не снизится до 2В, исключив конвертер. Остатки будут уже мелочи, особенно принимая во внимание копеечную стоимость этих батареек. При наличии конвертера идея с коммутатором питания вполне здравая. Но опять-же, все пляски из-за того, что применяете не совсем подходящие для такого устройства детали. П
По датчикам: передергивать питание у Si7021 и BMP180 не вижу смысла. Они, сделав измерение, уходят в глугокий сон, а потом при пробуждении в них можно послать команды на внутренний soft reset. Когда передергиваете питание, наверное делаете это сразу у всех датчиков и вместе с резисторами I2C(?) Учтите, что датчикам нужно какое-то время на инициализацию после передергивания питания. Например, Si7021 нужно 18мс, у остальных не помню.
А зачем ставить BMP180 в выносной модуль? Давление на улице и в (жилом) доме одинаковое. У Вас-же будет и приемный конец. Поставьте BMP туда. Там самым уменьшите время на производство, вычисление, и передачу его показаний на радость батареям.
Диод: у 1N5817 меньше прямое падение напряжения при малых токах. Именно, про 0.1А оно около 0.3В против аж 0.8 у BAT54. При меньших токах разница тоже имеется. Работать конвертер, конечно, будет, но эффективность его
может быть ниже. Кстати, при малых напряжениях батарей, при запуске конвертера от них отбирается больший ток, чем в стационарном режиме. В результате их напряжение может просесть настолько, что преобразователь не
запустится. Т.е. выигрыш по высасыванию всей энергии из них будет под вопросом в сравнении с безконверторным вариантом. Это, конечно, только мысли вслух, нужен эксперимент. В плане эффективности лучше-бы использовать
конвертер с синхронным выпрямлением.
BH1750: как вижу он вносит наибольшие проблемы со своим питанием. Если все, что от него требуется - это распознать день или ночь на дворе, то почену-бы не поставить просто фото-резистор? Я вообще не очень понимаю зачем он Вам нужен. Через окна и так видно. А для логгирования показаний на приемном конце все равно будет RTC. Кстати, в чем проблема поставить часовой кварц и на передающем конце?
Я-бы не стал жадничать с батареями и при питании от 2хАА/ААА давал-бы схеме работать пока их напряжение не снизится до 2В, исключив конвертер. Остатки будут уже мелочи, особенно принимая во внимание копеечную стоимость этих батареек. При наличии конвертера идея с коммутатором питания вполне здравая. Но опять-же, все пляски из-за того, что применяете не совсем подходящие для такого устройства детали. П
Re: STM32 на батарейках
Пн янв 11, 2016 23:57:48
Ser60 писал(а):По датчикам: передергивать питание у Si7021 и BMP180 не вижу смысла. Они, сделав измерение, уходят в глугокий сон, а потом при пробуждении в них можно послать команды на внутренний soft reset.
Нет, просто так передергивать питание действительно нет никакого смысла. Даже резет выполнять я наверное не буду, хотя сейчас он делается перед каждым измерением. Только время отнимает. Дергать питание я планирую только в одном случае -- если датчик начинает вести себя аномально.
А зачем ставить BMP180 в выносной модуль? Давление на улице и в (жилом) доме одинаковое. У Вас-же будет и приемный конец. Поставьте BMP туда. Там самым уменьшите время на производство, вычисление, и передачу его показаний на радость батареям.
Насчет какого-то приемного конца, тут еще не все понятно будет ли он вообще. Есть идея изобразить нечто навроде бродкаста, а уж принимающие устройства пусть сами разбираются, какие им данные нужны из общего пакета. Если при такой схеме размещать датчики где-то помимо основного сенсора, то возникнет проблема, как собирать данные в одну кучу. Хотя идея измерять давление внутри дома и является привлекательной, плодить сущности тоже бы не хотелось. Понимаю, что куча разных датчиков не добавляет батареям долголетия, но тут можно выкрутиться меняя переодичность опроса. Что-то опрашивать чаще, что-то реже, причем приоритеты можно менять, если они зависят от каких-то известных факторов. Например, для моей задачи нет никакого смысла налегать на частые измерения освещенности, скажем в полночь или полдень. Зато в закатные или рассветные часы интерес к результатам измерений повышается. Или, когда, например, установившееся давление долго не меняется, то можно частоту опроса BMP180 снизить, а если давление "поехало", то восстановить. В определенной степени энергопотребление можно снижать организационно, уточняя как, когда и какие измерения производить.
Диод: у 1N5817 меньше прямое падение напряжения при малых токах. Именно, про 0.1А оно около 0.3В против аж 0.8 у BAT54.
Мы верно в какие-то разные справочные листки смотрим. Зависимость падения напряжения от протекающего тока для BAT54, 1N5817 и SS12 (картинки идут в таком же порядке):
BAT54 я выбирал не только по падению напряжения, но и по обратном току.
при запуске конвертера от них отбирается больший ток, чем в стационарном режиме. В результате их напряжение может просесть настолько, что преобразователь не
запустится. Т.е. выигрыш по высасыванию всей энергии из них будет под вопросом в сравнении с безконверторным вариантом.
Все верно. Однако, поигравшись с включением/выключением я пришел к выводу, что преобразователь имеет смысл включать лишь когда напряжение на батареях упадет на значительную величину, что будет уже ставить под сомнение возможность нормальной эксплуатации. Другими словами, в определенный момент преобразователь включается и больше уже не выключается до замены батарей. Это, как раз и получается высасывание остатков. То, что этих остатков может оставаться еще прилично, явствует из материалов тестирования батареек. Интерактивный график для АА у меня почему-то не отображается, но для ААА есть интересные данные. У некоторых батареек по достижению напряжения 1 вольта дальше происходит почти моментальное опустошение, но есть и такие, как та же GP Ultra, которая достигнув даже величины 0.8в, еще в течении сорока минут может отдавать 200ма, пока совсем не помрет. Если линейно масштабировать (что скорее всего не правильно, но какое-то представление может дать), то 200ма в течении сорока минут это 40 тысяч минут при усредненном потреблении сенсора в 200мка. Это ж месяц работы, а с учетом, что АА будут потолще, то и того больше. Прикид конечно грубый и расходование остатков всяко будет выше, но в преддверии неминуемого краха сенсор может и снизить аппетит, понизив частоту опроса датчиков. Тогда на подсосе он сможет проковылять еще дольше. Некоторое снижение потребительских свойств устройства, как бы будет говорить, что если хотите качества, то меняйте батарейки. Если лень, то кушайте, что дают.
Это, конечно, только мысли вслух, нужен эксперимент. В плане эффективности лучше-бы использовать конвертер с синхронным выпрямлением.
В условиях неопределенности, когда не совсем понятно, нужен этот преобразователь или нет, не хотелось закупаться дорогими комплектующими. В эту версию сенсора точно пойдет BL8530, а там уже может нарисоваться вообще иная картина с тем, что нужно, а что нет.
BH1750: как вижу он вносит наибольшие проблемы со своим питанием. Если все, что от него требуется - это распознать день или ночь на дворе, то почену-бы не поставить просто фото-резистор?
Ну не совсем день-ночь. Планируется управление дежурным освещением и если калиброванный датчик выдает более менее достоверные параметры и зависимость от температуры известна, то с фоторезистором бы предстоял невероятный геммор с тарировкой. ВАХ фоторезистора и так имеет довольно "горбатый" вид, а если на нее наложится температурная зависимость неизвестного свойства, то где потом вообще концы искать -- неизвестно.
С другой стороны, снимать показания с фотоорезистора придется с помощью АЦП. Все, что связано с АЦП смущает своей энергетикой. По мне, так я бы вообще АЦП не включал, если бы не контроль батарей. И учитывая требования по энергетике, я бы скорее вместо фоторезистора применил светодиод в обратном включении и измерял время стекания заряда, которое сильно зависит от освещенности. Такой метод я применял для регулировки светимости индикаторов в зависимости от освещения и он в целом работает не плохо.