软硬件环境： Pxa310/300 + WinCE + WinMobile
中断唤醒源的设置可以说是一个纯“硬件”的活，因为它跟CPU关系非常紧密，不同的CPU即使同样在wince或者winmobile环境下，对于中断唤醒源的设置都是不同的。最近对于marvell pxa310/300里面中断唤醒源的设置了解了一下，发现跟之前pxa270系列的CPU也有很大差别。
将一个GPIO设置为中断唤醒源，在pxa270里面需要做如下工作：
1. 将此GPIO配置为输入GPIO功能，根据要求使能该GPIO是上升沿触发还是下降沿触发；
2. 用动态方式或者静态方式，让此GPIO关联上一个系统中断；
3. 调用如下函数，使能与这个GPIO绑定的系统中断作为唤醒源
KernelIoControl(IOCTL_HAL_ENABLE_WAKE, &g_SysIntr, sizeof(g_SysIntr), NULL, 0, NULL)
以上操作都是在驱动的初始化函数中完成的。
将一个GPIO设置为中断唤醒源，在pxa310里面需要做的工作前三步跟pxa270一样，但是也不尽一样，区别在于：
1. 上面第二步关联系统中断不一样。在pxa270里面是直接用该GPIO动态申请一个系统中断，或者用函数OALIntrStaticTranslate()静态关联一个系统中断。但是在pxa310里面，中断的关联要看该GPIO是属于哪一类的中断，通过查询CPU的pin脚功能定义可以得知，比如GPIO122的功能2是KP_DKIN<5> (wake ADxER[21])，所以要把该GPIO作为中断唤醒源的话，就需要map这一类型ADxER[21]的IRQ源。CPU的寄存器ADxER里面定义了所有可以作为唤醒源的IRQ，你可以用该IRQ为base来动态申请一个系统中断，也可以用函数OALIntrStaticTranslate来静态关联一个系统中断，但是这个IRQ必须是ADxER寄存器里面指定的IRQ。
2. 需要在驱动的powerdown函数里面，将该GPIO重新配置成可以作为唤醒的功能脚。比如GPIO122，正常使用的时候是作为普通中断GPIO来用的，也即是GPIO122的功能0，要作为唤醒源的话，需要在系统进入suspend之前将此GPIO重新配置为唤醒功能，也就是使用GPIO122的功能2。
这样的话，当系统处于suspend状态，GPIO122上如果有中断过来，满足触发条件的话，系统就会被唤醒了。
看过pxa310的spec上pin功能定义的朋友们就会发现一个问题了，GPIO有这么多，但是唤醒功能的IRQ源只有那么32个，而且很多都是使用的同一个唤醒源啊，如：
GPIO122的功能2是KP_DKIN<5> (wake ADxER[21])
GPIO123的功能2是KP_DKIN<4> (wake ADxER[21])
都是使用的KP类型的唤醒源，且是第21个。
GPIO112的功能1是UART2_RXD (wake GENERIC[4])
GPIO114的功能1是UART2_CTS (wake GENERIC[4])
都是使用的GENERIC[4]的IRQ。
这样的话，如果GPIO122和GPIO123同时作为唤醒源的话，他们map系统中断的IRQ就会是同一个IRQ了。
的确是这样的。
但是如果这样的话，系统怎么样去区分到底是那个GPIO唤醒系统的呢？？？
这个问题我也没弄清楚，如果有大侠知道的话请指点一下。
个人认为，唤醒系统的触发源就那么几种，如power key的按下，SD卡的插拔，耳机的插拔或者usb的插拔，所以在选择GPIO的时候尽量不要选用同一个唤醒源类型的GPIO；另外，只能够从功能上来区分到底是那个GPIO唤醒了系统，比如SD卡插拔唤醒了系统，那肯定不是耳机插入中断这个GPIO唤醒的系统，即使他们使用了同一个类型的唤醒源。
以上仅为个人总结的一点心得，欢迎拍砖！
Hzh
2010.03.27 11:29 AM
from:http://blog.csdn.net/ricky_hu/archive/2010/03/27/5422011.aspx
有的时候我们调试Android应用可能涉及中文内容，但是在DDMS的Logcat下显示中文时为乱码，这里大家可以通过自己编译SDK来解决，有关编译Android SDK方法可以参考如何编译Windows平台的Android SDK 下面一起看下哪个代码存在问题吧。
在Android源码DDMS中我们找到 MultiLineReceiver 这个类，对应GIT开源在development/tools/ddms/libs/ddmuilib/src/com/android/ddmuilib/，最主要的就是有关String实例化时最后一个参数，看到ISO-8859-1了吧，我们将这个换成gb2312就可以很好的显示简体中文了，繁体嘛可以考虑big5这种编码等等了，当然了Android123推荐大家使用UTF-8这种兼容性最好的。
public abstract class MultiLineReceiver implements IShellOutputReceiver {
public final void addOutput(byte[] data, int offset, int length) {
if (isCancelled() == false) {
String s = null;
try {
s = new String(data, offset, length, "ISO-8859-1"); //问题在这里，ISO-8859-1就是Latin-1我们俗称西欧语言
} catch (UnsupportedEncodingException e) {
// normal encoding didn't work, try the default one
s = new String(data, offset,length);
}
// ok we've got a string
if (s != null) {
// if we had an unfinished line we add it.
if (mUnfinishedLine != null) {
s = mUnfinishedLine + s;
mUnfinishedLine = null;
}
mArray.clear();
int start = 0;
do {
int index = s.indexOf("\r\n", start);
// if \r\n was not found, this is an unfinished line
// and we store it to be processed for the next packet
if (index == -1) {
mUnfinishedLine = s.substring(start);
break;
}
String line = s.substring(start, index);
if (mTrimLines) {
line = line.trim();
}
mArray.add(line);
// move start to after the \r\n we found
start = index + 2;
} while (true);
if (mArray.size() > 0) {
String[] lines = mArray.toArray(new String[mArray.size()]);
// send it for final processing
processNewLines(lines);
}
}
}
}
}
今天上班解决了一个问题：android程序通过蓝牙socket读取数据时，需要读多次才能把完整的响应APDU读全。当前用的方法来自android示例程序：
<!--EndFragment-->public void run() {
Log.i(TAG, "BEGIN mConnectedThread");
byte[] buffer = new byte[1024];
int bytes;
// Keep listening to the InputStream while connected
while (true) {
try {
// Read from the InputStream
Log.i(TAG, "Read from the InputStream...");
bytes = mmInStream.read(buffer);
Log.i(TAG, "Read from the InputStream, length is "+bytes);
// Send the obtained bytes to the UI Activity
mHandler.obtainMessage(BluetoothChat.MESSAGE_READ, bytes, -1, buffer)
.sendToTarget();
} catch (IOException e) {
Log.e(TAG, "disconnected", e);
connectionLost();
break;
}
}
}
响应APDU是
02001580FFFFFFFF00A4040010D15600010180038000000001000000006A03，
接收三次，每次的结果都不一样：
（1）02001580FFFFFFFF00A4040010D1560001018003 8000000001000000006A 03
（2）02 001580FFFFFFFF00A4040010D15600010180038000000001000000006A 03
（3）02001580FFFFFFFF00A4040010D15600010180038000000001000000006A 03
修改示例代码：响应APDU是可以解析的，第3个字节的值加上10就等于响应APDU的长度，其中10是前缀和后缀的长度之和。
public void run() {
Log.i(TAG, "BEGIN mConnectedThread");
byte[] buffer = new byte[1024];
// int bytes;
int len = 0;
int i = 0;
// Keep listening to the InputStream while connected
while (true) {
try {
// Read from the InputStream
Log.i(TAG, "Read from the InputStream...");
// bytes = mmInStream.read(buffer);
buffer[i++] = (byte) mmInStream.read();
if (i == 3) {
len = buffer[2] + 10;
}
Log.i(TAG, "Read from the InputStream, data is "
+ buffer[i - 1]);
if (i == len) {
// Send the obtained bytes to the UI Activity
mHandler.obtainMessage(BluetoothChat.MESSAGE_READ, len,
-1, buffer).sendToTarget();
len = 0;
i = 0;
}
} catch (IOException e) {
Log.e(TAG, "disconnected", e);
connectionLost();
break;
}
}
}
255不就够啦