4e9f8c71f9
refactor: 优化任务状态，EXIT状态仅表示任务已退出
...
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I53e98540af4deb44e64f6879df340b27efb201b8
2022-04-02 14:55:20 +08:00
390a488a97
feat: L0支持systick动态调频
...
Close #I4YXW9
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I052fe71e507f76184c8ac5d6349e368494033cde
2022-03-22 20:44:25 +08:00
21b46e82f3
fix: 修复未使用的参数和类型比较编译报错问题
...
Signed-off-by: fangye <fangye@talkweb.com.cn>
Change-Id: I64f9e0cd20b62f877f353340b81922ddd45fbf7c
2022-02-15 18:53:30 +08:00
fb11ab181e
feat: 同步调度部分优化至liteos_m
...
1.tick timer与调度进一步剥离
2.性能敏感函数内敛化
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I00c27216e286dd7ca9c02db3e2377707d628a786
2022-02-12 14:52:36 +08:00
194ac5898d
fix: 当前仓代码编译告警的问题
...
【背景】
当前仓代码存在编译告警需要处理
【修改方案】
在测试用例中屏蔽了-Werror选项
在对应的代码处添加了相应函数的声明头文件
【影响】
对现有的产品编译不会有影响。
re #I4N50W
Signed-off-by: yinjiaming <yinjiaming@huawei.com>
Change-Id: I7dc1e38105aa3d60f9f991f34f88875cccb48463
2022-01-19 02:27:14 +00:00
f635450d7c
feat: 内核提供tick timer框架，支持多架构多平台通用化
...
背景：
当前Arch下tick timer的实现依赖于弱函数机制，三方适配时出错及限制较大，且tick
timer作为内核必须模块，未模块化，当前散落在tick和调度等模块中，且当前存在arch依赖
内核，内核也依赖arch的情况，为了解决上述问题，将tick timer模块化，通过提供tick
timer框架实现内核依赖Arch而Arch不依赖内核，并且可以减少对外暴漏的接口，使得三方
适配时更加明确需要实现的接口。
方案描述：
1.tick timer结构
在kernel_liteos_m/arch/include/los_timer.h，中定义结构：
typedef struct {
UINT32 freq;
INT32 irqNum;
UINT32 (*init)(HWI_PROC_FUNC tickHandler);
UINT64 (*getCycle)(UINT32 *period);
VOID (*reload)(UINT64 time);
VOID (*lock)(VOID);
VOID (*unlock)(VOID);
HWI_PROC_FUNC tickHandler;
} ArchTickTimer;
并声明对外获取tick timer的接口：
ArchTickTimer *ArchSysTickTimerGet(VOID)
define LOS_SysTickTimerGet ArchSysTickTimerGet
2.在每个架构下提供默认的tick timer操作：
STATIC ArchTickTimer g_archTickTimer = {
.freq = xxx, 必填
.irqNum = xxx, 必填
.init = xxx, 必填
.getCycle = xxx, 必填
.reload = xxx, 必填
.lock = xxx, 必填
.unlock = xxx, 必填
.tickHandler = NULL, 可选
}
并实现：ArchTickTimer *ArchSysTickTimerGet(VOID) 接口
3.内核los_tick.c中提供对外(其它模块)和公共的tick timer初始化操作函数，
如果用户不想启用系统默认的tick timer,则需要在 "内核初始化之前" 调用接口：
LOS_TickTimerRegister(const ArchTickTimer *timer, const HWI_PROC_FUNC tickHandler)
将用户自己的tick timer或中断处理函数 注册进去。
用户也可以注册自己的中断处理函数(用户不提供，默认使用系统提供的)。
BREAKING CHANGE:
原来版本中每个架构下提供的tick timer相关操作函数为弱函数：
WEAK UINT32 HalTickStart(OS_TICK_HANDLER handler);
WEAK VOID HalSysTickReload(UINT64 nextResponseTime);
WEAK UINT64 HalGetTickCycle(UINT32 *period);
WEAK VOID HalTickLock(VOID);
WEAK VOID HalTickUnlock(VOID);
用户如果需要启用自己的tick timer需要自己实现相关接口(强属性)，在 "内核初始化之前" 通过调用：
LOS_TickTimerRegister 接口替换系统默认提供的tick timer相关接口。
无论用户提供的tick timer 还是系统默认提供的，均在内核初始化时启动。
Close #I4N7XV:arch 重构
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I83ad0bdf303904f0e73f808b57b60183619fddcd
2021-12-31 10:50:33 +08:00
04bf3a682f
feat: synchronizing arch api
...
命名规范：修改少量Arch接口，命名规范化调整：
1.修改arch/include下接口声明，所有arch对外提供调用函数均以ArchXX命名
2.提取多个架构均有实现的公共函数声明至arch/include对应头文件中以供外部调用，并修改命名格式为ArchXX
3.修改OS_HWI_WITH_ARG为LOSCFG_PLATFORM_HWI_WITH_ARG并移至los_config.h中
4.typedef VOID (*OS_TICK_HANDLER)(VOID);暂时移至arch/include/los_timer.h中
5.实现atomic原子操作相关接口，位于arch/include/los_atomic.h,arm架构部分与汇编指令相关原子操作接口使用ARCH_ARM宏进行控制是否编译
BREAKING CHANGE: 1.修改arch/include下接口，以ArchXX命名函数
2.提取公共函数声明:ArchAtomicXchg32bits、ArchAtomicDecRet、ArchAtomicCmpXchg32bits
3.新增部分原子操作c内联实现
Close #I4N7XV
Signed-off-by: LiteOS2021 <dinglu@huawei.com>
2021-12-25 18:36:09 +08:00
939414ea9a
!456 fix: tick中断处理时，无挂起任务时应更新当前运行任务的时间片, 并触发一次调度
...
Merge pull request !456 from zhushengle/tick
2021-12-15 01:57:10 +00:00
eff6b5533c
fix: 解决kernel目录下一些函数入参过剩导致编译错误的问题
...
Signed-off-by: suzongyao <suzongyao@talkweb.com.cn>
2021-12-13 17:15:26 -08:00
ea12d40caf
fix: tick中断处理时，无挂起任务时应更新当前运行任务的时间片, 并触发一次调度
...
Close #I4LRZG
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I4472fb50c775b832688aa7a555498901a80e2999
2021-12-13 11:37:50 +08:00
d7c0059dc4
fix: 调度中将pm相关的部分用LOSCFG_KERNEL_PM包含
...
Close #I4L00F
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I0dbe0954dcb881c0079677c215aceb099d6d1b94
2021-12-06 19:12:55 +08:00
91903a3716
fix: 修正部分编码风格问题
...
Close #I4K8M7
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: If34d5c632cbb06f639434d8c35fb226a0253f4a7
Signed-off-by: zhushengle <zhushengle@huawei.com>
2021-11-29 14:22:39 +08:00
cc8a794229
feat: 调度、任务及pm解耦
...
pm中冻结线程的操作，融合至OsSchedSuspend和OsSchedResume，
使得调度模块提供对应完整的方法给任务模块，做到之间的相互解耦，
方便其它调度算法的融入。
Close #I4JTN6
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: Ifde7077166a2fe67e7246fa68f777844640d67db
2021-11-25 16:54:02 +08:00
4061deaae8
!311 feat: 支持posix 和 cmsis join能力
...
Merge pull request !311 from zhushengle/join
2021-09-24 00:30:44 +00:00
ecfdf7ff9b
feat: 支持posix 和 cmsis join能力
...
支持API:
LOS_TaskJoin
LOS_TaskDeatch
pthread_join
pthread_deatch
osThreadJoin
osThreadDetach
Close #I44V26
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: Ib61e69c280eef2e4b3b79d9bba7bbd5a300c7fe4
2021-09-23 18:54:14 +08:00
9f185b5b52
fix: pm模块解冻线程时存在删除空链表且时间片频繁唤醒系统
...
1.如果冻结线程状态为delay，则此时pendlist为NULL，解冻时不需要delete
2.低功耗时关闭时间片，减少时间片频繁唤醒系统
3.risc-v 中64位相加存在溢出
Close #I4AKUS
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: Icb9e8f7df8488635f9660d3932b06fa6f57e6133
2021-09-18 11:42:08 +08:00
9b5739ab11
feat: 低功耗支持冻结线程等需求
...
1.支持低功耗时冻结线程
2.支持延时锁
3.低功耗与idle分离
4.支持对接电源管组件的低功耗接口
LOS_PmReadLock --- 常阻塞，低功耗线程阻塞于该接口，当系统无任何模块持锁时会唤醒低功耗线程, 触发低功耗流程
LOS_PmSuspend --- 进入低功耗流程
Close #I49FJF
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I009255cfa1852b109dd8bfaf9c779e976660d621
2021-09-14 19:55:26 +08:00
4e11ded476
!267 fix: 删除延时节点后，存在时间无法有效刷新的场景
...
Merge pull request !267 from zhushengle/sched
2021-08-19 00:39:21 +00:00
0a87c04d58
fix: 删除延时节点后，存在时间无法有效刷新的场景
...
1.从延时队列上删除延时节点时，如果该延时节点的响应时间比当前系统tick的响应时间小时，
将tick的响应时间修改为OS_SCHED_MAX_RESPONSE_TIME，以保证tick响应时间能够被刷新。
2.任务切换时，若g_schedResponseID为旧任务的taskID时(tick的响应时间为旧任务的时间片
结束时间)，将tick的响应时间修改为OS_SCHED_MAX_RESPONSE_TIME。
Close #I45I9Y
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: Ia77b789a10112935b719e8f733ba33835894e060
2021-08-14 15:53:28 +08:00
509cf59bef
fix: 以g_sysSchedStartTime是否为0判断时间轴是否生效存在极限场景导致调度时间不生效
...
初始化调度时间不以g_sysSchedStartTime是否为0为界限，而以g_sysSchedStartTime是否为64位最大值，
为界限, 避免特殊以下场景：调度开启时系统时间为0，导致初始化的g_sysSchedStartTime还是0，导致
调度启动后获取的调度时间轴始终为0.
Close #I45HP5
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: Ie0ef4e7d149f09ac466c649c0f2d6538f5322439
2021-08-14 11:30:46 +08:00
2118c84616
fix: tick 动态化计算优化，减小中断执行时间对系统总体时间的影响，保证软件定时器的响应精度。
...
方案描述：
1.周期软件定时器超时添加一个startTime字段，用于记录当前软件定时器的开始计时的时间，
在定时器响应时，开始时间修改为上一次响应的结束时间(消除了中断执行时间对软件定时器
的影响)。
2. 在执行tick中断的过程当中，持有tick动态计算锁，保证在该过程中不会触发tick周期
的计算，在tick中断结束时统一计算设置。 --- 提升tick中断的执行效率
3. 在设置tick周期时，减掉tick中断执行的时间，减小周期动态化带来的时间误差
4.新增LOSCFG_BASE_CORE_TICK_PER_SECOND_MINI配置宏，用于配置tick中断的最小响应精度
Close #I3YGP1
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: Ia53e4accce497bce870557c2c3387ce51fa3fed3
2021-08-09 21:16:22 +08:00
b3841ed1dd
fix: 在内核初始化前期启动tick timer
...
解决系统未初始化完成前无timer可用的问题。
Close #I410F0
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: I3799b9b0ff03cb1dfe80a97816a484df28ae49fd
2021-07-21 10:02:42 +08:00
e5e9289a08
fix: 调度过程低概率触发OsSchedTaskEnQueue断言，导致系统异常
...
当任务A调用LOS_EventRead阻塞开中断后，突然响应中断B，此时任务A已入阻塞链表，
任务状态为OS_TASK_STATUS_PEND | OS_TASK_STATUS_RUNNING；而B的回调函数中调用
LOS_EventWrite唤醒任务A，这个过程会调用OsSchedTaskWake，将任务A从阻塞链表中
取出，并去除OS_TASK_STATUS_PEND状态，且调用OsSchedTaskEnQueue将任务A添
加到调度队列并增加OS_TASK_STATUS_READY状态。OsSchedTaskWake全部流程完成后，
会开中断并调用LOS_Schedule，在LOS_Schedule流程中由于当前任务为A，且状态为
OS_TASK_STATUS_RUNNING | OS_TASK_STATUS_READY，会再次调用OsSchedTaskEnQueue，
从而被OsSchedTaskEnQueue断言拦住。修改方式：当任务状态含有OS_TASK_STATUS_RUNNING时
OsSchedTaskWake中不调用OsSchedTaskEnQueue。
close: #I3VX9Y
Signed-off-by: zff <zhangfanfan2@huawei.com>
Change-Id: I28f33d25504ade47469980fd6bb0b922bf4756da
2021-06-23 19:25:58 +08:00
d0efdfc20d
!169 feat: L0支持低功耗投票框架
...
Merge pull request !169 from zhushengle/PM
2021-06-22 11:55:22 +00:00
558ce14bec
feat: L0 支持低功耗框架
...
1.【需求描述】
L0 支持低功耗投票框架, 使内核与应用、驱动分离开，通过注册及投票机制控制系统的低功耗模式,
减低系统功耗,提升设备电池寿命。
2.【方案描述】
(1).提供注册机制，使驱动与内核分离
(2).提供投票机制，判断系统运行模式
(3).记录持锁设备，便于回溯
进入：系统运行进入idle任务时判断当前的功耗模式，如果上层应用未对当前功耗模式(deep和shutdown)
持锁，则系统准备进入当前模式,首先所有设备依次进入当前模式，如果有设备进入当前模式失败，则恢复
已进入当前模式的所有设备，并且功耗模式变为normal模式；设备依次进入当前功耗模式后cpu再进入当前
功耗模式。
恢复：功耗模式为deep时，需要恢复逻辑，时系统恢复运行。当有中断出发时，系统会退出低功耗模式，
恢复顺序为：首先cpu先恢复，然后设备依次恢复。
BREAKING CHANGE:
1.原调度中基于tick timer的低功耗扩展和当前的pm模块合并，删除原对外接口LOS_SchedSleepInit,
变为pm模块统一提供的LOS_PmRegistered接口.
2.原来在arch los_timer.h下提供的低功耗模式为枚举LOS_SysSleepEnum，其中OS_SYS_NORMAL_SLEEP
和OS_SYS_DEEP_SLEEP不符合对外定义，统一修改为LOS_SYS_NORMAL_SLEEP和LOS_SYS_DEEP_SLEEP,
并移至los_pm.h中.
3.VOID HalEnterSleep(LOS_SysSleepEnum sleep) 变更为UINT32 HalEnterSleep(VOID).
Close #I3UDNV
Signed-off-by: zhushengle <zhushengle@huawei.com>
Change-Id: Id5382c42c8055ba7850895a3f575130a73e38a65
2021-06-22 13:15:06 +08:00
bcec32e389
fix: 延时队列为NULL时，返回的响应时间为64位最大值，导致无法更新tick timer的响应周期
...
问题描述：
当g_schedResponseTime = OS_SCHED_MAX_RESPONSE_TIME，且nextExpireTime =（UINT64-1时,
表示系统的延时队列已为NULL, 此时tick timer 中应该设置为最大值，但由于判断
g_schedResponseTime - nextExpireTime >= OS_CYCLE_PER_TICK,导致条件不成立，直接返回，
无法将其设置为最大值，导致tick 中断一直频繁响应。
解决方案：
将延时队列为NULL时的返回值以及idle线程的时间片修改为OS_SCHED_MAX_RESPONSE_TIME - OS_CYCLE_PER_TICK,
保证延时队列为NULL，能够正常设置tick响应的最大值。
Close #I3W1LF
Change-Id: I0d09119240ae5a50ddcb0c96fb23cd3d6e70b892
Signed-off-by: zhushengle <zhushengle@huawei.com>
2021-06-17 20:23:13 +08:00
191644e441
fix: fix typos
...
Correct words function、procedure
close https://gitee.com/openharmony/kernel_liteos_m/issues/I3RR6A
2021-05-19 14:49:13 +08:00
bb84279cc2
!112 fix: fix function name
...
Merge pull request !112 from rtos-lover/los_sched
2021-05-18 09:42:55 +08:00
43c04f6f5c
fix:Low power expansion.
...
Close #I3RCHR
Change-Id: I8db9ae791b234b8237ce5a8e56d4d6581833b9ee
2021-05-14 17:08:47 +08:00
f7d50d0fbf
fix: fix function name
...
correct function name OsSchedSetIdleTaskSchedParam
close https://gitee.com/openharmony/kernel_liteos_m/issues/I3PXEX
2021-05-08 10:12:52 +08:00
628cdcbea0
IssueNo:#I3IK07
...
Description:liteos_m scheduling optimization and low power design.
Sig:kernel
Feature or Bugfix:Feature
Binary Source:No
Change-Id: I56bb190c73c8d7497ddbf2ad49ad522143008117
2021-04-14 17:27:42 +08:00
cd30e62998
IssueNo:#I3IK07
...
Description:liteos_m scheduling optimization and low power design.
Sig:kernel
Feature or Bugfix:Feature
Binary Source:No
Change-Id: I5b692a503ce6128626eec8f9a37742d7caa1fea9
2021-04-14 09:22:36 +08:00
f685eeb97d
IssueNo:#I3IK07
...
Description:liteos_m scheduling optimization and low power design.
Sig:kernel
Feature or Bugfix:Feature
Binary Source:No
Change-Id: If913b673c9b69039b51ca416be0a77ebccf2773b
2021-04-13 21:48:04 +08:00
zhushengle
fangye
yinjiaming
LiteOS2021
openharmony_ci
suzongyao
openharmony_ci
YOUR_NAME
rtos-lover
zhushengle