Mstar之事件流程分析

注:本人博文整理至优快云以方便查阅,源博文位于EDN


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


 3ffa9231-9b28-4eaa-872e-e36c8ce58a1d.JPG


       从图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事件的走向应该有了个初步的了解。更多的细节,请自己调试吧。


资源下载链接为: https://pan.quark.cn/s/140386800631 通用大模型文本分类实践的基本原理是,借助大模型自身较强的理解和推理能力,在使用时需在prompt中明确分类任务目标,并详细解释每个类目概念,尤其要突出类目间的差别。 结合in-context learning思想,有效的prompt应包含分类任务介绍及细节、类目概念解释、每个类目对应的例子和待分类文本。但实际应用中,类目和样本较多易导致prompt过长,影响大模型推理效果,因此可先通过向量检索缩小范围,再由大模型做最终决策。 具体方案为:离线时提前配置好每个类目的概念及对应样本;在线时先对给定query进行向量召回,再将召回结果交给大模型决策。 该方法不更新任何模型参数,直接使用开源模型参数。其架构参考GPT-RE并结合相关实践改写,加入上下文学习以提高准确度,还使用BGE作为向量模型,K-BERT提取文本关键词,拼接召回的相似例子作为上下文输入大模型。 代码实现上,大模型用Qwen2-7B-Instruct,Embedding采用bge-base-zh-v1.5,向量库选择milvus。分类主函数的作用是在向量库中召回相似案例,拼接prompt后输入大模型。 结果方面,使用ICL时accuracy达0.94,比bert文本分类的0.98低0.04,错误类别6个,处理时添加“家居”类别,影响不大;不使用ICL时accuracy为0.88,错误58项,可能与未修改prompt有关。 优点是无需训练即可有较好结果,例子优质、类目界限清晰时效果更佳,适合围绕通用大模型api打造工具;缺点是上限不高,仅针对一个分类任务部署大模型不划算,推理速度慢,icl的token使用多,用收费api会有额外开销。 后续可优化的点是利用key-bert提取的关键词,因为核心词语有时比语意更重要。 参考资料包括
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值