思考的越多,发现以前做的项目漏洞百出,现在想全面推翻重做。

wuwoliu 2015-07-12 10:35:49
项目软件部分不大,当初做的太简陋了,但是现在想想应该涵盖了很多概念,所以要重新写一遍。

功能:每100ms,调用一次硬件静态库里的函数读取得到float数组(32长度,一维),调用10次后,加起来求平均,求完平均值后,正好是1秒钟,调用自己写的显示函数fa显示数据(用textout函数,为了显示更快),清空计数等下一个10次。
每100ms,调用一次硬件静态库里的函数读取得到一个十六进制数,取位得到0或者1,有变化(从0变成1,或者从1变成0)时,调用其他函数,并由上一个显示函数fa显示出来。
每1秒,向串口发送一次某协议的读取字符串,发送之后50ms内,用硬件提供的函数改变串口的接收电平状态,使串口处于接收状体,50ms是下位仪表反馈的最长时间,所以要在50ms内改变电平状态,接收完数据,再改变一次电平状态。
通过虚拟键盘消息,接收键盘输入的信号,并调用显示函数fb显示出来。

编程要求:用mfc基本对话框。
以前做法:全部用设定定时器settimer,精度不高,但可以保证是10次平均之后才显示的。读取十六进制数,不是实时的,有一定延迟。串口这里问题大了,不知道发送缓冲区什么时候发完的最后一个字节,设定高低电平就不好用,有时候快,有时候慢,而且settimer精度要有55ms(不知道是每次都延后55ms,还是有延后有提前),导致有时候发送不全,有时候接收不到。ontimer里如果定时器太多,假如有同时触发2个定期器,是同时进行,还是按消息队列先后顺序,一个一个进行。如果一个接一个进行,其中一个定时器里函数太长,是不是也影响下一个定时器的准确度。

想这样做:使用mfc基本对话框的界面线程,在初始化的时候,启动其他几个线程。线程1,循环采集十六进制数,如果有改变,调用的函数也写在该线程下,通过线程发消息把十六进制数发给界面线程显示,显示可以滞后一点,动作反应要实时。
用多媒体定时器,定时100ms,10次之后求平均,并调用显示。
键盘消息仍旧写在界面线程里。

串口这里想不到好办法,如何获取发送缓冲区发送最后一个字节的时间,并使用多媒体定时器,来改变电平。串口接收创建一个线程,循环接收,并处理显示数据。

大家帮忙看看,重新做的,这样构架程序可以吗?
...全文
149 6 打赏 收藏 转发到动态 举报
写回复
用AI写文章
6 条回复
切换为时间正序
请发表友善的回复…
发表回复
cs1438250 2015-07-15
  • 打赏
  • 举报
回复
引用 5 楼 zhao4zhong1 的回复:
Multiple Threads in the User Interface http://msdn.microsoft.com/zh-cn/library/ms810439.aspx
看完了,我做的程序线程之间通信少,同时访问全局变量没有。底层硬件总线也没冲突,还是多线程比settimer好多了。
赵4老师 2015-07-13
  • 打赏
  • 举报
回复
Multiple Threads in the User Interface http://msdn.microsoft.com/zh-cn/library/ms810439.aspx
wuwoliu 2015-07-12
  • 打赏
  • 举报
回复
引用 3 楼 worldy 的回复:
这么简单的东西,本身就没有多少架构的问题,把逻辑思考清楚,安照清楚的逻辑走一遍就成了
软件只是小副本,硬件的比较重要。settimer现在看肯定是不行了。只能用线程了。
worldy 2015-07-12
  • 打赏
  • 举报
回复
这么简单的东西,本身就没有多少架构的问题,把逻辑思考清楚,安照清楚的逻辑走一遍就成了
wuwoliu 2015-07-12
  • 打赏
  • 举报
回复
引用 1 楼 jiqiang01234 的回复:
MFC的对话框模式,反而不如win32 sdk来的方便。毕竟MFC库的一些东西自定义起来不是很方便。如果用win32 sdk来实现,可以把消息循环和事件循环统一起来(使用MsgWaitForMultipleObjects (...)) ,这样处理起非阻塞的事件会很方便,就可以用CreateWaitableTimer (...)之类的内核对象来定时。串口操作用ReadFile()和WriteFile()的非阻塞模式overlapped来实现。总之,整个系统处于非阻塞模式下,及时性比较有保证(当然,前日是每个函数调用,不能有太费时的操作)。
觉得那个硬件有问题。电平调整不应该由应用程序来做,应该是底层硬件
jiqiang01234 2015-07-12
  • 打赏
  • 举报
回复
MFC的对话框模式,反而不如win32 sdk来的方便。毕竟MFC库的一些东西自定义起来不是很方便。如果用win32 sdk来实现,可以把消息循环和事件循环统一起来(使用MsgWaitForMultipleObjects (...)) ,这样处理起非阻塞的事件会很方便,就可以用CreateWaitableTimer (...)之类的内核对象来定时。串口操作用ReadFile()和WriteFile()的非阻塞模式overlapped来实现。总之,整个系统处于非阻塞模式下,及时性比较有保证(当然,前日是每个函数调用,不能有太费时的操作)。

16,475

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • Web++
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧