Szybkie prototypowanie zastosowań Internetu rzeczy (IoT) z obsługą technologii Bluetooth za pomocą zestawu rozwojowego i gotowych płytek rozszerzeń

Przez: Stephen Evanczuk

Przekazane przez: Północnoamerykańscy redaktorzy DigiKey

Popyt na inteligentne produkty połączone daje szerokie możliwości deweloperom, którzy są w stanie szybko przekształcić koncepcje w działające zastosowania Internetu rzeczy (IoT). Dostępność energooszczędnych procesorów, opcji łączności bezprzewodowej i szerokiej gamy sprzętowych urządzeń peryferyjnych stanowi solidną podstawę do wdrażania odpowiednich, gotowych do produkcji projektów o niskim poborze mocy.

Jednak na wczesnym etapie definiowania produktu deweloperzy potrzebują elastycznej platformy rozwojowej do tworzenia szybkich prototypów w oparciu o tę samą klasę procesorów, podsystemów łączności i urządzeń peryferyjnych. Możliwości szybkiego budowania działających prototypów i łatwego dodawania funkcji są niezbędne dla dostarczania wczesnych koncepcji i wspierania rozwoju oprogramowania na zamówienie.

Niniejszy artykuł pokazuje, w jaki sposób deweloperzy mogą korzystać ze sprzętu i oprogramowania firmy Silicon Labs do szybkiego budowania wyspecjalizowanych, energooszczędnych prototypów połączonych urządzeń Internetu rzeczy (IoT) przy użyciu szerokiej gamy łatwo dostępnych, gotowych płytek rozszerzeń.

Możliwość szybkiego prototypowania

Badając nowe możliwości dla zasilanych bateryjnie bezprzewodowych urządzeń Internetu rzeczy (IoT), deweloperzy mogą ugrzęznąć w niuansach związanych z tworzeniem działającej platformy rozwojowej. Dzięki zintegrowanym podsystemom zaawansowane układy SoC (system-on-chip) mogą stanowić rdzeń takiej platformy, ale deweloperzy nadal muszą zbudować wokół nich kompletny system.

Aby zbudować odpowiednią platformę rozwojową dla tych urządzeń, deweloperzy muszą nie tylko spełnić podstawowe wymagania dotyczące solidnej wydajności i dłuższej żywotności baterii, ale także muszą zapewnić elastyczność, aby sprostać specyficznym wymaganiom poszczególnych zastosowań. Zestaw badawczy BGM220-EK4314A firmy Silicon Labs spełnia tę kombinację potrzeb, pozwalając deweloperom skupić się na szybkim prototypowaniu nowych koncepcji projektowych, zamiast zajmować się szczegółami związanymi z budowaniem własnej platformy rozwojowej.

Elastyczna i szybka platforma rozwojowa

Oferując niedrogą platformę do tworzenia rozwiązań opartych na technologii Bluetooth, zestaw badawczy BGM220-EK4314A łączy w sobie moduł BGM220P Wireless Gecko firmy SiLabs (BGM220PC22HNA), wbudowany debuger SEGGER J-Link, przycisk, diodę elektroluminescencyjną (LED) i wiele opcji rozszerzeń (ilustracja 1).

Wygląd zestawu badawczego SiLabs BGM220-EK4314AIlustracja 1: zestaw badawczy BGM220-EK4314A firmy SiLabs zapewnia połączenie wydajności przetwarzania, zarządzania energią i elastyczności konfiguracji potrzebne do szybkiego tworzenia prototypów i oceny różnych konfiguracji sprzętu peryferyjnego. (Źródło ilustracji: Silicon Labs)

Moduł BGM220P służy jako kompletne rozwiązanie dla małych, zasilanych bateryjnie urządzeń Internetu rzeczy (IoT). Jego zintegrowany układ SoC EFR32BG22 Blue Gecko charakteryzuje się bardzo niskim poborem mocy, funkcjami kąta nadejścia (AoA) i kąta wyjścia (AoD) Bluetooth oraz dokładnością lokalizacji poniżej jednego metra - wszystko to jest potrzebne w coraz większej gamie popularnych rozwiązań Bluetooth zawierających znaczniki śledzenia zasobów, inteligentne zamki do drzwi, urządzenia fitness i nie tylko.

Moduł BGM220P może pracować jako niezależny system i zawiera w sobie układ SoC EFR32BG22 z 512kB pamięci flash, 32kB pamięci o dostępie swobodnym (RAM), kryształami wysokiej częstotliwości (HF) i niskiej częstotliwości (LF) (XTAL) oraz dopasowaną ceramiczną antenę sieciową o częstotliwości 2,4Ghz do łączności bezprzewodowej (ilustracja 2).

Diagram modułu BGM220P firmy SiLabsIlustracja 2: moduł BGM220P firmy SiLabs, który może służyć jako samodzielny system, zawiera w sobie układ SoC EFR32BG22 Blue Gecko oraz dodatkowe komponenty potrzebne do wdrożenia urządzenia obsługującego technologię Bluetooth. (Źródło ilustracji: Silicon Labs)

Omawiany moduł może służyć jako samodzielny host dla niewielkich projektów Internetu rzeczy (IoT), ale także jako koprocesor sieciowy (NCP) dla procesora hosta podłączonego przez interfejs UART modułu. Zintegrowany stos Bluetooth realizuje usługi bezprzewodowe dla aplikacji działających na module w projektach autonomicznych lub przetwarza polecenia otrzymane z hosta podczas pracy w projektach NCP.

Energooszczędny bezprzewodowy układ SoC

Bezprzewodowy układ SoC Bluetooth modułu BGM220P EFR32BG22 łączy w sobie 32-bitowy rdzeń Arm Cortex-M33, radio 2,4GHz, zabezpieczenia, podsystemy zarządzania energią oraz wiele układów czasowych i opcji interfejsów. Zaprojektowany specjalnie do konstrukcji zasilanych bateryjnie o bardzo niskim poborze mocy układ SoC EFR32BG22 wykorzystuje wiele funkcji zarządzania energią, które umożliwiają działanie baterii pastylkowej nawet przez dziesięć lat.

Przy zasilaniu z jednego zewnętrznego źródła, układ SoC wykorzystuje swoją wewnętrzną jednostkę zarządzania energią do generowania wewnętrznych napięć zasilania. Podczas pracy jednostka zarządzania energią kontroluje przejścia między pięcioma trybami zasilania układu SoC (EM). Każdy tryb dodatkowo zmniejsza zużycie energii, utrzymując coraz mniej aktywnych bloków funkcjonalnych, gdy układ SoC przechodzi z trybu aktywnego (EM0) do trybu uśpienia (EM1), trybu głębokiego uśpienia (EM2), trybu zatrzymania (EM3) lub trybu wyłączenia (EM4) (ilustracja 3).

Diagram układu SoC EFR32BG22 firmy Silicon Labs (kliknij, aby powiększyć)Ilustracja 3: jednostka zarządzania energią układu SoC EFR32BG22 kontroluje przejścia między trybami zasilania EM0, EM1, EM2, EM3 i EM4 (oznaczenia kolorystyczne na dole grafiki). (Źródło ilustracji: Silicon Labs)

W trybie aktywnym (EM0) przy częstotliwości 76,8MHz i napięciu 3V, przy wykorzystaniu wewnętrznej przetwornicy prądu stałego układ SoC pobiera 27μA/MHz. EM0 jest normalnym trybem pracy, jedynym, w którym rdzeń procesora Cortex M33 i wszystkie bloki peryferyjne są dostępne.

W trybie uśpienia (EM1) dostępne są wszystkie urządzenia peryferyjne. Coraz mniejsza ich liczba pozostaje aktywnych, gdy system przechodzi w jeszcze niższe tryby poboru mocy. W trybach niższego poboru mocy redukcja aktywnych zegarów i bloków funkcjonalnych skutkuje znacznie niższymi poziomami zużycia energii:

  • 17μA/MHz w trybie uśpienia (EM1)
  • Tryb głębokiego uśpienia 1,40μA (EM2) z 32kB pamięci RAM i zegarem czasu rzeczywistego (RTC) działającym z LFXO
  • Tryb zatrzymania 1,05μA (EM3) z 8kB pamięci RAM i zegarem czasu rzeczywistego działającym ze zintegrowanego oscylatora rezystorowo-kondensatorowego (RC) o ultraniskiej częstotliwości 1kHz (ULFRCO) układu SoC
  • Tryb wyłączenia 0,17μA (EM4)

Niektóre urządzenia zasilane bateryjnie wymagają czegoś więcej niż tylko obsługi procesora w trybach pracy o niskim poborze mocy. Wiele rozwiązań obsługujących technologię Bluetooth zazwyczaj wykazuje przez dłuższy czas niewielką aktywność lub brak aktywności, ale po jej wznowieniu wymaga krótkich czasów latencji. W rzeczywistości, nawet jeśli urządzenie ma mniejsze wymagania dotyczące latencji, długi czas wybudzania marnuje energię, ponieważ procesor nie wykonuje żadnej użytecznej pracy, jako że kończy proces wybudzania i przechodzi w tryb aktywny (lub kończy proces przechodzenia w tryb niskiego poboru mocy z trybu wyższego poboru mocy).

Ponieważ czas między aktywnymi okresami skraca się, korzystanie z trybu uśpienia o niskim poborze mocy może nawet przynieść efekt przeciwny do zamierzonego, gdy powolne wybudzanie lub czas wejścia w tryb zasilania zużywa więcej energii niż zostałoby zużyte, gdyby procesor pozostawał w trybie wyższej mocy podczas okresu nieaktywności. W rezultacie deweloperzy pracujący nad optymalizacją czasu pracy baterii czasami utrzymują procesor w trybie wyższej mocy niż jest to wymagane z punktu widzenia potrzeb przetwarzania danego zastosowania.

Używając procesora z krótszym czasem wybudzania i wejścia, deweloperzy mogą w pełni wykorzystać tryby niższego poboru mocy procesora. W trybie EM1 układ EFG32BG22 wybudza się w ciągu trzech cykli zegara (1,24µs), a jego czas wejścia wynosi 1,29µs, przy czym wartości te wzrastają do odpowiednio 8,81ms i 9,96µs w trybie EM4 (tabela 1).

Tryb zasilania Wybudzenie (wykonywanie z pamięci RAM/Flash) Wejście (wykonywanie z pamięci Flash)
EM1 3 cykle zegara / 1,24μs 1,29μs
EM2 5,15 / 13,22μs 5,23μs
EM3 5,15 / 13,21μs 5,23μs
EM4 8,81ms (tylko Flash) 9,96μs

Tabela 1: czasy wybudzania i wejścia w tryb zasilania układu SoC EFG32BG22. (Źródło tabeli: Silicon Labs)

Metoda używana do wybudzania procesora po wznowieniu aktywności może również znacząco wpłynąć na żywotność baterii. Chociaż niektóre zastosowania - na przykład przemysłowe - wymagają, aby systemy korzystały z przetwarzania odpytywanego w celu zapewnienia precyzyjnej synchronizacji czasowej, wiele rozwiązań w obszarach konsumenckich wykorzystuje przetwarzanie oparte na zdarzeniach, aby reagować na określone działania. Na przykład stosowanie metod odpytywania dla rozwiązań opartych na zdarzeniach może znacznie obniżyć żywotność baterii, gdy procesor będzie się wielokrotnie niepotrzebnie wybudzać.

Podobnie jak wiele projektów opartych na czujnikach wykorzystuje funkcję wybudzania przy przerwaniu działania, aby uniknąć wielokrotnego wybudzania procesora tylko w celu sprawdzenia aktywności, funkcja wybudzania przy aktywności częstotliwości radiowej wbudowana w podsystem radiowy układu SoC EFG32BG22 umożliwia podobne podejście oparte na przerwaniu działania. Umożliwia to deweloperom utrzymywanie procesora w trybie niskiego zużycia energii do momentu wystąpienia aktywności na częstotliwościach radiowych (RF).

W praktyce deweloperzy przełączają bezprzewodowy układ SoC EFG32BG22 w tryb EM2, EM3 lub EM4 o bardzo niskim poborze mocy i wybudzają układ SoC, polegając na funkcji wybudzania przy aktywności częstotliwości radiowej. Wykrywając energię powyżej określonego progu, funkcja RFSENSE zużywa 131nA. Bardziej selektywny tryb RFSENSE zużywa nieco więcej prądu przy natężeniu 138nA, ale filtruje on przychodzące sygnały o częstotliwości radiowej, aby uniknąć wybudzenia przez szum radiowy, zamiast przez prawidłowy sygnał o częstotliwości radiowej.

W niektórych przypadkach układ SoC EFG32BG22 wcale nie musi wybudzać rdzenia procesora, aby reagować na zdarzenia zewnętrzne: system PRS (Peripheral Reflex System) firmy SiLabs pozwala urządzeniom peryferyjnym reagować na zdarzenia i działanie bez wybudzania rdzenia procesora. Urządzenia peryferyjne mogą komunikować się ze sobą bezpośrednio, a ich funkcje można łączyć, aby uzyskać złożone funkcje. Korzystając z funkcji systemu PRS w trybach o niższym zużyciu energii, deweloperzy mogą znacznie zmniejszyć pobór mocy bez uszczerbku dla krytycznych funkcji, takich jak akwizycja danych z czujników.

Wbudowane debugowanie i łatwa rozbudowa

Wbudowany w płytkę zestawu badawczego BGM220 moduł BGM220P zapewnia pełny zestaw możliwości zarządzania energią i przetwarzania układu SoC EFR32BG22 przy pracy nad zasilanymi bateryjnie urządzeniami Bluetooth. Inne funkcje płytki pomagają przyspieszyć proces rozwoju, gdy istnieje potrzeba szybkiego zbudowania prototypów w celu zbadania nowych koncepcji projektowych.

Wbudowany debugger SEGGER firmy J-Link jest dostępny za pośrednictwem złącza Micro-B USB płytki i umożliwia pobieranie oraz debugowanie kodu, a także tworzy wirtualny port COM umożliwiający dostęp do konsoli hosta. Debuger obsługuje również funkcję interfejsu śledzenia pakietów (PTI) SiLabs do analizowania pakietów przesyłanych lub odbieranych przez sieć bezprzewodową.

W przypadku szybkiego prototypowania dostępność wielu opcji rozbudowy zapewnia elastyczność w odkrywaniu nowych pomysłów projektowych, które wymagają różnych kombinacji czujników, aktuatorów, opcji łączności i innych peryferiów. Czerpiąc z szerokiej gamy dostępnych płytek rozszerzeń mikroBUS i sprzętu systemu łącznościowego Qwiic od wielu dostawców, deweloperzy mogą szybko skonfigurować platformę rozwojową dla każdego zastosowania.

Płytka mikroBUS podłączona do dedykowanego gniazda łączy się z modułem BGM220P przez interfejsy I2C, SPI lub UART. Złącze Qwiic zapewnia interfejs I2C systemu Qwiic do podłączania jednej lub kilku płytek Qwiic na odległość do około 1,2m. W przypadku połączeń na większe odległości deweloperzy mogą użyć płytki QwiicBus EndPoint SparkFun (COM-16988), która wykorzystuje sygnalizację różnicową do utrzymania integralności sygnału I2C na odległości do około 30,5m.

Szybki rozwój zastosowań

Firma SiLabs stosuje koncepcję szybkiej ekspansji do opracowywania oprogramowania zastosowań. Wraz z pakietami do obsługi płytek, sterownikami, bibliotekami i listwami do rozwoju niestandardowych rozwiązań, firma oferuje kilka przykładowych aplikacji zawartych w środowisku deweloperskim Simplicity Studio, a także dodatkowe projekty dostępne w repozytoriach GitHub firmy SiLabs. W rzeczywistości deweloperzy mogą rozpocząć badania nad rozwojem zastosowań czujników za pomocą dołączonej przykładowej aplikacji do pomiaru temperatury, która jako źródło danych wykorzystuje wewnętrzny czujnik temperatury układu SoC EFR32BG22.

Ta zbudowana wokół standardowej usługi Bluetooth Health Temperature aplikacja do pomiaru temperatury stanowi demonstrację przebiegu przetwarzania w ogólnej aplikacji Internetu rzeczy (IoT) z obsługą technologii Bluetooth zbudowaną na architekturze oprogramowania SiLabs. Aplikacja ta wywołuje szereg procedur inicjujących dla usług systemowych i usług aplikacji, które konfigurują programy do obsługi przerwań i wywołania zwrotne. Po zakończeniu inicjalizacji aplikacja przechodzi w niekończącą się pętlę oczekiwania na zdarzenia (listing 1).

Kopiuj
int main(void)
{
  // Initialize Silicon Labs device, system, service(s) and protocol stack(s).
  // Note that if the kernel is present, processing task(s) will be created by
  // this call.
  sl_system_init();



  // Initialize the application. For example, create periodic timer(s) or
  // task(s) if the kernel is present.
  app_init();



#if defined(SL_CATALOG_KERNEL_PRESENT)
  // Start the kernel. Task(s) created in app_init() will start running.
  sl_system_kernel_start();
#else // SL_CATALOG_KERNEL_PRESENT
  while (1) {
    // Do not remove this call: Silicon Labs components process action routine
    // must be called from the super loop.
    sl_system_process_action();



    // Application process.
    app_process_action();



#if defined(SL_CATALOG_POWER_MANAGER_PRESENT)
    // Let the CPU go to sleep if the system allows it.
    sl_power_manager_sleep();
#endif
  }
#endif // SL_CATALOG_KERNEL_PRESENT
}
Listing 1: przykładowe zastosowania Bluetooth firmy SiLabs korzystają z ogólnej struktury wykonawczej, w której nieskończona pętla umożliwia wywołaniom zwrotnym i programom obsługi zdarzeń przetwarzanie działań systemu i aplikacji po inicjalizacji. (Źródło kodu: Silicon Labs)

W tej aplikacji, gdy układ czasowy ustawiony podczas inicjalizacji odlicza czas, powiązana procedura wywołania zwrotnego wykonuje pomiar temperatury. Po tym zbudowaniu aplikacji i sflashowaniu płytki deweloperzy mogą wykorzystać aplikację EFR Connect firmy SiLabs - ogólną aplikację mobilną Bluetooth, która działa ze wszystkimi zestawami i urządzeniami Bluetooth firmy Silicon Labs. Oprócz zapewniania struktury wspomagającej dla aplikacji niestandardowych, aplikacja ta pomaga w rozwoju, udostępniając widok obsługiwanych charakterystyk związanych z usługą Bluetooth, taką jak usługa Bluetooth Health Thermometer używana w omawianej przykładowej aplikacji (ilustracja 4).

Wygląd aplikacji EFR Connect firmy SiLabsIlustracja 4: aplikacja EFR Connect firmy SiLabs demonstruje cechy charakterystyczne usług Bluetooth używanych w danej aplikacji, nie tylko przyspieszając tworzenie prototypów, ale także zapewniając strukturę do tworzenia niestandardowych aplikacji. (Źródło ilustracji: Silicon Labs)

Simplicity Studio pozwala deweloperom importować wiele różnych przykładów aplikacji Bluetooth, które obrazują różne scenariusze użycia, w tym projekty zbudowane z płytek Qwiic lub mikroBUS, osobno lub łącznie. Przykładem może być aplikacja, która demonstruje wykorzystanie standardowych usług Bluetooth do pomiaru częstości akcji serca (HR) i pulsoksymetru (SpO2) w połączeniu z płytką Heart Rate 2 Click mikroBUS MIKROE-4037 firmy Mikroelektronika, z bioczujnikiem MAX86161 firmy Maxim Integrated. Bioczujnik MAX86161 stanowi kompletny podsystem o niskim poborze mocy, który jest w stanie przesłać do procesora głównego podłączonego przez interfejs I2C dokładne pomiary HR i SpO2. (Więcej informacji na temat korzystania z bioczujnika MAX86161 w artykule Budowa całkowicie bezprzewodowego urządzenia głosowego hearable fitness - część 1: pomiar częstości akcji serca i SpO2).

Ze względu na zapotrzebowanie na dodatkowy sterownik i bardziej wymagający algorytm przetwarzania niż w przypadku aplikacji do pomiaru temperatury, aplikacja ta demonstruje bardziej złożony przykład architektury aplikacji oprogramowania urządzenia Internetu rzeczy (IoT) (ilustracja 5).

Diagram aplikacji HR/SpO2Ilustracja 5: przykładowe projekty, takie jak aplikacja HR/SpO2, pomagają przyspieszyć rozwój prototypów, jednocześnie demonstrując typowy przebieg procesu dla aplikacji z czujnikami Bluetooth o niskim poborze mocy. (Źródło ilustracji: Silicon Labs)

Podobnie jak wspomniana powyżej aplikacja do pomiaru temperatury, również ta aplikacja opiera się na szeregu procedur inicjalizacji w celu skonfigurowania systemu i usług. Tam, gdzie procedura app_process_action jest pusta w aplikacji temperatury, ta aplikacja dodaje wywołanie do procedury hrm_loop w app_process_action. Powoduje to wywołanie funkcji hrm_loop przy każdym przejściu przez nieskończoną pętlę najwyższego poziomu pokazaną wcześniej w listingu 1. Ponadto do okresowej aktualizacji danych HR i SpO2 używany jest programowy układ czasowy.

Z kolei procedura hrm_loop wywołuje proces maxm86161_hrm_process, który pobiera próbki z kolejki obsługiwanej przez funkcje pomocnicze i przekazuje je do procedury procesu próbki. To z kolei wywołuje parę procedur, maxm86161_hrm_frame_process i maxm86161_hrm_spo2_frame_process, które wykonują algorytmy sprawdzające i generujące odpowiednio wyniki HR i SpO2. Deweloperzy mogą przeglądać wyniki wraz z innymi charakterystykami usług za pomocą wspomnianej wcześniej aplikacji EFR Connect.

Inna przykładowa aplikacja pokazuje, w jaki sposób deweloperzy mogą bazować na złożonej aplikacji, takiej jak ta aplikacja HR/SpO2, rozszerzając własną platformę sprzętową. Dzięki zastosowaniu płytki z zestawu badawczego BGM220-EK4314A i ekosystemu oprogramowania SiLabs, bazowanie na istniejącym sprzęcie i oprogramowaniu jest stosunkowo proste. Firma SiLabs demonstruje to podejście za pomocą przykładowej aplikacji, w której do platformy sprzętowej/programowej używanej w powyższej aplikacji HR/SpO2 dodano wyświetlacz OLED. W tym przykładzie płytka rozszerzeń Qwiic z wyświetlaczem SparkFun OLED (LCD-14532) jest podłączona do złącza Qwiic płytki, natomiast płytka rozszerzeń Heart Rate 2 Click firmy MikroElektronika pozostaje na miejscu z poprzedniego przykładowego zastosowania HR/SpO2 (ilustracja 6).

Wygląd płytki z zestawu badawczego BGM220-EK4314A firmy Silicon Labs z wyświetlaczem OLEDIlustracja 6: deweloperzy mogą szybko dodać funkcjonalność do istniejącego projektu zbudowanego na płytce z zestawu badawczego BGM220-EK4314A - co pokazano tutaj na przykładzie wyświetlacza OLED dodawanego do istniejącego prototypu HR/SpO2. (Źródło ilustracji: Silicon Labs)

Poza dodaniem sterowników i usług wsparcia dla płytki OLED, aplikacja pozostaje w dużej mierze taka sama dla tej rozszerzonej wersji aplikacji HR/SpO2. Wspomniany wcześniej programowy układ czasowy dla aplikacji HR/SpO2 dodaje do funkcji hrm_update_display wywołanie, co powoduje wyświetlenie danych HR i SpO2 (listing 2).

Kopiuj
    /* Software Timer event */
    case sl_bt_evt_system_soft_timer_id:
      /* Check which software timer handle is in question */
      if (evt->data.evt_system_soft_timer.handle == HEART_RATE_TIMER) {
        heart_rate_send_new_data(connection_handle);
        break;
      }
 
      if (evt->data.evt_system_soft_timer.handle == PULSE_OXIMETER_TIMER) {
        pulse_oximeter_send_new_data(connection_handle);
        break;
      }
 
      if (evt->data.evt_system_soft_timer.handle == DISPLAY_TIMER) {
        hrm_update_display();
        break;
      }
      break;
Listing 2: korzystając z zestawu i ekosystemu oprogramowania, deweloperzy mogą dodać funkcję wyświetlacza do istniejącej aplikacji HR/SpO2 poprzez podłączenie płytki wyświetlacza i wprowadzenie minimalnych zmian w oprogramowaniu poza dodaniem wywołania funkcji, hrm_update_display, do programu obsługi układu czasowego wcześniejszej aplikacji. (Źródło kodu: Silicon Labs)

Takie podejście do sprzętu i oprogramowania zapewnia możliwości rozbudowy i pozwala deweloperom na szybkie tworzenie działających zastosowań IoT. Ponieważ zarówno sprzęt, jak i oprogramowanie można łatwo dodawać lub usuwać, deweloperzy mogą łatwiej badać nowe rozwiązania projektowe i oceniać alternatywne konfiguracje.

Podsumowanie

Zasilane bateryjnie urządzenia IoT z obsługą Bluetooth stanowią serce popularnych zastosowań i zapewniają kluczową możliwość zaspokojenia ciągłego zapotrzebowania na większą funkcjonalność i dłuższą żywotność. Skuteczne spełnienie tych sprzecznych oczekiwań wymaga od deweloperów umiejętności szybkiego badania nowych projektów i oceny alternatywnych koncepcji projektowych. Korzystając z zestawu rozwojowego i powiązanego oprogramowania firmy Silicon Labs, deweloperzy mogą szybko budować prototypy, dodając i usuwając sprzęt według potrzeb, aby spełnić określone wymagania zastosowania.

DigiKey logo

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of DigiKey or official policies of DigiKey.

Informacje o autorze

Image of Stephen Evanczuk

Stephen Evanczuk

Stephen Evanczuk has more than 20 years of experience writing for and about the electronics industry on a wide range of topics including hardware, software, systems, and applications including the IoT. He received his Ph.D. in neuroscience on neuronal networks and worked in the aerospace industry on massively distributed secure systems and algorithm acceleration methods. Currently, when he's not writing articles on technology and engineering, he's working on applications of deep learning to recognition and recommendation systems.

Informacje o wydawcy

Północnoamerykańscy redaktorzy DigiKey