#include "ioCC2530.h"
#define uchar unsigned char
#define led1 P1_0
#define led2 P1_1
#define led3 P1_4
#define led4 P0_1
void initled(void)
{
P1SEL &=~0x13;
P1DIR |= 0x13;
P0SEL &=~0x02;
P0DIR |= 0x02;
}
void init(void)
{
IEN0|=0x80; //开总中断
IEN1|=0x20; //开p0中断
P0IEN |=0x20; //注意还要打开 P0对应位的中断 否则不会引起中断
PICTL|=0x01; //选择高四位 下降沿置1
}
void main(void)
{
init();
initled();
P0IFG = 0x00;
led1=0;
led2=0;
led3=0;
led4=0;
while(1)
{}
}
#pragma vector=P0INT_VECTOR
__interrupt void P0_IRQ(void)
{
if(P0IFG!=0x00)//初始化时标志位就是0
{
if(led1==1)
{
led1=0;
}
else
{
led1=1;
}
P0IFG=0x00;
IRCON&=~0x20;
}
}
Android中的传感器主要有以下几种
传感器 Java中的名称 本地接口名称 数值
加速度 TYPE_ACCELEROMETER SENSOR_TYPE_ACCELEROMETER 1
磁场 TYPE_MAGNETIC_FIELD SENSOR_TYPE_MAGNETIC_FIELD 2
方向 TYPE_ORIENTATION SENSOR_TYPE_ORIENTATION 3
陀螺仪 TYPE_GYROSCOPE SENSOR_TYPE_GYROSCOPE 4
光线 TYPE_LIGHT SENSOR_TYPE_LIGHT 5
压力 TYPE_PRESSURE SENSOR_TYPE_PRESSURE 6
温度 TYPE_AMBIENT_TEMPERATURE SENSOR_TYPE_TEMPERATURE 7
距离 TYPE_PROXIMITY SENSOR_TYPE_PROXIMITY 8
陀螺仪传感器叫做Gyro-sensor，返回x、y、z三轴的角加速度数据。
角加速度的单位是radians/second。
根据Nexus S手机实测：
水平逆时针旋转，Z轴为正。
水平逆时针旋转，z轴为负。
向左旋转，y轴为负。
向右旋转，y轴为正。
向上旋转，x轴为负。
向下旋转，x轴为正。
磁力传感器简称为M-sensor，返回x、y、z三轴的环境磁场数据。
该数值的单位是微特斯拉（micro-Tesla），用uT表示。
单位也可以是高斯（Gauss），1Tesla=10000Gauss。
硬件上一般没有独立的磁力传感器，磁力数据由电子罗盘传感器提供（E-compass）。
电子罗盘传感器同时提供下文的方向传感器数据。
光线感应传感器检测实时的光线强度，光强单位是lux，其物理意义是照射到单位面积上的光通量。
光线感应传感器主要用于Android系统的LCD自动亮度功能。
可以根据采样到的光强数值实时调整LCD的亮度。
方向传感器简称为O-sensor，返回三轴的角度数据，方向数据的单位是角度。
为了得到精确的角度数据，E-compass需要获取G-sensor的数据，
经过计算生产O-sensor数据，否则只能获取水平方向的角度。
方向传感器提供三个数据，分别为azimuth、pitch和roll。
azimuth：方位，返回水平时磁北极和Y轴的夹角，范围为0°至360°。
0°=北，90°=东，180°=南，270°=西。
pitch：x轴和水平面的夹角，范围为-180°至180°。
当z轴向y轴转动时，角度为正值。
roll：y轴和水平面的夹角，由于历史原因，范围为-90°至90°。
当x轴向z轴移动时，角度为正值。
电子罗盘在获取正确的数据前需要进行校准，通常可用8字校准法。
8字校准法要求用户使用需要校准的设备在空中做8字晃动，
原则上尽量多的让设备法线方向指向空间的所有8个象限。
温度传感器返回当前的温度。
加速度传感器又叫G-sensor，返回x、y、z三轴的加速度数值。
该数值包含地心引力的影响，单位是m/s^2。
将手机平放在桌面上，x轴默认为0，y轴默认0，z轴默认9.81。
将手机朝下放在桌面上，z轴为-9.81。
将手机向左倾斜，x轴为正值。
将手机向右倾斜，x轴为负值。
将手机向上倾斜，y轴为负值。
将手机向下倾斜，y轴为正值。
压力传感器返回当前的压强，单位是百帕斯卡hectopascal（hPa）。
距离传感器检测物体与手机的距离，单位是厘米。
一些距离传感器只能返回远和近两个状态，
因此，接近传感器将最大距离返回远状态，小于最大距离返回近状态。
接近传感器可用于接听电话时自动关闭LCD屏幕以节省电量。
重力传感器简称GV-sensor，输出重力数据。
在地球上，重力数值为9.8，单位是m/s^2。
坐标系统与加速度传感器相同。
当设备复位时，重力传感器的输出与加速度传感器相同。
线性加速度传感器简称LA-sensor。
线性加速度传感器是加速度传感器减去重力影响获取的数据。
单位是m/s^2，坐标系统与加速度传感器相同。
加速度传感器、重力传感器和线性加速度传感器的计算公式如下：
加速度 = 重力 + 线性加速度
旋转矢量传感器简称RV-sensor。
旋转矢量代表设备的方向，是一个将坐标轴和角度混合计算得到的数据。
RV-sensor输出三个数据：
x*sin(theta/2)
y*sin(theta/2)
z*sin(theta/2)
sin(theta/2)是RV的数量级。
RV的方向与轴旋转的方向相同。
RV的三个数值，与cos(theta/2)组成一个四元组。
RV的数据没有单位，使用的坐标系与加速度相同
举例：
sensors_event_t.data[0] = x*sin(theta/2)
sensors_event_t.data[1] = y*sin(theta/2)
sensors_event_t.data[2] = z*sin(theta/2)
sensors_event_t.data[3] = cos(theta/2)
传感器的管理: SensorManager
SensorManager就是所有传感器的一个综合管理类,包括了传感器的种类、采样率、精准度等。我们可以通过getSystemService方法来取得一个SensorManager对象.代码如下:
SensorManager mSensorManager = (SensorManager)getSystemService(SENSOR_SERVICE);
取得SensorManager对象之后,可以通过getDefaultSensor方法来获得我们需要的传感器类型通过如下代码可以得到一个加速度传感器:
mAccelerometer = mSensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER);
通過getSensorList(int type)获得可用的传感器列表
传感器的监听事件: SensorEventListener
onSensorChanged(int sensor,float values[]) 方法在传感器值更改时调用。该方法只对受此应用程序监视的传感器调用。
该方法的参数包括：
一个整数，指示更改的传感器；
一个浮点值数组，表示传感器数据本身。有些传感器只提供一个数据值，另一些则提供三个浮点值。方向和加速表传感器都提供三个数据值。
onAccuracyChanged （Sensor sensor,int accuracy） 方法在传感器的精准度发生改变时调用。其参数包括两个整数：一个表示传感器，另一个表示该传感器新的准确值。
注册和卸载传感器
要与传感器交互,应用程序必须注册以侦听一个或多个传感器相关的活动。
Android中提供了registerListener来注册一个传感器，并提供了unregisterListener来卸载一个传感器。
registerListener方法包括3个参数:
第1个参数,接收信号的Listener实例
第2个参数,想接收的传感器类型
第3个参数,接收频度.包括最快、游戏、普通、用户界面四个常量值。
当应用程序请求特定的采样率时，其实只是对传感器子系统的一个建议，不保证特定的采样率可用。
最快： SensorManager.SENSOR_DELAY_FASTEST
最低延迟，一般不是特别敏感的处理不推荐使用，该种模式可能造成手机电力大量消耗，由于传递的为原始数据，算法不处理好将会影响游戏逻辑和UI的性能。
游戏： SensorManager.SENSOR_DELAY_GAME
游戏延迟，一般绝大多数的实时性较高的游戏都使用该级别。
普通： SensorManager.SENSOR_DELAY_NORMAL
标准延迟，对于一般的益智类或EASY级别的游戏可以使用，但过低的采样率可能对一些赛车类游戏有跳帧现象。
用户界面： SensorManager.SENSOR_DELAY_UI
一般对于屏幕方向自动旋转使用，相对节省电能和逻辑处理，一般游戏开发中我们不使用。
一般在OnResume中調用register註冊,在onPause和onStop中調用unregister卸載
调用之后返回一个布尔值,true表示成功,false表示失败
//注册传感器
Boolean mRegisteredSensor = mSensorManager.registerListener(new SensorEventListener(), mSensorManager.getDefaultSensor(Sensor.TYPE_ORIENTATION), SensorManager.SENSOR_DELAY_FASTEST);
//卸载传感器
mSensorManager.unregisterListener(this);
例子：
package com.light.android;
import android.app.Activity;
import android.hardware.Sensor;
import android.hardware.SensorEvent;
import android.hardware.SensorEventListener;
import android.hardware.SensorManager;
import android.os.Bundle;
import android.widget.TextView;
public class MainActivity extends Activity implements SensorEventListener {
private SensorManager sm;
private TextView tv1,tv2,tv3,tv4,tv5;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
sm = (SensorManager) getSystemService(SENSOR_SERVICE);
tv1 = (TextView) findViewById(R.id.tv1);
tv2 = (TextView) findViewById(R.id.tv2);
tv3 = (TextView) findViewById(R.id.tv3);
tv4 = (TextView) findViewById(R.id.tv4);
tv5 = (TextView) findViewById(R.id.tv5);
}
@Override
protected void onResume() {
super.onResume();
sm.registerListener(this, sm.getDefaultSensor(Sensor.TYPE_ACCELEROMETER), SensorManager.SENSOR_DELAY_UI);
sm.registerListener(this, sm.getDefaultSensor(Sensor.TYPE_LIGHT), SensorManager.SENSOR_DELAY_UI);
sm.registerListener(this, sm.getDefaultSensor(Sensor.TYPE_AMBIENT_TEMPERATURE), SensorManager.SENSOR_DELAY_UI);
sm.registerListener(this, sm.getDefaultSensor(Sensor.TYPE_ORIENTATION), SensorManager.SENSOR_DELAY_UI);
sm.registerListener(this, sm.getDefaultSensor(Sensor.TYPE_MAGNETIC_FIELD), SensorManager.SENSOR_DELAY_UI);
}
@Override
protected void onPause() {
super.onPause();
sm.unregisterListener(this);
}
@Override
protected void onStop() {
super.onStop();
sm.unregisterListener(this);
}
@Override
public void onAccuracyChanged(Sensor sensor, int accuracy) {
}
@Override
public void onSensorChanged(SensorEvent event) {
int type = event.sensor.getType();
switch (type) {
case Sensor.TYPE_ACCELEROMETER:
StringBuffer sb1 = new StringBuffer();
sb1.append("加速度傳感器");
sb1.append("\n X軸的加速度: "+event.values[0]+" m/s^2");
sb1.append("\n Y軸的加速度: "+event.values[1]+" m/s^2");
sb1.append("\n Z軸的加速度: "+event.values[2]+" m/s^2");
tv1.setText(sb1.toString());
break;
case Sensor.TYPE_LIGHT:
StringBuffer sb2 = new StringBuffer();
sb2.append("\n 光傳感器");
sb2.append("\n 周圍光線強度 "+event.values[0]+" lux");
tv2.setText(sb2.toString());
break;
case Sensor.TYPE_AMBIENT_TEMPERATURE:
StringBuffer sb3 = new StringBuffer();
sb3.append("\n 溫度傳感器");
sb3.append("\n 周圍溫度 "+event.values[0]+" °C");
tv3.setText(sb3.toString());
break;
case Sensor.TYPE_ORIENTATION:
StringBuffer sb4 = new StringBuffer();
sb4.append("\n 方向傳感器");
sb4.append("\n 與Z軸的夾角 "+event.values[0]);
sb4.append("\n 與X軸的夾角 "+event.values[1]);
sb4.append("\n 與Y軸的夾角 "+event.values[2]);
tv4.setText(sb4.toString());
break;
case Sensor.TYPE_MAGNETIC_FIELD:
StringBuffer sb5 = new StringBuffer();
sb5.append("\n 磁場傳感器");
sb5.append("\n X軸的磁場 "+event.values[0]);
sb5.append("\n Y軸的磁場 "+event.values[1]);
sb5.append("\n Z軸的磁場 "+event.values[2]);
tv5.setText(sb5.toString());
break;
}
}
}
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:orientation="vertical" >
<TextView android:id="@+id/tv1"
android:layout_width="wrap_content"
android:layout_height="wrap_content"/>
<TextView android:id="@+id/tv2"
android:layout_width="wrap_content"
android:layout_height="wrap_content"/>
<TextView android:id="@+id/tv3"
android:layout_width="wrap_content"
android:layout_height="wrap_content"/>
<TextView android:id="@+id/tv4"
android:layout_width="wrap_content"
android:layout_height="wrap_content"/>
<TextView android:id="@+id/tv5"
android:layout_width="wrap_content"
android:layout_height="wrap_content"/>
</LinearLayout>效果：
对冲基金是金融行业一种降低风险的行为或策略，最通俗的解释是，在一个市场货资产上交易，以对冲在另一个市场货资产上的风险。很多具有杠杆的放大效应，或规避风险的“缓冲”作用。但放在互联网领域来看，对冲就变成了一种新玩法。
在互联网行业里，这几年有不少这样的案例，腾讯、百度、阿里、360，不管是产品的布局，还是玩的资本收购动作，很多都有对冲的痕迹。说白了就是，不愿意把鸡蛋放在一个篮子里，通过多条腿走路或押宝的方式，虚晃一招，表面看起来像障眼法，实则目的性很明确。
今天上午，在百度世界大会上，百度终于露出来了真正的对冲意图，重磅提出了Light App的轻应用概念，给出的说法是帮助长尾应用突破应用商店模式下的寡头困局。熟悉百度的移动互联网玩法和套路的人都很清楚，百度的后手终于出来了。
这是不是在玩对冲？百度为什么这样选择？
百度花费了19亿美元收购了91无线，只看交易本身的人觉得不划算，但如果放在百度移动互联网的“格局”里，对交易背后考量下，你会发现这颇有对冲基金的味道。
91无线的强分发能力，占据的是Native App应用的入口。当时就能猜得出来，Native App虽然目前是移动互联网的主流形态，但80%的中长尾APP应用的使用率实际上是在下降，而且下滑速度很快，但长尾应用的用户需求却与日俱增。应用商店的模式短期难以解决这个问题。
只不过，百度不可能坐等WebApp的成熟，所以就上演这出先将91无线拿下，占领现有的APP形态，进而又暗度陈仓重磅推轻应用的这场大戏。因为在Native App和轻应用未来的关系还没有明确，押宝一方的策略并不科学，也不保险。所以“对冲”来降低风险，无论哪一路胜出，还是未来式并行的趋势，百度都有足够的综合能力。
当然，百度这次采取了“对冲”的作法，还有一个原因：无论是Native App还是轻应用，在两个战线上，百度都具备强大的分发能力，收购91无线后，加上百度手机助手的能量，Native App日均分发下载量达到了6900万，这是一个绝对靠前的数字；Light App应用上，百度向来走的是移动基础架构能力的供应商路线，在移动云技术、服务的能力输出和供应生态上，是强势地位。而且Light App的形态更贴近搜索，搜索的智能分发功能就能对接上。一旦如此杀伤力更大。所以百度已有的能力能支撑双线模式的运作，在两个战场布局更为合理。
那么百度这种“对冲”的玩法能成吗？
如果说一定没问题，那绝对是骗人的。就连拥有了4.5亿用户的微信，以及7.5亿手机QQ的腾讯，都不敢说能叱咤未来的移动互联网。所以说，百度玩“对冲”目的是在短期市场形态模糊，看不清晰未来的环境下，让百度在“空窗期”积累开发者、用户规模，等待时机一旦成熟，就可以玩跷跷板的游戏了。
但这里面依然会存在两方面问题：
一是Native App分发能力。6900万日均分发量是一个尴尬的数字，虽然在规模上排名第一了，但后面的360手机助手相当接近，远没有一股独大，形成类搜索的市场状态。百度和360目前的差距不是很大，两者的距离还不属于安全距离。
二是Light App刚刚提出来，虽然Native App商店分发模式的弊端日渐暴露，高推广费、刷榜作弊、大量僵尸APP应用浮现等现象，让“重APP”在安装推广、留存率、用户活跃度无法保障，但轻应用现在并不完全成熟，很多技术上的问题尚未完全攻克。在商业模式、认可度，开发者聚集效应及商业变现能力上，都还只是一个“轮廓”。这是一个更未知的领域。
这次百度世界大会上，围绕着Light App的云生态，百度开始大作文章，开源的APP开发框架clouda工具、环境，还有语音云、人脸识别、图像处理等开放的云组件，甚至还提出了针对开发者向Light App“迁移”的多条转换路径和方法。百度大动干戈如何折腾又是为什么呢？显然目的仅有一个，就是充分降低“对冲”的风险，尽快在Native App未落定的缓冲时间里，把Light App“养”大，并看到结果。
轻应用会是百度最需要的产品形态吗？
谈到这里，很多人可能会有一个印象，貌似Native App只是一个托儿，是一个为Light App做嫁衣的“过渡产品”。而最终的产品形态，百度更像是卯足劲奔轻应用去的。怎么说呢？目前来看，是！但未来难说，现在下这样的结论还为时过早。
HTML5以及百度推出一大堆的开发工具和云能力，短期还难以判断轻应用的规模、以及在中长尾应用上的价值兑现会如何。这看起来类似百度联盟当年汇聚几十万的站长的意味，但两者有很大的区别。Light App会不会主宰下一个移动互联网时代？目前只能说，Native App符合高频、交互要求高的应用，能获得最佳的体验，至少当下轻应用绝对完全替代存在瓶颈。Light App在低频、偏内容型的应用上更具优势，特别是结合搜索的分发能力，能接触到更广泛的用户。后者从Native App阵营逃出来的可能很大。
另外，百度为Light App还铺了很多路。这次百度在CLOUDA框架中还推出了可检索性的技术，这个技术看起来单一，背后则是百度实现应用内搜索、分发及匹配的野心，也是为Light App落地、摇旗呐喊的一个武器，借解决“用户找不到应用，应用与用户需求不匹配”的难题，来为Light App加码。
对冲有时就像放烟雾弹，让对手分不清真假，也能让自己多个后手。但未来究竟是Native App Or Light App？百度并没有给出明确的答案。不过能感觉出来Light App在百度眼里的份量，虽然未来是不是最佳形态还不肯定，但至少目前是。