ArcCore重构

AUTOSAR定义了一系列PlatformTypes，如uint8/uint16/uint32等等基本类型。

It contains all platform dependent types and symbols. Those types must be abstracted in order to become platform and compiler independent.

ArcCore中实现如下：

#include <stdbool.h>#include <stdint.h>#ifndef PLATFORM_TYPES_H#define PLATFORM_TYPES_H#define CPU_TYPE            CPU_TYPE_32 #define CPU_BIT_ORDER       MSB_FIRST #define CPU_BYTE_ORDER      HIGH_BYTE_FIRST#ifndef FALSE#define FALSE        (boolean)false#endif#ifndef TRUE#define TRUE        (boolean)true#endiftypedef _Bool                  boolean;typedef int8_t                 sint8;typedef uint8_t               uint8;typedef char                char_t;typedef int16_t                sint16;typedef uint16_t              uint16;typedef int32_t             sint32;typedef uint32_t               uint32;typedef int64_t              sint64;typedef uint64_t              uint64;typedef uint_least8_t       uint8_least;typedef uint_least16_t      uint16_least;typedef uint_least32_t      uint32_least;typedef int_least8_t        sint8_least;typedef int_least16_t       sint16_least;typedef int_least32_t       sint32_least;typedef float               float32; typedef double              float64;  typedef volatile int8_t vint8_t;typedef volatile uint8_t vuint8_t;typedef volatile int16_t vint16_t;typedef volatile uint16_t vuint16_t;typedef volatile int32_t vint32_t;typedef volatile uint32_t vuint32_t;typedef volatile int64_t vint64_t;typedef volatile uint64_t vuint64_t;#endif

可以看到，其中直接使用了_Bool类型，uint8_t等这些类型，来定义boolean/uint8等这些类型。

那_Bool/uint8_t这些类型从何而来呢？

一定是从上面的include中来：

#include <stdbool.h>#include <stdint.h>

这两个文件来自于编译链。亦即这些类型的定义会随着编译链的变化，而可能发生变化。

1. 我们需要这种变化吗？AUTOSAR的软件模块不应该建立在一个统一的类型之上吗？

需要。回到文章最开始那句话，所有这些types都是platform dependent，随platform而变。这里来自于编译链的这两个头文件正好是我们所需要的platform-dependent types.

 

2. 这两个文件靠的住吗？每个工具链都提供这两个文件吗？

事实上，我最开始移植编译时即报找不到类型的错误。当打开这两个文件时，可以发现文件头位置的注释中有如下两句：

* ISO C Standard:  7.16  Boolean type and values  <stdbool.h>* ISO C99: 7.18 Integer types <stdint.h>

即这两个文件都是ISO C标准所定义的文件。只要C编译器是按标准实现的，则有这两个文件。不按ISO C标准实现的编译器能拿出来用吗？

这里也提示了，找不到类型的问题，是因为没有打开C99的支持。所以找不到stdint.h。

 

3. uint8/uint16/uint32这样的类型定义太普遍了，很有可能跟系统中的其他模块，比如芯片商提供的bsp，或者rtos里面定义的类型系统重复，以致重命名错误。

是否应该统一在这些类型前面添加前缀，比如AR_UINT8/AR_UINT16/AR_UINT32？

现实中，在编译MPC5xxx系列时，确实遇到了vint8_t类型冲突的问题。(可以把这里的删除掉，vint8_t在标准文档中没有要求)

暂时不能改，一则使用太普遍，加了略显繁杂。二则这些类型名是AUTOSAR标准里面定义的，不是ArcCore自由发挥的。