FeedBurner RSS
联系博主
Email or Gtalk:
'民工技术' Category
为AVR写的1602A液晶屏幕驱动程序
April 12, 2009为1602ALCD屏幕实现的基本驱动功能，8位数据线，3位控制线，可自定义端口，可从LCD_Init函数设定工作方式，实现发送单字符和字符串的基本功能，带busy_wait。使用avr-gcc 编译。 代码下载：http://code.google.com/p/ptcoding/source/browse/trunk/AVR 更新：SVN目录内还有串口通讯的模块，以及串口和LCD驱动结合起来的一个试验性程序 参考资料：lcd1602a_398762.pdf（英文） ourAVR （注意两份资料的出入，前者更详细） 开发手记： 之前从天河赛格买了个1602的液晶屏，折腾了两天，终于让ATmega48驱动起来。 1602本来是一个挺简单的器件，8位数据线和3位控制线，其工作时序图初看起来挺复杂，但其实也就E端使能脉冲的事情，但是折腾下来，再一次验证了“简体中文”资料的不可靠，还有就是“这就是传说中的‘驱动程序’”。 首先我是从ourAVR网站提供的1602B液晶使用范例提供的资料入手（1602A、B好像没太大区别），借鉴了人家用ICCAVR写的代码（虽然代码是我敲的，但是基本上还是抄的），当LCD上显示出第一个字母时，还挺兴奋的，然而，这只是刚刚开始……（才100多行代码，加上看资料个把小时什么都好了。） 接下来才是噩梦般的调试，要么给黑方块，要么乱码，不稳定，这次能显示，重启就不行……还是ourAVR那篇资料提醒了我，初始化工作做的不够，写个循环发20次初始化信号，果然稳定了…… 奇怪阿，我明明按照Datasheet的数据来写的，怎么初始化不够呢？……说起1602的Datasheet，ourAVR那里提供了一份中文版，由“长沙太阳人电子有限公司”整理的，区区5页PDF，我另外Google了一份英文版的，顶，80多页，仔细一看，时序图居然有出入！转念一想，1602作为一种标准产品，一般的厂商只是兼容罢了，有多少出入还是正常的吧？不能全相信网上的Datasheet... 也从网上找了其他人写的1602驱程，51的、汇编的什么都来，有些的E使能脉冲居然是下降沿的，如此借鉴来借鉴去，折腾了两天。 最后还是被编译器“跹”了一回，比如把字符串写在发送函数的参数里就给我显示黑方块、乱码，又看了半天AVR的Flash空间、SRAM空间、EEPROM空间等的一大堆，最后才确定，是因为我使用之前《初尝Linux下的AVR单片机开发》里面的avr-objcopy -j .text参数，导致被放在.data段的字符串根本没有放到烧录文件内。 最后还有时序问题。一开始我使用了Busy Wait（读LCD的D7），认为以后就不用考虑命令时序了（LCD接受的命令有us级的一般命令ms级的两条清屏命令），结果还是乱的一团糟，最后往Busy Wait里面放了个死循环，发现程序根本都不绕进去，原来AVR芯片太快的，输出E信号后等不及LCD输出。 其他人写的驱动中，有些根本不考虑Busy标志的问题（干脆R/W接地），只要等候的时间足够，就可以保证写入的正常。在我最后写好的驱动中，我尝试把调用LCD_Busy_Wait的地方换成_delay_ms(5)，把整个LCD_Busy_Wait注释掉，这样工作起来是完全正常的，而且还省了36字节的程序，只是感觉上屏幕的反应就有那么一点的拖滞感。也可以把这个delay换成_delay_us(100)，这样没有拖滞感，但注意0x01这样的复位命令要注意要加个ms级的延时，但如果这样的延时语句多几条，程序在延时上膨胀的体积就远不止36字节了（别小看_delay_ms()，延时越久代码就越大），还不如用上Busy_Wait，这就需要应用在的来衡量了。
初尝Linux下的AVR单片机开发
April 2, 2009此前接触过AVR单片机，发现无论是书店里面的教材，还是网上一大堆的中文资料，无一例外都是说windows下使用WinAVR、ICCAVR之类的，Linux方面的简直只字不提，难道这就是传说中的中国国情？外国情况可很不一样，玩单片机的Geek一般都很哈Linux，做单片机开发的软件一应俱全，当然还是开源的。 昨天从淘宝重新买了条USB的下载线，回来一看是USBasp的设计，附送的光盘当然也是win下的驱动和说明了，忽略。 插上下载器，lsusb，认倒是认出来了，叫做VOIT，那怎么用呢？上网一搜，原来USBasp是德国人的设计http://www.fischl.de/usbasp/，GPL的，其中提到AVRDUDE支持USBasp，当然也有源码下载。不过我用的是Ubuntu，发挥超级牛力的时候到了：sudo apt-get install avrdude，恩，几秒钟搞定，让他们去编译吧！ Linux下做单片机开发当然首选GCC，就如这些英文教程说的，下载源码？No，No，APT has Super Cow Powers，继续sudo apt-get install gcc-avr binutils-avr avr-libc 几分钟装完，很好，估计那些下载源码回来编译的同学要去喝两个小时茶才能用了。 万事俱全，先写个单片机的HelloWorld，借用micahcarrick的源码： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 #define F_CPU 1000000UL /* 1 MHz CPU clock */ #include <util/delay.h> #include <avr/io.h> [...]
测试ibus输入法默认词库的流行词覆盖度
April 1, 2009这些天一直在想怎么扩充ibus输入法的词库，虽然一般使用感觉还好。在网上找到sogou提供了一个“互联网词库”，里面是搜索引擎分析出来的15万多词语，本想拿来导入到ibus，先用python测试了一下有多少词语已经在ibus的默认词库中，最后发现15万流行词中只有200多不在默认词库中，ibus词库确实挺优秀。 程序输出：（测试代码见后） seached: 157200 times. 215 phrases not in the database, written in file 'notexist' 查看notexist文件，发现除了后半部分一大堆频度为1的成语之外，只有20多个大频率词没在默认词库： （- -｜原来连“裸体”都没有？太和谐了！建议广滇驹推荐ibus为国家首选输入法） 乾坤 3561275 N, 乾隆 3088184 N, 乾净 1533219 夥伴 1052393 瞭望 984469 宏碁 979267 乾脆 953204 乾燥 624377 清乾隆 480337 乾隆皇帝 380252 N, 阿房宫 235461 乾隆年间 214986 定乾坤 210477 乾隆帝 149133 乾坤袋 143966 著色 111072 萧乾 84647 [...]
让Ubuntu更新内核时自动编译官方版Nvidia驱动模块
March 31, 2009目前Ubuntu 8.10中提供的最新Nvidia显卡驱动依然是180.11，除了不支持一些新的显卡，缺乏一些功能，在有些平台上也不稳定，容易Crash。很多人都用上Nvidia官网版的驱程，可是每当系统更新内核的时候，不得不回到console重新安装一次Nvidia，虽然不是很复杂，但长久如此，也挺麻烦的。 UbuntuForums上面一个Howto介绍了解决方法，下面简述之： 本方法不适合使用EnvyNG安装的驱动。 确保你全手动安装过Nvidia驱动并确定你所用的版本正常工作。 把NV的驱动安装文件复制到/usr/src，同时建立一链接。 sudo mv NVIDIA-Linux-x86-180.37-pkg1.run /usr/src sudo ln -s /usr/src/NVIDIA-Linux-x86-180.37-pkg1.run /usr/src/nvidia-driver 我安装的是180.37版本，注意不同版本的文件名不同。链接的作用是以后如果换一个新版的驱动进来，修改该链接即可，不用修改下面的脚本。 保存下面的代码为文件update-nvidia #!/bin/bash # # Set this to the exact path of the nvidia driver you plan to use # It is recommended to use a symlink here so that this script doesn't # have to be modified when you [...]
关于ibus输入法词库
March 30, 2009目前Linux下几个拼音输入法都处于初级的开发阶段，很难说哪个特别成熟，除了老牌的Fctix，基于SCIM平台有默认的智能、巨蟒、SunPinYin，当然还有我用的ibus。SunPinYin是Sun的OpenSolaris里面的一个项目，基于“统计语言模型”，技术刚刚的，据说反应极快，虽然目前功能欠缺，但真让人期待。 默认词库最大的似乎是巨蟒，据说用了sogou早期的词库，但是似乎词库处理上算法有点粗糙，而Fcitx的词库实在太小……ibus算中规中矩，词库不小，不算新，但也很容易让用户上手。 ibus当然也不完美，比如删词功能就经常不行（Ctrl + num），之前有hao的首选字突然变成了“号”，但明显“好”才更常用，郁闷了几天，安装了sqlitebrowser，打开用户词库，找到“号”把user_freq调回单位数（居然说我输入了几百次，晕！可能某次程序出错多循环了一会。） 盯着词库看挺好玩的，想到如果能导入搜狗词库多好（ibus比较却成语类的词），还顺手照书上例子试了下用Python读取ibus的数据库。没什么意义，当是数据库编程的Hello World吧。
HOWTO: Compile jpcap 0.7 for amd64
March 18, 2009As was introduced in it's project home, Jpcap is a Java library for capturing and sending network packets. However, this project hadn't been updated for quite a long time, and NO any 64bit platform version was provided. In the Google Discussion Group, "Tri" tried to compile jpcap in Ubuntu 8.04 64bit, and failed, giving such [...]
PyETGO 专辑下载脚本 Python练习作品
March 10, 2009PyETGO 0.3 更新版下载：http://code.google.com/p/ptcoding/source/browse/trunk/PyETGO 本脚本可跨平台使用，在Win下需要wget for Windows， 把wget.exe放在脚本所在目录即可。 Wget下载：http://www.interlog.com/~tcharron/wgetwin-1_5_3_1-binary.zip 感谢Twitter上的好友mengzehe关于Win下使用的测试和提醒。 感谢Ubuntu论坛上网友的测试。 v0.3 2009.03.16 -对获取的XML列表中存在的非法字符进行过滤（解决曲名含"&"等不规则字符导致无法下载） v0.2更新 2009.03.11 -为在Win下使用本脚本，全部使用Unicode的字符串来提示（0.1有部分乱码） -修改写入Intro.txt文件的方法，使用writelines，会根据操作系统不同写入不同换行符，减少乱码 -写入文件名前过滤Win下的非法文件名字符/\:<>?|等 大概实现这样的功能： 下载http://music.etgo.cn/上的任意专辑的音乐文件 专辑的存放目录命名为“歌手名 - 专辑名” 多CD的专辑，音乐文件命名为“CD号-轨号_歌手 - 歌名”，单CD则为“轨号_歌手 - 歌名” 下载专辑的封面和封底文件cover.jpg、coverback.jpg 从页面中抽出的专辑信息和介绍文字写入Intro.txt 首次使用需要用-u和-p输入一个ETGO账户以获取Cookie，以后下载只需用-a指定一个专辑的页面 下载时可随时使用Ctrl + C中断，重新下载时自动从断点续传。 花了好几天的时间在这个脚本上，基本把Python的特性摸熟了。 ETGO是国内一个娱乐网站，有电影、Mp3等，资源不算新，格式也就192～256K那样，没太大特色，但其有自己的服务器，运营稳定，这几年来我偶尔都从那里Down些专辑，基本上浏览器的嗅探+序号批量下载就可搞定，而且速度不赖。网站的免费试听使用的是Flash的播放器，这个脚本则模拟了播放器读取列表的功能，骗回所有Mp3的原始地址，然后调用wget下载。 稍微记录下开发过程。
继续CETQuery——C语言版
March 2, 2009用C来做这个题目还真是截然不同的感觉，没有HTTPConnection，没有urllib，所有报文都得自己构建自己解析……更麻烦的是中文问题，不得不调用到系统库来进行解码…… 貌似这次最满意的一行代码是： char type = (id[9] - 1) ? '6' : '4';
Page optimized by WP Minify WordPress Plugin