本来早就应该写的。

可行性：Mega128处理图像（主要是图像格式及大小转换）能否胜任的问题，是否要借助fpga/cpld加以实现？-_-# —> ^_^

1. Gprs模块：TR800相关数据手册， 注意ATE0这个命令（让我郁闷了一阵），此后决定认真的重读数据手册。

2. Xmodem通信协议（已写）。

3. Spi总线：XF-S4240语音芯片的通信方式有I2C,SPI,UART,选用SPI。

设置如下：atmega128- SPI初始化时，将PORTB的MOSI、SCLK和SS引脚作为输出，同时将MISO作为输入引脚，并打开上拉电阻，设置主机模式，高位优先，数据速率f/ 16。

SPI的寄存器进行初始化设置时，应注意以下几点：
    .正确选择和设置主机或从机，以及工作模式（极性），数据传输率；
    .注意传送字节的顺序，是低位优先（LSB First）还是高位优先（MSB Frist）；
    .正确设置MOSI和MISO接口的输入输出方向，输入引脚使用上拉电阻。

4. Usart：由于数据量比较大，误差累积将导致后面的数据出错，故用无误差的晶振频率（试过用16Mhz，但往往是只有前面的一小部分数据正确，往后的数据都出错，改用11.0592后没有发生过数据出错问题，出错就重传）；中断+数据缓存区（FIFO），若直接对buffer操作，则注意先把index置零。

5. 全彩Led屏通信协议：由于屏只有windows下的开发dll，肯定不能用在atmega128上了，屏提供的windows程序与Led屏的通信用serialport分析得到通信协议格式。

6. 摄像头通信协议：使用的是zm460，RS232接口,相当郁闷的是数据手册是有误的，只能设定被动模式，而且波特率不能改动，加上指令格式有些错误，庆幸的是有串口监控。

7. 串口硬件设计：公、母串口要配备好，弄清串口线需要交叉还是直通，gprs模块要求硬件流控制信号(rts&cts)，不用则将其屏蔽掉（7-8短接），否则不能通信。

8. 红外探头:测试后，红外探头没有描述的灵敏，没办法，只能把红外检测程序考虑完善（就利用这个不灵敏的特点），经调试最后得到很好的稳定性。

9. 图像转换：jpeg->xmp

10. 硬件的布局及布线:

布线要合理，不要跳线太多，做pcb布线的话还是好好的学习一下其相关理论。

后期正式做板时，由于硬件布线不好，程序经常跑飞，那种心情叫无奈。

提高硬件可靠性的考虑： 

硬件-

.大面积铺地(网格)；

.晶振用地围住；

.每个IC的VCC加上一个0.1uF的电容。

.外围设备控制光耦隔离

软件-
    .采用振荡电路的输出小幅度；
    .选择合适的启动延时参数 ；
    .片内的看门狗 ；
    .不用I/O口设定输出低电平 。

由于没有JTAG仿真器，程序的调试都是用串口回传数据，在适当的地方设置把裸机上的数据回传同样起到仿真器的效果。

前言：把前段时间做的事情总结一下。

DATA STRUCTURE IN RAM

  Many of the devices that are possible targets of avr-libc have a minimal amount of RAM. The smallest parts supported by the C environment come with 128 bytes of RAM. This needs to be shared between initialized and uninitialized variables (sections .data and .bss), the dynamic memory allocator, and the stack that is used for calling subroutines and storing local (automatic) variables.

  Also, unlike larger architectures, there is no hardware-supported memory management which could help in separating the mentioned RAM regions from being overwritten by each other.

  The standard RAM layout is to place .data variables first, from the beginning of the internal RAM, followed by .bss. The stack is started from the top of internal RAM, growing downwards. The so-called "heap" available for the dynamic memory allocator will be placed beyond the end of .bss. Thus, there's no risk that dynamic memory will ever collide with the RAM variables (unless there were bugs in the implementation of the allocator). There is still a risk that the heap and stack could collide if there are large requirements for either dynamic memory or stack space. The former can even happen if the allocations aren't all that large but dynamic memory allocations get fragmented over time such that new requests don't quite fit into the "holes" of previously freed regions. Large stack space requirements can arise in a C function containing large and/or numerous local variables or when recursively calling function.

   avr-gcc的栈由内部RAM的顶部向下生长，这样就潜在两个危险性：一是动态分配的堆和栈有可能互相覆盖；二是.data &.bss的数据过多和栈数据覆盖。实际上以上两个问题都发生了，图像数据10Kbytes左右，处理时所需空间大概30多Kbytes（动态+静态）。小插曲1：当时由于LED彩屏的中间位置图像发生奇变才注意到这个问题-_-!

Note:

The pictures shown in this document represent typical situations where the RAM locations refer to an ATmega128. The memory addresses used are not displayed in a linear scale.

RAM map of a device with internal RAM

  On a simple device like a microcontroller it is a challenge to implement a dynamic memory allocator that is simple enough so the code size requirements will remain low, yet powerful enough to avoid unnecessary memory fragmentation and to get it all done with reasonably few CPU cycles. Microcontrollers are often low on space and also run at much lower speeds than the typical PC these days.

  The memory allocator implemented in avr-libc tries to cope with all of these constraints, and offers some tuning options that can be used if there are more resources available than in the default configuration.

Internal vs. external RAM

  Obviously, the constraints are much harder to satisfy in the default configuration where only internal RAM is available. Extreme care must be taken to avoid a stack-heap collision, both by making sure functions aren't nesting too deeply, and don't require too much stack space for local variables, as well as by being cautious with allocating too much dynamic memory.

  If external RAM is available, it is strongly recommended to move the heap into the external RAM, regardless of whether or not the variables from the .data and .bss sections are also going to be located there. The stack should always be kept in internal RAM. Some devices even require this, and in general, internal RAM can be accessed faster since no extra wait states are required. When using dynamic memory allocation and stack and heap are separated in distinct memory areas, this is the safest way to avoid a stack-heap collision.

Tunables for malloc()

  There are a number of variables that can be tuned to adapt the behavior of malloc() to the expected requirements and constraints of the application. Any changes to these tunables should be made before the very first call to malloc(). Note that some library functions might also use dynamic memory (notably those from the <stdio.h>: Standard IO facilities), so make sure the changes will be done early enough in the startup sequence.

  The variables __malloc_heap_start and __malloc_heap_end can be used to restrict the malloc() function to a certain memory region. These variables are statically initialized to point to __heap_start and __heap_end, respectively, where __heap_start is filled in by the linker to point just beyond .bss, and __heap_end is set to 0 which makes malloc() assume the heap is below the stack.

  If the heap is going to be moved to external RAM, __malloc_heap_end must be adjusted accordingly. This can either be done at run-time, by writing directly to this variable, or it can be done automatically at link-time, by adjusting the value of the symbol __heap_end.

  The following example shows a linker command to relocate the entire .data and .bss segments, and the heap to location 0x1100 in external RAM. The heap will extend up to address 0xffff.

avr-gcc ... -Wl,-Tdata=0x801100,--defsym=__heap_end=0x80ffff ...

  实际上如果你使用avrstudio内嵌gcc的话只要在Project->Configuration Options->Memmory中通过Add，选择Sram，在Name输入.data，Address输入0x801100即可，你也通过这个功能可方便移动自定义的数据或是默认的数据区。小插曲2：不知道是不是版本的原因，根据上面的方法在低版本（具体那个版本忘了，建议下载最新版）设置，完全没有效果，结果可以在编译信息或者看map文件，map文件很清晰的给出编译后数据的存放位置。如果你使用外部makefile或者是在PN下编译的话，你可以通过修改makefile中的Linker Options下的内容，如下所示：

#---------------- Linker Options ----------------

#  -Wl,...:     tell GCC to pass this to linker.

#    -Map:      create map file

#    --cref:    add cross reference to  map file

LDFLAGS = -Wl,-Map=$(TARGET).map,--cref

LDFLAGS += $(EXTMEMOPTS)

LDFLAGS += $(PRINTF_LIB) $(SCANF_LIB) $(MATH_LIB)

LDFLAGS += -Wl,--section-start=.data=0x801100

#加上上面这个语句即可以，当然上面的其他设置的关键参数也需要修改

小插曲3：把PN编译后的文件都删除时，再次编译时发现没有生成文件，有bug？关闭再打开又可以编译生成文件，但再次删除编译生成的文件时->再编译->仍旧没文件生成->bug,PN version v.2.0.7.667。

Note:

See explanation for offset 0x800000. See the chapter about using gcc for the -Wl options.

Internal RAM: stack only, external RAM: variables and heap

   If dynamic memory should be placed in external RAM, while keeping the variables in internal RAM, something like the following could be used. Note that for demonstration purposes, the assignment of the various regions has not been made adjacent in this example, so there are "holes" below and above the heap in external RAM that remain completely unaccessible by regular variables or dynamic memory allocations (shown in light bisque color in the picture below).

avr-gcc ... -Wl,--defsym=__heap_start=0x802000,--defsym=__heap_end=0x803fff ...

Internal RAM: variables and stack, external RAM: heap

    If __malloc_heap_end is 0, the allocator attempts to detect the bottom of stack in order to prevent a stack-heap collision when extending the actual size of the heap to gain more space for dynamic memory. It will not try to go beyond the current stack limit, decreased by __malloc_margin bytes. Thus, all possible stack frames of interrupt routines that could interrupt the current function, plus all further nested function calls must not require more stack space, or they will risk colliding with the data segment.

The default value of __malloc_margin is set to 32.

contd……