标签:Case case Use RTC 系统 use 用例 唤醒
我的工程实践选题为ESP32低功耗的实现,本项目基于ESP32嵌入式开发平台.
以此题为例,在理解项目需求的基础上进行用例建模,抽取Abstract use case,画出用例图,并确定每一个用例的范围High level use case,对关键用例进一步进行Expanded use case分析。
一、用例建模简介 从用户的角度来看,他们并不想了解系统的内部结构和设计,他们所关心的是系统所能提供的服务,也就是被开发出来的系统将是如何被使用的,这就用例方法的基本思想。 1、用例模型主要由以下模型元素构成: (1)参与者(Actor)参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统,他们代表的是系统的使用者或使用环境。
(2)用例(Use Case)
用例用于表示系统所提供的服务,它定义了系统是如何被参与者所使用的,它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
(3)通讯关联(Communication Association)
通讯关联用于表示参与者和用例之间的对应关系,它表示参与者使用了系统中的哪些服务(用例),或者说系统所提供的服务(用例)是被哪些参与者所使用的。 这三种元素在UML中的表述如下所示:
2、用例建模的主要步骤:
- 确定系统边界
- 确定参与者
- 找出所有的用例
- 确定每个用例的级别
- 撰写用例的文字描述
- 画出以整个系统为对象的顺序图
二、抽取Abstract use case
ESP32 拥有 18 个 RTC IO 和 10 个 TouchPad, 每一个 RTC IO 和 TouchPad 经过配置都可以将芯片从 deep_sleep 模式中唤醒, 从而可以实现低功耗方案.
资源包括:RTC外设、ULP协处理器、RTC快速内存、RTC慢速内存
Deep-sleep 模式下支持的唤醒源包括:
- 定时器
- touchpad
- Ext(0):RTC IO 中某个指定 GPIO 满足指定电平即唤醒
- Ext(1):RTC IO 中某些指定 GPIO 同时满足指定电平即唤醒
- ULP 协处理器
当 ESP32 进入 Deep-sleep 模式时,所有由 APB_CLK 驱动的外设、CPU 和 RAM 将掉电;RTC_CLK 继续工作;RTC 控制器、RTC 外设、ULP 协处理器、RTC 快速内存和 RTC 慢速内存可以不掉电,具体取决于 App 中的唤醒源设置。
三、用例图
四、High level use case
主要为Deep-Sleep模式下唤醒源的选择,在不同低功耗场景下,唤醒源的选择和唤醒方式都将导致功耗的不同。要根据不同场景的特点,设置最优的唤醒方式。
五、Expanded use case
- 若不是从 Deep-sleep 模式唤醒(例如重新上电或者复位),设备启动后会首先进入 Deep-sleep 模式,后续唤醒方式取决于
Wake up type
中的设置:- 若配置为 GPIO 唤醒,则需要按下 WakeUp 按键进行唤醒。唤醒后,主 CPU 使用 I2C 接口读取传感器数据;
- 若配置为 Timer 唤醒,则等设定时间后自动唤醒。唤醒后,主 CPU 使用 I2C 接口读取传感器数据;
- 若配置为 ULP 唤醒,则等 ULP 完成指定次数的数据读取后唤醒。唤醒后,主 CPU 从 ULP 中读取数据。
- 唤醒后,设备会自动连接上之前配置过的路由。
- 使用
sensor_server.py
脚本启动服务器 -
低功耗软件框架主要包含以下几部分:
- 网络配置与连接
- 睡眠与唤醒功能
- 读取传感器数据
- 上传数据至服务器
- 数据传输完成处理
标签:Case,case,Use,RTC,系统,use,用例,唤醒 来源: https://www.cnblogs.com/pghzl-123/p/11785372.html
本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享; 2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关; 3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关; 4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除; 5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。