16,472
社区成员
发帖
与我相关
我的任务
分享思考的越多，发现以前做的项目漏洞百出，现在想全面推翻重做。
项目软件部分不大，当初做的太简陋了，但是现在想想应该涵盖了很多概念，所以要重新写一遍。
功能：每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次之后求平均，并调用显示。
键盘消息仍旧写在界面线程里。
串口这里想不到好办法，如何获取发送缓冲区发送最后一个字节的时间，并使用多媒体定时器，来改变电平。串口接收创建一个线程，循环接收，并处理显示数据。
大家帮忙看看，重新做的，这样构架程序可以吗？
功能：每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次之后求平均，并调用显示。
键盘消息仍旧写在界面线程里。
串口这里想不到好办法，如何获取发送缓冲区发送最后一个字节的时间，并使用多媒体定时器，来改变电平。串口接收创建一个线程，循环接收，并处理显示数据。
大家帮忙看看，重新做的，这样构架程序可以吗？
...全文
请发表友善的回复…
发表回复
cs1438250 2015-07-15
- 打赏
- 举报
看完了，我做的程序线程之间通信少，同时访问全局变量没有。底层硬件总线也没冲突，还是多线程比settimer好多了。
赵4老师 2015-07-13
- 打赏
- 举报
Multiple Threads in the User Interface http://msdn.microsoft.com/zh-cn/library/ms810439.aspx
wuwoliu 2015-07-12
- 打赏
- 举报
软件只是小副本，硬件的比较重要。settimer现在看肯定是不行了。只能用线程了。
worldy 2015-07-12
- 打赏
- 举报
这么简单的东西，本身就没有多少架构的问题，把逻辑思考清楚，安照清楚的逻辑走一遍就成了
wuwoliu 2015-07-12
- 打赏
- 举报
觉得那个硬件有问题。电平调整不应该由应用程序来做，应该是底层硬件
jiqiang01234 2015-07-12
- 打赏
- 举报
MFC的对话框模式，反而不如win32 sdk来的方便。毕竟MFC库的一些东西自定义起来不是很方便。如果用win32 sdk来实现，可以把消息循环和事件循环统一起来(使用MsgWaitForMultipleObjects (...)) ，这样处理起非阻塞的事件会很方便，就可以用CreateWaitableTimer (...)之类的内核对象来定时。串口操作用ReadFile()和WriteFile()的非阻塞模式overlapped来实现。总之，整个系统处于非阻塞模式下，及时性比较有保证(当然，前日是每个函数调用，不能有太费时的操作)。
