一，前言

之前从空白已经配置了2个调度表，一个是绑定到了trusted一个nontrusted app，但是oscounter用的是一个，而在我的理解中，app容器中所有元素除了isr，包括counter也应该是独立的。今天做了实验发现我的理解是错误的。

二，自定义需求

我就又加了一个trustedcnt专用，然后增加一个10ms周期alarm的task作为trustedapp，其它2个调度表放到2个nontrustedapp，然后工程配置检查的就有些cnt不能访问的报错，我折腾下能生成os代码后，无板仿真一跑发现4个nontrustedapp中的task可以运行，trustedtask也就是一个alarm10ms的不能运行。

三，问题排查

1. 通过调试看源码来定位。
   第一次进入tick增加的中断，Os_AppAccess = 4因为Os_RunningISR选的app值不匹配。其实都是代码中自动生成的。难道配置的不合理？等于设计不合理，但是没有违反os原则，所以可以生成代码。

   
   image.png
   image.png

2. 通过看手册理解access对应的配置项
   我之前理解的isr可以在app中共用，看生成的代码是不可共用的呢！再去看手册，发现了之前配置的时候owner by和下面的access搞不清楚，感觉是一样的意思，就配置成一样了。现在才理解，owner by的就不需要配置access了，因为都是owner by一个app的，他们这些object会自动组合。所以ownerby是强相关，access是弱相关，比如某个app1中taskA中要激活app2中的taskB，就需要在access中加入了访问权限了。这和trusted和nontrusted无关，是app 元素间的权限问题。

   
   image.png

3. 真相大白，看懂代码也看懂了os手册中的描述
   上图理解后，这里appA，AppB，AppC中的元素都可以互相访问。那么我把counter改成了1个应该是可以的。然后报错如下

   
   image.png
   

   TickCounter1ms不是trustedApp的，所以Alarm是trustedApp就访问不了。
   Alarm中的access添加另外2个，其实TickCounter1ms的owner是NonTrustedAppCore0，加一个就可以了。生成代码后，仿真运行起来正常。

   
   image.png
   所以要访问的元素先有唯一的ownerby app。然后任何的app中的object要访问这个元素，就在access中添加元素的容器app即可有访问权限了。就像一句古话，找6个人问就可以联系到你要找的人，这也体现的是一种关联关系。

四，小结

有些配置项搞不清楚什么含义，随意配置下能生成代码，结果也会造成大错，所以在没有深入理解配置项的情况下，生成的代码看来还是有风险的。不过能直接看源码的且能100%复现的问题都好解决。这也就是我学习工具的时候必须去看源码的原因，因为只有这样才能闭环验证我理解的配置项是否正确。事实证明我的闭环学习方法是有用的，实践是检验真理的唯一标准。