读取：pgm_read_byte(&x[0][0]); pgm_read_byte(&x[0][1]); pgm_read_byte(&x[1][2]); 读取并赋值给SRAM变量：uint8_t sx = pgm_read_byte(&x[0][0]); 也可： uint8_t sx[2][3]; sx[0][0] = pgm_read_byte(&x[0][0]);
另一种定义方式： uint8_t x PROGMEM = 1; 等价于 prog_uint8_t x = 1; uint8_t x[] PROGMEM = 1; 等价于 prog_uint8_t x = {1, 2, 3, 4}; ... ... 这种定义方式更为灵活，比如可以定义结构体数组： struct st{ uint8_t x; uint8_t y[100]; };
const struct st arr[] PROGMEM = {... ...}; 如果是第一种定义方式，是无法定义结构体常量的
可以看到，处理定义和取值方式不同，其它操作都是一样的。除此之外还有更多的常量定义形式： prog_void、 prog_char、prog_uchar、prog_int8_t、 prog_uint8_t、 prog_int16_t、 prog_uint16_t、 prog_int32_t、 prog_uint32_t。 读取方式有：pgm_read_byte(), pgm_read_word(), pgm_read_dword(), pgm_read_float。其参数 都是短整型地址，要注意的是读取函数必须在函数中才可以使用。另外，AVR的SRAM和FLASH是独立编址的， SRAM是8bit编址，FLASH是16bit，所以在FLASH赋值/赋址给SRAM变量时，根据编译器的不同可能要进行强 制转换，如uint8_t x = (uint8_t)pgm_read_byte(&y),否则可能会出现警告或错误。
附：如果是在ICCAVR中，直接配置编译选项”treat const as __flash“即可将const常量都存储在FLASH ，读取时使用img[]。注意，配置此选项后，所有的const都将存储在FLASH中，这相比WINAVR也是一个缺点。
编译器或IDE选项 Release版本 和 Debug版本的区别：
Debug 为调试版本，调试版本使编程人员集中于程序逻辑设计，而不用考虑程序的细节问题，比如变量初始化、数组越界、内存对齐、数据类型转换、动态内存释放等等，这些任务 在Debug版本中 编译器都帮你做了，你只需几种精力解决逻辑部分。
并且，debug版本还支持中断调试、逐步调试等等功能，允许程序员在某些位置设定标志位，允许在程序运行时查看变量值等等。
因为如上原因，debug版本的程序相对比较大。
如果程序在Debug版本中运行通过了，那至少证明一点：你的程序逻辑是正确的。
Release 为发布版本，很多情况下，从Debug版本切换到Release版本后会出现程序错误的现象，原因就是Release要观察所有程序的细节了：没有初始化的变量、越界的数组、数据类型转换导致的精度丢失、动态内存没有及时释放等等，
如果在Debug版本中可以运行，而在Relase版本中不能运行，你至少不用去理会程序逻辑问题了，而原因可能有：
- 上述提及的 变量、越界、转换、内存 等等细节问题要检查修复
- Debug和Release版本，在一些IDE中它们索引资源的路径不一样，比如库的路径、头文件的路径等等，并且对索引资源要求也可能不同，比如要使用一个库A，库A还分Debug版本和Release，那么在引用时就要注意版本问题
- IDE的重新编译问题：一些IDE，当切换了版本之后，比如VS2008，如果你直接按F5调试运行，可能会报错一大堆，那可能并不是真的有问题，而是VS2008不检查上次的目标文件是什么版本生成的，导致Debug版本生成的目标文件还存在，release版本就直接拿这些来编译链接。所以最好的做法是，无论是维护别的程序还是自己切换了版本，第一步就是“重新生成解决方案”。
-->
2022年6月17日 09:30:09
char c = -1;
if ( -1 != c ) { .... } //这段代码竟然工作了！！！
环境：ARM7_LPC2214, ARM GCC
原因是，整个环境中的常数都是int类型的，-1赋值给c时，只赋值前8bit， 当进行对比时，-1当然不能等于c，
实际的比较方法应该是：if ( (char)-1 != c )..
给-1强转之后，比较的就是-1的前8bit，结果就是相同的
这个跟操作环境也有关系，测试X86下没有问题