[原创] 【手机DIY】辛昕6. stm32f0的串口 和 定时中断

辛昕   2014-7-12 22:05 楼主
这两个晚上,因为上班的事情有点小紧张,所以就暂时停下了 之前的 HMI接口的设计。

这两个晚上在调整的活儿主要是和一个队列有关(虽然后来发现其实队列是没有问题的)
所以顺带把队列测试,和 整理好了。

这个队列也是可以直接用在 手机DIY的项目上的——串口接收。

然后,事情过去了,昨晚周五休息了一个晚上,和朋友聚在一起聊天。

因为朋友是开咖啡厅的,我们在里头常常聚会,时间久了,看店的继续看店,我就在那对着笔记本继续调调程序。

stm32f0因为比较新,官方例程库里都不带串口,废了不少劲搞定了——但是不带中断的。 刚刚也就是这里没搞定。

定时中断也顺带调好了。

先发这个贴。
因为资料不好找,弄得有点小累了,考虑到上班还有个 汉字编码 的问题要解决,所以,先弄一弄,也当是休息。




强者为尊,弱者,死无葬身之地

回复评论 (11)

哦,对了,一会搞一搞,把队列的部分发出来~~ 顺带分析一下在不带重载功能的C语言里,该如何处理它的发布问题。 至于HMI界面。 我尽可能尽快解决了 串口的接收中断,假若不行,也先放下——即使最后我搞不定,我也一样有办法处理这个东西。 HMI界面将安排在这之后。 到时候内容和源码会继续发在 【手机DIY】辛昕5 里,省得那个贴变成了 标题党~~~ 本帖最后由 辛昕 于 2014-7-12 22:07 编辑
强者为尊,弱者,死无葬身之地
点赞  2014-7-12 22:05
感觉楼主好尽心尽责,工作兴趣两不误
点赞  2014-7-12 22:27
终于有点时间坐下来继续写代码了。
最近,坛里的一个朋友问我相关的AT的问题,以及我自己遇到的一些自己的经历,听朋友说的情形,我都认识到,分层是非常重要的。

而我过去所做的努力,也一直是朝着这个方向去的。
然而我回头看看我uLib uS时干的时候,我发现我的设计思路还是在不断变化。

比如串口,我曾经因为采用 超时机制 的方式来解决串口接收问题。但我最终发现这个东西今天我居然不能马上搬过来用,这就是一个设计失败的信号。

我自己想了想,发现问题所在,我对底层的抽象还是不够根本,彻底。

我曾经设计的思路可以说费劲了我的心思,估计很多想看的人也被我弄晕了。
然而我今天重新想了这么久,居然发现,我现在设计出来的东西居然简单到只有 下面 两个声明。
  1. /*
  2.      我们在实际中,会使用各种方式,中断,查询......
  3.      但是,从软件的角度来说,串口只不过是 发送一个字节,接收一个字节;
  4.    
  5. */
  6. int Uart_Send_Byte(char b);
  7. int Uart_Recv_Byte(char *b);


强者为尊,弱者,死无葬身之地
点赞  2014-7-17 00:03
当然,事情还要往细里想一想,不能把我在uLib时的所有考虑都抛到后边去。
我当时考虑的事情有
1.对象化 —— 串口不止一个啊,我不希望每一个都写一组函数啊;
2.异步化,或者说 非阻塞;
  ——在这种层次上——非应用层,我绝对不能允许它阻塞
说实话,这个限制非常严格,甚至会在某些情况下给我造成很大的麻烦,而且,假如我拥有一个多任务环境,这甚至是没意义的,然而为了让我的函数可以应用在更广泛的更简单的包含裸机系统,我必须做这种自我限制。

因为异步化,所以我让这两个函数都有了返回值。
甚至是 接收函数,我也没有使用 最自然的方式,用返回值承接接收到的那个字节。

因为这个返回值我是用来表达 收发状态的(是否完成还是在进行中),这样我就可以异步化。

而对于第一个问题,对象化,也就是说,我必须考虑很多时候我会有很多个串口,那么我该如何处理这种情况?
当然,在uLib过后,比如我前面在做 12864的显示驱动的封装时,我已经使用了一套很完整的方法。

这个很简单,因为 上面的这两个函数,其实只是我具体的底层提供的,至于 我用什么具体的方法(环形队列或者超时机制)也罢,我总是可以用一个指针接收这个真正的函数。

如此看起来,这个简单的设计似乎足够合理了。

先睡觉。
强者为尊,弱者,死无葬身之地
点赞  2014-7-17 00:09
下一步,我就要用不同于 uLib那时候的思路,来实现一个 环形队列 的方法,来实现 串口 的 数据帧的收发 驱动。

它接收的底层驱动有且只有两个
便是上面那两个 字节收发函数。

强者为尊,弱者,死无葬身之地
点赞  2014-7-17 00:11
Queue-20140717.rar (262.11 KB)
(下载次数: 39, 2014-7-17 17:41 上传)
强者为尊,弱者,死无葬身之地
点赞  2014-7-17 17:41
今天弄了弄 串口 收发(接收中断);

中间出了点奇奇怪怪的问题。
中间还怀疑过 直接 TTL 连 USB-TTL 有问题,半途焊了个 232转接电路.....

虽然最后啥都没用,感觉上代码没什么改动,不过现在看起来正常了。

但是,感觉几个库函数确实有点问题。
比如我先试着不中断,只在轮训里,直接查询收发,一个很奇怪的现象是,
本来我是发一个收一个,两个都是 堵塞的,按道理是我串口助手发一个就收回一个,但我发现它实际上是 发一个收两个;

更奇怪的是,我debug模式下,嘿嘿,他奶奶的,它居然给我正常了......

后来我在串口接收中断里发送,它又正常了。

这个地方预感肯定是有问题的。
但现在我决定,先整理接口。

强者为尊,弱者,死无葬身之地
点赞  2014-7-19 18:56
  1. void demo_uart1(void)
  2. {
  3.     static U16 dest = 0x0000;
  4.    
  5.     test_Led();
  6.    
  7.     while(USART_GetFlagStatus(USART1,USART_IT_RXNE) != SET);
  8.     USART_ClearFlag(USART1,USART_IT_RXNE);
  9.    
  10.     dest++;
  11.    
  12.     USART_SendData(USART1,dest);
  13.     while(USART_GetFlagStatus(USART1,USART_FLAG_TXE) != SET);
  14.     USART_ClearFlag(USART1,USART_FLAG_TXE);
  15. }


这个地方我想不通为什么,我特意让dest叠加。
于是我想,我不需要怀疑这个来自库的底层发送函数,所有问题只是在这个代码不知以什么原因出现了串口助手发送了一个,却造成了奇怪的两次判断到的标志。
强者为尊,弱者,死无葬身之地
点赞  2014-7-19 19:25
为适应AT(其实就是字符串格式的 串口数据串收发)。
已经完成。

还是使用做好的队列,改动极小。这也显示了 这个简单的,小小的抽象数据结构的威力。
如 C语言描述 的作者 Mark Allen Weiss 所说的那样

这些简单的操作,却显示出非常强大的功能,真是出乎人的意料。

之前老是没调通,主要是在某个函数的调用上。
说起来也是命名没起好,结果自己误会了自己。

现在搞定了。

正打算接上GPRS模块继续尝试真正的命令时,意外发现,上次重装电脑,GTM900的资料都放在桌面的文件夹里都丢了,真伤感。

于是想到打开论坛的帖子,我记得有几个哥们给我留了资料,呵呵~~

不过还是先洗澡吧
强者为尊,弱者,死无葬身之地
点赞  2014-7-24 23:07
代码一会稍微整理贴上——

这阵子因为调试中遇到一些麻烦,加上时间比较紧,怕给耽误了,所以暂时代码基本没整理过。
强者为尊,弱者,死无葬身之地
点赞  2014-7-24 23:07
路过。。。赞赞
点赞  2014-7-26 08:01
电子工程世界版权所有 京B2-20211791 京ICP备10001474号-1 京公网安备 11010802033920号
    写回复