IAR3.11.1forSTM8的优化设置选项

前言

用STM8S003F3P6做的实验板，用库函数编程，写了用例工程，将每个硬件都单独验证过了。
开始写正式程序，开始很开心，开开心心写代码。

只是搭了正式工程框架，将每个硬件基础操作代码，都挪进去，还在整理测试业务逻辑。整体进度还不到一半。突然编译时，报错说代码空间不够了…

Error[Lp011]: section placement failed 
            unable to allocate space for sections/blocks with a total estimated minimum size of 0x2d36 bytes (max align 0x1) in <[0x008000-0x009fff]> (total uncommitted space 0x1f80). 
Error while running Linker 

STM8S003就8KB代码空间。

这次做的东西，是有参考设计在那摆着的。
如果没有参考设计，我还好跟领导说，代码空间不够了，换个代码空间多点的MCU.
参考设计上，人家的STM8S003F3P6完成了几个功能点，我完成不了，跟领导开不了口。
开始在想，要不改寄存器或纯汇编编程，向领导多要1个月来做后续的任务。
还在想，将实现同样简单功能的寄存器版工程和库函数版工程编译出的MAP文件比一下，看看到底size差距有多大。
最后在想，不是有优化选项么？将优化开打最大，看看代码能放下么？
试了一下，果真可以放得下，不优化11.5KB的代码，现在不到6.1KB, 优化的很NB!

  6 151 bytes of readonly  code memory
  1 036 bytes of readonly  data memory
    314 bytes of readwrite data memory

Errors: none
Warnings: none

自己开始想多了:)
也尝试将IAR中其他设置改改，不过对生成的代码尺寸没影响。只有优化选项管用。
IAR3.11.1 for STM8的优化设置如下：

<2020_1006_2006>
发现随人优化了编译后的size, 但是程序访问外部设备的时序(延时)全不对了。
人家都写好验证过的驱动实现，优化后，设备取值不对了。是时序无效引起的。

即使有些延时相关的变量加上 volatile， 也不能正常访问设备(e.g. I2C)。
这有点头痛，换MCU?

<2020_1006_2017>
查资料，有同学说，IAR中， 可以在不允许优化的函数实现前面加上 #pragma optimize=none
试过了，采用最小size + #pragma optimize=none 指定不允许优化的函数。对设备的访问和延时都正常。先这样。

#pragma optimize=none
void delay_us(uint16_t nus)
{
  __asm(
    "PUSH A          \n"    //1T,压栈
    "DELAY_XUS:      \n"
    "LD A,fac_us     \n"    //1T,fac_us加载到累加器A
    "DELAY_US_1:     \n"
    "NOP             \n"    //1T,nop延时
    "DEC A           \n"    //1T,A--
    "JRNE DELAY_US_1 \n"    //不等于0,则跳转(2T)到DELAY_US_1继续执行,若等于0,则不跳转(1T).
    "NOP             \n"    //1T,nop延时
    "DECW X          \n"    //1T,x--
    "JRNE DELAY_XUS  \n"    //不等于0,则跳转(2T)到DELAY_XUS继续执行,若等于0,则不跳转(1T).
    "POP A           \n"    //1T,出栈
  );
}

#pragma optimize=none
void delay_ms(uint32_t nms)
{
  uint8_t t = 0;
  
  if (nms > 65) {
    t = nms / 65;
    while (t--) {
      delay_us(65000);
    }
    
    nms = nms % 65;
  }
  
  delay_us(nms * 1000);
}

<2020_1007_1616>
程序空间还是不够(进度才3/4)，而且优化后，发生了栈溢出的问题。因为单步优化后的程序，只能看个大概。不容易找出原因。

比较了一下同样功能的小程序，寄存器版本比库函数版本编译后占用的程序空间要小几百个字节，内存占用都一样。但是程序编译出来后，都是几百个字节的规模啊（库函数版本600bytes, 寄存器版本280bytes）。

现在准备改一个寄存器版本的，不优化。单步调整和验证实现。这样就不会出现程序空间不够的问题。

优化都是没招时，采用的方法。而且不是很靠谱，会出一些意料外的事情。最好就是不采用编译器优化（如果程序空间够）。
<2020_1021_2122>
感觉程序空间不够，准备换MCU. 多9毛钱。领导不同意。他的理由也充分，基本相同的硬件电路，参考设计行，你为啥不行.

啥也不说了，直接用寄存器版编程实现。空间也不够。
通过MAP文件，检查主要矛盾，发现显示代码一上来就6KB.
采用IAR low优化，程序空间也不够。
将显示代码优化后，剩出2KB. 继续硬着头皮去写后续代码。
将菜单处理快写完时，程序空间又不够了。
继续看map文件，大于100个字节的函数都看了，没有优化空间。
没招了，将延时函数不优化。然后采用IAR high size优化, 仁慈的IAR编译器帮我省出来1.4KB.

将菜单处理写完，再写modbus协议回包。知道空间有限，只写个最简单的回包处理。
最后调试过，初步测试一下通过。
最后一看map文件，程序空间只剩470字节…

改天有时间，再从这个寄存器版本移植一个库函数版本看看，反正正常些程序空间都是不够，看看IAR编译器high size 优化，是否8KB的STM8S003F3也能完成同样的功能?