Jakie czynniki należy wziąć pod uwagę przy wyborze zintegrowanego MCU Wi-Fi dla urządzenia brzegowego o niskiej mocy?

Motywacja do tego pytania wynika z faktu, że jakiś czas temu stworzyłem proste urządzenie brzegowe IoT typu proof of concept (PoC) przy użyciu mikrokontrolera i procesora sieciowego CC3100 Wifi . Jednym z problemów związanych z tym prototypem było to, że konfiguracja wymagała znacznej mocy. W ten sposób nie był w stanie przezwyciężyć zalet istniejącego urządzenia o niższej mocy, które może trwać od ponad 2 do 10 lat, w zależności od wyboru baterii i częstotliwości użytkowania.

W zależności od zastosowania obecny produkt wykorzystuje akumulator 6 V DC o pojemności od 1400 mAh do 2400 mAh. Urządzenie ma element wykrywający małą moc i mechanizm uruchamiający. Ładowność najprawdopodobniej wyniesie około 100 bajtów. Częstotliwość komunikacji będzie co około dwie minuty podczas szczytowej aktywności. Dzięki postępom w zakresie Internetu Rzeczy i wymaganiom rynku ten PoC zyskał trochę uwagi.

Zgodnie z sugestią kilku dostawców platform IOT patrzę na bezprzewodowy MCU CC3200 z Texas Instrument przede wszystkim dlatego, że jest następcą CC3100. Gdy system nie jest używany, na poziomie systemu można całkowicie wyłączyć zasilanie CC3100. Jest to znacząca zaleta dla niskiej mocy na poziomie systemu. Po wykryciu aktywności element wykrywający budzi mikrokontroler poprzez przerwanie. Istnieją inne zintegrowane MCU Wi-Fi, takie jak ESP8266 , BCM43362 , ATWINC1500B , 88MC200 i wiele innych. Korzystam z ULPBench Scores, aby przeprowadzić analizę pierwszego rzędu mikrokontrolerów małej mocy, a następnie analizę taką jak opisana wJak wybrać mikrokontroler do aplikacji o niskiej mocy? aby pomóc wybrać mikrokontroler o niskiej mocy. Użyłem parametrów takich jak pobór prądu w trybie aktywnym na częstotliwość i pobór prądu w różnych trybach niskiej mocy, aby dokonać świadomego wyboru. Więc w celu utrzymania opcji niskiego poboru mocy i dodania możliwości IoT, jakie krytyczne parametry (mogą być związane z komunikacją bezprzewodową), na które powinienem zwrócić szczególną uwagę przy wyborze zintegrowanego MCU Wi-Fi?

Bibliografia:

• SimpleLink ™ CC3100 / CC3200 Wi-Fi Internet na chipie Podsystem sieci Zarządzanie energią
• Jak wybrać moduł Wi-Fi?

Ponieważ Twoim najważniejszym ograniczeniem jest niski pobór mocy, myślę, że już zwracasz uwagę na 2 najważniejsze parametry: pobór prądu w trybie aktywnym na częstotliwość i pobór prądu w różnych trybach niskiej mocy.

Utrzymanie komunikacji jako stałej (tj. Ten sam protokół komunikacyjny i częstotliwość EM), a następnie wybranie najlepszego MCU jest kwestią prawidłowego zsumowania tych dwóch parametrów. A oto jak stworzyłem jedną wartość liczbową, którą mógłbym porównać we wszystkich opcjach:

1. Utwórz prognozowany profil aktywności dla urządzenia (jak często się komunikuje i na jak długo) w danym okresie - powiedzmy w ciągu tygodnia.
2. Oblicz aktualny pobór przy częstotliwości EM stosowanej dla czasów w wybranym okresie, gdy komunikacja jest aktywna - tj. Pobór 10 uA (częstotliwość 900 MHz) przez 2 s przy 1000 x aktywności w tygodniu oznaczałoby 20 000 uA-s / tydzień.
3. Obliczyć bieżący pobór dla czasów w wybranym okresie, gdy urządzenie znajduje się w domyślnym trybie niskiego poboru mocy - tj. Pobór 10 nA w [7 dni x 24 godziny x 60 minut x 60 s - aktywność 1000 x 2 s] oznaczałaby 6028 uA -s / tydzień.
4. Dodanie 2 daje prąd w wysokości 26 028 uA-s / tydzień dla tego hipotetycznego MCU.
5. To obliczone tygodniowe bieżące losowanie można następnie porównać dla wszystkich MCU.

Wiem, że jest to bardzo uproszczony sposób patrzenia na aktywność MCU - tj. Właśnie rozważone 2 stany: bezczynny i komunikujący się ... ale wierzę, że wszystkie inne stany będą miały proporcjonalny i niewielki wkład do jednego z nich 2. Na przykład zużycie energii dla obliczeń (cykli instrukcji) można łączyć ze stanem komunikacyjnym i najprawdopodobniej będą one miały bardzo mały udział pod względem mocy w porównaniu z podsystemem komunikacyjnym. Chodzi o to, że spojrzenie na te 2 stany jest wystarczające dla procesu selekcji.

Nie ma magicznej kuli, więc myślę, że rada będzie boleśnie oczywista. Najpierw zacznij odrywać od największych odbiorców energii.

Czy naprawdę wyłączasz wszystkie układy i obwody, gdy są bezczynne? Wiem, że niektóre deski i tarcze hobbystyczne nie zawsze całkowicie wyłączają wszystko, czego można oczekiwać.

Jeśli jest to siłownik, czy możesz użyć lżejszego silnika lub zmniejszyć tarcie w układzie napędowym? Większy obraz, czy możesz przeprojektować napędzane obciążenie, aby miało mniejszą masę lub aby było lepiej zrównoważone?

Jeśli jest to komunikacja, zacznij od częstotliwości komunikacji. Jakie czynniki wpłynęły na istniejącą decyzję „dwuminutową”? Czy możesz poświęcić się, by rzadziej się komunikować? Czy możesz przejść na model podrzędny pubu i odpowiedzieć mniejszą liczbą bajtów, gdy pozwalają na to warunki?

Ponownie sprawdź protokół. Każdy wygolony bajt stanowi oszczędność 1% bieżącego budżetu mocy RF. Wysyłasz jakieś wartości logiczne? Użyj flag bitowych, a nie ASCII „Y” lub „N”. Upewnij się, że używasz najmniejszego możliwego kontenera - nie przesyłaj 16-bitowej liczby całkowitej, jeśli liczba ma dopuszczalny zakres tylko 0–99. Większość protokołów zasilanych bateryjnie stara się je jak najmocniej wycisnąć; np. jeśli raportujesz o tablicy elementów 5x5, adres musi być tylko polem 5-bitowym, a nie 8-bitowym. Wykorzystanie cykli procesora do logiki związanej z kompresją skutkuje znacznie niższym całkowitym poborem mocy niż przesyłanie niepotrzebnych bitów.

Jeśli dużym poborem mocy jest procesor (wątpliwy, ale możliwy), czy możesz wykonywać sztuczki, takie jak wstępnie obliczone tabele wyszukiwania, a nawet odciążyć część pracy do usługi zdalnej?

Nie ma jednego ostatecznego zestawu parametrów, których można by użyć do wyboru takiego zintegrowanego urządzenia, ale myślę, że jako pierwsze przybliżenie, nowo zaprojektowane urządzenia mogą być znacznie lepsze niż coś sprzed kilku lat. Chociaż koncepcja nie jest nowa, ten poziom integracji i agresywne cele władzy sprawiają, że rynek ten ewoluuje.

Zwróć szczególną uwagę na oferowane stany mocy, patrząc z perspektywy całego systemu (regulatory, oscylatory, kondycjonowanie sygnału czujnika). Jest możliwe (mało prawdopodobne), że twój 2-minutowy stan aktywny skorzysta z mniej głębokiego snu niż normalny stan operacyjny.

Stan użytkowy o najniższej mocy powinien odpowiadać za większość zużycia energii. Dokładnie to, jak to wygląda, zależy od rzeczy, takich jak to, czy możesz działać bezpośrednio z zasilania bez regulatora, minimalnego napięcia roboczego itp.

Jeśli chodzi o stan aktywny, weź pod uwagę najwięcej pamięci RAM lub intensywne operacje obliczeniowe i przetestuj je, używając najbliższych równoważnych dostępnych części (w oparciu o procesor, szybkość i architekturę pamięci). W twojej aplikacji wydaje się, że przygotowanie ładunku i szyfrowania może być dość trywialne, ale ogólnie nie jest to oczywiste założenie. Stany przechowywania mogą umożliwiać integrację czujnika bez np. Zapisywania / przywracania stanu.

Dopasuj szybkość zegara i architekturę do wymagań aplikacji. W stanie uśpienia oszczędzasz moc upływu. Niższe docelowe prędkości zegara dla urządzenia mogą oznaczać, że musi on pozostawać w stanie aktywnym przez dłuższy czas, ale także skutkować konstrukcją zapewniającą lepszą wydajność upływu (a także może niższe napięcie robocze).

Nie poznasz absolutnie najlepszego projektu, dopóki nie wykonasz iteracji więcej niż jednego projektu - jest po prostu zbyt wiele parametrów (i do tego czasu twój produkt zacznie się starzeć), więc aspekty wyższego poziomu przepływu projektu są nadal ważny. Jeśli możesz zoptymalizować architekturę, aby zmniejszyć liczbę przypadków budzenia o 5%, powinno to być zauważalne w przypadku czasu pracy baterii.