高通

这里以新建一套麦克风音效举例。 首先通过QACT软件以离线调试的方式打开任意一组音效。 通过左上角菜单栏，选择Tools -----> Device Designer。 先观察HANDSET_MIC的参数配置。 然后点击左下角的新增按钮，仿照上述参数配置一组音效，重新命名，注意命名稍微规范一些。 点击ok保存后即可使用该音效了。 来源： CSDN 作者： Rock 自律 链接： https://blog.csdn.net/crow_ch/article/details/103948331

一、AR概念： 增强现实（Augmented Reality，简称AR），是在虚拟现实的基础上发展起来的新技术，也被称之为混合现实。是通过计算机系统提供的信息增加用户对现实世界感知的技术，将虚拟的信息应用到真实世界，并将计算机生成的虚拟物体、场景或系统提示信息叠加到真实场景中，从而实现对现实的增强。 二、工具： 在这里我们主要是用高通的Vuforia SDK来演示如何在Unity下制作一个简单的AR的demo，Vuforia SDK是一套很完整的可以直接调用的AR API，而假如想深入了解SDK内部的关于AR中图片识别以及跟踪的算法，我们需要从Open CV入手。 1.Unity——我使用的是Unity5.3.1f版本 2.Vuforia SDK插件——从官网（https://developer.vuforia.com/downloads/sdk）下载最新的5.5的Unity专用版本 三、实战： 1.在Unity中新建一个3D项目，取名为TestAR 2.导入下载好的Vuforia SDK插件包：vuforia-unity-5-5-9.unitypackage 3.导入成功后，再Assets目录下回多出一个Vuforia文件目录和一些其他的辅助文件 4.将默认场景中的Main Camera删掉，并将Vuforia/Prefabs目录下的ARCamera相机拖至场景中 5

高通QCC系列固件升级指南 高通QCC系列固件升级有两种方式：USB HID和高通app，两种升级方式都需先经过以下步骤。 升级前准备工作 （1）通过QMDE打开对应的工程，点击tools->setup DFU security菜单，生成对应的key文件，这个步骤是为了确保板子中的固件和要升级的固件的key一致才能升级，key不一致不能升级成功。 点击上图菜单后，会弹出下图，选择key文件保存的位置，选默认即可。 如果之前没有生成过key，会直接生成key文件到相应目录。 如果之前生成过，会弹出下图框：让你选择使用之前的还是重新生成。如果用之前的，会弹框让你选择之前key所在的目录。 到这里第一步就算完成了。 （2）完成第一步之后，重新rebuild工程，之后将生成的带key文件的固件通过烧写器deploy all进板子。 这一步很重要，否则后续升级会报OEM validation failed footer的错误，这是key文件不一致导致的。 （3）制作.bin文件，点击tools->build DFU file 稍后会弹出配置路径的窗口，选默认即可： 然后依据adk版本选择签名，6.1以上版本选择sign all projects 之后选择要升级的工程，可以选择全升级或只升级部分改动的工程，根据需要选择即可。 是否加密，点击非加密即可。 等待一会，bin文件就会自动生成

一、主要问题 本项目采用的是高通的SDM450平台，单USB口出来后接了USB HUB 同时可以连接电脑等，这就有个问题，当我同时连接电脑并将USB HUB上电后，在主从切换之间就有问题，也就是当处于主模式的时候，通过拉高USB_ID管脚进入从模式，这时候就会切换失败；或者处于从模式的时候，将USB_ID管脚拉低进入主模式的时候，也会切换失败。 二、原理图 主控部分原理图 usb_ID 控制部分原理图 Vbus电路原理图 通过原理图可以很清晰的看出，通过HOST_EN管脚可以控制USB_ID管脚，然后进行主从的状态切换 三、原理 高通Android9.0 kernel4.9 主从切换问题主要涉及到两个方面，一是通过OTG_ID 管脚的高低电平进行中断进行主模式的进入和退出；一是通过VBUS电压检测进行从模式的进入和退出。(注意这里只是相应模式的进入和退出，例如退出主模式后不一定是进入从模式，退出从模式不一定是进入主模式) 四、软件分析过程 用于VBUS和OTG_ID检测相关驱动 kernel/msm-4.9/drivers/platform/msm/gpio-usbdetect.c 用于设置主从状态相关驱动 kernel/msm-4.9/drivers/extcon/extcon.c kernel/msm-4.9/drivers/extcon/driver.c 驱动简单分析

\kernel\sound\core\control.c \kernel\sound\core\ \kernel\sound\soc\codecs\Msm8x16-wcd.c 从上往下的大致流程： amixer-用户层 |->snd_ctl_ioctl-系统调用 |->snd_ctl_elem_write_user-内核钩子函数 |->snd_ctl_elem_wirte- |->snd_ctl_find_id-遍历kcontrol链表找到与给定id相匹配的kctl |->kctl->put()-调用kctl的成员函数put() |->snd_soc_put_volsw modem重启了的代码:\kernel\drivers\soc\qcom\smd.c 起始ioctl：\kernel\sound\core\control_compat.c snd_ctl_elem_write_user_compat >> snd_ctl_elem_write >> result = kctl->put(kctl, control); ADC1 Volume函数get put设置\kernel\sound\soc\codecs\msm8x16-wcd.c 最终读写寄存器函数：\kernel\sound\soc\soc-core.c 更往上:\kernel\sound\core\control.c:

在高通android p的平台上，一个第三方的apk设置为默认的桌面后（或在开机向导界面），在无锁屏的情况下，休眠后马上按电源键唤醒，比较大的概率出现点击或滑动界面无反应，通过调试后发现ViewRootImpl.java中的draw（）方法中返回后造成的 private boolean draw(boolean fullRedrawNeeded) { Surface surface = mSurface; if (!surface.isValid()) { //快速休眠唤醒后view调用到这里会直接返回 return false; } } 在网上查到说是google的一个path造成的。 解决这个问题可按如下修改 void setWindowStopped(boolean stopped) { if (mStopped != stopped) { mStopped = stopped; final ThreadedRenderer renderer = mAttachInfo.mThreadedRenderer; if (renderer != null) { if (DEBUG_DRAW) Log.d(mTag, "WindowStopped on " + getTitle() + " set to " + mStopped); renderer.setStopped

UAF42滤波器/低通/高通/带通 滤波器 原理图/PCB设计 调试注意事项 目录 UAF42滤波器/低通/高通/带通 滤波器 原理图/PCB设计 调试注意事项 1.特性参数 1.1 基本特性 2.使用说明 2.1模块简介 2.2模块使用 2.2.1由IN2输入法 2.2.2由IN1输入法 2.3原理图说明 2.3.1模块原理图 2.3.2调节中心频率 2.3.3调节Q值及增益 模块原理图-PDF、原理图库、PCB库下载 1.特性参数 1.1 基本特性 UAF42芯片一款有源滤波器芯片，可由单芯片实现低通，高通，带通滤波器，可选其一进行输出，并可通过改变电路中滑变阻值，轻松调节其滤波器中心频率，Q值，通带增益等，也可方便实现Butterworth、Bessel、Chebyshev1等款式滤波器。 注 ： 1、当滤波器具有相同阶数时： 巴特沃斯滤波器通带最平坦，阻带下降慢。 切比雪夫滤波器通带等纹波，阻带下降较快。 贝塞尔滤波器通带等纹波，阻带下降慢。也就是说幅频特性的选频特性最差。但是，贝塞尔滤波器具有最佳的线性相位特性。 2.使用说明 2.1模块简介 UAF42模块用途广泛——低通、高通、带通，使用方便，跳线即可选择低通、高通或带通形式之一。 易于设计，调节滑变即可轻松调节滤波器品质因数(Q值)，中心频率等，中心频率可高至40kHz。 供电： ±5V~±18V 信号输入：

高通将android的camera模块重新修改了一下，与原生的方式存在一些差异。这里将前段时间学习的一些零散知识进行一下总结，便于以后查阅。 1.整个模块主要巡行三个主线程：control、config及frame，control用来执行总的控制，是上层控制接口（这个线程还未去了 解）？config主要进行一些配置，这个线程里面主要进行3A的工作，另外还有一些跟效果有关的设置；至于frame线程好像主要用来做预览吧。目前还 只是大致了解config线程。 2.在Qualcomm执行初始化时就会调用到mm_camera_exec（）函数来建立config线程 launch_cam_conf_thread（）；阅读此线程函数体会发现里面使用了select机制来检测配置指令并进行分发（调用不同的分支函 数）。后面就是一连串的function call了。 关于select机制还有不少疑点需要进一步学习：指令的来源？如何对文件进行控制的？ 比如下面这一段LOG就可以看到对AE、AWB及HIS设置的过程（只贴了部分）： E/CAM_FD ( 194): ...... entering config duty loop ...... E/CAM_FD ( 194): cam_conf: MSM_CAM_IOCTL_GET_STATS: resptype=1 ctrl_cmd.type=4 E

1 camera基本代码架构 高通平台对于camera的代码组织，大体上还是遵循Android的框架：即上层应用和HAL层交互，高通平台在HAL层里面实现自己的一套管理策略； 在kernel中实现sensor的底层驱动。但是，对于最核心的sensor端的底层设置、ISP效果相关等代码则是单独进行了抽离，放在了一个 daemon进程中进行管理： 图1 Qualcomm平台camera代码架构简图 由于高通把大部分具体的设置及参数放到了daemon进程中，所以在kernel部分只是进行了V4L2的设备注册、IIC设备注册等简单的动作： 图2 kernel层camera主要代码简图 如上图，camera在kernel层的主文件为msm.c，负责设备的具体注册及相关方法的填 充；在msm_sensor.c文件中，主要维护高通自己的一个sensor相关结构体—msm_sensor_ctrl_t，同时把dts文件中的配置 信息读取出来；kernel层对于不同的sensor对应自己的一个驱动文件— xxsensor.c，主要是把power setting的设定填充到msm_sensor_ctrl_t中。 在vendor目录下，高通把各个sensor实质性的代码放置在此。一部分代码是高通自己实现的daemon进程和kernel层及HAL层进行通讯的 框架代码

高通平台开发实践经验 本文以一个3GPP下MO call（mobile original call）为例，简述从上层到下层如何建立call。安卓架构很多人都有印象，从APP层到FrameWork层到HAL层再到Linux Kernel层。由于安卓有两个处理器，一个是AP（Application Processor），一个是BP（baseband processor），而通话主要由BP去处理，所以这里我们关注BP。 一、平台架构分析 图1 高通平台架构 一个正常的主叫通话经过以下顺序发送到网络： UI（属于APP层） Telephony（属于FrameWork层） RIL.Java（属于FrameWork层） RILD（属于HAL层） QCRIL（高通设计实现的RIL处理机制，完成reqeust、response和modem indication）。 QMI（高通提供的与modem侧的接口） AP和BP的通信通过共享内存 Call manager（也就是CM，modem还有许多其他的模块这里不作介绍） NAS（Non-Access Stratum非接入层，业务建立、移动性管理等，通话问题主要关注NAS，OTA消息也是从NAS发出来的） AS（Access Stratum接入层，无线资源控制和无线链路控制） 最后发往网络 二、OTA (over the air）信令流程 三