大家以后用Proteus仿真LCD1602时,要注意啊,血的教训
用Proteus仿真LCD1602时,一定不要在程序中检测“忙”信号,否则会进入死循环,不显示,实际使用时再加上 哈哈,什么叫仿真?就是像真的一样,但是毕竟不是真的:)
用过两次仿真后,就不用仿真了,直接搭电路,真刀真枪,行就行不行就不行。 留个位... 没办法,有BUG 仿真好了,但我的TS1620-1还是没显示,不知道和1602相同吗 从不用仿真,不是信不过,只是最后的程序还是要在真实环境上运行的,何不一开始就真刀真枪的上呢。
常常听见有人说:我仿真是没问题的呀,然后就N个人争执不下.... 没有硬件条件下才软件仿真,有条件为什么要仿真啊,而不是真实啊!!! 定量硬件实验! 定量硬件实验! 有条件当然用真实的。但是,如果是学生呢?大家有钱,有条件,但是这个世界上有很多应届本科生都不怎么有钱,不怎么有条件啊!现在都要求动手能力,如果没钱买硬件,又不去用软件仿真,那还哪来动手能力!
我觉得,可以用仿真软件入门。想提高就不行了! Proteus这玩意对于实际开发产品来说是害人的,对于学生来说学习用用还是可以的。
手边有硬件就绝不用Proteus! 我看不惯Proteus已经很久了,没有器件时玩玩还可以。
QQ:185932251
电子攻城师群:64485187
学习电子技术,共同提升水平,交流工作经验及工作机会! 我想还有很多的BUG 那个花了我2天的时间 一直没找到毛病 Proteus还是不错,本人在工地,没实验条件,就用这个软件学点东西。
AD,按键部份模拟比较差,响应速度慢 我做过两次仿真,等真做在电路时,都不行.像上面说的一样,真枪真刀 为什么我的通过了啊?我用的lm016和mega16 仿真适合对硬件依赖不高的场合,主要是对算法之类的有个把握,适合做算法密度较高的快速验证,如果是以硬件为主体的设备,那么一定要用硬件测试,没条件创造条件也要用硬件测试。 回复【楼主位】qkj1575 齐开军
-----------------------------------------------------------------------
我也是这个问题,调了一晚上,在硬件上可以有,就是在Proteus上通不过;
发现在模拟的时候,它一直在测试BUSY;
后来,在测试BUSY时,先把DatePort设为低电平就可以了。 感谢啊 我的问题也解决了! 使用工具,但是不能依赖工具。
使用工具也是有技巧的,不然抓着刀刃瞎舞,无非自伤。 仿真只是参考而已,当不得真! 仿真忙检测是没问题的,一个要注意忙检测的写法,一个是双击1602,会看到有一个频率,把那个频率调大一些就可以了,兆级 用仿真失败,该! 痛恨proteus的都是卖开发板的,有了proteus他们生意差了很多,{:titter:}, 用Proteus仿真LCD1602时,一定不要在程序中检测“忙”信号,否则会进入死循环,不显示,实际使用时再加上
you are so wrong that's not funny.
上一个通过的static void LCD_Dat( const unsigned dat )
{
u8 i;
u8 cnt=255;
do{
LCD_DATA( 0xff );
RS_LOW();
RW_HIGH();
EN_HIGH();
_nop_();
i = LCD_STATUS();
EN_LOW();
cnt--;
}while( i && cnt );
if ( cnt )
{
RS_HIGH();
RW_LOW();
LCD_DATA( dat );
_nop_();
EN_HIGH();
_nop_();
EN_LOW();
}
}
static void LCD_Cmd( const unsigned cmd )
{
u8 i;
u8 cnt=255;
do{
LCD_DATA( 0xff );
RS_LOW();
RW_HIGH();
EN_HIGH();
_nop_();
i = LCD_STATUS();
EN_LOW();
cnt--;
}while( i && cnt );
if ( cnt )
{
RS_LOW();
RW_LOW();
LCD_DATA( cmd );
_nop_();
EN_HIGH();
_nop_();
EN_LOW();
}
}
我之前也是这个问题,后来发现不是仿真的问题,是仿真软件把信号传输延时都干出来了。
检测忙标志位是,大体上是先读允许,再加载数据端口的电平状态,然而问题就出在这里:
读允许后,p仿出了信号延时,要过一阵子才能在BIT7给出空闲信号。
最后解决办法是,读允许后,等一段时间再检测BIT7。此法仿真实物均通过。
后来想想的确是这样的,哪能刚以读允许,1602就传来信号啊;实物通过那是RP好,真正重要的其实是软件不稳定 我这个已经很多天了 {:sweat:} #include<reg51.h>
#include"delay.h"
#define uchar unsigned char
sbit RS= P2^0;
sbit RW= P2^1;
sbit E = P2^2;
uchar CheckBusy(void)
{
uchar BF;
RS = 0;
RW = 1;
E= 1;
BF = P0;
E= 0;
RW = 0;
return BF;
}
void Command(uchar com)
{
uchar BF;
do
{
BF = CheckBusy();
BF &= 0x80;
}while(BF == 1);
RS = 0;
RW = 0;
E= 1;
P0 = com;
E= 0;
delay(1);
}
void Data(uchar dat)
{
uchar BF;
do
{
BF = CheckBusy();
BF &= 0x80;
}while(BF == 1);
RS = 1;
RW = 0;
E= 1;
P0 = dat;
E=0;
RS =0;
}
void LCD1602_Init(void)
{
Command(0x3c);
Command(0x0c);
Command(0x01);
Command(0x04);
Command(0x80);
}
void Write_LCD1602(uchar Address, uchar *WData)
{
uchar temp = 0;
while(WData != '\0')
{
Command(Address);
Data(WData);
temp++;
Address += 0x01;
}
}Proteus仿真绝无问题 仿真有时和实际有区别{:shutup:} t3486784401 发表于 2012-5-14 16:39 static/image/common/back.gif
我之前也是这个问题,后来发现不是仿真的问题,是仿真软件把信号传输延时都干出来了。
检测忙标志位是,大 ...
任何软件都可能存在BUG。但是大多数人总是把自己的BUG也算在软件的身上。
Proteus中的1602检忙的问题,很多年前我也过不去这道坎。无奈,只好采用延时的办法。
一年之后,事实证明,BUG在自己一方。
忙信号检测要有检测超时
页:
[1]