Hur man skriver bärbar C-kod för Iot-enheter

Att skriva bärbara C-kod för IoT-enheter är en grundläggande färdighet för inbyggda utvecklare som behöver distribuera applikationer över olika hårdvaruplattformar. IoT-ekosystemet omfattar mikrokontroller med ARM Cortex-M, RISC-V, AVR och proprietära arkitekturer, var och en med unika minneskartor, perifera register och kompilatorkvarnar. Utan avsiktlig design för portabilitet, kod som fungerar på ett mål bryter ofta på en annan, vilket leder till kostsamma omskrivningar och underhållsmar.

Förstå portabilitet i IoT utveckling

Portabilitet innebär att källkoden kan sammanställas och köras på olika hårdvaruarkitekturer med liten eller ingen modifiering. I IoT-världen är portabilitet inte bara en bekvämlighet - det är ett företagskrav. Produktlivscykler är långa, leveranskedjor skift och ny kisel visas ständigt. En portabel kodbas gör att du kan återanvända befintlig firmware över produktgenerationer, snabbt svänga till alternativa komponenter under brister och minska tid till marknaden för derivatprodukter.

Portabilitet finns på ett spektrum. I ena änden är kod som är helt plattformsoberoende (t.ex. generiska sorteringsalgoritmer) sammanställer var som helst. I andra änden är kod som direkt manipulerar hårdvaruregistren i sig icke-portabel. Målet med bärbar C för IoT är att isolera icke-portabla detaljer bakom abstraktionslager så att kärnverksamhetslogiken och algoritmkoden förblir återanvändbar.

Vanliga utmaningar för att koda portabilitet

Flera skillnader på låg nivå pest inbäddade C portabilitet:

• Endianness. ARM Cortex-M och AVR är föga endian; vissa äldre arkitekturer (t.ex. Freescale HC12) är big-endian. Direkt gjutning pekar eller fackföreningar över bytesorder leder till tyst data korruption.
• ]]Word size and type definitions.] En ] kan vara 16 bitar på en 8-bitars AVR, 32 bitar på en Cortex-M0, och 64 bitar på en RISC-V 64-bitars processor. Kod som antar ] är exakt 32 bitar kommer att bryta.
• Registrera skillnader i kartläggning. Även två MCU:er från samma leverantör har ofta olika perifera basadresser, bitfält och konfigurationssekvenser.
• ]Compiler extensions and pragmas.] GCC, IAR, ARM Compiler 6 och Keil var och en har sina egna syntax och inline montering dialekter.
• ]Medlemslayout och inriktning.] Vissa plattformar kräver strikt anpassning för 32-bitars åtkomst; andra hanterar felaktig åtkomst med en felhanterare.
• ]Interrupt hantering och stackanvändning. Avbryt vektorer, prioriterade modeller och häckande beteende varierar mycket.

Nyckelstrategier för att skriva bärbar C-kod

Hårdvaruabstraktionslayers (HAL)

Det mest kraftfulla verktyget i portabelkodsarsenalen är ett hårdvaruabstraktionsskikt ]. Ett väldesignat HAL utsätter ett enhetligt API för gemensamma perifera (GPIO, UART, I2C, SPI, timers) medan du döljer det underliggande register-bashing. Gränssnittet bör definieras i en header (t.g. ) som förklarar [FLT:

Ett typiskt HAL-imagemang ser ut så här:

// hal_gpio.h (common)
typedef uint8_t gpio_pin_t;
typedef uint8_t gpio_port_t;
void hal_gpio_set_output(gpio_port_t port, gpio_pin_t pin);
void hal_gpio_set_high(gpio_port_t port, gpio_pin_t pin);
void hal_gpio_set_low(gpio_port_t port, gpio_pin_t pin);

Plattformsspecifika filer (t.ex. ) innehåller det faktiska registeret skriver. När man flyttar till en ny MCU behöver endast lågnivå HAL-källor skriva om, medan alla högre lager förblir orörda.

Anta standardbibliotek

C-standardbiblioteket ger en bärbar grund för många gemensamma operationer. Funktioner som ], strängverktyg och matematiska funktioner finns på alla överensstämmelse med C-kompilatorn. Undvik antaganden om bibliotekets interna är kritisk - skriv aldrig om för prestanda om du inte har verifierat att din kompilators genomförande är otillräcklig.

För IoT-system med begränsat minne, överväga att använda en delmängd av standardbiblioteket (t.ex. newlib-nano ] i GCC-ekosystemet) snarare än att rulla dina egna strängrutiner. På samma sätt är ] makro och ] är universellt tillgängliga. Länk: ]GNU C-biblioteksdokumentation[]] är en utmärkt referens för att förstå vad som garanterasportabel.

Använda fasta bredddatatyper

Använd alltid typerna från ] och ] för att deklarera heltalsvariabler med explicita bredder: ]]]], ]]], ]]] etc. Undvik enkel ]]] ]]] eller ]]] för allt som måste ha en känd storlek. För loopräknäknare och små index där inte är inte, [[[[[[[[[[[[[[[[[[FL]]]]]]]]]]]]]]]]]]]]][FL]]]]][FL]]][FL][FL][FL]]]]]][FL]]]][FL][FL][FL]]]][FL]][FL

När du behöver serialisera data över byte-orienterade transporter, kombinera fasta bredd typer med explicit byte-order konverteringsfunktioner (]], ], eller deras bärbara motsvarigheter). aldrig helt enkelt kasta en till en och skicka den över ett nätverk-endianness kommer att bita dig.

Villkorlig sammanställning

Preprocessordirektiv är ett legitimt verktyg för plattformsspecifik kod, men de måste användas på ett rättsligt sätt. Definiera en liten uppsättning konfigurationsmakron i en enda central rubrik (t.ex. ) snarare än att sprida genom varje fil. Exempel:

// platform_config.h
#if defined(STM32L4)
 #define PLATFORM_STM32L4
#elif defined(EFM32GG)
 #define PLATFORM_EFM32GG
#else
 #error "Unsupported platform"
#endif

Sedan i koden, använd den generiska ]] endast när det är absolut nödvändigt. Tänk på att överdriven gör koden svår att läsa och underhålla. Föredra HAL abstraktioner över villkorlig sammanställning där det är möjligt.

Minimera externa beroenden

Varje tredjepartsbibliotek du inkluderar är en potentiell bärbarhetsrisk. Innan du lägger till ett beroende, kontrollera att det stöder alla dina målarkitekturer och att det inte drar in icke-portabla antaganden. Bibliotek som är skrivna helt i bärbar C (t.ex. ]FatFS ] eller ]]]]]]FreeRTOS] är säkrare än de som förlitar sig på inline montering eller kompilatorspecifikspecifik prageringsprogram med egna pragmastorkar.

Länk: ]Embedded.com artikel om verklig bärbar C-kod erbjuder ytterligare perspektiv på hantering av beroenden.

Praktiska tips för att förbättra portabiliteten

Skriv modulär kod

Bryt din firmware till oberoende moduler med väldefinierade gränssnitt. Varje modul bör exponera sin funktionalitet genom en headerfil och dölja sina interna detaljer. Denna separation av problem gör det enkelt att ersätta en modul med en bärbar version när du portar till en ny plattform. Till exempel bör en motorkontroll modul prata med en HAL för PWM-utgång, inte direkt till en timer perifera register.

Dokument Hårdvaruberoende

Uppenbarligen annotera någon kod som förutsätter specifika hårdvarubeteenden. Använd kommentarer för att förklara varför en viss icke-portabel metod valdes, vilka plattformar den fungerar på, och vad som skulle behöva ändras för ett annat mål. Denna dokumentation är ovärderlig när den ursprungliga utvecklaren är otillgänglig och en ny ingenjör måste portera koden.

Använd Cross-Platform Build Tools

Byggsystem som CMake ] eller ]]]Meson]] kan hantera flera målkonfigurationer från en enda projektstruktur. CMake låter dig till exempel ange verktygskedjafiler för varje plattform och ställa in sammanställda definitioner baserat på målet. Detta eliminerar behovet av manuellt underhåll av separata projektfiler för IAR, Keil och GCC. Link:

#define BIT_SET(reg, bit) ((reg) |= (1u << (bit)))
#define BIT_CLEAR(reg, bit) ((reg) &= ~(1u << (bit)))