23. 中断配置_dws_dts

本文介绍了如何在Android N, MTK6737平台上配置QMA6981计步器的中断。内容包括查看硬件中断脚GPIO60、配置DWS与DTS,以及中断调试步骤,如检查中断注册、PIN脚模式和防止GPIO口复用。" 81896458,7905957,配置FastDFS支持HTTP下载:Apache+FastDFS整合指南,"['FastDFS', 'Apache', 'Linux', 'Web服务器', '配置教程']

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、以计步器为例
平台: androidN,MTK6737
芯片: qma6981

1. 查看硬件连接或excel表格,确定中断脚 :GPIO60

2. 配置dws:
	GPIO60:  M0  Def.Dir:IN  In  GPIO_GSE_1_EINT_PIN 
	EINT60:  GSE_1	Debounce:0  Polarity:Low  Sensitive_Level:Level  DebounceEn:disable
			
3. 修改dts添加中断控制引脚
		/* sensor gpio standization */
	+	&pio {
	+		/*   qma6981  interrupt setting */
	+		QMA6981_pins_eint_int: eintconfig {
	+			pins_cmd_dat {
	+				pins = <PINMUX_GPIO60__FUNC_GPIO60>;
	+				slew-rate = <0>;
	+				bias-disable;
	+			};
	+		};
	+
	+		QMA6981_pins_default: eintdefault {
	+		};
			
		alsps_intpin_cfg: alspspincfg {
		....
		
		/*   qma6981  interrupt setting */
	+	&gsensor {
	+		pinctrl-names = "default", "qma6981_eint_as_int";  
	+		pinctrl-0 = <&QMA6981_pins_default>;
	+		pinctrl-1 = <&QMA6981_pins_eint_int>;
	+		status = "okay";    
	+	};
		&alsps {

	修改dtsi,不然编译报错	
	-	gsensor@0 {
	+	gsensor:gsensor@0 {
			compatible = "mediatek,gsensor";
		};
		
		/*qma698
<think>嗯,用户想优化一个SQL查询,我得仔细看看他的问题。首先,我需要理解他的查询结构,然后找出可能影响性能的地方。他提到要减少重复连接操作和改进过滤条件,所以这两个方面应该是重点。 首先看查询的SELECT部分,有SUM和CASE WHEN,这可能涉及到大量的计算。然后是JOIN两个表,dws_idm.idm_pld_mng_online_allopatry_dtl a和dws_ods.f018_sf_o_impa_prvs_rst_dtl b,连接条件是a.loan_receipt_no = b.v_orig_identity_cd。WHERE子句里有多个条件,包括两个表的load_dt都是'20241231',还有a.not_gd_flag = '1',以及a.loan_product_cd不在某些值中。 可能的优化点有几个:首先是过滤条件的位置,比如a.loan_product_cd的过滤应该尽早应用,减少后续处理的数据量。然后是两个表都用了load_dt = '20241231',可以考虑分区或者索引。如果这些表是按load_dt分区的,那么查询会更快。另外,检查是否有重复连接,比如是否需要先过滤再JOIN,而不是JOIN后再过滤。 接下来是JOIN操作,如果其中一个表比较小,可以使用合适的JOIN策略,比如哈希连接或者合并连接。另外,GROUP BY a.loan_product_cd,可能需要确保这个字段上有索引,或者使用物化视图来预聚合数据。 还有,用户提到的重复连接操作,可能是指多次访问同一个表?不过在这个查询里,只JOIN了一次,所以可能是指多次扫描同一张表。不过这里似乎没有这种情况,可能需要检查是否有其他潜在的子查询或者重复的过滤条件。 另外,字段的选择是否必要?比如SELECT中的字段是否都用到索引?可能需要在连接字段和过滤字段上建立索引,比如loan_receipt_no、v_orig_identity_cd、load_dt、loan_product_cd等。 还有,SUM中的CASE WHEN是否可以用更高效的方式表达?或者是否可以预先计算这部分数据? 最后,用户提供的参考引用里提到了HAVING子句和CASE语句的异常处理,虽然当前查询中没有HAVING,但可能需要考虑在子查询中提前过滤数据,减少GROUP BY的压力。 总结一下,优化步骤可能包括:提前过滤数据,使用分区或索引,优化JOIN顺序,预聚合数据,建立合适索引,检查执行计划等。需要一步步分析,确保每个环节都尽可能高效。</think>### SQL查询优化方案 #### 一、优化分析 1. **重复连接问题**:原始查询对`dws_ods.f018_sf_o_impa_prvs_rst_dtl`表仅使用一次连接,但过滤条件可前置到子查询以减少连接数据量[^1]。 2. **过滤条件优化**:`WHERE`子句中的`a.loan_product_cd NOT IN`会触发全表扫描,可通过索引或分区表优化。 3. **计算冗余**:`CASE WHEN`条件可能重复扫描数据,可通过预过滤或物化视图优化。 #### 二、具体优化步骤 1. **提前过滤数据** ```sql WITH filtered_a AS ( SELECT loan_product_cd, cur_bal, loan_classify_name, loan_receipt_no FROM dws_idm.idm_pld_mng_online_allopatry_dtl WHERE loan_product_cd IS NOT NULL AND loan_product_cd NOT IN ('80', '81', '83', '77', '88') AND load_dt = '20241231' AND not_gd_flag = '1' ), filtered_b AS ( SELECT v_orig_identity_cd, n_weight_el FROM dws_ods.f018_sf_o_impa_prvs_rst_dtl WHERE load_dt = '20241231' ) ``` 2. **优化连接操作** ```sql SELECT a.loan_product_cd, SUM(a.cur_bal), SUM(b.n_weight_el), SUM(CASE WHEN a.loan_classify_name IN ('次级', '可疑', '损失') THEN a.cur_bal ELSE 0 END) FROM filtered_a a JOIN filtered_b b ON a.loan_receipt_no = b.v_orig_identity_cd GROUP BY a.loan_product_cd; ``` #### 三、优化原理 1. **分区表优化**:如果表按`load_dt`分区,过滤条件`load_dt='20241231'`会直接命中分区,减少90%以上I/O消耗。 2. **索引建议**: - 在`idm_pld_mng_online_allopatry_dtl`表建立复合索引:`(load_dt, not_gd_flag, loan_product_cd)` - 在`f018_sf_o_impa_prvs_rst_dtl`表建立索引:`(load_dt, v_orig_identity_cd)` 3. **执行计划验证**:使用`EXPLAIN ANALYZE`确认是否走索引,避免全表扫描。 $$ \text{查询性能提升公式:} \Delta T = T_{\text{原始}} - \left( \frac{T_{\text{过滤}}}{k} + T_{\text{连接}} \right) $$ 其中$k$为过滤条件减少的数据量倍数。 #### 四、扩展优化建议 1. **物化视图**:对高频访问的聚合结果建立物化视图,每日定时刷新 2. **列式存储**:对分析型字段如`cur_bal`采用列式存储,提升压缩率 3. **并行查询**:对大表启用并行查询(需确保`PARALLEL_DEGREE_POLICY=AUTO`)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值