求助:傻孩子 uC/OS-II 应用中,键盘处理时如何划分各任务,使得程序更加模块化?
假如一个实际应用中需要15个按钮:<SET> : 按钮用于进入参数设置状态或者退出参数设置状态
<UP> :按钮用于参数设置时,增加数值
<DOWN> :用于参数设置时,减少参数值
<F1> :为功能键,按一下F1键,控制器开始运行,控制马达运转.
<F2> :为功能键,按住F2键,马达转速按照一定的斜率,在1秒内增加10转
<F3> :为功能键,按住F3键,马达转速按照一定的斜率,在1秒内减少10转
等等.
我在前后台程序设计中,为了模块化,
1.把键盘扫描程序做成一个子程序1
2.把参数设置做成一个子程序2
3.把功能键的处理做成一个子程序3
4.其中F2和F3是特殊功能键,因为按住F2键,马达转速按照一定的斜率,在1秒内增加10转,需要放在中断服务程序中执行.
中断服务程序每隔10毫秒执行一次,因此每来一次中断,马达转速增加10/100转,因此1秒后,刚好10转.
根据uC/OS-II教科书的上的原则:
(1).任务和任务之间通信可以采用一对一或者多对一方式通信.禁止一对多方式通信.
也就是说,可以是一个任务或者多个任务发送消息,但是只能一个任务接收消息.
我如果按照下述划分任务,虽然能够符合上述原则,但是全部代码放在一个任务中,显得代码也太长了吧!而且不符合模块化,同时
特殊功能键F2和F3又怎么办呢?
任务1:键盘扫描任务,周期执行.通过延时节拍进行任务切换.检测到按键后,发送键盘消息.
任务2:键盘处理程序,事件触发,检测到键盘消息后执行.
如何合理的规划任务呢? 就像我们经常使用的手机一样.
手机上有很多按键:数字键和功能键.
数字键:用于设置参数或者输入电话号码.
功能键:复杂功能.
不可能把所有的处理程序制作成一个任务吧!
同时开机键和关机键需要连续按住3秒,才能执行. 键盘扫描+键盘处理 一个任务,仍消息到一个消息队列(生产者)
键盘消息处理程序(消息地图系统)一个任务(消费者),消息地图系统根据
消息的不同,对于占用时间很小的函数,直接在本任务里面执行;对于大型函
数,则需要独立的任务(消费者)——动态建立或者静态建立根据情况,推荐静
态建立——消息处理函数发送消息(生产者)给对应的任务,触法嗷嗷待哺的大型任务。
10ms一个的消息处理任务,不算Time critical的,但是对于真正实时性要求高的任务
不应该放到上述的系统中,而应该是用一个独立的任务监视并处理。 如果只建立两个任务
任务1:键盘扫描任务,周期执行.通过延时节拍进行任务切换.检测到按键后,发送键盘消息.
任务2:键盘处理程序,事件触发,接收到键盘消息后执行.
问题1:
任务2的程序代码不就太长了吗?既要处理参数设置方面的按键处理,又要处置系统功能方面的按键处理. 这么多不同的代码
全部在这个任务中,不显得繁琐吗?
问题2:
F2和F3殊功能键如何处理?
因为按住F2键,马达转速按照一定的斜率,在1秒内增加10转(就像PID的给定值,不是一次加上去的,而是在一段时间内匀速加上去的)
谁让你都写在一个函数里面……
特殊功能特殊起一个任务 请教Gorgon Meducer:
(1).任务和任务之间通信可以采用一对一或者多对一方式通信.禁止一对多方式通信.
我看邵贝贝教授的书上面没提到者个问题呀。 为什么要禁止一对多的通信呢,有什么讲究么?
另外,总是看到生产者-消费者模型,是不是可以把它理解成就是一种任务之间通信的方式(类似于消息队列)。有什么本质的区别么?
感谢 生产者消费者模型是一种资源模型,用于任务的互斥、同步等等。
可以理解为是一种基本的任务间通讯方式。
应该说,消息队列本身就是一种 消费者和生产者模型。
一对多通讯存在一个问题,即标志的生存周期难以确定。容易造成
通讯同步错误。你只要考虑下,一个人物设定了一个标志,多个任
务检测这个标志——那么这个标志什么时候实效呢?谁来决定失效,
设定失效的时候,会不会有任务掉队?
你就明白这个问题了。 学习了。。 mark 有道理,任务的合理划分很重要 学习!向Gorgon Meducer 傻孩子
致敬!
页:
[1]