ArcCore重构-Platform_Types.h实现辨析
https://mp.weixin.qq.com/s/y768VcKD6Co7iD6u8LYoYg
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 #endif typedef _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自由发挥的。