杂七杂八的

今天编程实在编不动了,好烦。所以写点东东吧,把这段时间发现列一下。
CANopen项目的:
#1# printf和fprintf这样的语句,执行时需要百微秒完成,所以在测量微秒级的代码效率的时候,一定不要在代码里面添加打印输出,否则结果都是错的。
#2# 尽管FLASH已经很并且据说可以擦写多次,但是调ARM的时候,还是把FLASH给写坏了,所以不要在FLASH里调代码。
#3# 超级终端中要输入字符串给目标板的时候,要把流量控制关掉。不知道使所有的都这样,还是ATmel的特例。
#4# 即使a++这样的语句在高级语言里,也不是原子操作。对临界区的保护,还是用操作系统的比较好,设标志量的办法,还是会有问题的。CRITICAL_SECTION是不错的选择。
#5# 内存接口真的是很慢的一个东西。就ARM来说吧,本身内存控制跑在慢几倍的外围时钟上,SDRAM的特点还要多个周期才能访问一次。所以片内RAM和片外SDRAM会有5到10倍的减速,忍无可忍。ARM9的cache和MMU好像也不太管用。
#6# 用MATLAB验证,在选择hash表的散列函数时,(index*ran_num)>>n和(index*ran_num)相比,移位之后的随机性更好,并且对ran_num的依赖度也变小了。不信可以试一试。
 
电梯项目的:
#7# ADS和仿真器在一起对程序设置断点是不可靠的,当有强干扰的时候,断点会不起作用。
#8# 数字示波器显示的东西不一定是真的。因为有采样率的关系,所以显示得很可能是包络,或者根本就是错的。如果出现很矛盾显示结果,改变采样率或者改用老的模拟示波器,会发现也许数字示波器错了。
 
其他的:
#9# 突然发现china-pub里面,北工大也成了高校用户了。上回买书白花了5元送书费。
Advertisements

多线程编程

    最近在搞多线程的东东。一个程序,5个线程。其中两个是驱动,一个监视线程,一个是我自己的调度机,一个GUI线程。
    CANopen的项目眼看有些眉目了,却被这个多线程的东东搞得焦头烂额。程序运行1分钟还是好的,几分钟之后会出现没有规律的,随机的,并且莫名其妙的空指针退出情况。如果在程序管理器上看,开始的时候还只需要25.7M的内存,运行一会CPU占用率就能到97%,内存占用100M以上。在双CPU的系统上能跑出如此性能,看来Bug不是一星半点。
    奋斗了三天,终于把内存稳定在了25.7M上,即清除了内存泄露。然而,程序仍然莫名其妙的死。而且往往在临届区内死。明明我做了保护,可仍然不起作用。好像这种问题超出了我的解决范围,不过仍然在冥思苦想中。
    从此可见,对称多处理肯定会是一个充满挑战的领域。在一个CPU上的多线程已经如此难搞,更何况在多个CPU上的并行处理。希望能有机会搞一搞。