Mstar之事件流程分析

最新推荐文章于 2023-01-18 15:58:19 发布

jerome_home

最新推荐文章于 2023-01-18 15:58:19 发布

阅读量309

点赞数

分类专栏： Mstar Feature phone

本文链接：https://blog.csdn.net/jerome_home/article/details/8364170

版权

Mstar Feature phone 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

注：本人博文整理至CSDN以方便查阅，源博文位于EDN

在事件流程的PPT已经讲的蛮详细了。本来还想写写架构，看了一下，文档里已经介绍的可以了。还是只记录下事件方面的。

从图1其实已经可以看的相当的明了了，只是缺少了点细节。在刚开机的时候(底层部分可以看sys_premain.c)，系统会为各个Task进行初始化，包括任务的优先级，初始化函数，Message的解析函数，Task占用的堆栈空间等。模拟器上具体的可以在sc\application\cus_app\sc\src\Cus_app.c的MKerApp_getLoadAppInfo函数中看到，Target的在cus_Main。

以音频播放器为例看下从MMI层到Driver层事件是怎么进行传递的(不讨论具体细节)。

SrvAudioPlayerPause --> AudioPlayerSrvPause --> _AudioPlayerSrvPause --> ABL_AudStopPlayReq -->

ABL_AudStopPlay --> esl_AudPlayCmdReq --> MdlAudPlayCmdReq -->

MsSend(...) --> MdlAudPcmPlayCmd --> DrvAudioPausePCMPlayback ....

可以看出事件的传递大概为：Applet --> Service --> ABL --> DBL --> ESL --> MDL(不确切) --> DRIVER

注释：

ABL：Application Bridge Layer defines the bridge functions between applications and Resource Manager。

DBL：Driver Bridge Layer defines the bridge functions between drivers and Resource Manager。

ESL：Enhanced Service Layer

ISL：Internal Service Layer

ESH: Enhanced Service Handler

CSL：Common Service Layer

MDL：Middleware(中间件) Layer

首先看下MDL具体职责，

接口上，

1)提供其他驱动及上层调用的接口；

2)运行在调用的Task，执行参数的合法性检查；

3)处理同步、异步机制；

4)将参数打包成消息发送给对应的驱动Task；

5)禁止直接操作硬件寄存器。

解析方面，

1)负责消息的处理和状态切换；

2)处理定时器消息；

3)调用底层驱动；

4)执行回调函数，回报执行结果。

我们知道在驱动的架构中从上到下依次为ESL(里面有ISL)，ESH，CSL，Driver。ESL，ESH，CSL都隶属于MDL。MDL处理驱动层到MMI层的消息映射，承上启下，同时沟通处理各个驱动Task之间的消息。对于设计这层的一部分理由应该是为了更好的将MMI与Driver进行分离。

驱动各层的具体职责为：

ESL：向MMI提供接口函数，通常是向驱动Task发送消息。

ISL：驱动的不同Task之间沟通的函数接口，用于分析不同的驱动或组件。

ESH：处理驱动Task中收到的消息，通常来自ESL和ISL。

CSL：驱动的porting层。

Driver：DRV层并不直接操作硬件，而是通过HAL(Hardware Abstract Layer)来操作硬件。这样做的目的在是为了可以做到不同硬件平台的通用。那么你也就不难明白为什么会有B2，B3宏来控制了，每种硬件平台都有他独自的HAL接口。

如果从驱动开发的角度，开发者面向的更多直接是MDL而不会如架构中的那般具体，将来自驱动消息进行处理，然后发送到MMI。更多的请参看驱动开发相关文档。

我们已经大概了解了从MMI到Driver事件是如何传递的了，那么从Driver到MMI又是如何呢？

以按键为例，从触发中断、解析到映射为MAE对应的事件的过程。

DrvKeypadISR --> MdlVkeyParser --> dev_DevicePaser --> _MdlVkeySendMsg --> MMI_Task_ParseMsg -->

mmi_kbd_data_if --> MAE Shell处理…

那么MAE Shell的处理又是怎么进行的呢？

在MMI Task中可以看到首先会将事件压入事件队列(MAE_Shell_DispatchMessage)，紧接着进行处理(MAE_Shell_ProcessEvent)。

详细看下MAE是怎么处理事件的。优先级最高的是APM(Applet Manager)，管理Applet的启动，挂起，恢复，停止，嵌入，中断等操作。然后的switch选择，重点在于default的handling events。

还是以按键为例。

mmi_CORESRV_HandleEvent --> BaseAppletHandleEvent --> _ViewMgrHandleEvent -->

_ViewMgrMLRootContainer_HandleEvent -->

WdgCommonHandleEvent --> ((pThis->pEvtToCBTbl + nIdx)->pfn)(pApplet, (u32)nEvt, nParam1, nParam2)

跟踪程序可以知道，一个按键消息(普通)首先会传给当前Applet中的聚焦Widget，然后再传递到Window的状态等的回调。问题来了，只能传给当前聚焦的Widget，那要是这个消息想传给非聚焦项该怎么办呢？办法当然是有的，可以注册一个监听聚焦Widget事件的回调函数，那么你就有办法获取所有需要的事件信息。具体的函数为WHANDLER_INIT, WdgCommonSetHandlerHookFunc。

说到这里，我想你对于Mstar事件的走向应该有了个初步的了解。更多的细节，请自己调试吧。