PullUp NRF52842
Michal Grunt
michal.grunt na gmail.com
Středa Leden 22 17:07:35 CET 2025
Děkuji za mereni a analýzu. Ještě studuji jak v programu implementovat
použití 32khz krystalu a vynuceného sleepu pri nečinnosti či mezi vysílání
reklamy. Ptal jsem se GPT a ten mi odpověděl timto (otázka je zda jsem
dobře položil dotaz...). Mohlo by to v principu být nějak takto? Ještě mi
psal, že Zephyr už má nějaký power management implementovaný...
Děkuji
#include <stdbool.h>
#include <stdint.h>
#include "nrf.h"
#include "nrf_delay.h"
#include "nrf_soc.h"
#include "nrf_ble_gatt.h"
#include "nrf_ble_qwr.h"
#include "nrf_sdh.h"
#include "nrf_sdh_ble.h"
#include "app_timer.h"
#include "app_error.h"
#include "ble_advdata.h"
#include "ble_advertising.h"
// Inicializace BLE a dalších potřebných komponent
static void ble_stack_init(void) {
ret_code_t err_code;
// Inicializace SoftDevice
err_code = nrf_sdh_enable_request();
APP_ERROR_CHECK(err_code);
// Inicializace BLE obsluhy
err_code = nrf_sdh_ble_default_cfg_set(1, &ble_stack_init);
APP_ERROR_CHECK(err_code);
err_code = nrf_sdh_ble_enable(&ble_stack_init);
APP_ERROR_CHECK(err_code);
}
static void advertising_init(void) {
ret_code_t err_code;
ble_advertising_init_t init = {0};
// Parametry reklam
ble_advdata_t adv_data;
memset(&adv_data, 0, sizeof(adv_data));
adv_data.name_type = BLE_ADVDATA_FULL_NAME;
adv_data.include_appearance = false;
adv_data.flags = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE;
// Inicializace reklam
init.advdata = adv_data;
err_code = ble_advertising_init(&m_advertising, &init);
APP_ERROR_CHECK(err_code);
}
static void advertising_start(void) {
ret_code_t err_code;
// Začít vysílat reklamy
err_code = ble_advertising_start(&m_advertising, BLE_ADV_MODE_FAST);
APP_ERROR_CHECK(err_code);
}
static void enter_sleep_mode(void) {
// Před uspáním vypneme některé periferie, aby se šetřila energie.
NRF_POWER->TASKS_LOWPWR = 1;
__WFE(); // Čekáme na přerušení nebo událost (jako je třeba vysílání
reklamy)
}
int main(void) {
// Nastavení 32kHz krystalu pro přesné časování
NRF_CLOCK->TASKS_LFCLKSTART = 1; // Startujeme 32 kHz krystal
while (NRF_CLOCK->EVENTS_LFCLKSTARTED == 0); // Čekáme na stabilizaci
hodin
// Inicializace BLE stacku a reklam
ble_stack_init();
advertising_init();
// Hlavní smyčka
while (true) {
advertising_start();
// Uspání mezi vysíláním reklam (čekání, než reklama skončí)
enter_sleep_mode();
}
}
Dne po 20. 1. 2025 17:28 uživatel Tomáš Hamouz <
konfery.tomas.hamouz na seznam.cz> napsal:
> Měření na našem projeku s nRF82532
>
> Celý vysílací děj adverttisingu trvá 4ms (standardní 3 kanály).
> Při nastavení výkonu na 0 dBm (stačí min. na 10m) vyšel průměrný odběr při
> vysílání 3,9 mA.
> Bylo to zhruba koleno závislosti Pwr - Idd, při menším výkonu je už
> dominantní vlastní spotřeba MCU.
>
> Spotřeba byla počítaná jako integrál křivky, roztažené na celou obrazovku
> osciloskopu, měřeno na odporu.
> Máme tu sice 6.5 místný Keithley, ale pro ten pulzní odběr to měřilo
> hausnumera.
>
> V mezeře byla spotřeba cca 10uA, ale to zahrnuje celou desku včetně
> ostatního HW na desce.
>
> V příloze je zhruba průběh, ten malý hrbolek na začátku k tomu patří také.
>
> Tomáš
>
>
>
> Děkuji za odpověď. O BLE se příležitostně zajímám něco přes rok a vlastně
> si vzpomínám, že s tím skenováním máte pravdu a že reklama na nějaké delsi
> přenosy moc není (spis sem tam neco). Mohl bych příležitostně požádat o
> změření té spotřeby? Děkuji.
>
> MG
>
> Dne ne 19. 1. 2025 16:28 uživatel Tomas Hamouz <
> konfery.tomas.hamouz na seznam.cz> napsal:
> Jako zdroj 32kHz se může použít:
> - Xtal 32k - nejmenší spotřeba v klidu, součástky navíc
> - RC interní - nejjednodušší, přijatelná spotřeba v klidu, stačí na BLE,
> málo přesný na NFC
> - dělička z hlavního Xtalu - velká spotřeba v klidu
>
> LF hodiny slouží jen k časování ve spánku, ale ten procesor víceméně spí
> furt. Mají v SDK velmi hezký systém timerů, odvozený od LFC, který slouží
> pro spouštění funkcí dle potřeby, aniž by to zvyšovalo klidovou spotřebu.
> K vyslání advertisingu se samozřejmě CPU budí, ale pokud se stáhne
> vysílaný výkon a bude rozumná perioda, tak je střední hodnota odběru velmi
> malá. Teď z hlavy nevím, ale v pondělí můžu z práce poslat konkrétní čísla.
>
> Lepší je posílat data při připojení, pak je totiž otevřený komunikační
> kanál a data chodí spolehlivě. Pokud se posílají v advertisingu, musí taky
> protistrana mít spuštěný scanning a zatím všechna zařízení která jsem
> zkoušel do cca 1 min scanning skončí.
>
> Navíc, při standardním advertisingu se posílají 3 pakety (na 3 kanálech),
> kdežto při spojení jen jeden.
>
> Tomáš
>
>
>
>
>
> Díky za info. Ještě by mě zajímalo jak je to u NRF s 32khz krystalem.
> Dočetl jsem se, že z těch asi 3 možnosti jak dostat hodiny na nízké
> frekvence je externí 32khz krystal jediná možnost jak se dostat se stálou
> spotřebou na jednotky uA (mozna cca 10uA uz si to nepamatuji). Ostatní
> možnosti (delicka atd) už jsou se spotřebou na stovky uA. Nějak nemohu
> zatím najít info zda kdyz se přejde s hodinami na 32khz jestli ten procesor
> umí i něco jiného než jenom spat. Zda k vyslani reklamy není nutné procesor
> probudit nebo jak to je. Mám takovou ideu a spotřeba je rozhodující
> (NRF+akcelerometr nic vic). A zatím ještě nevím zda data z akcelerometru
> vysílat v rámci reklamy nebo jako service po připojení. Přičemž bych
> potřeboval při používání vyšší refresh dat z alcelerometru. Při nečinnosti
> klidně sem tam reklama, že to žije (akcelerometr může spat). Něco jako je
> iTag, ale chci data z akcelerometru a ne jenom pohyb/nepohyb, ale i XYZ.
> Tak přemýšlím jak na to a hlavně to umět pak prověřit co se týče spotřeby
> zda to sedí s tím co jsem zamyslel.
>
> MG
>
> Dne čt 16. 1. 2025 12:31 uživatel Jindrich Fucik <fulda na seznam.cz> napsal:
> Tohle je něco, na co u microchipu také upozorňují v datasheetech.
> Pokud na lince nejsou puluppy a je jako vstup (chápej - je ve vzduchu),
> tak probíhá část vyhodnocování - například jestli daný vstup nemá vliv
> na wake up a tak. Takže pokud je dostatek šumu, tak spotřeba může vzrůst
> poměrně signifikantně. Pochopitelně pak na tom vstupu jsou ještě další
> periferie, které při změnách také něco vyhodnocují a probouzejí se k
> životu.
>
> Dne 15.01.2025 v 19:38 Michal Grunt napsal(a):
> > Tady jsem se dočetl, že pokud budou PU aktivní i během spánku tak budou
> > odebírat 0.x uA. Četl jsem to snad i jinde. Někdo měl problém v tom, že
> > ty PU pred spánkem vypnul, měl to pak ve spanku ve vzduchu a mělo to
> > spotřebu stovky uA.
> >
> >
> https://electronics.stackexchange.com/questions/600927/best-practices-for-low-power-consumption-battery-operated-i2c-pullups
> <
> https://electronics.stackexchange.com/questions/600927/best-practices-for-low-power-consumption-battery-operated-i2c-pullups
> >
> >
> > Děkuji za graf že ktereho je jasné jaké hodnoty pro jaké rychlosti.
> >
> > Dne st 15. 1. 2025 10:04 uživatel Pavel Hudeček <edizon na seznam.cz
> > <mailto:edizon na seznam.cz>> napsal:
> >
> > __
> > Ještě jsem se podíval do DS:
> >
> >
> > Na průměr v µA bude rozhodně potřeba ten Pu vypínat spolu s čidlem,
> > případně kombinovat s externím ňáký 100k-několik M, aby to čidlo
> > mezitím nějak nezblblo, pokud se mu teda nevypíná napájení.
> >
> > PH
> >
> > Dne 14.01.2025 v 17:26 Michal Grunt napsal(a):
> >> Zdravím, plánuji mít NRF52832 a k tomu LIS2DW12. Je nutné mít na
> >> I2C externí pullup nebo stačí interní v NRF? Zrovna dneska jsem
> >> narazil na článek nebo spíš problém ve fóru kde tazatel řešil
> >> větší spotřebu řádově stovky uA místo jednotky uA a řešilo se tam,
> >> že by to mohly delat pullupy a to ještě nejspíš zapomenuté zapnuté
> >> u nějaké sběrnice NRF, která se nepouzivala...
> >>
> >> Ještě doplňující dotaz jak se měří spotřeba v řádech uA?
> > _______________________________________________
> > HW-list mailing list - sponsored by www.HW.cz <http://www.HW.cz>
> > Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
> > http://list.hw.cz/mailman/listinfo/hw-list
> > <http://list.hw.cz/mailman/listinfo/hw-list>
> >
> >
> > _______________________________________________
> > HW-list mailing list - sponsored by www.HW.cz
> > Hw-list na list.hw.cz
> > http://list.hw.cz/mailman/listinfo/hw-list
> _______________________________________________
> HW-list mailing list - sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>
>
>
>
> --
> Best regards,
> Tomas mailto:konfery.tomas.hamouz na seznam.cz
> _______________________________________________
> HW-list mailing list - sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
> _______________________________________________
> HW-list mailing list - sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20250122/36aaa8a3/attachment.htm>
Další informace o konferenci Hw-list