全局不关总中断的 RTOS，CosyOS视频教学, 送【USB转双串口，烧录器，仿真器】

Cos***

1、系统初始化后，内存区域未必是0。
如果我们希望某些内存区域或全局变量初始化后为零，则必须采取相应的清零操作，如启动文件内存清零、变量赋初值为0等方式，
否则初值未必为零，可能会导致应用错误。

2、某些全局变量，我们需要初始化为特定值（非0），包括基本类型的变量、数据结构（数组、结构体等）。

我通常的做法是：
1、启动文件内存清零。
2、某些全局变量，如果需要初始化为特定值，在定义时直接赋初值。

tzz***

多看看你的OS还是很有好处的，STC32出来的时间不长. 就因为和51内核比较像，相当于拿来就会用，所以很少去看编绎手册之类的东西. 比如REMOVEUNUSED，之前我还不知道，我一直苦恼编绎器为什么不把没用的代码自动删除。直到昨天才知道还有这玩意，解决了我一大困惑

tzz***

CosyOS大侠, 全局不关中断,是如何互斥访问全局变量的,这里面的原理能给大家讲透吗

比如有一个全局变量,无法元子一次性读写, 现在有4个优先级中断允许读写, 并且任务也可以读写, 不关中断如何保证读写正确?

这两天在看你的OS代码, 本为想从原代码入手去窥察一番, 但发现有些耗时呀,嘿嘿. 自己一下子又想不透, 向你来求助了

我自己想到一个办法分两步实现:
1. 中断写的同时创建一个OS服务,由服务更新一个副本的值用来提供给任务读取.
2. 任务写,写的是任务副本,写完以后做一个元子标识, 只要提供两个副本给任务循环使用, 中断即可正确读到任务写的值.
我说的这个办法, 一个中断对应任务共享还勉强说得过去, 如果是多级中断嵌套访问,那就不行了, 或者说就算能实现, 开销也非常的大, 实际上是得不偿失的.
你究竞是用了什么办法呢?

tzz***

给CosyOS两个建议:

1. 做一个最简范本, 项目内只有必要代码, 比如STC32G设备库这种就暂时不要加入到最简范本.  做一个建项目流程, 引导新手一步一步的创建项目,  创建第一个任务, 功能尽量简单, 比如只要闪烁某个LED就可.  降低门槛引流, 用户只有入门了才有后话.
2. 各OS档都出一份代码讲解,这个任务量比较大, 但对推广是非常有用的. 但凡要用到RTOS的程序员,都不是泛泛之辈, 他们不可能对你的代码不了解就放心使用,但要自己通读那肯定是有困难的.  如果做到详细讲解, 最终赢得用户量, 这对你OS的发展非常有帮助, 因为使用者也无形之中成为了你的开发团队中的一员.

Cos***

tzz1983 发表于 2023-11-23 09:55
CosyOS大侠, 全局不关中断,是如何互斥访问全局变量的,这里面的原理能给大家讲透吗

比如有一个全局变量,无 ...

目前，CosyOS对于中断本地服务（只读访问），主要是中断中读全局变量、中断中接收邮件，在使用上还是有一定的限定条件的。
这个问题也是迄今为止仍然困扰我的问题。实际上，当你深入研究、思考所有的访问情况后，你会发现其它的问题都不是问题，只有一个问题不好解决，就是中断中对全局资源的只读访问。
如果我们假定在中断中不会读取一个非原子的全局变量、不会接收邮件，将取得完美的结果。
但对于OS来说，我们又不能做这种假定，必须要允许用户在中断中做相应的读访问。
这几日，我一直在考虑到底该如何解决这个问题。
首先，消息队列是采用的互斥访问（每个队列都有一个二值信号量）。所以，在中断中接收消息会有失败机率（返回NULL）。然而对于消息队列来说，也只能如此。
对于非原子全局变量，我现在考虑如下两种方式：
1、OS不再提供相应的服务。这样也是说的通的，因为全局变量本就是用户对象，非内核对象。用户对非原子的全局变量的访问，可自行处置，如使用二值信号量实现互斥访问，或全局临界区等。
2、我已经想到了一种方法，可以完美解决相关问题，就是如果在中断中读一个非原子的全局变量，则必须创建一个副本，这个副本可以，用户自己创建，也可以OS创建，而后由OS提供相应的服务来实现。但这个方法在实现起来比较繁琐，对于用户来说并不友好，又要占用更多的内存，处理上又需花费更多的时间。


对于邮箱，暂时先不议。

Cos***

我现在正在考虑重新解决中断中的读访问问题，因为现有方式存在着一定的限定条件，这就是不可靠因素，如果用户不注意这些问题，访问就可能会出错。
所以说聪明的方法还是关总中断呢，中断一关，什么问题都没有了。

Cos***

下面是CosyOS当前在中断中读一个全局变量时的注意事项：
当用户在中断中读一个全局变量时，
如果在某个与该中断优先级不同的非最低优先级的中断中会写同一个全局变量，那么仅在下面两种情况下会确保万无一失：
1、在那个中断中，用于写该全局变量的局部变量为常量（不会改变）；
2、那个中断的发生频率足够低，可保证在PendSV中最终完成服务（写全局变量）以后，那个中断才会再次发生。

所以说，如果恰巧遇到相应的情况，还是会有读错的机率。

Cos***

实际上，对于一个非原子访问的全局变量来说，问题的关键就在于，不怕任何地方读写，就怕中断中读。
除了在中断中的读访问外，其它任何位置（任务、滴答、中断）中的读写访问都是在“服务层”中执行，操作流不会被打断，全局变量是不会重入的。
只有在中断中的读访问是非常令人讨厌的，因为它必须在本地执行，无法挂起到PendSV中。因为既然要读，就是要用，而且是马上就用，就必须读到啊？
中断是有生命期的，每次中断响应后再返回，本次的生命期就结束了。所以在中断中读，就只能在本地立即读到。
而中断又是动态的，不一定什么时候就会进入，所以，对中断中的读访问的处理是十分艰难的。
OS即然提供相应的服务支持，就要让它能读到，所以不能用一般意义的互斥访问的方法，因为可能会读取失败。
如果实现不了，干脆就不要管了，由用户自己去处理吧。
我也正在考虑提供不同的方案给用户。。。

tzz***

CosyOS 发表于 2023-11-23 14:41
实际上，对于一个非原子访问的全局变量来说，问题的关键就在于，不怕任何地方读写，就怕中断中读。
除了在 ...

在你的介绍文中提到Keil RTX是不关中断的, 没有可借鉴的方法吗

Cos***

tzz1983 发表于 2023-11-23 15:37
在你的介绍文中提到Keil RTX是不关中断的, 没有可借鉴的方法吗

我正在考虑我说的能完美解决这个问题的那个方案，做为选项提供给用户选择。