C 在具有两种体系结构的嵌入式系统中使用的整数和布尔类型

我正在为一个嵌入式系统编写一些软件，主要是用C语言编写的。它恰好是一个双核TI平台，我正在使用一些供应商和其他库。处理器有一个32位的ARM内核，可以进行字节访问（

sizeof（char）==1

和

sizeof（int）==4

：分别为8位和32位），还有一个C28内核，它是一个32位的CPU，具有

sizeof（char）==sizeof（int）==1

：都是16位（）

我计划避免使用诸如

int

和

char

之类的类型，而是总是明确地说明我在做什么。无论如何，我都会计划这样做，但当“char”有点叛逆，而且不总是8位时，情况就更糟了

但是，我有相当多的整数和布尔定义集（和浮点，但不必担心它们），具体取决于我包含的标题的数量和类型：

在手臂一侧：

<stdint.h> // from the ARM compiler's include dir
typedef   signed char   int8_t;
typedef unsigned char  uint8_t;
typedef          short  int16_t;
typedef unsigned short uint16_t;
typedef          int    int32_t;
typedef unsigned int   uint32_t;
typedef          long long  int64_t;
typedef unsigned long long uint64_t;

至于布尔人，我有

<stdbool.h> // on ARM
<stdbool.h> // on C28
typedef unsigned char bool;

<xdc/std.h> // on both
typedef unsigned short  Bool;       /* boolean flag */

// TI Driver library
typedef unsigned char tBoolean;

// TI Flash access library
typedef unsigned char       boolean;

这意味着我可以像这样包含，并防止强制标题用户首先包含某些库标题，或通过将库包含添加到我的标题来强制其可见性：

// someimpl_arm.c
#include "someheader_arm.h" // include first of all to ensure that all types are visible to the headers
#include <some_ti_lib.h> // brings in UintN, for example

// main.c
#include "someheader_arm.h" 
#include <some_ti_lib.h> // e.g. needed by main.c functions
// include order doesn't matter - UintN isn't needed by someheader_arm.h

//someimpl\u arm.c
#首先包括“someheader\u arm.h”//include，以确保所有类型的标题都可见
#例如，include//引入UintN
//main.c
#包括“someheader\u arm.h”
#包括//例如main.c函数所需
//包含顺序无关紧要-某些标题不需要UintN

库函数的函数签名有时采用

unsigned long

样式或

UintN

样式，但总是相当清楚将发生什么。最主要的问题是，即使我从库中调用的函数使用了一系列令人兴奋的定义，也要保持代码中的头和变量整洁一致

事实上，像

char

和

int

这样的东西在两个内核上完全不同，这是一个有趣的怪癖，但我的问题即使是在单核处理器上，我只是比平常有更多的类型在浮动

---

所以问题是：将C99标准头作为代码中的通用标准，而忽略库中提供的各种类型，这有意义吗？

“这将产生副作用，即我在ARM和C28核心之间共享的任何头都不能使用

uint8\u t

”—为什么不呢？它们是扩展的标准类型，

stdint.h

是一个标准标题，是必需的。在我看来，你正在构造一个不存在的问题。在标准类型可用的情况下，不要使用自制类型@user694733:那么它就不能处理具有较小类型的代码，这使得在不进行重大修改的情况下，不可能使用使用较小类型的代码。或者他可以使用

intN\u least

类型，这是必需的。@Olaf，是的，没有

uint8\u t

。这很好，在两个核心之间共享的任何代码都将显式地处理它，至少使用

[u]intN\u

或在两侧使用

uint16\u t

，或者类似的方法。不管怎么说，没有多少代码被共享，而那些代码被小心地打包到共享内存中。@user694733我想第一个注释实际上是关于主题的。不过，删除了我的最后两个。顺便说一句，

sizeof（char）==1

始终为真，因此该部分没有添加太多信息。：）“这将产生一个副作用，即我在ARM和C28核心之间共享的任何头文件都不能使用

uint8\u t

”-为什么不能？它们是扩展的标准类型，

stdint.h

是一个标准标题，是必需的。在我看来，你正在构造一个不存在的问题。在标准类型可用的情况下，不要使用自制类型@user694733:那么它就不能处理具有较小类型的代码，这使得在不进行重大修改的情况下，不可能使用使用较小类型的代码。或者他可以使用

intN\u least

类型，这是必需的。@Olaf，是的，没有

uint8\u t

。这很好，在两个核心之间共享的任何代码都将显式地处理它，至少使用

[u]intN\u

或在两侧使用

uint16\u t

，或者类似的方法。不管怎么说，没有多少代码被共享，而那些代码被小心地打包到共享内存中。@user694733我想第一个注释实际上是关于主题的。不过，删除了我的最后两个。顺便说一句，

sizeof（char）==1

始终为真，因此该部分没有添加太多信息。：）

typedef char          INT8; // from the NDK network headers
typedef unsigned char u8_t;  // from the uIP network headers

<stdbool.h> // on ARM
<stdbool.h> // on C28
typedef unsigned char bool;

<xdc/std.h> // on both
typedef unsigned short  Bool;       /* boolean flag */

// TI Driver library
typedef unsigned char tBoolean;

// TI Flash access library
typedef unsigned char       boolean;

// someheader_arm.h
#include <stdint.h> // only need a standard header, not a TI one
#include <stdbool.h>

extern uint8_t getDeviceFooIndex(void);
extern bool    isDeviceFoobared(void);

// someimpl_arm.c
#include "someheader_arm.h" // include first of all to ensure that all types are visible to the headers
#include <some_ti_lib.h> // brings in UintN, for example

// main.c
#include "someheader_arm.h" 
#include <some_ti_lib.h> // e.g. needed by main.c functions
// include order doesn't matter - UintN isn't needed by someheader_arm.h