Sdílet prostřednictvím

Návrhy návrhu základní aplikace vysoké úrovně

  • Článek

Důležité

Toto je dokumentace k Azure Sphere (starší verze). Azure Sphere (starší verze) se vyřazuje 27. září 2027 a uživatelé musí do této doby migrovat do Azure Sphere (integrované). K zobrazení dokumentace k Azure Sphere (integrované) použijte selektor verzí umístěný nad obsahem.

K vytvoření základní aplikace základní úrovně (HL) na pevných základech byste měli použít základní osvědčené postupy. Nejrelevavantnější jsou následující:

Základní aplikace vysoké úrovně (HL) spouštějí kontejnerizované v operačním systému Azure Sphere. Během kontroly kódu a návrhu řešení pro zákazníky jsme zjistili několik typických problémů s aplikacemi pro hl-core. Toto téma popisuje návrhy na vylepšení návrhu pro řešení těchto problémů.

Obecné základy

Pokud chcete vytvořit základní aplikaci HL na pevných základech, měli byste použít základní osvědčené postupy. Nejrelevavantnější jsou následující:

  • Inicializace a ukončení: Vždy nezapomeňte zpracovat signál SIGTERM operačního systému Azure Sphere a správně inicializovat a zničit všechny obslužné rutiny (například pro periferní zařízení) při ukončení, ať už při chybovém ukončení nebo chybě. Další podrobnosti najdete v tématu Inicializace a ukončení a dokumentace GNU k ukončovacím signálům.
  • Vždy používejte ukončovací kódy: Zajištění, aby aplikace HL-core vždy poskytovala smysluplný návratový kód při ukončení nebo chybovém ukončení (například pomocí obslužné rutiny SIGTERM), je nezbytná pro správnou diagnostiku chování zařízení, zejména z telemetrie výpisu stavu systému zařízení. Další informace naleznete v tématu Ukončovací kódy a shromažďování a interpretace chybových dat.
  • Ujistěte se, že případy selhání vždy vedou k ukončení nebo chybovému ukončení aplikace místo ve stavu zablokování: Logika propracovaného obnovení selhání může být neproduktivní, protože může představovat chyby nebo chování, které vede k zablokování nebo stavu, který je obtížné diagnostikovat. Dobře navržená aplikace Azure Sphere by měla vždy upřednostňovat chybové ukončení nebo ukončení (s nenulovým ukončovacím kódem) do potenciální situace zablokování, protože výsledkem je obojí:
    • Telemetrie chyb, povolení diagnostiky pro tento problém
    • Šance okamžitého obnovení do pracovního stavu, protože operační systém Azure Sphere restartuje aplikaci.
  • Zpracování chyb a protokolování: Přesné zpracování chyb a protokolování je základem vývoje kvalitních aplikací. Rychlé implementace funkcí můžou zůstat zachované ve vrstvách kódu a následně sestavené, protože aplikace se vyvíjí až do úplného škálování. Další informace o osvědčených postupech najdete v tématu Zpracování chyb a protokolování.
  • Použijte systémový časovač jako sledovací modul: Jedním z nejdůležitějších osvědčených postupů je implementace zpětného volání "watchdog timer" (podobně jako hardwarové, které jsou k dispozici v holých MCU), které sleduje kritické stavy aplikace, detekuje zablokování a odpovídajícím způsobem funguje (například ukončování a odesílání telemetrie). Další informace naleznete v tématu Použití systémového časovače jako sledovacího zařízení.
  • Nikdy nenasazujte produkční aplikace vytvořené tak, aby se zaměřily na sadu nástrojů beta verze: Použití sad nástrojů beta verzí se nedoporučuje, protože není možné zaručit, že se v následujících verzích operačního systému nezmění podmnožina beta verze. Sady nástrojů beta verze se vydávají výhradně pro testování nových funkcí před oficiální verzí sady SDK.

Zpracování souběžnosti

  • EventLoop používejte, kdykoli je to možné: Vlákna a synchronizační objekty (tj. mutexy, semaphores atd.) se používají k provádění téměř souběžných úloh, ale v rámci integrovaných systémů jsou tyto objekty nákladné z hlediska využití systémových prostředků. Proto pro účely zlepšení výkonu zvažte použití epoll namísto vláken u úloh, které nejsou přísně kritické a nejsou citlivé na vzájemné blokování. Informace o monitorování a odesílání událostí pomocí EventLoopu, včetně souvisejících ukázek, najdete v tématu Applibs eventloop.h.
  • Hledejte efektivitu souběžných úloh: Je důležité zajistit, aby blokující operace a časové limity byly v rámci zpětných volání epoll zachovány na minimum, jinak budou ovlivněny všechny ostatní zpětné volání epoll.
  • Kdy použít vlákna (pthread): Pro konkrétní scénáře, jako je například blokování volání, může být použití vláken užitečné, i když tyto scénáře by měly mít omezenou životnost a měly by být vymezeny na konkrétní úlohy. Například vzhledem k tomu, že operační systém Azure Sphere (spuštěný Linux) nezpřístupňuje IRQs pro aplikace jádra HL (je k dispozici pouze pro rt-core Apps), může být použití kombinace úloh epoll a pthread optimální při zpracování, například podřízené sériové komunikace při stahování dat z internetu.

Důležité

Operační systém Azure Sphere může přerušit včasné operace, zejména když provádí ověření zařízení, kontroluje aktualizace nebo nahrává telemetrická data. U úkolů řízení kritických pro čas zvažte přesunutí těchto úloh do jader M4 a jejich koordinaci s odpovídajícím protokolem prostřednictvím mezijádrových poštovních schránek. Další informace najdete v ukázce komunikace mezi jádry.

Kromě těchto návrhů si projděte dokumentaci k Azure Sphere týkající se asynchronních událostí a souběžnosti.

Monitorování připojení

Dobře navržená základní aplikace vysoké úrovně (HL) musí implementovat správnou úlohu kontroly stavu připojení, která by měla být založena na robustním stavovém počítači, který pravidelně kontroluje stav internetového připojení (například pomocí časovače epoll ) pomocí Networking_IsNetworkingReady API. V některých případech můžete použít funkci Networking_GetInterfaceConnectionStatus, protože poskytuje podrobnější stav stavu připojení souvisejícího s konkrétním síťovým rozhraním, které může aplikace jádra HL použít k lepšímu řešení stavu, i když to stojí, protože se nedoporučuje volat častěji než každých 90 sekund.

Zpětné volání stavového počítače by obvykle mělo mít následující atributy:

  • Proveďte co nejrychleji.
  • Interval dotazování musí být pečlivě navržen na základě konkrétního scénáře aplikace a celkových požadavků řešení (například konstantní čas, přírůstkové zpoždění atd.).
  • Jakmile se zjistí odpojení, může být užitečné zavolat Networking_GetInterfaceConnectionStatus jednou za účelem protokolování stavu konkrétního síťového rozhraní, které se dá použít k diagnostice problému a upozornit uživatele prostřednictvím uživatelského rozhraní (například LED diody, displej, terminál). Ukázka tohoto přístupu najdete v hlavním kódu ukázky DHCP Azure Sphere.
  • Aktivujte mechanismus (například prostřednictvím globální proměnné), který zastaví všechny ostatní úlohy v aplikaci jádra HL, která provádí (nebo jsou svázané) se síťovými komunikacemi, aby se optimalizovala spotřeba prostředků, dokud se připojení znovu nepublikuje.
  • Nástroj cURL nedávno aktualizoval chování zpětného volání a osvědčené postupy. I když se Azure Sphere snažila zajistit, aby starší verze chování cURL fungovaly podle očekávání, doporučujeme při používání curl_multi postupovat podle nejnovějších pokynů k zabezpečení a spolehlivosti, protože použití rekurzivních zpětného volání může vést k neočekávaným chybám, výpadkům připojení a potenciálním ohrožením zabezpečení. Pokud se timerCallback aktivuje s vypršením časového limitu 0 ms, považuje se za časový limit 1ms, aby se zabránilo rekurzivním zpětným voláním. Nezapomeňte také volat curl_multi_socket_action explicitně alespoň jednou po voláních curl_multi_add_handle.

Kroměpředchozíchch

  • Po odeslání dat zapněte čip Azure Sphere. Podrobnosti najdete v tématu Správa stavu Power Down pro zařízení Azure Sphere.
  • Vzhledem k tomu, že několik problémů může mít za následek dlouhé exponenciální vypršení časového limitu vypnutí, je důležité sledovat celkovou dobu provozu a nastavit časovač vypnutí na rozumný limit, aby se baterie nevyprázdnila za podmínek, kdy připojení už není možné kvůli externím výpadkům nebo jiným faktorům mimo kontrolu aplikace.
  • Při řízení monitorování připojení během výpadků může wi-fi transceiver vypnout vypnutím síťového wlan0 rozhraní (viz Networking_SetInterfaceState) a čekáním na další kontrolu připojení znovu, což šetří přibližně 100 mW.

Správa a využití paměti

Na platformách s omezenými paměťmi můžou aplikace, které provádějí časté přidělení paměti a rušení přidělení, způsobit, že správa paměti operačního systému bude mít potíže s efektivitou, což způsobí nadměrnou fragmentaci a vyčerpání paměti. Konkrétně v Azure Sphere MT3620 to může vést k nedostatku paměti, které by mohly aktivovat spuštění vraha OOM operačního systému Azure Sphere.

Je zřejmé, že aplikace se často vyvíjejí od počátečního testování konceptu, který je komplexnější s funkcemi požadovanými pro progresivní verze, a nakonec zanedbávají menší funkce, které byly původně zahrnuty. Tady jsou návrhy a optimalizace, které se osvědčily pro mnoho scénářů analyzovaných v tomto poli:

  • Zejména v rámci aplikací s jádry HL, které využívají paměť, je nezbytné sledovat využití paměti aplikace prostřednictvím rozhraní API Azure Sphere popsané v tématu Určení využití paměti RAM aplikace za běhu. Obvykle se to implementuje ve watchdogu epoll-timer a aplikace odpovídajícím způsobem reaguje na neočekávané využití paměti, aby bylo možné restartovat rozumně; Například ukončení s odpovídajícím ukončovacím kódem.

    Několik zákazníků a partnerů zjistilo, že je užitečné použít nástroj sledování paměti Heap Tracker , který je publikován v galerii Azure Sphere. Tato knihovna transparentně odkazuje na existující aplikaci hl-core a sleduje přidělení paměti a jejich související ukazatele, což umožňuje zjednodušenou detekci většiny případů nevracení paměti a zneužití ukazatele.

Důležité

Tento postup může snížit zdánlivě nevysvětlené zařízení nereagující nebo selhání často hlášené z pole. Taková selhání jsou obvykle způsobená nevracením paměti nebo přetečením, která nejsou správně zpracována aplikací HL-core a vedou VrahA OOM k vypnutí procesu aplikace. To spolu s nízkým připojením, které blokuje odesílání telemetrie operačního systému Azure Sphere, může vést k potenciálním incidentům polí, protože diagnostika může být zjištěna pouze vyžádáním diagnostických protokolů operačního systému Azure Sphere.

  • Na platformách s omezenými paměťmi je obecně vhodnější vyhnout se dynamickému přidělování paměti, kdykoli je to možné, zejména v rámci často nazývaných funkcí. Tím se výrazně sníží fragmentace paměti haldy a pravděpodobnost následných selhání přidělení haldy. Zvažte také posun paradigmatu od opakovaného přidělování dočasných pracovních vyrovnávacích pamětí na přímý přístup ke zásobníku (pro proměnné přiměřených velikostí) nebo globálně přidělených vyrovnávacích pamětí, které se při přetečení zvětší (prostřednictvím realloc) (viz dynamické kontejnery a vyrovnávací paměti). Pokud je potřeba paměť přesměrovat, zvažte využití nevyužité paměti na jádrech M4 (viz Paměť dostupná v Azure Sphere), které mají 256KiB, přičemž pro ukládání dat do mezipaměti se odlehčenou aplikací RT-Core. Nakonec můžete použít externí SD karty nebo flash. Ukázky najdete v následujících úložišťch:

Následující návrhy vám také můžou pomoct při odhadu a rezervaci paměti, která by byla potřebná k tomu, aby aplikace hl-core fungovala v plné kapacitě v průběhu životního cyklu, a zároveň vám umožní lépe odhadnout celkovou paměťovou stopu aplikace pro pozdější optimalizaci návrhu. Další informace o optimalizaci využití paměti v aplikacích jádra HL, včetně funkcí v operačním systému Azure Sphere a sadě Visual Studio, najdete v následujících článcích: