Środowisko programistyczne

Możesz tworzyć aplikacje dla usługi Azure Sphere na Windows 11, rocznicowej aktualizacji Windows 10 (lub nowszej) albo na komputerze z systemem Linux z systemem Ubuntu 24.04 (wersja wstępna), Ubuntu 22.04 LTS lub Ubuntu 20.04 LTS. Jeśli korzystasz z Windows 11, użyj wersji 22.02 (lub nowszej) pakietu Azure Sphere SDK.

• W przypadku systemu Windows zainstaluj Windows SDK. Za pomocą programu Visual Studio, Visual Studio Code lub wiersza polecenia możesz tworzyć, wdrażać i debugować aplikacje w systemie Windows.
• W przypadku systemu Linux zainstaluj pakiet Linux SDK. Za pomocą Visual Studio Code lub wiersza polecenia możesz tworzyć, wdrażać i debugować aplikacje w systemie Linux.

Klawiatura SDK Azure Sphere zawiera następujące główne składniki:

• Sysroots, które zawierają biblioteki, pliki nagłówków i narzędzia, które są używane do kompilowania i łączenia aplikacji, która jest skierowana do określonego zestawu interfejsów API.
• Definicje sprzętu, które opisują możliwości sprzętowe dostępne na różnych urządzeniach sprzętowych i mogą być używane do określania ich w app-manifest.json plikach.
• CMakeFiles, które definiują rozszerzenia Azure Sphere na CMake.
• Interfejs Command-Line Azure Sphere (CLI).

Samouczki przeprowadzą Cię przez tworzenie i wdrażanie pierwszej aplikacji. Udostępniamy również repo próbki w GitHub , który zawiera przykładowe aplikacje, które pokazują, jak programować sprzęt Azure Sphere i korzystać z interfejsów API.

Środowisko uruchomieniowe aplikacji Azure Sphere

Środowisko uruchomieniowe aplikacji Azure Sphere udostępnia dwa zestawy bibliotek do tworzenia aplikacji na wysokim poziomie: podstawowe interfejsy API i interfejsy API aplikacji. Podstawowe interfejsy API są oparte na bibliotekach, które nie są przeznaczone wyłącznie na urządzenia Azure Sphere, natomiast interfejsy API aplikacji są przeznaczone specjalnie dla urządzeń Azure Sphere. Aplikacje wysokiego poziomu utworzone za pomocą zestawu SDK Azure Sphere kompilują się i łączą z tymi interfejsami. Tych interfejsów API nie można używać w aplikacjach z obsługą czasu rzeczywistego.

Pliki nagłówków podstawowych interfejsów API są instalowane w katalogu instalacyjnym zestawu Sysroots\API set\usr\include foldery katalogu instalacji zestawu Azure Sphere SDK. Pliki nagłówków dla interfejsów API aplikacji są instalowane w folderze Sysroots\API set\usr\include\applibs katalogu instalacji zestawu Azure Sphere SDK.

Wskazówka

Standardowe nagłówki POSIX C znajdują się w dwóch folderach: Sysroots\API set\usr\include for general API headers and Sysroots\API set\usr\include\sys for low-level, system-dependent API headers. Zalecamy używanie ogólnych interfejsów API.

Narzędzia

Azure Sphere SDK zawiera platformę Azure CLI do zarządzania urządzeniami, opracowywania i wdrażania aplikacji oraz pracy z usługami w chmurze.

CMake, wraz z lekkim narzędziem kompilacji Ninja, zapewnia koordynację kompilacji dla aplikacji Azure Sphere. Jeśli używasz programu Visual Studio, programy CMake i Ninja są instalowane automatycznie. Jeśli używasz Visual Studio Code lub Azure CLI, musisz zainstalować je samodzielnie w systemie Windows lub Linux.

Zarówno program Visual Studio, jak i Visual Studio Code mają rozszerzenia Azure Sphere, które upraszczają tworzenie aplikacji Azure Sphere. Dzięki tym rozszerzeniom możesz łatwo tworzyć, debugować, testować i wdrażać aplikacje Azure Sphere bezpośrednio z poziomu środowiska IDE. Oba rozszerzenia mają pełną obsługę narzędzi CMake usługi Azure Sphere.

Pojemniki

Azure Sphere zapewnia kontener, który pakuje zestaw SDK w autonomicznym środowisku systemu Linux. Używając kontenera ze wstępnie zdefiniowanym środowiskiem kompilacji, możesz uniknąć etapów instalowania (lub odinstalowywania, a następnie ponownego instalowania) właściwego środowiska kompilacji SDK. Środowisko konstruowania można zmodyfikować tak, aby odpowiadało Twoim potrzebom, i replikować je na wszystkich komputerach hosta w tym samym czasie z jednolitymi wynikami. Aby uzyskać szczegółowe informacje , zobacz Tworzenie aplikacji Azure Sphere za pomocą kontenerów . Kontenera można także używać w ramach scenariusza ciągłej integracji, w którym potok kompilacji, taki jak GitHub Actions lub Azure Pipelines, automatycznie odbudowuje aplikację za każdym razem, gdy zostanie wprowadzona zmiana kodu źródłowego. Aby uzyskać szczegółowe informacje, zobacz Dodawanie ciągłej integracji do kompilacji kontenera .

Co to jest kontener?

Kontenery to przenośne pakiety dostarczane z własnymi lekkimi środowiskami, które działają na jądrze maszyny hosta. Kontenery są lekkie, ponieważ używają warstw udostępnionych. Te warstwy można udostępniać wycinkami systemu operacyjnego lub udostępnionych aplikacji. Warstwy unikają obciążenia maszyny wirtualnej, która zawiera cały system operacyjny i wszystkie skojarzone aplikacje. Udostępnianie pozwala na małe kontenery i szybkie rozruch.

Możesz pobrać kontenery z rejestru kontenerów, takiego jak Rejestr Artefaktów Microsoft (MAR).

Jakie kontenery są wnosne do usługi Azure Sphere

Kontener środowiska kompilacji SDK platformy Microsoft Azure Sphere zapewnia gotowe środowisko programistyczne. Kontener zawiera następujące elementy:

• Wersja systemu Ubuntu Linux dla bieżącej wersji usługi Azure Sphere
• Bieżąca wersja pakietu Azure Sphere SDK dla systemu Linux
• Dodatkowe narzędzia wymagane przez SDK, takie jak CMake i Ninja

W usłudze Azure Sphere są używane kontenery programu Docker skonfigurowane z plikami tekstowymi programu Dockerfile . Możesz utworzyć pliki Docker, które używają obrazu kontenera podstawowego, aby utworzyć niestandardowy kontener do tworzenia aplikacji Azure Sphere. Uruchomienie dostosowanego kontenera pobiera najnowszy obraz podstawowy, jeśli nie znajduje się on na komputerze hosta, tworzy nowy dostosowany kontener w razie potrzeby, konstruuje określoną aplikację i kończy pracę. Następnie możesz skopiować dane wyjściowe kompilacji aplikacji na komputer hosta, na który jest zainstalowany pakiet SDK Azure Sphere, i załadować aplikację na urządzenie. Niestandardowy kontener kompilacji nie jest zwykle używany interakcyjnie, ale może być na przykład do diagnozowania problemów z kompilacją.