Útmutató szakemberek számára IoT-eszközök hibakereső eszközeihez és technikáihoz

Egy jól együttműködő szoftverrel és hardverrel rendelkező beágyazott rendszer kifejlesztése rendkívül összetett folyamat, és kihívást jelent még a legegyszerűbbnek tűnő Internet of Things (IoT) eszközök esetében is. Olyannyira, hogy amikor valami – előbb-utóbb, de elkerülhetetlenül – elromlik, a hibaelhárítás általában nem néhány óráig, hanem hetekig vagy hónapokig is eltarthat. Ezek a késedelmek növelik a fejlesztési költségeket, megakadályozzák, hogy a termék időben piacra kerüljön, késleltetik a gyártási ütemterveket, és hasznavehetetlenné teszik az ellátási láncokat, illetve az üzleti terveket.

A hibakereséssel töltött idő csökkentésére és a projekt pályán tartására legjobb hardveres hibakereső eszközök és szabadon elérhető szoftverek kombinációját használni, hogy betekintést nyerjünk a rendszer működésébe, és behatároljuk a problémák keletkezésének helyét. Ezért, az ehhez a munkához szükséges megfelelő eszközök megléte mind a szakemberek, mind a hobbisták esetében drámai módon segíti a gyors és pontos munkavégzést.

Ez a cikk olyan fejlesztőeszközöket és szoftvereket tárgyal, amelyek IoT-eszközök teljesítőképességének elemzésére, illetve hibakeresésre használhatók. A cikkben példa IoT-eszközként az STMicroelectronics egyik fejlesztőkártyája szerepel, illetve a SEGGER Microcontroller Systems eszközei és szoftverei a rendszer megértéséhez, valamint a hibakereséshez. Emellett számos tippet és trükköt is megvitat, amelyekkel minimalizálható a hibakeresési idő, és az IoT-projektek határidőre történő átadása megvalósítható.

Hibakeresés egy tipikus IoT eszköznél

Az IoT-eszközök szinte minden iparágban elterjedtek, az okos otthontól az ipari felügyeleti vezérlésig. Az alkalmazások sokfélesége ellenére néhány tipikus összetevő jelen van minden IoT-eszköznél. A teljesség igénye nélkül ezek a következők:

• mikroprocesszor;
• csatlakoztathatóságot biztosító rádió;
• érzékelők.

Egy fejlesztő nem akar saját kártyát készíteni a hibakeresési technikák kidolgozásához vagy az alkalmazás programrészeinek teszteléséhez. Ez egyszerűen túl időigényes. Ehelyett bölcsebb, ha egy olyan olcsó fejlesztőkártyát választ, mint az STMicroelectronics B-L4S5I-IOT01A Discovery Kit for IoT Node terméke. Ez szinte mindent tartalmaz, ami egy tipikus IoT-eszközön megtalálható (1. ábra).

1. ábra: Az STMicroelectronics B-L4S5I-IOT01A Discovery Kit for IoT Node tartalmazza egy IoT-eszközhöz jellemzően szükséges összes komponenst. (Kép: STMicroelectronics)

A kártyán jelen van egy STM32L4S5VIT6, ami egy 120 MHz-es sebességgel működő Arm® Cortex®-M4 mikrovezérlő, maximálisan 2 Mbájt flash és 640 kbájt RAM támogatással. A feladat szempontjából fontos, hogy a kártyán Wi-Fi és rengeteg érzékelő található, amelyek segítségével gyorsan felépíthető egy IoT-teszteszköz.

Professzionális hibakereső hardvereszközök

Szinte minden fejlesztőkártya rendelkezik beépített JTAG/SWD interfésszel, így a fejlesztőknek nem kell saját programozót beszerezniük. Ehelyett a fejlesztőkártyával már a kidobozolás után azonnal dolgozhatnak. Ez marketing szempontjából ugyan nagyszerű, a valódi mérnöki munka szempontjából azonban nem: a kártyákba épített hibakeresők gyakran drámaian leegyszerűsített, korlátokkal rendelkező változatok, például a rendelkezésre álló töréspontok számát és az interfész átviteli sebességét illetően. A beavatatlanok számára ezek a korlátozások talán nem tűnnek nagy dolognak, de korlátlan számú törésponttal elkerülhető a töréspontok állandó engedélyezése és letiltása, a gyors adatátviteli sebességek pedig szükségesek az alkalmazások nyomon követéséhez (a nyomon követésről bővebben a szoftvereszközök című fejezetben).

Számos olyan különböző eszköz létezik, amelyek professzionális hibakeresési élményt nyújthatnak, de maguk az eszközök csak a megoldás felét jelentik. Az eszközök számára szükséges a jó szoftveres támogatás. Hardver és szoftver szempontjából is kiemelkedő eszközkészlet a SEGGER J-Link sorozat. Ez a sorozat szinte minden típusú fejlesztő számára kínál hibakereső verziót, a diákoktól és hobbistáktól kezdve a kőkemény profikig.

A tapasztalatok szerint az átlagos fejlesztők számára két modell a leginkább alkalmas: a J-Link Base és a J-Link Ultra+ (2. ábra). Ez a két egység formai szempontból azonos, de a J-Link Ultra+ a fejlesztők számára a RAM-ba való gyorsabb letöltési sebességet biztosít (3 Mbájt/s szemben az 1,0 Mbájt/s sebességgel), illetve az SWD interfész sebessége is gyorsabb (100 MHz helyett 30 MHz). A gyorsabb sebesség sokat számít, ha a fejlesztő nyomon akarja követni az alkalmazását, hogy tisztában legyen annak teljesítőképességével, az RTOS viselkedésével, és hibakeresést végezzen a rendszerén.

2. ábra: A SEGGER J-Link Ultra+ egy 50 MHz-es célinterfész révén továbbfejlesztett hibakeresési élményt nyújt a fejlesztők számára. (Kép: SEGGER Microcontroller Systems)

A J-Link és a B-L4S5I-IOT01A fejlesztőkártya kombó előnye, hogy a kettő egy Tag-Connect TC2050-IC-NL kábelen és a TC2050-CLIP-3PACK rögzítő kapcson keresztül csatlakoztatható. Ezek lehetővé teszik a debugger csatlakoztatását a fejlesztőkártyához a körömágy formájú csatlakozón keresztül (3. ábra). Előfordulhat, hogy a J-Link 20 pólusú csatlakozóját a TC-2050 kábel 10 pólusú csatlakozójához kell adaptálni. Az egyik erre használható lehetőség a J-Link 10 pólusú 8.06.04 adaptere.

3. ábra: A B-L4S5I-IOT01A fejlesztőkártyán a Tag-Connect szerelt kábel a nyomtatott áramköri lap körömágyszerű lenyomattal rendelkező csatlakozóján keresztül csatlakoztatható (jobbra). (Kép: STMicroelectronics)

Ha a fejlesztő ezt az útvonalat a hardveres oldalon lezárta, akkor a szoftveres eszközöket használhatja az alkalmazás elemzéséhez és a hibakereséshez.

Professzionális hibakereső szoftvereszközök

Van jó néhány olyan szoftver, amely jól működik a SEGGER J-Link eszközeivel, és amelyeket meglepő módon a SEGGER nem biztosít. A következőkben néhány ilyen ingyenes eszközt tekintünk át, és megnézzük, hogy a fejlesztők hogyan használhatják őket a szoftvereikben lévő hibák kijavítására.

Az első a J-Scope. A J-Scope egy oszcilloszkópszerű eszköz, amely változók értékeit jeleníti meg az idő függvényében. A fejlesztők egyetlen változót vagy több tucat változót is figyelemmel kísérhetnek. Vegyük figyelembe azonban, hogy minél több változót figyelünk, annál kevesebb mintavétel végezhető mielőtt a minták tárolására szolgáló puffer túlcsordulna, és adatvesztés következne be.

A változók kiválasztása úgy történik, hogy a J-Scope megkapja a fordítóprogram által kiadott .elf fájlt. Ez megadja a kiolvasandó memóriahelyeket, a fejlesztő pedig beállíthatja a mintavételi sebességet, és figyelemmel tudja kísérni a változó(k) értékeinek alakulását az idő múlásának függvényében. Egy egyszerű példa a háromváltozós nyomkövetésre a 4. ábrán látható.

4. ábra: A J-Scope segítségével a J-Link révén az alkalmazás valós idejű futtatása közben is megfigyelhetők a változók. (Kép: SEGGER Microcontroller Systems)

A következő az Ozone. Az Ozone egy hibakereső interfész és teljesítőképesség-elemző. A fejlesztők betölthetik az .elf fájljukat az eszközbe, és forrásszintű hibakeresést végezhetnek. Töréspontokat állíthatnak be és frissíthetik a kódjukat. A fejlesztők számára különösen hasznos funkció, hogy utasításkövetést is végezhetnek (ha a hardverük támogatja), és azonosíthatják, hogy milyen assembly és C kódú utasítások végrehajtása történt meg. Ez különösen hasznos a hardware-in-loop (HiL) tesztelés kódlefedettségének ellenőrzésére.

Az Ozone segíthet a fejlesztőknek a rendszer teljesítményének elemzésében (5. ábra) és a változók időbeli megjelenítésében is. Ez a J-Scope-hoz hasonló képességeket biztosít, de sokkal integráltabb módon. Még az energiafogyasztás nyomon követésére és az összes ilyen esemény egy helyen való szinkronizálására is használható.

5. ábra: Az Ozone a kódlefedettség és az RTOS-tudatos hibakeresés mellett a változók J-Linken keresztüli nyomon követésére is használható az alkalmazás valós idejű futása közben. (Kép: SEGGER Microcontroller Systems)

A harmadik eszköz a SystemView. A SystemView lehetővé teszi a fejlesztők számára, hogy elemezzék az RTOS rendszerük futás közbeni viselkedését. A feladatváltást egy nyomkövetési pufferben rögzítik, majd a hibakeresőn keresztül jelentik a SystemView-nak (5. ábra). A SystemView ezt követően úgy jeleníti meg ezeket az információkat, hogy a fejlesztő láthatja rendszerének kontextusváltásait és mérheti a teljesítményét. Ez nagyszerű módszer a rendszer vizualizálására, valamint a hibák és egyéb problémák megtalálására.

6. ábra: A SystemView olyan kapcsolatot biztosít egy RTOS-hez, amely lehetővé teszi a fejlesztők számára, hogy mérjék a feladatok teljesítményét, és megjelenítsék, hogy mit és mikor csinál az RTOS. (Kép: SEGGER Microcontroller Systems)

Tippek és trükkök beágyazott rendszerek hibáinak elhárításához

Egy IoT-eszköz esetén a hibaelhárítás végzésekor a fejlesztőknek hardveres és szoftveres szempontból is megfelelő eszközökkel kell rendelkezniük. Mindkét darabnak a helyén kell lennie, ha minimalizálni akarják a hibakereséssel töltött időt. A sikeres hibaelhárításhoz a fejlesztőknek számos „tippet és trükköt” érdemes figyelembe venniük, például:

• Olyan professzionális hibakereső programot kell használniuk, amely maximalizálja az interfész átviteli sebességet. A rendszerből kinyerhető hasznos adatok mennyisége attól függ, hogy milyen gyorsan lehet azokat fogadni. A lassúbb sebesség hosszabb hibakeresési munkamenetet eredményez.
• A hibakereső szoftvert konfigurálni kell még a fejlesztési ciklus elején. A fejlesztőknek nem szabad megvárniuk egy probléma felmerülését, és hogy csak azt követően kezdjenek hozzá a hibakeresési eszközök beállításához.
• Használniuk kell nyomon követő eszközöket a fejlesztés kezdetétől fogva. Ez lehetővé teszi a fejlesztők számára, hogy nyomon kövessék a rendszerük teljesítményét és azonnal megértsék, hogy a szoftverváltozások hogyan befolyásolják azt.
• Nyomon kell követniük az utasításokat vagy mintavételezniük kell a programszámlálót a rendszer kódlefedettségének megértéséhez a tesztelés során. A nem tesztelt feltételes ágak és programrészek szinte biztosan hibákat fognak tartalmazni.
• Gyors átviteli protokollokat kell használniuk az adatok chipen kívüli továbbítására; ilyenek például a Real-time Transfer (RTT) könyvtárak.

Ezen „tippeket és trükköket” megfogadó fejlesztők sok időt meg fognak takarítani, és sokkal kevesebb keserűségben lesz részük egy-egy IoT-eszközt fejlesztésekor.

Összegzés

Az IoT-eszközök szoftverei összetetté váltak, de ez nem jelenti azt, hogy a professzionális vagy hobbifejlesztőknek folyamatosan hibakereséssel kell bajlódniuk a rendszereik esetében. Professzionális fejlesztőeszközök és szoftverek használatával a fejlesztők rendelkezésére áll nemcsak a rendszer hibakereséséhez, hanem az elemzéséhez és teljesítőképességének javításához szükséges áttekités is. Az ilyen eszközökbe való befektetéssel a felhasználók drámaian csökkenthetik a hibakereséssel töltött időt, és ésszerű időn belül működőképessé és piacra vihetővé tehetik projektjeiket.