好久没更新博客了, 最近实在太忙了, 那就水一下, 更新涂鸦作品一张.
绘图软件使用的是我最近给客户开发的 StylusSketch 应用.
分类： 我的项目
我的项目列表
速度补偿压感效果的改善
在纸质笔记本上书写的时候，会随着书写速度的快慢，钢笔笔迹会相应变细或者变粗，这样的笔迹更加动感，优美。终于，手写控件也实现了这个效果。在普通触摸屏上能实现这样的效果，的确不错。
图1：
图2
Android 原笔迹手写实现普通触摸屏的压感笔锋效果
Android 要实现原笔迹手写的压感，笔锋，必须要配合更好的压感触摸屏，例如电磁屏。三星的 note 系统，微软的 surface 系列，都是需要加装电磁屏的。E人E本，好记星的平板，有电磁屏的加成，也能很好的实现压感笔锋的效果，而且效果并不比三星微软的差。
如果没有电磁屏，也可以依靠最近兴起的主动电容屏来实现压感笔锋的效果，但是效果略差。
如果连主动电容屏也没有，那就是普通的电容屏，这样一般只能实现没有压感笔锋的效果，只能勉强用用，无法体会平板手写的优雅~~~
之前，手写控件也受限于此，无法实现普通电容屏的压感笔锋效果，效果如下：
幸好，现在我的手写控件已经克服这个问题，通过算法实现了普通电容屏的压感笔锋效果，而且整体效果也很好。
看图：
原笔迹手写控件支持鼠标
支持鼠标了。当前只是电磁笔，手指，以及鼠标。更加完善了。
手写控件支持同步显示功能
手写控件支持同步显示功能，简单来说，就是 View1书写，然后另外一个 View2 用来同步显示。这个是继支持导入 SVG 数据后的又一个改进。
技术上都是没有什么难点，毕竟数据格式都是我自己定义的。同步数据支持同步整个 View 的笔迹，也支持增量添加笔迹。增量添加这个在实际应用场景应该会很受用，例如同步网络端传输过来的笔迹数据。
看效果图：
下一个目标应该是支持手写动作的回放了，加油。还有一个目标，就是笔迹粗细根据书写速度进行调整，估计这样的手写效果会更加漂亮。
手写控件：加权滑动平均值法滤波算法解决压力变化过大的问题
在手写控件适配到其他平板的时候，会发现每个平板的压力反馈值有不小的差异，这样会存在一种情况，在某些平板上，就是在收笔的时候压力突然变小后，就成前面一段粗，后面一段细，
这个时候，使用简单的滤波算法能简单的解决问题。
滑动平均值法：
滑动平均值法当前采样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文件的可重用性，真的很方便，而且最终的项目打包时，库的集成方面的工作也是无忧解决。大赞。
好记星N818S
解决触摸屏 ft5x06 I2C 总线无法通讯问题
现象描述：
新平板产品量产过程中，工厂反映有1%的触摸屏出现无法正常工作。拿到不良的触摸屏后，通过分析系统启动的 log，发现触摸屏驱动已经加载，但是 probe 函数中打印无法找到 0x38 设备。0x38 设备就是 ft5x06 的设备从地址，证明 I2C 通讯没有成功。但是奇怪的是，这些不良的触摸屏在上一款硬件雷同的平板上可以正常工作。
原因分析：
I2C 通信不成功的原因无非以下几点：
- 通讯协议不正确。
- I2C从设备地址不正确
- I2C通讯线上没有加上拉电阻：由于I2C的从设备的SDA，SCL的PIN是输出开漏的，所以必须加上拉电阻，同时根据I2C设备的数量上拉电阻的大小也会不同。从1K~10K以上，当然不能太大,也不能太小。
- 电路干扰
- 通信时序
因为我们上一款平板的触摸屏驱动是由 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，