Android底层开发之红外遥控驱动移植

1.红外遥控驱动移植

     每个脉冲都是一个中断，逐个脉冲计数判断就成了红外信息接收驱动程序。

 

 

就是一个普通的GPIO口。

 

 

关于休眠后通过红外遥控器唤醒系统

    

系统休眠

Android的开发者网站中以应用开发者的角度说明了系统电源状态，以CPU，Screen，Keyboard的工作状态来区分。

 

这里呈现给应用开发者的状态，但对于操作系统和Linux内核来说是有严格的等级制度的。

* Early suspend 相当于PC中的睡眠状态

* suspend       相当于PC中的suspend状态

* 

 

对于电源直接供电设备，可以让系统级应用开启一个PARTIAL_WAKE_LOCK锁。这样系统默认进入的就是浅休眠，唤醒问题得以解决。

 

以下四个方法：

1. if resume handler of rk remote driver can run at very first place in whole resume process;

2. if handler wait proper key signal (drop partial signal) then you can get key code and decide "continue to wake or sleep again";

3. if remote controller send key code repeatedly while "drop partial signal and wait proper/complete key signal";

4. if the system is only _early suspend_ don't _suspend_. likes a PC we used.

 

深度休眠后遥控器不能唤醒系统分析和方案选择

 

Android休眠状态主要有浅休眠/深度休眠，前者相当于PC机上的待机状态 后者相当于睡眠状态。Android系统深度休眠后，所有的驱动（包括红外驱动）是不工作的。红外信号是一串连续的波形。测试在深度休眠时红外信号到CPU之前都是正常完好的。当按下遥控器上的按键时，CPU收到红外信号后会立即开始唤醒所有驱动，但是在这个时间段中红外信号是在不断地输入，等到红外遥控驱动唤醒完成后它所能接收到的信号并不是一个完整的信号，所以也无法解析出一个正确的按键，没有办法向上层系统上报一个唤醒的键值。接着内核会再次进入休眠状态。导致系统不能正常唤醒。

 

1. 唤醒系统时首先唤醒IR驱动；         

   个人评价：无论再怎么首先唤醒IR驱动，也会导致丢失部分红外信号；

 

2. 接收到信号时将信号保存，等IR驱动唤醒成功后再传至其处理函数；

   个人评价：这个需要在PM中实现，复杂度有点高；

 

3. 遥控器连续发送相同信号，直到系统完全唤醒停止；

   个人评价：这个要修改遥控器的实现，且红外传输一般是单向的，不切合实际。

 

4. 系统只进入浅休眠状态（相当于PC上的「待机」状态），不进入深度休眠状态。

   个人评价：对于电源供电设备，完全可以照此方法实现，这也是普通PC机的实现方法。不用过度按照电池供电设备(手机/平板)的而丧失一些易用性。同时照此实现方法后之前一直搁置的鼠标/键盘唤醒系统的问题也同时得以解决。

 

关于「确定真正问题之前疑点」的解答

1. 连接USB OTG线到PC机时为什么可以正常使用

   因为这里系统进入的是 浅休眠 不是深度休眠，所有驱动工作正常。

 

2. 为什么产线版本系统可以正常唤醒

   当时测试时，由于产线版本系统中有一个 硬件测试 APP在运行，

   该软件限制了系统进入「深度休眠」，关闭或者删除后问题就可以重现。

 

3. 多次按键能偶尔能唤醒

   在红外驱动被唤醒后，再按的键后遥控器发出的红外信号是可以被完整接收到的。

   但这有相当大的偶然性。

关于第4种方法的代码实现

一段代码就可以实现，将其添加至SystemUI中：

PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE);

wl = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "My Tag");

wl.acquire();

 

画的两个原理手图：