标签存档: 数组

在 IAR 中定义大数组变量,导致程序不能运行的解决办法

解决方法
在 IAR 中定义大数组变量,导致程序不能运行的解决办法总结
MSP430 大数组定义,不能正常运行的问题

定义太大的 RAM,那就有可能会遇到 RAM 中定义的变量/数组在超过一定范围的时候,MSP
程序不能正常运行的现象吧.一般初步判断,可以用 I/O 输出电平来确定程序进程.这样可以非常方
便的知道该问题是由于 WDT 造成的,(RAM 的初始化时间大于 WDT 默认的 32MS 时间,因此 MSP
复位)

下面来看下解决的办法:

A、 对数组用 __no_init 定义,上电编译器不产生特殊的附加函数去初始化 RAM
例:__no_init u8 GprsTXBuf[1000]; 注意关键字以两个下划线开头,尾部没有下划线,
中间一个下划线。

B 、修改 IAR 中 Cstartup.S43 文件中__program_start 子程序,增加一个关闭 WDT 的操作或者
设置 WDT 时间长度超过 32MS。(建议不到万不得已,不要改这个文件!)
文件地址:IAR Systems\Embedded Workbench 6.0 Evaluation\430\src\lib\430

C 、在 Project–Options–Linker–Config中选择 Override default programe,并将 Entry lib 设置
成 __program_start

上述是已知解决 RAM 初始化时间超 WDT 默认而复位的解决方法

一般编译器中 C 项自动开启,只要加上 A 项就可以解决问题,B 项在不清楚的情况下,不建
议做修改。

本文摘自网络。

 

大意了,又一次遇到指针问题

又一次遇到一个指针引起的问题,没有让他成为bug,呵呵。

看看这条语句:
memcpy(&g_GlobalBuf+DF_POSI_FEE_RATE,(const u8 *)&FeeRate,70);
本意是要把FeeRate数组中的内容拷贝到u8型数组g_GlobalBuf数组中从第 DF_POSI_FEE_RATE 个元素开始的空间中。但实际得到的结果是  &g_GlobalBuf+DF_POSI_FEE_RATE 指向的地址偏移了十万八千里,实际上错误的偏移量为 sizeof( g_GlobalBuf )* DF_POSI_FEE_RATE,也就是说偏移了 DF_POSI_FEE_RATE个 g_GlobalBuf数组的空间。

原因:很简单, &g_GlobalBuf 是一个指向数组的指针,而不是一个 u8* 指针,所以  &g_GlobalBuf+1 指向的是下一个数组的首地址而不是 g_GlobalBuf[1] 这个元素。

正确的写法: &g_GlobalBuf[DF_POSI_FEE_RATE ]  或者 (u8 *)( &g_GlobalBuf )+ DF_POSI_FEE_RATE

———————-添加一个指针与数组的小知识点  2014/10/28  —————————–

定义: char a[2][10],则如下:
+ &a 0x0012ff20 unsigned char [2][10]*
+ &a[0] 0x0012ff20 unsigned char [10]*
+ &a[0][0] 0x0012ff20 unsigned char *

在清空数组时使用sizeof的好处

在程序中,有时候我们需要清空数组,一般定义数组时使用一个BUFF_SIZE宏,晴空数组时也使用这个宏。

但是其实有更好的方法,使用sizeof宏。在所有的数组晴空操作中都使用sizeof宏的好处是可以有效避免数组越界。

例如:

u8 TxBuff[32]  = {0};

for (i=0;i<sizeof(TxBuff);i++)
{
    TxBuff[i] = 0;
}