【此坑已弃，谢谢各位】0.关于STM8S库的封装

辛昕

【此坑已弃，谢谢各位】0.关于STM8S库的封装 [复制链接]

此坑已弃，谢谢各位的持续回复！    写在正题以前：为什么是stm8s003

         前阵子学AD，画了一块stm8s003的最小板，打了100片，然后就扔到淘宝上，在朋友的店里挂着。

         下面是链接（我本来是很不习惯打广告的，感觉怪怪的，不过先前和 楠哥打招呼，所以也就放了。）这里特别说一下，这个例程系列只是配合这个链接，不管买不买，其实我还是对 程序 特别是有针对性的例程更感兴趣，所以，希望这些代码可以帮到大家，提速大家的开发。STM8S的库是统一的，理论上来说，这些例程也可以方便的换到其他型号上使用——方便到什么程度？方便到只需修改器件型号即可——当然如果IO你换了位置当然也要换换是不是？
         空PCB  http://item.taobao.com/item.htm? ... xDlx&id=36592100056
         最小板 http://item.taobao.com/item.htm? ... 1551&_u=k3ba1jb7c5e
         
         算是随便摆着卖。有需要的朋友——这样呢，你可以省去不少麻烦，又是画板，又是打板，花钱花时间，这种方式呢，大家就当是省事吧（也省钱）。因为只是一个最小板也没什么特别。它的最初目的是方便以后直接配合洞洞板做一些比较简单的小项目，DIY,或者是目标板打样以前验证用。
         为什么是stm8s003，这里随便扯几句。

         选哪种单片机作为一个通用性使，每个人根据自己的经验会有不同的选择，我个人倾向意法：
         一则它是欧美系（欧美系意味着很多东西，电性能有保证，开发环境先进高级，无须担心什么只能汇编）；
         二则它容易获得；
         三则价格便宜（高性价比）；
         其实从51到stm8，到现在逐渐过渡到stm32。我选单片机不以8位或者32位，或者ARM非ARM作为理由，我只看需要不需要，弄起来方便不方便——这个涉及到很多比较琐碎的细节，比如下载器，开发环境，是否具备c乃至c++编译器 等等等等......这个确实也是和经验有关系。
         stm32f030这个系列的出现，彻底消除了我对32价格的担心，于是这个时候，stm8这个系列，只剩下stm8s003f3P3这个型号我还感兴趣。因为它的确很便宜，而且内设也相对比较丰富，可以干很多事情，特别适合简单小应用。所以，我才选择了拿它打一批板。

         好了说了那么多，沙发进正题。

辛昕

相信大家见到的绝大多数st库，不管是8位还是32位，都是采用直接包含所有的源文件，这样则不论用到什么外设，都可以无须再添加。
       但这样会造成一些麻烦，比如有时候编译起来会比较慢——这个地方我也想不明白为什么，因为那些都没有变化过，当然这是有时的，也说不定。
      而一个更深层次的麻烦在于两点：
      1.哪怕只是一个简单到只有GPIO 定时中断的简单应用，都有大量的源代码，在代码的管理上会造成不必要的麻烦。
    2.这个说了很多次，事实上，任何具有通用性的代码封装成库都是为了这个目标：
     避免一个通用代码的同步问题。
    不管什么库，在使用过程中都有可能要改动，如果只是把代码直接嵌入项目，很可能出现不同项目使用的库实际上是有细微差别的，这会使得这些库的管理变得更加麻烦。
    所以，我的惯用做法是 封装成不可见不可改动的 二进制可执行库。然后链接编译。

    随之附上我自己用于编译这个库的项目文件夹。

    stm8s105-lib-20131220.rar (2.36 MB, 下载次数: 741)

2013-12-20 16:40 上传

点击文件名下载附件

stm8s105-lib-20131220.rar (2.36 MB, 下载次数: 741)

2013-12-20 16:40 上传

点击文件名下载附件

    在IAR下编译库其实很简单。就是在option->General Option中的Output页中的 Output file中勾选 Library就可以了，默认勾选 Executable。

[ 本帖最后由 辛昕 于 2013-12-20 16:40 编辑 ]

辛昕

1.首先我使用的是IAR这个IDE，但是使用其他的IDE，应该也不是太大的问题。
   这种编译和使用库的方式，其关键，说白了，也就是设置搜寻头文件的路径而已。没什么太大不了的。
2.以下的说明，来自上一个楼层附件中的说明文档：
    1.STM8S库版本号 V2.0.1 / 18-November-2011
*补充： 本库中的 I2C 源码
        stm8s_i2c.c;
                stm8s_i2c.h；
    在跑相关i2c例程时，无法调通。后朋友帮忙调试时，找到一个来自早期库版本
(V1.1.1 / 09-May-2009)的i2c，方解决；
    此处尚未经过严密查证，暂且放下，特此说明；
3.关于IAR设置头文件路径的方法，设置位置 点击 右侧项目名，前面带个蓝色实体方块，选option。
   在其中的  c/c++ option中切换到 preprocessor页。
这里也要说明的是：
   本系列例程，为了避免因为过度依赖 ide环境文件设置造成 在不同MCU，不同开发板，乃至不同ide等开发环境上的移植遇到麻烦。
   本系列例程，除了头文件路径以及器件型号选择，拒绝使用任何额外设置。
   ——这么说的意思是，希望你也能提供经过你确切验证，并且能指明在何种型号MCU上，有比较详细说明，比较单一功能纯粹的例程（关于这个，过后会整理一个贴，单独发。）

辛昕

其实关于st这个库，早就想骂他了。
最好是骂他骂到狗血淋头。

但是也罢，如果爆粗能解决问题，那我们都爆粗去好了。

事情是昨晚决定接着做stm8s003系列例程，这次是简单的串口。
虽然是很简单的，但是因为我马上就能用上，所以我还是决定先做这个。

在使用库的时候，因为我过去一直用的型号是stm8s105，这型号上面只有一个uart2，而现在的stm8s003只有一个uart1，链接库时提示打不开uart1。
我忽然想起st库很操蛋，有很多根据型号才打开的条件宏。

于是我就下决心收拾一下这个该死的库。
我本以为只不过是打开外设而已，这没什么了不起。

于是我逐个逐个断开。
OK编译通过。

接下来一个该死的麻烦是 assert_param这个函数。
它把实现方式提供给外部应用程序，但是大多数时候它只不过是简单的死循环。
其实这个函数大多数是用来检查 参数是否在enum的范围内。
这个地方用死循环是有毛病。

1.假如是编程时传递错误，那么，这个错误最简单最合适的处理方式应该是 #error#，直接编译出错，提示编程者；
2.而假如是在运行中出现计算错误，这个，我想，实现这个宏的那个混蛋就是这样想的，他让它死循环。
可是能造成死循环的情况有很多，于是这个混蛋就这样混淆了隐藏了这个很简单的错误。

当然，这个地方其实是很不好处理的。
但是，我决定把它关闭了。

因为一个稍微像话点的库，不应该有这种特性——
每使用一个不同系列的stm8s芯片都要回到库去重新打开某些条件编译然后重新编译。
如果是这样，我情愿单独封装成N个stm8sxxx库。

话说回来这个st库，其实有好些地方，看得出来它是像模拟C标准库
比如他自己实现的assert断言功能。
可是，很多地方实现的画虎不成反类犬，真让人想抽死他。
比如我昨晚就特么想抽死他。

也罢，暂时没啥闲心可以淡定地考虑怎么收拾这个库，先押着。
我现在的目的只是如何做到剔除那个该死的 MCU类型宏选项。

辛昕

对stm8s库 修改的一个想法：

       其实我也说不清楚为什么这件事情让我突然这么冒火，也许是类似的代码和库见多了，也或者单纯只是它没有符合我的想象那样工作，因而耽误了我的进程——我本以为在003上重复一个串口例程，不过十几二十分钟的事情......
       当然了，我必须接受，总是有很多事情不如人意，可惜，在代码这件事情上我还是做不到。

       算了不扯这些没用的，写完赶紧吃饭去。

       再次说明，前面我试图简单去掉所有和 器件型号 有关 的条件编译宏 是非常天真的。
       这有两个原因：
       1.客观原因，相同的外设具体到不同型号上，规格，性能不一样，当然的，库涉及的代码也有所有区分，如果我想简单的单纯去掉所有限制，也就相当于保留了一个最大的功能集合——在编译体积上我可以不就结，在运行时间上我想也许我也可以稍微放松一下，但是我就怕它最后合在一起出事——因为从这个库的实现手法来看，他从一开始就没有考虑过这种情况，它只是不断地在 条件编译，万一出现冲突，事情就闹大了。
       ——这种事情，我真的遇到过。
       2.这个库的原因，如上所说，它从一开始就没打算这种 保留最大功能集合，而只是应用者调用时有差异使用，那么，我修改起来就会非常痛苦——我需要遍历整个库的源码，头文件，去一句一句删掉。
         那么，以后如果出错要恢复呢？这几乎是不可想象的。

      因此，我停下来，决定先吃饭，因为这件事情显然到今天晚上吃晚饭以前，如果照这样疯狂的干下去，我也不知道能不能完成。
      至于其后遗症更是想都不敢想。

      那么，其实，最简单的事情，就是——
      封装几个子库
      像我以前一样，stm8s105系列一个库，现在stm8s003一个库。那就什么事情都没有了。
     
      ——之所以在库里遍布了这么多的条件编译，甚至是在实现代码里也是，无非也是求一个通用。
      通用是一个非常伟大但是也同样非常大代价的事情，如此，我怎么可以和它一样犯同一个错误呢？

      好了，吃饭去～～

辛昕

其次，采用 CLK_GetClockFreq() 这个函数获取系统时钟，也有不妥当之处。
因为这个函数依赖一个外部宏，那就是 HSE_VALUE;
因为事实上，STM8S内部没有真正可以用于采样获取时钟频率的硬件。
它只不过是通过 寄存器（对HSI LSI），以及这个 HSE_VALUE宏来确定频率。

我们都知道，如果我希望把这个库单独封装，那么，对外部晶振频率这种随时会变化的环境，采用宏写入库，那将是一个大麻烦。

因此这个地方是造成这个 库无法单独封装 的又一个障碍。

我暂时没想到太好的办法。
但显然，这个地方是一个隐患。

过后也许会考虑比较单纯的，采取单独增加填写 BRR1 BRR2寄存器的函数，或者想办法把外部晶振频率传递入库，让它可以获得真正的 实际频率。

注：此内容引用  [开源/进行中直播] 【stm8s003系列例程】2 基本串口收发（中断接收方式）
【stm8s003系列例程】2 基本串口收发（中断接收方式）
https://bbs.eeworld.com.cn/thread-428053-1-1.html

god_of_death

学习了

610537129

分享下，谢谢搂住

什么鬼

mark

zxcm

你好，我最近刚上手STM8，用的是STM8S003，我遇到一些问题能否帮忙解决一下，在我使用STM8S003 AD的时候采样转换值一直为0，搞不懂哪里出来问题，不知道这种情况你有遇到吗？打扰之处还请谅解，谢谢。

fdsjens

学习了，谢谢

么么小辉

谢谢了

maxims

哇喔，写得好精彩。