CosyOS 发表于 2023-11-9 03:36
那我就简单谈一谈我所了解的“互斥访问”，有不足之处望大家谅解。
一、访问
这个工程很是浩大，越说牵扯到的问题就越多，容易引起歧义的地方也越多，以后还是尽量少说。
CosyOS 发表于 2023-11-9 08:33
这个工程很是浩大，越说牵扯到的问题就越多，容易引起歧义的地方也越多，以后还是尽量少说。 ...
所以如果要想研制一个产品级而不是玩家版的STC单片机RTOS，应该像读研究生一样经历一个流程：先学RTOS理论，然后调研现有的单片机RTOS现状和特点，最后再规划动手完成实际作品。
本帖最后由 tzz1983 于 2023-11-9 10:03 编辑
CosyOS 发表于 2023-11-9 08:33
这个工程很是浩大，越说牵扯到的问题就越多，容易引起歧义的地方也越多，以后还是尽量少说。 ...
说还是要说的, 要不大家怎么交流, 怎么进步, 表达自己的观点, 保留不同的声音, 这样就好
我觉得大家都可以自由发表自己的观点, 不一定要分个对错.
如果一定要分对错, 那错的一定是做的最多的那个人, 这不公平
至于谁的好谁的不好, 这就更不要去评论了, 三人行, 必有我师, 好的接收, 自认为不好的就让他随风而去.
也不用怕别人对我们的言论进行评击, 人家说的对,我就接收, 自认为说的不对的, 就不要去管它了.
反正最终的目的就是交流, 偶尔别那么严肃, 聊聊天也好的, 我们做软硬件的, 除了和机器交流, 也需要多和人聊天啊, 要不怎么会出现一个优秀的程序员找不到老婆这种现象{:biggrin:}
如此就欣欣向荣了
是的，应该多交流的，以后交流的重点还应放在解决实际问题上。
CosyOS 发表于 2023-11-9 03:36
那我就简单谈一谈我所了解的“互斥访问”，有不足之处望大家谅解。
一、访问
在RTOS中可以用信号量或二进制信号量(UCOS中只有信号量)就可以实现互斥和同步。
互斥：创建信号量，初始化信号量为1，需要使用共享资源的任务按以下流程操作，就可以实现互斥
等待信号量->使用资源->发送信号量
同步：1个任务等待信号量，另一个任务发送信号量。
本帖最后由 CosyOS 于 2023-11-9 17:19 编辑
fanxsp 发表于 2023-11-9 16:23
在RTOS中可以用信号量或二进制信号量(UCOS中只有信号量)就可以实现互斥和同步。
互斥：创建信号量，初始化 ...
具体来说，其它RTOS一般都可以用信号量、二值信号量实现互斥；
但对于CosyOS来说，二值信号量是可以随意使用的，没有限制。
但计数信号量通常是不可以在中断中获取的（除非只在相同优先级的各个中断中获取，其它的中断、任务中不会获取）。
杨为民 发表于 2023-11-8 19:42
（1）楼主的标题已经改为“RTOS临界区中（仅指关闭总中断的方法），用户是否可以任务切换的初步思考”了， ...
对于MCU来说， 外部来源的中断往往意味着外部“信号”， 这些信号是MCU存在的意义（在产品中）。
所以， 如果要以关中断来“操作系统”， 对于MCU来说有些得不偿失。
杨为民 发表于 2023-11-9 09:22
所以如果要想研制一个产品级而不是玩家版的STC单片机RTOS，应该像读研究生一样经历一个流程：先学RTOS理 ...
你是否开发过成功的产品， 而不是移植别人的软件？
如果只是移植过软件， 来否定原创的价值，有些无理。
我的十多年来，产品销售过很多海内外客户。我理解一个好的软件是对于需求的应答,
而不是定义是否符合某人的教材。
13918210822 发表于 2023-12-29 17:56
你是否开发过成功的产品， 而不是移植别人的软件？
如果只是移植过软件， 来否定原创的价值，有些无理。 ...
（1）这是我研发的RTOS，RTOS的每一行代码都是我写的。
https://www.stcaimcu.com/forum.php?mod=viewthread&tid=1402
（2）这是我研发的RTOS，RTOS的每一行代码都是我写的。这个RTOS使用的是我研发的C语言编译器，C语言编译器的每一行代码都是我写的。
https://www.stcaimcu.com/forum.php?mod=viewthread&tid=2490
我提一些实际需求， 请教Cosy老师如何从RTOS角度来支持会比较好
以下需求考虑适配STC32F或资源更多的平台（8K+ edata, 4K+ xdata, 54k Flash/EEPROM)
1。不可以关闭任何中断， 如果在任何时候关中断， 只能由用户关闭， 不能由系统服务代劳
这个类似于驱动的启动和关闭， 不能由操作系统来没有用户请求的情况下“代劳”
原因是， 产品的设计者会更了解实际产品的需求， 而不是提前设计操作系统的设计师
2. ISR的应答应该在“驱动”层级，永远不会 “被“任务调度”打断
3. 服务层应该对“消息/命令队列”，“FIFO"等常用数据服务提供来自平台的支撑
4. 可以明确地调整栈的大小以及位置。从而相对动态的适配“活跃”会话的数量（是否有动态调整的可能）
更具体的， 有一个GPIO模拟特殊接口(SMI). 有6+1个UART(分时），有N个ADC, 有一个debug console(UART)， 无(CAN,USB,SPI,I2C,PWM等等）
这样一个项目可以用前后台，但是，如果能不丢失任何信号、不损失实时性的前提下，使用某个RTOS似乎更加易于后期扩展和维护。
一个实际而相对复杂的需求， 请cosy老师有空给些建议