明确易用的中断编程,增加应用程序可靠性本文不详细讲解djyos的中断系统实现原理,有兴趣的,可参考相关文档。
传统RTOS,中断处理在ISR中进行,有经验的程序员,只在ISR中处理少量必须立即完成的工作,然后,一般会通过信号量或者消息通知一个线程,由线程接着完成后续工作。但也有些初级程序员,在ISR中完成冗长的工作。传统RTOS,对ISR例程会有较大限制,许多操作系统服务是不允许在ISR中使用的,一不小心就会中招。文档完善的操作系统,会有一个长长的清单,说明哪些服务不允许在ISR中使用,哪些是允许的。文档不完善的呢?你只有自己看着办了。墨菲定律告诉我们,就算你文档很完善,只要存在ISR中误用系统服务的可能,就一定会有人这样做。
这样做的后果是什么呢?遗憾的是,没有人能准确描述,上帝也只能说“不可预知后果”;
这样的bug会在什么时候爆发呢?只有上帝知道;你不知道中断什么时候发生,只要不发生在“不该发生的时间”,系统就平安无事,天知道什么时候会中断会发生在“不该发生的时间”。
嵌入式产品中,什么问题是最可怕的呢?调试和测试不出来,会到达用户手上,且不可预知后果的问题,是最可怕的!那些运行数月,内存莫名其妙地被误改的问题,很可能跟它有关。
ISR中误用系统服务就属于这种“上帝才知道答案”的问题。
然而,墨菲先生对djyos却无可奈何,djyos把中断分为两类,一类叫异步信号,对应于并非紧急的中断,例如键盘,异步信号的响应函数中,允许调用全部系统服务;另一类叫实时中断,对应需要紧急处理的中断事件,在实时中断的处理函数中,则禁止使用所有的系统服务。看官,这里没有模棱两可的地方,要么就全部允许,要么就都不允许。
对于普通的中断(异步信号),是允许使用全部系统调用的,只要你养成良好编程习惯,检查系统调用的返回值,就不会出错。程序员根本没有机会犯在ISR中误用系统服务这种错误。
对于实时中断,则完全禁止使用系统服务,最明确的东西,也就是最不容易搞错的。不像传统操作系统,有些系统服务可用,有些不可用,很模糊,程序员很容易混淆。
3.1. Djyos中断编程方法 3.1.1. 实时中断编程模型1、 编写ISR服务程序,像普通C函数一样编写即可。
u32 __uart1_int(ufast_t uart_int_line)
{
}
2、 使用下列语句序列设置中断:
int_isr_connect(cn_int_line_uart1,__uart1_int);
int_setto_real(cn_int_line_uart1);
int_echo_line(cn_int_line_uart1);
int_restore_real_line(cn_int_line_uart1);
第一句,把ISR函数跟中断线联系起来。
第二句,把相应中断设置成实时中断。
第三句,假响应一下,以免硬件的初始化状态影响。
第四句,使能中断
上述初始化过程,来自一个实际应用,该应用的mcu使用lpc1225,主频40Mhz,flash速度20Mhz,实际运行速度在20Mhz~40Mhz之间。但要实现2.5Mbps baud的串口通信,如果不能再接收中断发生5uS内响应中断的话,必然丢数据。因此,该应用使用了djyos的实时中断机制,实测下来,中断响应时间小于1.5uS,效果很理想。
3.1.2. 异步信号的事件模式编程这是djyos推荐的编程模型。
1、 编写事件处理函数。
void uart1_event(void)
{
While(1)
{
//do something
djy_wait_evtt_pop(djy_my_evtt_id(),1,cn_timeout_forever);
}
}
2、 登记事件类型,用于异步信号处理的事件,一般设为关联型事件。
uart1_evtt = djy_evtt_regist(enum_correlative,100,0,1, uart1_event,0x1000,NULL);
3、 按照下列指令序列初始化中断号:
int_evtt_connect(cn_int_line_USART1,uart1_evtt);
int_setto_asyn_signal(cn_int_line_USART1);
int_echo_line(cn_int_line_USART1);
int_restore_asyn_line(cn_int_line_USART1);
第一句,把事件类型与中断号联系起来。
第二句,把中断号设为异步信号。
第三句,假响应一下,以免硬件的初始化状态影响。
第四句,使能中断。
此后,只要发生uart中断,就会自动弹出uart1_evtt类型的事件。第一次弹出事件后,uart1_event将被执行,处理完相应的事务后,将会在djy_wait_evtt_pop( )函数处阻塞,直到下一次中断的到来。应用程序完全不需要写ISR程序,由于uart1_event是普通的事件处理函数,它跟普通事件处理函数一样,可以得到所有OS服务。
3.1.3. 异步信号的 ISR模式编程这种编程模型,与传统RTOS相似,不同的是,djyos的ISR可以调用全部系统服务,唯一的限制是,不能发生实际阻塞。比如,可以在ISR中调用malloc,但如果内存不足,在线程中调用的话,将会被阻塞,在ISR中调用的话,将返回NULL,不会被阻塞。只要养成良好的编程习惯,检查系统调用的返回值,就不会出错。
1、 编写ISR服务程序,像普通C函数一样编写即可。
u32 __uart1_int(ufast_t uart_int_line)
{
}
2、 使用下列语句序列设置中断:
int_isr_connect(cn_int_line_uart1,__uart1_int);
int_setto_asyn_signal(cn_int_line_uart1);
int_echo_line(cn_int_line_uart1);
int_restore_asyn_signal_line(cn_int_line_uart1);
第一句,把ISR函数跟中断线联系起来。
第二句,把相应中断设置成异步信号中断。
第三句,假响应一下,以免硬件的初始化状态影响。
第四句,使能中断
这个过程,跟实时中断非常相似,就是函数名不一样而已,但实现过程是有很大差别的。这种方式下,__uart1_int函数中是可以使用全部系统服务的。
3.1.4. 异步信号的 ISR和事件混合模式编程1、 编写事件处理函数。
void uart1_event(void)
{
While(1)
{
//do something
djy_wait_evtt_pop(djy_my_evtt_id(),1,cn_timeout_forever);
}
}
2、 登记事件类型,用于异步信号处理的事件,一般设为关联型事件。
uart1_evtt = djy_evtt_regist(enum_correlative,100,0,1, uart1_event,0x1000,NULL);
3、 编写ISR服务程序,像普通C函数一样编写即可。
u32 __uart1_int(ufast_t uart_int_line)
{
}
4、 按照下列指令序列初始化中断号:
int_evtt_connect(cn_int_line_USART1,uart1_evtt);
int_isr_connect(cn_int_line_uart1,__uart1_int);
int_setto_asyn_signal(cn_int_line_USART1);
int_echo_line(cn_int_line_USART1);
int_restore_asyn_line(cn_int_line_USART1);
第一句,把事件类型与中断号联系起来。
第二句,把ISR函数与中断号联系起来。
第三句,把中断号设为异步信号。
第四句,假响应一下,以免硬件的初始化状态影响。
第五句,使能中断。
此后,只要发生uart中断,就会先调用__uart1_int函数,然后自动弹出uart1_evtt类型的事件。可以在__uart1_int( )函数中处理比较紧急的事务,比如copy硬件缓冲区,把其他事情留给uart1_event( )做。第一次弹出事件后,uart1_event将被执行,处理完相应的事务后,将会在djy_wait_evtt_pop( )函数处阻塞,直到下一次中断的到来。
这种玩法,功能有点类似于linux的中断上半部和下半部的功能,但比linux更简洁易用。
4. 降低模块间耦合,提高应用程序可靠性另一个会严重降低应用程序可靠性的地方,就是模块间互相耦合,搅在一起。搅在一起的代码,就像一盘意大利面条,又杂又乱,如果代码写成这样的话,可靠性要高,上帝都会笑。
那么,避免意大利面条式的编码,全是应用程序的责任吗?OS作为基础软件,就一点责任都没有吗?这显然是不对的,只是大多数OS开发者没有意识到这点罢了,他们只讲究OS自身的高汇聚低耦合,忘记了OS的基本职责。消防部门的职责不仅仅是救火,更重要的是防火;OS的职责不仅仅是把出错的应用程序杀死,更重要的是帮助用户设计正确的应用程序。前面讲到,djyos的中断设计,可以消灭用户错误地调用系统服务的错误,但这只是帮助用户设计正确程序的初级阶段,帮助的只是程序员;那么,帮助用户,甚至是迫使用户编写高内聚、低耦合的模块,降解模块间的相互纠缠的关系,才是高级阶段,帮助的是系统工程师。
许多操作系统,描述自己功能强大时,总是喜滋滋地宣称自己的api多么丰富,程序员想干什么都可以支持。其实,api不是越多越好,甚至有些api是有害的,比如线程间(对应djyos的事件)互相直接控制的api,包括但不限于:
线程无条件挂起;
直接唤醒别的线程;
设置别的线程的优先级;
杀死别的线程;
等等……
这些功能,咋一看上去,是帮助程序员控制程序,但实质上是有害的,以“线程无条件挂起——直接唤醒别的线程”这对冤家来说吧。
写过C代码的都知道,goto是很受忌讳的语句,甚至有人根本不用,而提倡用if、for、while来实现程序转移。那么,大家有没有想过,我们为什么这么忌讳goto呢?为什么偏爱if、for、while呢?因为goto是很粗暴、不讲道理的转移,而if、for、while呢,它清楚地说明了转移的原因和条件,有理有据!我们对函数内的goto耿耿于怀的同时,却无视长期存在的、组件之间、线程之间的大GOTO,甚至有些操作系统还为提供了丰富的大GOTO为卖点,说什么为应用程序提供丰富的服务。
什么是大GOTO呢?操作系统环境下编程,一个线程往往代表一个独立模块。绝大多数操作系统提供了无条件的线程休眠、暂停和唤醒功能,线程执行到任何时候,都可以无缘无故地倒地就睡,cpu将转而执行另一个就绪线程,就像用GOTO跳转到另一个线程一样,究竟跳到哪个线程呢?不知道!小goto还有个标号让你知道跳到哪里,大GOTO则连跳到哪里读不知道。线程睡着以后,自己是不会唤醒自己的了,但其他任何线程都可以无条件地把它唤醒,这又涉嫌模块间互相操作。因此,无条件的休眠、暂停和唤醒,使程序的执行过程跨模块地搅在一起,是模块间失去独立性,如果两个线程是由两个团队独立开发的,则属于两个团队间交叉跳转。
Djyos不提供模块间互操作功能,以降低模块间的耦合,这样,可能会给用户编写模块内的代码带来些许不便,但能使每个模块独立化。要知道,登10次泰山的难度,也比不上登一次珠峰;同样,把十个简单系统做可靠的难度,低于把一个复杂系统做可靠。Djyos刻意帮助用户降解可能存在的模块间耦合,不以“帮助用户少写几行代码”为目标。djyos不提供任何类似的操作,所有事件都是自己控制自己的行为,没有任何事件处理函数间交叉控制的可能。djyos并不是不让事件暂停、休眠和阻塞,只是像if、for、while一样,要求程序员说明理由,为此,djyos提供了丰富的同步功能,程序员使用这些同步函数,明确告诉操作系统,自己停下来的理由,以及明确的唤醒条件,由操作系统检测到这些条件成立后,唤醒自己。这样,应用程序每个事件都自己控制自己行为,从而彻底避免了应用程序模块之间直接的交叉控制。也就是说,djyos中不存在跨事件(对应其他操作系统的线程)的大GOTO。
一个线程,直接控制别的线程的优先级,也是很致命的,一个线程的优先级,属于其核心内部数据,在面向对象的思想中,是最应该隐藏的信息。而直接被别的模块控制,还谈什么模块独立性。Djyos的djy_set_prio函数,只能设置正在执行的事件(对应其他操作系统的线程)自己的优先级。
如何管理数据,是降低模块间耦合性的重要一环,有经验的系统工程师,拿到项目后,首先想到的,是如何组织和管理数据的问题。广义上,应用程序需要的一切数据都是资源,DJYOS操作系统系统提供一个简单易用的资源管理模块,用于管理用户比较关注的、对程序运行意义重大的资源,并提供了丰富的资源管理api函数。在DJYOS资源管理模块的协助下,应用程序管理数据将变得非常简单。更主要的是,如果用户坚持用资源管理器管理所有数据,将使不同的软件模块实现细节上获得惊人的一致性。一个有一定规模的软件,必然要划分为若干模块才能顺利开发,如果不加约束,各模块可能各自设计自己喜欢的方法管理各自的数据。这种不一致性将增加软件的复杂度,增加阅读和修改软件的难度,而且,这样不可避免地会增加软件规模,增加编程和测试的工作量。若要在开发团队内和团队间人员调配,新人将花较多的时间熟悉新模块,而如果各模块代码有一致性,就会降低人员调配时交接工作的难度。