这个DS18B20程序哪里有问题

hysy

jimmy_xt 发表于 2013-6-1 10:04
18b20读取太慢。

我在Mega32+VFD时钟上用过，对VFD刷新有严重影响，实在是解决不了。

读取18B20会耽误刷屏？那你的程序是流水程序了，呵呵。不够科学啊!一般这样的思维方式都是学校老师教的。害了一袋又一袋人啊！我们可敬又可恨的叫兽先生。

benli

jimmy_xt 发表于 2013-6-1 14:17  我严格按器件手册上时许写的读取函数，单纯的读取，需要2ms。  LZ这个需要2.8ms因为前面还有发送转换指令。 ...

延时函数并不精确，加上单片机执行指令的时间，时间时间要长的多，

jimmy_xt

hysy 发表于 2013-6-1 15:36
读取18B20会耽误刷屏？那你的程序是流水程序了，呵呵。不够科学啊!一般这样的思维方式都是学校老师 ...

您方便给个合理些的架构么。

目前程序结构如下：

调度器：就是一个swich语句。系统主要任务是VFD扫描，约占用80%的CPU时间，剩余空闲时间由调度器调度。

主任务：VFD扫描程序io_vfd_scan()，是可重入函数。但是，中断会造成亮度的改变。为了保证显示效果，也必须保证其原子性。每5ms调用一次，耗时略多于4ms。


其他任务：（仅表示主要任务）
1、18b20读取，原子操作，否则有出错概率。耗时2ms。
2、18b20转换命令，原子操作。理由同上，耗时1ms。

（下面均为可重入任务，随便调度即可）
3、湿度（AD转换）、时间（RTC读取），转字符串，取字模，放进显示缓冲区。
4、usart发送亮度湿度时间数据、随时响应usart发来的指令（可以作为串口屏用）
5、VFD亮度调节（AD读亮度信息），中断方式调节亮度（中断处理时间低于1us）
6、杂项，键盘扫描等等……

主任务造成CPU整段的空闲时间低于1ms。现在要完成2ms的18b20读取任务。不知有何合理方案。

jimmy_xt

benli 发表于 2013-6-1 15:48
延时函数并不精确，加上单片机执行指令的时间，时间时间要长的多，

延时不准的话，你很难读出18b20.
1-wire总线对时序要求非常严格。

我用的延时函数很准，早就用端口反转的方式实验过了，最多也就10%的误差。

benli

jimmy_xt 发表于 2013-6-1 16:42  延时不准的话，你很难读出18b20.  1-wire总线对时序要求非常严格。  

要求并不太高的，例如，某处延时要求15~60us的范围

hysy

ucos RTos的18b20搞成的人还是很多的，你主程序都没操作系统概念看它意义不大了。个人感觉你的显示驱动不应该占独立时间。操作系统调度跟你的switch调度两个概念...
http://www.embedream.com/bjzm/2009-05-16/81.html
随便从网上找的一个帖子，不过方法硬是用软件描述硬件功能，感到有点压抑。

lyxing

感觉ds18b20对时间的占用主要在温度转换上，9位  93.75 ms、12位 750 ms，读取时间就少很多，一般读取流程是先执行温度转换再等待结果，必然占用很长时间，如对温度要求不高，可以牺牲温度精度来减少时间；如对温度的实时性不强，还有更省时间的办法，即先读取温度：再发温度转换指令（即本次读上次的温度，下次读本次的温度），相当于温度转换不占用时间，程序继续向下运行，这个以前实验过，效果明显。
还可以提高晶振频率，对整个程序提速。

benli

lyxing 发表于 2013-6-1 22:51
感觉ds18b20对时间的占用主要在温度转换上，9位  93.75 ms、12位 750 ms，读取时间就少很多，一般读取流程 ...

读取费时也不少

lyxing

benli 发表于 2013-6-1 22:53
读取费时也不少

那就大换血试试，24MHZ 6T 驱动32*64还真有点吃力，当初驱动16*64搞不定，只好把硬件换成24mhz  1T  stc60s2.