הוספת חיבוריות Wi-Fi רצופה מבלי להתפשר על חיי הסוללה

ה- Wi-Fi נותרה דרישת החיבוריות העיקרית עבור התקני אינטרנט של דברים (IoT) רבים הודות לרוחב-הפס הרחב והנוכחות בכל מקום שהוא מציע. עם זאת, עבור התקנים לבישים והתקני IoT מוזני-סוללות אחרים, דרישות ההספק של פתרונות Wi-Fi קונבנציונליים הפכו את חיבוריות ה- Wi-Fi הרצופה ללא-מעשית, ולרוב המפתחים נדרשים להתפשר על היבט כלשהו של פונקציונליות ההתקן, הביצועים או חיי הסוללה.

בעוד שתכנון פיתרון Wi-Fi מותאם-במיוחד כדי למטב אותו עבור הספק נמוך עשוי להיות אופציה עבור צוותים מסוימים, זו עשויה להיות התחייבות יקרה וגוזלת זמן, במיוחד בהתחשב במחסור במתכנני RF מיומנים. נדרש פתרון שלם יותר ההופך את ה- Wi-Fi הרצוף למעשי עבור התקני IoT בהספק-נמוך.

מאמר זה מראה כיצד מפתחים יכולים לממש חיבוריות Wi-Fi רצופה באמצעות מאפייני הספק נמוך המובנים בהתקן מערכת-על-שבב (SoC) לאלחוט מבית Dialog Semiconductor.

האתגרים של תמיכה בחיבוריות Wi-Fi עבור התקנים ניידים

ה- Wi-Fi מספק בדרך כלל את השילוב של נוכחות בכל מקום ומאפייני ביצועים הנדרשים במגוון רחב של יישומי IoT הבנויים סביב מוצרים ניידים אישיים, התקני בית חכם ומערכות אוטומציה בבניינים, אם להזכיר כמה. עם זאת, בעבר צריכת הזרם הגבוהה יחסית של תת-מערכות Wi-Fi אילצה את המפתחים להתפשר על חיי הסוללה או על עוצמת האות בהתקני IoT מוזני-סוללות.

דרישות ההספק הגבוה של פיתרונות ה- Wi-Fi המסורתיים מביאות אתגרים נוספים למפתחי ה- IoT. לדוגמה, הדרישות עבור הן חיבוריות Wi-Fi והן חיי סוללה ארוכים יכולות להוסיף לגודל התכן ולמורכבותו כדי שיתאים לסוללות גדולות יותר. עבור התקנים לבישים או התקני IoT רבים בהם סוללות גדולות יותר אינן אופציה, הניסיון להאריך את חיי הסוללה על ידי הפחתת עוצמת אותות ה- Wi-Fi (וצריכת ההספק הנלווית) אינו בר-ביצוע.

לצד נושאים אלו, מפתחי ה- IoT מתמודדים עם מגבלות מעשיות של סביבת אותות Wi-Fi טיפוסית שבה עוצמת האותות יכולה להשתנות באופן משמעותי עקב הפרעות רבות-נתיבים ומאפייני אותות אחרים בתדר רדיו (RF). ביישומים כמו מחשבים ניידים, הצרכן יכול פשוט להעביר מחשב נייד למיקום אחר עם אות Wi-Fi טוב יותר. לעומת זאת, מנעול חכם או מכשיר ביתי צריכים לשמור על חיבוריות אמינה וביצועים חסונים, ללא תלות במקום התקנתו.

כדי לתמוך הן בחיי סוללה ארוכים והן בעוצמת האותות של Wi-Fi חסון, המפתחים מנצלים בדרך כלל את אופני השינה עם צריכת הספק נמוכה הזמינים במעבדים המתקדמים ביותר, התקני רדיו ורכיבי חומרה מורכבים אחרים. על ידי מקסום משך הזמן שהתקנים צמאי-הספק פועלים באופני ההספק הנמוך בהתאמה שלהם, המפתחים יכולים לממש תכנים המאריכים את חיי הסוללה של תכני המערכות שלהם, בדרך כלל עם מעט השפעה על פונקציונליות המערכת. בתכנים אלו, קוצב-זמן בהספק-נמוך מעיר באופן מחזורי את המערכת לזמן קצר כדי לקרוא חיישנים ולשדר אלחוטית נתוני חיישנים לפני שהוא חוזר לאופן שינה.

אולם עבור חלק מיישומי ה- IoT, התקן ה- IoT צריך לשמור על חיבור רצוף לרשת ה- Wi-Fi כדי להבטיח מענה מהיר לפקודות המשתמשים הנשלחות באמצעות אפליקציות סלולריות, תוכנות שולחן-עבודה או אפילו התקנים אחרים. לדוגמה, מנעולים חכמים, מנורות ומתגים שנמצאים בבתים חכמים צריכים להישאר מחוברים כדי לספק מענה מיידי לפקודות המשתמש. ההמתנה להתקן מבוסס-קוצב-זמן להתעורר מתי שהוא, לגלות את הפקודה ולבסוף לפתוח דלת או להדליק אור פשוט לא יהיה מקובל על המשתמשים.

ה- SoC‏ DA16200‏ מבית Dialog Semiconductor ומודולים נלווים מספקים פתרון יעיל בהספק-נמוך המסוגל לתמוך בדרישות עבור הן Wi-Fi רצוף והן חיי סוללה ארוכים.

מימוש חיבוריות Wi-Fi עם SoC‏ לאלחוט

תוכנן במיוחד עבור תכני IoT מוזני-סוללות, ה- DA16200 SoC משלב Arm® Cortex®-M4F עם מערכת רדיו Wi-Fi שלמה המריצה חבילת תוכנת רשת שלמה, וחוסך את הצורך במעבד רשת חיצוני או במעבד מארח המספק פונקציונליות של חבילת תוכנה. ביחד עם תת-מערכת הרדיו, ההתקן משלב מערך שלם של בלוקים פונקציונליים וממשקים הנדרשים בדרך כלל בתכני IoT (איור 1).

איור 1‏: ה- DA16200 SoC מבית Dialog Semiconductor מספק פיתרון Wi-Fi שלם המסוגל להעניק חיבוריות Wi-Fi רצופה תוך צריכת זרם מינימלית. (מקור התמונה: Dialog Semiconductor)

ביחד עם מספר ממשקים סטנדרטיים, ההתקן כולל ממיר אנלוגי-לדיגיטלי (ADC‏) אוגר קירוב-עוקב (Successive Approximation‏) (SAR‏) Bit‏-12‏ 4 ערוצים כדי לתמוך קליטת אותות אנלוגיים.

להרצת האפליקציה, ל- DA16200 יש מספר זיכרונות פנימיים הכוללים:

• זיכרון קריאה-בלבד עבור טוען ה- Boot‏, Kernel‏ המערכת, חבילת תוכנת רשת ומנהלי-התקנים.
• זיכרון גישה אקראית סטטי (SRAM‏) עבור נתוני התוכנית. קוד התוכנית מורץ-במקום (XIP) בזיכרון Flash טורי הנגיש באמצעות ממשק זיכרון Flash טורי חיצוני של ההתקן.
• זיכרון ניתן-לתכנות חד-פעמי (OTP) משמש לאחסון נתוני ההתקן כמו גם מפתחות הצפנה וטוען Boot‏ מאובטח. נתוני OTP נותרים מאובטחים מכיוון שניתן לגשת אליהם רק דרך בקר ה- OTP, ואחרת הם נותרים בלתי-נראים לגישה רגילה לנתונים דרך אפיק המערכת.

כדי לעזור למפתחים לענות על הביקוש הגובר לאבטחת התקנים מחוברים, ה- DA16200 SoC משלב מערך רחב של מנגנוני אבטחה, כולל מנוע הצפנה עבור תקן Advanced Encryption Standard‏ AES)‏, Secure Hash Algorithms‏ (SHA), והצפנות אחרות כמו גם תמיכה בפרוטוקול Transport Layer Security‏ (TLS). ההתקן כולל גם את אבטחת הקניין הרוחני (IP‏) Arm TrustZone CryptoCell-312‏ (CC312‏). מתוכנן עבור התקני הספק-נמוך, ה- CC312‏ תומך ב- Boot מאובטח ומאפשר Root of Trust‏ עבור יישומים מאובטחים.

ההתקן מפשט את החיבוריות האלחוטית הודות לבלוק RF‏ מקיף. ביחד עם השכבה המובנית של Media Access Control‏ (MAC‏) 802.11 והשכבה הפיזית (PHY‏) המובנית 802.11b/g/n, תת-מערכת הרדיו כוללת מקמ"ש על-השבב עם מגברי הספק (PA) משולבים ומגברים עם רעש נמוך (LNA) החוסכים את הצורך ברכיבים אקטיביים חיצוניים. בזמן הפעולה, מעבד ARM Cortex-M4F של ה- DA16200 מבצע את חבילת התוכנה המשובצת Transmission Control Protocol/Internet Protocol‏ (TCP/IP‏) כדי להוריד את עומס פעולות החיבוריות מהמעבד המארח של המערכת.

כדי לספק כוח לבלוקים השונים, כולל בלוק ה- RF, ה- DA16200 SoC משלב ממיר DC-DC, מייצבים עם מפל-מתח נמוך (LDO) ומתגי הספק. מנוהל על ידי בלוק שעון זמן-אמת (RTC) של ההתקן, הממיר ומייצבי ה- LDO יוצרים את כל פסי הספקת-הכוח מסוללת VBAT‏ יחידה. בעוד שממיר ה- DC-DC מייצר 1.4 וולט עבור בלוק ה- RF וה- LDO הדיגיטלי מתוך VBAT, ה- I/O LDO מייצר את ה- 1.8 וולט הדרוש עבור זיכרון ה- Flash‏ החיצוני וה- General Purpose I/O‏ (GPIO) של ההתקן (איור 2).

איור 2‏: יחידת ניהול הספקת-הכוח של ה- DA16200 SoC מבקרת את רכיבי הספקת-הכוח המשולבים של ההתקן המספקים מתח לקבוצות הספקת-הכוח הנפרדות. (מקור התמונה: Dialog Semiconductor)

יחידת ניהול הספקת-הכוח של ה- DA16200 SoC מבקרת את הספקת-הכוח לקבוצות נפרדות אלו כחלק מהפונקציה שלה של ניהול שלושת אופני ההספק-הנמוך (שינה):

• אופן שינה 1 מציע את הפעולה בהספק הנמוך ביותר של 0.2 מיקרו-אמפר (μA): באופן זה, ההתקן לרוב מושבת אך מתעורר בתוך 150 מילי-שניות (ms‏) בתגובה לטריגר חיצוני המועבר לשני פיני היקיצה של ה- SoC או לאחד ממספר I/O דיגיטליים, או כאשר אות כניסה אנלוגי עולה על סף מוגדר-מראש.
• אופן שינה 2 צורך μA‏ 1.8 בלבד תוך שמירה על פונקציונליות RTC: באופן זה, ה- SoC מתעורר בפחות מ- ms‏ 100‏ בתגובה לאירועי יקיצה חיצוניים או בסיום מחזור של קוצב-זמן פנימי מתוכנת.
• אופן שינה 3 מספק אופן Wi-Fi ייחודי המחובר ברציפות תוך צריכת זרם מינימלי וויכולת יקיצה תוך פחות מ- ms‏ 2‏ לאחר גילוי של מנות (Packets‏) נתוני Wi-Fi נכנסות: כמתואר להלן, שימוש באופן שינה 3 עם פונקציונליות TCP Keep Alive‏ קונבנציונלית מספק את הבסיס עבור מימוש יכולת חיבוריות Wi-Fi רצופה הצורכת זרם ממוצע של פחות מ- μA‏ 50‏.

טכנולוגיית ניהול הספקת-כוח דינמית מאפשרת חיבוריות Wi-Fi רצופה

בבסיס אופני שינה בהספק-נמוך אלו נמצאת טכנולוגיית Dynamic Power Management‏ (DPM) הקניינית מבית Dialog Semiconductor‏ המכבה מיקרו-אלמנטים על השבב שאינם בשימוש, כשהתוצאה היא צריכת הספק מינימלית כאשר ההתקן אינו משדר או קולט נתונים. במהלך פעולות Wi-Fi, ה- DPM מקטינה למינימום את צריכת ההספק במהלך פעולות שידור וקליטה באמצעות אלגוריתמים מתקדמים המעירים את המיקרו-אלמנטים רק כאשר הם ממש נדרשים.

ערכת פיתוח התוכנה DA16200‏ (SDK) מבית Dialog Semiconductor‏ ממצה את פרטי ניהול צריכת ההספק ופעולת ה- DPM באמצעות ממשק תכנות היישומים (API) של ה- DPM Manager‏ שלו. עבור פיתוח תוכנה מותאמת-במיוחד, ה- SDK‏ מעניק גישה לחבילת התוכנה של היישומים והשירותים של ה- DA16200‏ (איור 3).

איור 3‏: ארכיטקטורת התוכנה של ה- DA16200 SoC מספקת מערך שלם של שירותי מערכת ויישומים הדרושים לתמיכה בחיבוריות Wi-Fi סטנדרטית בהתקני IoT‏. (מקור התמונה: Dialog Semiconductor)

מימוש חיבוריות Wi-Fi רצופה משלבת שימוש ב- DPM Manager‏ ובספריית NetX Duo TCP/IP‏. ספריית NetX Duo‏ מספקת את מאפיין TCP Keep Alive‏ השולח מנות (Packets‏) TCP ללא נתונים לנתב ה- Wi-Fi ומבטיח שהנתב ישמור על חיבור Wi-Fi אקטיבי. המפתחים קוראים למאפיין זה פשוט על ידי הגדרת אפשרות TCP Socket‏ הנוכחית (keepalive_enabled) כ- TRUE, ומספקים את מספר השניות (keepalive_timeout) בין מנות Keep Alive‏. ה- NetX Duo משדר אוטומטית את מנות ה- Keep Alive‏ לפי הצורך.

בעוד שמנות ה- Keep Alive‏ שומרות על חיבור הרשת עם נתב או מארח אחר, היכולת של ה- DA16200 להתעורר מאופן שינה 3 נשענת על זיהוי של אלמנטי מידע סטנדרטיים של Traffic Indication Map‏ (TIM) או של Delivery Traffic Indication Map‏(DTIM) המשובצים בחבילות (Frames‏) הניהול של 802.11, ומשמשים כדי להתריע לתחנות הרשת, כדוגמת מערכת מבוססת-DA16200, כי תעבורת רשת זמינה עבורן. כאשר ה- DA16200 מוצב באופן שינה 3, טכנולוגיית ה- DPM של ה- DA16200 מבטיחה שתת-מערכת הרדיו תשתמש בהספק מינימלי בחיפוש אחר אלמנטי TIM/DTIM. כאשר תת-מערכת הרדיו DA16200 מזהה אלמנטים של TIM/DTIM, היא מעירה את ה- SoC להתחיל לעבד תעבורת Wi-Fi רגילה, כמו כל תחנת רשת.

באמצעות ה- DA16200 DPM Manager API, המפתחים צריכים לבצע רק כמה קריאות אינטואיטיביות כדי לממש פונקציונליות זו. לאחר שהגדירו את תצורת ה- DPM הנדרשת, כולל פרמטרים וקריאות-חוזרות, המפתחים משתמשים בקריאות פונקציות DPM Manager API כדי לקרוא ולתקשר אחרת עם ה- DPM Manager‏. הכניסה והיציאה מאופן שינה 3 מטופלת בצורה שקופה על ידי הטכנולוגיה של ה- DA16200 DPM.

יישומי דוגמה הכלולים ב- SDK ממחישים את תבניות התכנון הבסיסיות הדרושות למימוש רצף פעולות זה (רשימת קוד 1).

Copy
#define TCP_CLIENT_KA_DPM_SAMPLE_DEF_KEEPALIVE_TIMEOUT            55
[lines deleted]
void tcp_client_ka_dpm_sample_wakeup_callback()
{
    PRINTF(GREEN_COLOR " [%s] DPM Wakeup\n" CLEAR_COLOR, __func__);
 
    dpm_mng_job_done(); //Done operation
}
[lines deleted]
void tcp_client_ka_dpm_sample_recv_callback(void *sock, UCHAR *rx_buf, UINT rx_len,
                                            ULONG rx_ip, ULONG rx_port)
{
    int status = NX_SUCCESS;
 
    //Display received packet
    PRINTF(" =====> Received Packet(%ld) \n", rx_len);
 
    tcp_client_ka_dpm_sample_hex_dump("Received Packet", rx_buf, rx_len);
[lines deleted]
    dpm_mng_job_done(); //Done operation
}
[lines deleted]
void tcp_client_ka_dpm_sample_init_user_config(dpm_user_config_t *user_config)
{
[lines deleted]
    //Set DPM wakeup init callback
    user_config->wakeupInitCallback = tcp_client_ka_dpm_sample_wakeup_callback;
[lines deleted]
    //Set Recv callback
    user_config->sessionConfig[session_idx].session_recvCallback =
        tcp_client_ka_dpm_sample_recv_callback;
[lines deleted]
    //Set KeepAlive timeout
    user_config->sessionConfig[session_idx].session_ka_interval =
        TCP_CLIENT_KA_DPM_SAMPLE_DEF_KEEPALIVE_TIMEOUT;
[lines deleted]
}
[lines deleted]
void tcp_client_ka_dpm_sample(ULONG arg)
{
[lines deleted]
    //Register user configuration
    dpm_mng_regist_config_cb(tcp_client_ka_dpm_sample_init_user_config);
 
    //Start TCP Client Sample
    dpm_mng_start();
 
    return ;
}

רשימת קוד 1: באמצעות ה- DA16200 SoC, המפתחים יכולים לממש חיבוריות Wi-Fi רצופה באמצעות תצורות וכמה קריאות לפונקציות ה- DPM API. (מקור הקוד: Dialog Semiconductor)

כפי שמוצג ברשימת קוד 1, המפתחים מממשים יכולת זו במידה רבה תוך שימוש רק בפונקציית אתחול (tcp_client_ka_dpm_sample_init_user_config ()) המגדירה פרמטרי תצורה שונים הכוללים מרווחי Keep Alive‏ (TCP_CLIENT_KA_DPM_SAMPLE_DEF_KEEPALIVE_TIMEOUT), ומספקת קריאות-חוזרות שונות הכוללות את אלו עבור יקיצת DMP‏ (tcp_client_ka_dpm_sample_wakeup_callback()) ועבור עיבוד מנות נתונים נכנסות (tcp_client_ka_dpm_sample_recv_callback ()). כדי להתחיל את רצף היקיצה של ה- TCP Keep Alive‏ וה- DPM, פונקציה נפרדת (tcp_client_ka_dpm_sample ()) פשוט קוראת לרוטינת תצורה (dpm_mng_regist_config_cb (tcp_client_ka_dpm_sample_init_user_config)) ול-DMP Manager‏ (dpm_mng_start).

כפי שצוין קודם לכן, כל הרצף הזה, כולל מנות TCP Keep Alive‏ סטנדרטיות וניטור Wi-Fi מאופשר-DA16200 DPM, תוצאתו היא יכולת חיבוריות Wi-Fi רצופה שבדרך כלל צורכת זרם ממוצע של פחות מ- μA‏ 50‏.

אותה תבנית תכנון יכולה לשמש גם להעיר את ה- SoC‏ מאופני השינה שלו כדי לטפל בפעולות אחרות. למשל, יישום לדוגמה מראה שימוש ב- RTC של ה- DA16200 כדי להעיר את ה- SoC לעיבוד נתונים (רשימת קוד 2).

Copy
#define    SAMPLE_FOR_DPM_SLEEP_3        // Sleep Mode 3
 
#define    MICROSEC_FOR_ONE_SEC        1000000
#define    RTC_TIMER_WAKEUP_ONCE        5    // seconds
#define    RTC_TIMER_WAKEUP_PERIOD        10    // seconds
static void rtc_timer_dpm_once_cb(char *timer_name)
{
[lines deleted]
static void rtc_timer_dpm_periodic_cb(char *timer_name)
{
    /*
     *Caution : Don't spend a lot of time in the calback function called by timer.
     */
    dpm_app_sleep_ready_clear(SAMPLE_RTC_TIMER);
 
    PRINTF("\nWakeup due to Periodic RTC timer!!!\n");
    tx_thread_sleep(10);
 
    dpm_app_sleep_ready_set(SAMPLE_RTC_TIMER);
}
[lines deleted]
void rtc_timer_sample(ULONG arg)
{
[lines deleted]
        /* Periodic timer */
        status = dpm_timer_create(SAMPLE_RTC_TIMER,
                                  "timer2",
                                  rtc_timer_dpm_periodic_cb,
                                  RTC_TIMER_WAKEUP_PERIOD,
                                  RTC_TIMER_WAKEUP_PERIOD);
[lines deleted]
        dpm_app_sleep_ready_set(SAMPLE_RTC_TIMER);
[lines deleted]
    }
 
    while (1)
    {
        /* Nothing to do... */
        tx_thread_sleep(100);
    }
}

רשימת קוד 2: המפתחים יכולים לממש פונקציונליות מבוססת-קוצב-זמן בהספק-נמוך עם ה- DA16200 באמצעות כמה קריאות לפונקציות ה- DPM API כדי להבטיח צריכת הספק מינימלית במהלך פרקי-זמן אופן שינה של ה- DA16200. (מקור הקוד: Dialog Semiconductor)

כפי שמוצג ברשימת קוד 2, המפתח קורא לפונקציית DPM Manager API‏ (dpm_timer_create()) כדי ליצור קוצב-זמן (SAMPLE_RTC_TIMER), ולפונקציית DPM Manager API‏ אחרת (dpm_app_sleep_ready_set()) כדי לציין שהמערכת מוכנה לחזור לאופן שינה. לאחר מכן מנוע ה- DPM יקבע כמה מהר המערכת יכולה לחזור לאופן שינה עם צריכת הספק נמוכה על בסיס הפעילות הנוכחית. מאוחר יותר, כאשר מחזור קוצב-הזמן מסתיים, המערכת מבצעת את פונקציית הקריאה-החוזרת של המפתח, rtc_timer_dpm_periodic_cb (), המבצעת את הפעולות הנדרשות - במקרה זה, פשוט הדפסת הודעה לקונסולה. לאחר סיום הפעולה, אותה פונקציית קריאה-חוזרת מבצעת את ה- dpm_app_sleep_ready_set () כדי להודיע למנוע ה- DPM שהמערכת מוכנה לחזור לישון. כמו קודם, מנוע ה- DPM משלים את המעבר לאופן שינה בזמן המתאים.

מודולי Drop-In מפשטים את תכנון ה- Wi-Fi

בעוד שה- DA16200 SDK‏ מפשט את תכנון התוכנה, משמעות הפונקציונליות הנרחבת של ההתקן היא תכנון ממשק חומרה פשוט יחסית. באמצעות ה- DA16200 SoC לצד התקן Flash חיצוני, כגון המעגל-המשולב (IC) של זיכרון NOR‏ 16 מגה-ביט (Mbit‏) W25Q16JVSNIQ‏ מבית Winbond Electronics‏ וכמה רכיבים נוספים, המפתחים יכולים לממש תכן IoT מאובטח מאופשר-Wi-Fi (איור 4‏).

איור 4: עם הפונקציונליות המשולבת הנרחבת שלו, ה- DA16200 SoC מבית Dialog Semiconductor דורש זיכרון Flash טורי חיצוני ומינימום רכיבים נוספים כדי לממש מערכת Wi-Fi שלמה. (מקור התמונה: Dialog Semiconductor)

המפתחים המעוניינים לזרז את פיתוח התכנים שלהם על בסיס ה- DA16200 SoC יכולים לפנות למודולי Dialog Semiconductor החוסכים את הצורך עבורם במימוש ממשק החומרה של SoC. ביחד עם ה- DA16200 SoC, המודולים כוללים 4 מגה-בייט (Mbytes‏) של זיכרון Flash‏, רכיבי RF, ובחירה בין אנטנת שבב מובנית (DA16200MOD-AAC4WA32) או מחבר u.FL עבור אנטנה חיצונית (DA16200MOD-AAE4WA32). מורשים במלואם על ידי FCC, IC, CE וגופים רגולטוריים אחרים, המודולים בגודל של ‎13.8 x 22.1 x 3.3 מילימטר (מ"מ) מספקים פיתרון חומרה Drop-In עבור מימוש חיבוריות Wi-Fi רצופה בהספק-נמוך.

המפתחים המעוניינים לבחון חיבוריות Wi-Fi רצופה ולבנות במהירות אב-טיפוס של תכני IoT המבוססים על ה- DA16200 SoC יכולים לנצל מיידית את יתרונות ערכת הפיתוח DA16200MOD-DEVKT מבית Dialog Semiconductor. ערכה זו משלבת מודול DA16200MOD עם ממשק USB, מפתחות וחיבורים כדי לסייע בזירוז הפיתוח וניפוי הבאגים של תכנים מבוססי-DA16200.

סיכום

היכולת לשמור על חיבוריות Wi-Fi רצופה הוא מאפיין שגרתי של מחשבים ניידים ומוצרים מחוברים אחרים. עם זאת, עבור התקנים לבישים והתקני IoT מוזני-סוללות אחרים, דרישות ההספק של פתרונות Wi-Fi קונבנציונליים הפכו את חיבוריות ה- Wi-Fi הרצופה ללא-מעשית, ולרוב המפתחים נדרשים להתפשר על היבט כלשהו של פונקציונליות ההתקן, הביצועים או חיי הסוללה.

ה- SoC מבית Dialog Semiconductor מספק פיתרון Wi-Fi שלם המסוגל להעניק חיבוריות Wi-Fi רצופה תוך צריכת זרם מינימלית. כפי שהוצג, באמצעות SoC או המודולים הנלווים אליו, המפתחים יכולים לממש במהירות התקנים מאובטחים מוזני-סוללות המסוגלים לספק למשתמשים את היתרונות של חיבוריות Wi-Fi רצופה תוך עמידה בציפיות שלהם לחיי סוללה ארוכים.