在ti的CSL（chip support library 把ti所有chip都支持了）中把寄存器的分布都用结构体定义了一次，这样做不是很浪费空间么
/**************************************************************************
* Register Overlay Structure for __ALL__
**************************************************************************/
typedef struct {
volatile Uint32 REVISION;
volatile Uint8 RSVD0[12];
volatile Uint32 SYSCONFIG;
volatile Uint8 RSVD1[12];
volatile Uint32 EOI;
volatile Uint32 IRQSTS_RAW_0;
volatile Uint32 IRQSTS_RAW_1;
volatile Uint32 IRQSTS_0;
volatile Uint32 IRQSTS_1;
volatile Uint32 IRQSTS_SET_0;
volatile Uint32 IRQSTS_SET_1;
volatile Uint32 IRQSTS_CLR_0;
volatile Uint32 IRQSTS_CLR_1;
volatile Uint32 IRQWAKEN_0;
volatile Uint32 IRQWAKEN_1;
volatile Uint8 RSVD2[200];
volatile Uint32 SYSSTS;
volatile Uint32 IRQSTS1;
volatile Uint32 IRQEN1;
volatile Uint32 WAKEUPEN;
volatile Uint8 RSVD3[4];
volatile Uint32 IRQSTS2;
volatile Uint32 IRQEN2;
volatile Uint32 CTRL;
volatile Uint32 OE;
volatile Uint32 DATAIN;
volatile Uint32 DATAOUT;
volatile Uint32 LEVELDETECT0;
volatile Uint32 LEVELDETECT1;
volatile Uint32 RISINGDETECT;
volatile Uint32 FALLINGDETECT;
volatile Uint32 DEBOUNCEN;
volatile Uint32 DEBOUNCINGTIME;
volatile Uint8 RSVD4[8];
volatile Uint32 CLRIRQEN1;
volatile Uint32 SETIRQEN1;
volatile Uint8 RSVD5[8];
volatile Uint32 CLRIRQEN2;
volatile Uint32 SETIRQEN2;
volatile Uint8 RSVD6[8];
volatile Uint32 CLRWKUPENA;
volatile Uint32 SETWKUENA;
volatile Uint8 RSVD7[8];
volatile Uint32 CLRDATAOUT;
volatile Uint32 SETDATAOUT;
} CSL_GpioRegs;
离线
意思是 CSL_GpioRegs 这个结构体里面，
有些芯片根本没有这些寄存器？
emmm 三个情况
1.用宏编译控制，SoC没有就不包含不使用，SoC有就包含使用；
2.如果几款SoC寄存器是相同的，就包含同一个定义文件，定义一套他们通用的寄存器结构体；
3.SoC自己独有的，就自己包含一个独有的定义文件，定义一套独有的寄存器结构体；
离线
那这样做不会浪费存储空间
这样做目的，是不是先把准备写入寄存器的值写入这个结构体，然后再把整个结构体对着写入寄存器？
还是别有目的呢？
工程采用rtsc（xdctools）技术，暂时没搜到对这类结构体的操作或引用的代码，也许是给xdctools使用的？
俺再挖挖
最近编辑记录 Jin劲 (2018-08-16 12:03:26)
离线
结构体的声明只是声明，本身不占空间。
如果没有定义实例而是直接映射到寄存器空间，那么就不占空间，因为你寄存器本身就在那，把寄存器空间按照结构体来访问而已
如果是拷贝一份作为buffer，那是占空间，但有可能是方便软件维护
离线
结构体的声明只是声明，本身不占空间。
如果没有定义实例而是直接映射到寄存器空间，那么就不占空间，因为你寄存器本身就在那，把寄存器空间按照结构体来访问而已
如果是拷贝一份作为buffer，那是占空间，但有可能是方便软件维护
typedef struct
{
uint8_t reg[4];
}reg_t;
如果是这样的 映射到一个寄存器 可以按uint8_t大小访问吗 还是访问其中一个uint8_t内部实现是整个32位读出来 获取8位？
因为我看到有一些就是这样定义的 都是4字节对齐
最近编辑记录 Jin劲 (2018-08-16 13:26:12)
离线
#pragma pack(1)
typedef struct
{
uint8_t reg[4];
}reg_t;
#pragma pack()
这样才会 uint8_t 对齐
离线
达克罗德 说：结构体的声明只是声明，本身不占空间。
如果没有定义实例而是直接映射到寄存器空间，那么就不占空间，因为你寄存器本身就在那，把寄存器空间按照结构体来访问而已
如果是拷贝一份作为buffer，那是占空间，但有可能是方便软件维护typedef struct
{
uint8_t reg[4];
}reg_t;如果是这样的 映射到一个寄存器 可以按uint8_t大小访问吗 还是访问其中一个uint8_t内部实现是整个32位读出来 获取8位？
因为我看到有一些就是这样定义的 都是4字节对齐
是的，ARM环境对uint8都是先读32位再取8位的
所以同理，定义变量时你用uint8_t, uint16_t效率是不高的，一般如果对省内存没要求的话，我都是定义32位变量。当然，因为你是映射寄存器，所以这样的reg_t是应该这样定义
离线
Jin劲 说：达克罗德 说：结构体的声明只是声明，本身不占空间。
如果没有定义实例而是直接映射到寄存器空间，那么就不占空间，因为你寄存器本身就在那，把寄存器空间按照结构体来访问而已
如果是拷贝一份作为buffer，那是占空间，但有可能是方便软件维护typedef struct
{
uint8_t reg[4];
}reg_t;如果是这样的 映射到一个寄存器 可以按uint8_t大小访问吗 还是访问其中一个uint8_t内部实现是整个32位读出来 获取8位？
因为我看到有一些就是这样定义的 都是4字节对齐是的，ARM环境对uint8都是先读32位再取8位的
所以同理，定义变量时你用uint8_t, uint16_t效率是不高的，一般如果对省内存没要求的话，我都是定义32位变量。当然，因为你是映射寄存器，所以这样的reg_t是应该这样定义
定义变量时你用uint8_t, uint16_t效率是不高的 哇 又学到东西了
离线
楼主位的只是定义了类型，又没有定义该类型的实例，不占空间的，访问寄存器时只需要定义一个指向该类型的指针不就可以直接按名字访问寄存器了！
离线