分类： 我的项目

我的项目列表

Android 原笔迹手写实现普通触摸屏的压感笔锋效果

Android 要实现原笔迹手写的压感，笔锋，必须要配合更好的压感触摸屏，例如电磁屏。三星的 note 系统，微软的 surface 系列，都是需要加装电磁屏的。E人E本，好记星的平板，有电磁屏的加成，也能很好的实现压感笔锋的效果，而且效果并不比三星微软的差。

如果没有电磁屏，也可以依靠最近兴起的主动电容屏来实现压感笔锋的效果，但是效果略差。

如果连主动电容屏也没有，那就是普通的电容屏，这样一般只能实现没有压感笔锋的效果，只能勉强用用，无法体会平板手写的优雅~~~

之前，手写控件也受限于此，无法实现普通电容屏的压感笔锋效果，效果如下：
android-paintview-finger-pressure-not-ok

幸好，现在我的手写控件已经克服这个问题，通过算法实现了普通电容屏的压感笔锋效果，而且整体效果也很好。
看图：

android-paintview-finger-pressure

手写控件支持同步显示功能

手写控件支持同步显示功能，简单来说，就是 View1书写，然后另外一个 View2 用来同步显示。这个是继支持导入 SVG 数据后的又一个改进。

技术上都是没有什么难点，毕竟数据格式都是我自己定义的。同步数据支持同步整个 View 的笔迹，也支持增量添加笔迹。增量添加这个在实际应用场景应该会很受用，例如同步网络端传输过来的笔迹数据。

看效果图：
paint_sync

下一个目标应该是支持手写动作的回放了，加油。还有一个目标，就是笔迹粗细根据书写速度进行调整，估计这样的手写效果会更加漂亮。

手写控件：加权滑动平均值法滤波算法解决压力变化过大的问题

在手写控件适配到其他平板的时候，会发现每个平板的压力反馈值有不小的差异，这样会存在一种情况，在某些平板上，就是在收笔的时候压力突然变小后，就成前面一段粗，后面一段细，就像下图：
unnamed
这个时候，使用简单的滤波算法能简单的解决问题。

滑动平均值法：

滑动平均值法当前采样1次压力值，将本次采样值和以前的N－1次采样值一起求平均，得到当前的有效采样值。滑动平均值法把N个采样数据看成一个队列，对列的长度固定为N，每进行一次新的采样，把采样结果放入队尾，而扔掉原来队首的一个数据，这样在队列中始终有N个“最新”的数据。计算滤波值时，只要把队列中的N个数据进行平均，就可得到新的滤波值。

加权滑动平均值法：
上面提到的求平均值的算法，其实并不是很适合我们手写的场景，它更适合采样比较恒定的数据。所以我们需要对这个平均值算法做一些改善，不是求平均值，而是每个队列中的数值，分配一个权重，数值乘以权重，相加，得到最后的结果。

下面是一个最简单的例子，例子里面的队列只有两个数值，第一个数值的权重是 0.4，第二个数值的权重是 0.6，最后 pressure 就是平滑后的压力值。


float lastPressure = 0.0f;
float PRESSURE_FILTER_WEIGHT = 0.6f;
pressure = PRESSURE_FILTER_WEIGHT * realPressure
+ (1 - PRESSURE_FILTER_WEIGHT) * lastPressure;

lastPressure = pressure;

最后，通过调整权重，还可以动态调整最后的效果，以适应不同的平板硬件。

折腾Web项目

最近在折腾Web相关的项目，Web相关知识从零开始。不过，相比嵌入式驱动开发，Web项目的入门门槛还算是低的。这也是我这种懒人想死守嵌入式驱动开发的原因，毕竟门槛高，竞争比较少。

这次的Web练手项目，主要是根据用户提供的关键字，搜索出相应的题目以及答案。

项目的整个架构由我策划，基于Spring，整合Lucene搜索引擎，中文识别用IKAnalyzer，服务器用Ubuntu + tomcat。

历时两周，硬件+软件+知识储备都是从零开始，也算是对Web项目开发有了初步的认识。

同时新上手了Intellij idea这个主流的IDE，毕竟从零开始嘛，开发工具肯定用主流的，快捷键切换为Eclipse的即可。

也对Maven基于项目对象模型(POM)有所了解，主要用来简化项目的构建工作。当然刚接触时被一堆配置信息搞得晕头转向，特别是网上没有源的库还要自己手动配置整理。但一旦配置完成后，POM文件的可重用性，真的很方便，而且最终的项目打包时，库的集成方面的工作也是无忧解决。大赞。

继续阅读折腾Web项目

解决触摸屏 ft5x06 I2C 总线无法通讯问题

现象描述：

新平板产品量产过程中，工厂反映有1%的触摸屏出现无法正常工作。拿到不良的触摸屏后，通过分析系统启动的 log，发现触摸屏驱动已经加载，但是 probe 函数中打印无法找到 0x38 设备。0x38 设备就是 ft5x06 的设备从地址，证明 I2C 通讯没有成功。但是奇怪的是，这些不良的触摸屏在上一款硬件雷同的平板上可以正常工作。

原因分析：

I2C 通信不成功的原因无非以下几点：

  1. 通讯协议不正确。
  2. I2C从设备地址不正确
  3. I2C通讯线上没有加上拉电阻：由于I2C的从设备的SDA，SCL的PIN是输出开漏的，所以必须加上拉电阻，同时根据I2C设备的数量上拉电阻的大小也会不同。从1K~10K以上，当然不能太大,也不能太小。
  4. 电路干扰
  5. 通信时序

因为我们上一款平板的触摸屏驱动是由 RK 直接提供的，而且我们也量产1年时间，没有发现类似的问题。出问题的这款平板硬件跟上一版本的雷同，软件驱动也是一样的，所以认为软件驱动应该没什么问题，电气性的问题概率会大一点。

尽管如此，我还是重新检查了一遍触摸屏驱动，调整 I2C 速率，重新烧录后发现还是老样子。

决定去硬件组看看。硬件的同事用示波器观察了 I2C 的通信波形，发现出现了中间电平。数字电路不是只有高电平，低电平，1和0吗？怎么出来了一个中间电平了。什么是中间电平？例如芯片规格规定高电平是高于2.4V，电平低于0.4V，如果出现了1.4V的话，那就是中间电平了。

解决方案：

出现中间电平，可能是因为触摸屏内阻比较大，分压过大，造成低电平下不来。

可以通过修改上拉电阻，提高上拉电阻的分压比例，降低触摸屏内阻的分压比例，达到低电平降下来的效果。换10K上拉电阻，老样子，再换…直到换了一个50K的电阻之后，低电平果然就下来了，I2C 通信波形也很正常，触摸屏工作正常！但是50K上拉电阻的情况下，其它本来正常的触摸屏的波形就不是很好。这个方案不完美。

然后就考虑通过调整 CPU I2C 端口驱动电流来实现上拉电阻提高分压比例的方法，RK3188的 I2C 端口默认是 2 ma, 通过软件配置寄存器，将驱动电流调整为 4ma 后，波形正常了，不良的触摸屏也可以正常使用了。而且对其他正常的触摸屏也没有影响。

问题解决！

 

我的开源项目 Device Checker 设备检测器

一、项目介绍：

描述：

Device Checker 设备检测器是一款 android 应用，用于检测手机的各个硬件模块是否正常工作。

立项：

本人主业是嵌入式驱动开发，经常要跟设备的各个模块打交道，经常要写一些代码测试各个模块是否正常工作，所以有想法做这么一个项目，一方面是能增强自己的开发实力，一方面可以帮助到其他朋友验机（如果他们看得上眼的话～～～）。

开源：

开源的想法主要是学习一下开源项目的流程，当然有朋友一起学习开发就更好。源码托管选择了google code，

应用发布：

地址：http://www.mumayi.com/android-648974.html

继续阅读我的开源项目 Device Checker 设备检测器