正文

ArcCore重构-Platform_Types.h实现辨析

IP云
IP云V管理员/2 阅读
12/02
提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

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自由发挥的。

相关阅读

目录[+]