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
eff6b5533c
fix: 解决kernel目录下一些函数入参过剩导致编译错误的问题
...
Signed-off-by: suzongyao <suzongyao@talkweb.com.cn>
2021-12-13 17:15:26 -08:00
ecce17ea48
fix: 解决定时器超时但还在队列中无法删除的问题
...
利用每次创建时，软件定时器timerId都是唯一的（0~0xffffffff循环），在超时写队列时，同时记录软件定时器id，删除的时候更新软件定时器id，那么在处理软件定时器前，
通过队列中记录的id获取软件定时器控制块，如果控制块的id不等于记录的id，那么说明该软件定时器被删除过，将不执行对应回调函数，表现为删除该定时器。
BREAKING CHANGE: SwtmrHandlerItem结构体新增swtmrID字段，用于标识超时队列中软件定时器id
Close #I4LFVD
Signed-off-by: JerryH <huangjieliang@huawei.com>
Change-Id: I716176f177c4bc07adb348936d5568fbadcbebe7
2021-12-08 15:27:49 +08:00
c886629e27
fix:系统pend类接口未对软件定时器任务进行限制，容易引发软件定时器任务非正常挂起，
...
出现响应不及时的问题
close: #I44CI9
Signed-off-by: zff <zhangfanfan2@huawei.com>
Change-Id: I6aa612f3c34eef274eaa0c98efed0a3c4736de6e
2021-10-18 16:35:51 +08:00
61cbf83f5d
fix：修复software timer线程
...
readsize在第一次循环后可能未被正确赋值的问题
Signed-off-by: xiaofan <xiaofan@iscas.ac.cn>
2021-08-28 16:23:37 +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
1d33f5e4b0
!234 feat: L0 支持Trace
...
Merge pull request !234 from LiteOS/master
2021-07-31 02:58:59 +00:00
56c93a641b
feat: L0 支持Trace
...
1.【需求描述】
L0 支持Trace，提供两种工作模式：在线模式、离线缓存模式， 用于按时间线追踪系统事件，如任务切换、中断、ipc等。
2.【方案描述】
(1).在内核模块预置静态代码桩
(2).触发桩后，收集系统上下文信息
(3).离线模式则写入内存，用户可通过dump导出；
(4).在线模式通过pipeline对接IDE进行可视化解析和展示；
BREAKING CHANGE:
1.新增一系列trace的对外API，位于los_trace.h中.
LOS_TRACE_EASY简易插桩
LOS_TRACE标准插桩
LOS_TraceInit配置Trace缓冲区的地址和大小
LOS_TraceStart开启事件记录
LOS_TraceStop停止事件记录
LOS_TraceRecordDump输出Trace缓冲区数据
LOS_TraceRecordGet获取Trace缓冲区的首地址
LOS_TraceReset清除Trace缓冲区中的事件
LOS_TraceEventMaskSet设置事件掩码，仅记录某些模块的事件
LOS_TraceHwiFilterHookReg注册过滤特定中断号事件的钩子函数
Close #I41Y9Y
Signed-off-by: LiteOS2021 <dinglu@huawei.com>
2021-07-30 09:29:37 +08:00
ad8e96a00f
fix: los_swtmr.h不满足自包含要求对los_config.h存在依赖，但未包含los_config.h
...
close: #I40DHM
Signed-off-by: zff <zhangfanfan2@huawei.com>
Change-Id: I6903d2ece13ab0a4aadbc65f737c5f5a0f0a357a
2021-07-20 14:23:40 +08: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
8ef21e0b41
!115 fix: correct spelling
...
Merge pull request !115 from rtos-lover/los_swtmr
2021-05-15 09:45:21 +08:00
bcc34e22ed
fix: modify the return type of LOS_IntLock from UINTPTR to UINT32.
...
Change-Id: I6207e5cb7d612a154a88de4e9e274c67127361d8
2021-05-14 11:33:05 +08:00
dd5cefb0da
fix: correct spelling
...
correct some typos in los_swtmr.c It_los_queue_head_019.c
close https://gitee.com/openharmony/kernel_liteos_m/issues/I3PYLH
2021-05-08 10:30:25 +08:00
5cda1e77cc
fix:The SWTMR_ALIGN timer calculates the count error for the same period, and for the same response time, the later-inserted node should be behind the existing node.
...
Close #I3PS5B
Change-Id: I15317e64ea3376a4880e8eb0a3af3e3e8449ba08
2021-05-06 10:37:24 +08:00
793d2139b2
fix:Solution of conflict.
...
Close #I3IK07
Change-Id: I6913691a28c90b54fbda233209d43b981884f10c
2021-04-20 14:56:26 +08:00
3cea0e42b1
remove __cplusplus guards in .c files
...
Change-Id: Ie25b83a42d3ca35c3a6d624ef01f425a85957d7f
2021-04-19 18:19:28 +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
778c8b9930
update openharmony 1.0.1
2021-03-11 20:30:40 +08:00
25b432927c
Description: Sync liteos_m to OpenHarmony.
...
Reviewed-by: likailong
2021-01-30 18:05:13 +08:00
1405111aa9
Description: refactor
...
Reviewed-by: likailong
2020-12-16 17:30:08 +08:00
72c4acf01e
Description: liteos-m refactoring
...
Reviewed-by: wangmihu, zhushengle
2020-12-02 19:40:34 +08:00
82082fc0e6
Description:Liteos_m Support risc-v
...
Reviewed-by:likailong, zhangfanfan
2020-11-27 15:20:02 +08:00
07d25a8ae8
Description: liteos-m refactoring
...
Reviewed-by: liulei, shenwei
Change-Id: I7baba352c02b78aefc81fc5eca000d840d3b2fe3
2020-11-13 09:55:39 +08:00
zhushengle
suzongyao
JerryH
zff
xiaofan
openharmony_ci
LiteOS2021
rtos-lover
zhushengle
Caoruihong
mamingshuai
Caoruihong
likailong
zhushengle