如何用CPLD模拟1602
本帖最后由 woshigeshuai 于 2015-8-27 21:37 编辑51单片机控制1602显示，我现在想用CPLD模拟1602，接收51的数据
也就是我不接1602了，直接接一个CPLD。最后CPLD将接收的数据再通过其它什么方式
给STM32。
望大家给点意思，对CPLD不熟悉，没什么思路。
这样做的目的是? 直接再用个51得了用中断读锁存信号 blueice1108 发表于 2015-8-27 17:35
这样做的目的是?
把一些设备的显示放大，换彩屏。。。 mkliop 发表于 2015-8-27 17:35
直接再用个51得了用中断读锁存信号
本来51控制1602，是那种MOVX写法，数据在总线上的时间很短
用单片机去抓恐怕不行
如上图，数据存在的时间只有大概0.2us 楼主这标题 cpld模拟1602是不是改改更好？ woshigeshuai 发表于 2015-8-27 21:17
本来51控制1602，是那种MOVX写法，数据在总线上的时间很短
用单片机去抓恐怕不行
感觉还需要一个双口ram或者fifo来缓冲，不然你单片机没时间读走数据。
结果就得上fpga了，cpld容量不够。
最好是fpga仿真一个1602的控制器的芯，自己处理各种控制命令，用内部双口ram当显存，让你的stm32直接从显存的另一个口读出当前显示的点阵数据就行了 楼主是不是可以换个思路。既然在数据被输出时，EN产生了跳变，按照51 6T的MOVX速度，不可能有很快的对外部总线的连续操作。所以应该可以在STM32与51的DB间放置锁存器，来在这段时间内保持数据，同时STM32进中断，这就可以保证时序了。可以考虑用两片74HC573实现，一片实现写操作，一片实现读操作。 比如说stm32进中断需要12+4周期。也就是0.22us(72M)。倘若使用锁存器的话，完全可以保持数据1us。这样stm32就足够读到这部分数据了，并且也足够解析下面的数据了。回应51的读请求，另外用一片锁存器甚至数据总线驱动器就可以咯。如果stm32管脚有多，输入和输出可以用不同的GPIO。没多要注意用好OE线，双向口就怕冲突烧器件。这两个锁存器顺带还完成了电平转换，实现应该算很经济的。 先用示波器看看信号有多快，直接用STM32我觉得是可以的。 ahong2hao 发表于 2015-8-27 23:41
先用示波器看看信号有多快，直接用STM32我觉得是可以的。
人家说了0.2us脉宽，STM32中断裁决速度不够，为了稳定起见，锁存器应该是必须的 redroof 发表于 2015-8-27 21:39
感觉还需要一个双口ram或者fifo来缓冲，不然你单片机没时间读走数据。
结果就得上fpga了，cpld容量不够。 ...
如果是这样不如直接也实现个LCD控制器，STM32也可以不要了，哈哈
xwkm 发表于 2015-8-27 23:51
如果是这样不如直接也实现个LCD控制器，STM32也可以不要了，哈哈
想起来了，1602有忙标志的，如果你的51程序写的正确，做任何事之前都读忙标志，那么一个cpld的资源是够做个硬的标志位寄存器的。实际数据就是个锁存器。只要一写数据，硬的忙标志就置上，然后锁住数据等stm32读。就不怕来不及了 如果51只往1602写不回读, cpld实现并口转spi就行了, 不需要太多资源. redroof 发表于 2015-8-28 07:43
想起来了，1602有忙标志的，如果你的51程序写的正确，做任何事之前都读忙标志，那么一个cpld的资源是够做 ...
CPLD不是很熟悉，用ALTERA公司的芯片，使用图形开发怎么样？
个人比较喜欢图形开发。不过现在好像都是语言。 iskywolf 发表于 2015-8-28 08:20
如果51只往1602写不回读, cpld实现并口转spi就行了, 不需要太多资源.
图形开发CPLD方便吗？ woshigeshuai 发表于 2015-8-28 08:32
CPLD不是很熟悉，用ALTERA公司的芯片，使用图形开发怎么样？
个人比较喜欢图形开发。不过现在好像都是语 ...
图形开发不是正路，小规模可以，大了画图就没法看了。
另，你得先看看那个51程序怎么写的，如果那个程序不是你写的，很可能他要回读，那你cpld不够做 redroof 发表于 2015-8-28 09:38
图形开发不是正路，小规模可以，大了画图就没法看了。
另，你得先看看那个51程序怎么写的，如果那个程序 ...
数据能出现在总线上1us，被STM32捕获是完全够了。用锁存器+驱动器应该就能搞定了。用CPLD也不必要了 画个逻辑图咯：STM32需要一个八位口，连接74573和74245，用两根线分别控制573和245的OE。EN信号接入STM32的中断脚。同时EN接入573的锁存端。
进中断后判断是读还是写的操作，然后STM32操作245/573的OE即可。锁存器抢的时间应该足够了。 xwkm 发表于 2015-8-28 10:15
画个逻辑图咯：STM32需要一个八位口，连接74573和74245，用两根线分别控制573和245的OE。EN信号接入STM32的 ...
非常感谢朋友的热心回答，你说的方法我明白
使用573锁存，然后STM32读573的数据，我现在考虑就是用这种方法
朋友对数字电路这块还是很熟悉的嘛！！ xwkm 发表于 2015-8-28 10:15
画个逻辑图咯：STM32需要一个八位口，连接74573和74245，用两根线分别控制573和245的OE。EN信号接入STM32的 ...
对于回读操作，我表示怀疑。回读不是你用锁存器锁住数据等你慢慢读，而是你见到读信号后必须在低于1微秒内给出数据。
51总线不会等你的，时间到了数据口上的内容就被51收回了，你在任何情况下如果没及时给出数据，就错了。就算你99%情况可以及时响应也不够，必须100% redroof 发表于 2015-8-28 10:48
对于回读操作，我表示怀疑。回读不是你用锁存器锁住数据等你慢慢读，而是你见到读信号后必须在低于1微秒 ...
回读操作不难。1602的操作模式都是命令-读取。所以我完全可以读完指令后，立刻把数据写入缓冲器，然后RD信号的下降沿的时候，缓冲器就可以直接的输出数据了。 本帖最后由 xwkm 于 2015-8-28 11:32 编辑
写段伪代码
ISR:
PAL_INPUT;
573_OE_LOW;
DATA=PAL;
573_OE_HIGH;
PAL_OUTPUT;
if(WR)
{
if(DATA == READ_BUSY)
{
PAL = BUSY_FLAG;
}
else if(DATA && READ_DATA)
{
DISP_PTR = DATA & ~READ_DATA;
PAL = DDRAM;
}
}
也就是说，我大概在0.3us之内能够把数据输出到缓冲器上。然后RD信号控制缓冲器的OE端口，接着51单片机拉低RD，数据就被读出了。按照执行速度来看的话，完全够模拟时序。
接口电路也简单，573+245 xwkm 发表于 2015-8-28 11:20
回读操作不难。1602的操作模式都是命令-读取。所以我完全可以读完指令后，立刻把数据写入缓冲器，然后RD ...
可以读的东西有两种：忙标志+数据指针和读显示数据。你得两个锁存器分别锁住这两种东西。
因为设一下地址指针之后可以连读多次，而且理论上别人可以随便执行别的命令然后再来读（不管什么时候读，反正读到的是地址指针当前位置的数据）。
除非你在执行完任何修改地址指针的指令后，都输出一下当前对应的“显示数据结果”到锁存器，防备着51要读。不然肯定有仿真不全的时候，除非别人不用回读显示数据（估计90%的人是不会回读显示数据的）{:lol:}
更狠的，因为读忙标志+数据指针这个操作可以在任意时候随便执行，你得考虑什么时候更新忙标志，什么时候更新这个“数据指针”。难度不是一般的高。。。
当然相信99%的用户都不会管这个回读的数据指针，一般总是自己内部维护数据指针。所以你想办法维护一个正确的忙标志（其实就是你的一个IO口）靠硬的锁存器基本上就可以过关了。。。。
感觉上，有能力用个小CPLD或者几个锁存器缓冲器什么的，加STM32搭出一个100%正确仿真1602的东西，难度已经不低了。。。
redroof 发表于 2015-8-28 11:55
可以读的东西有两种：忙标志+数据指针和读显示数据。你得两个锁存器分别锁住这两种东西。
因为设一下地址 ...
我的想法就是这样咯。每次EN脉冲访问的时候，都把下次要读出的数据写入缓冲器。只要小心，全仿真不难实现。弄个全局变量指针，指在DDRAM/CGRAM上，EN脉冲来到的时候自动+1，很容易实现了。我的伪代码写的比较简略，不过差不多能明白意思就行:) xwkm 发表于 2015-8-27 23:23
比如说stm32进中断需要12+4周期。也就是0.22us(72M)。倘若使用锁存器的话，完全可以保持数据1us。这样stm32 ...
引脚的边沿时间触发dma，这样不要中断，只要总线仲裁就行。 redroof 发表于 2015-8-28 11:55
可以读的东西有两种：忙标志+数据指针和读显示数据。你得两个锁存器分别锁住这两种东西。
因为设一下地址 ...
12M 51。外部总线周期大概是1us。STM32在1us内最多跑72条指令，足够模拟1602，就是要是51和发疯一样不停读1602，哪就比较糟糕了，如果靠软刷新LCD效果就糟了。72条指令扣掉压栈中断裁决16条。还有56条。把输入的数据写入缓冲或者把输出数据写入缓冲器再设置几个标志位，应该没事。如果51上24M的话，哪可能就得靠BUSY来抢时间了。。。 本帖最后由 xwkm 于 2015-8-28 12:35 编辑
wx85105157 发表于 2015-8-28 12:24
引脚的边沿时间触发dma，这样不要中断，只要总线仲裁就行。
如果是这样的话也许可以省掉锁存器 xwkm 发表于 2015-8-28 12:32
如果是这样的话也许可以省掉锁存器
是可以考虑DMA开个缓冲区放一堆BUSY FLAG。。然后stm32就可以从容处理了 xwkm 发表于 2015-8-28 12:29
12M 51。外部总线周期大概是1us。STM32在1us内最多跑72条指令，足够模拟1602，就是要是51和发疯一样不停 ...
1微秒哪有72条指令，除开进出中断，能剩30条指令就烧高香了。
Flash是要分频的，实际只有24兆。不管它告诉你它有多宽，一次能读多少条指令，运气不好的时候都要3个周期读出1条指令。
从Flash里面读常量的时候经常会遇到这种情况。
CPU的流水线在遇到跳转或者调用的时候也要断流，损失2个周期。
要是两者同时遇到，这一条跳转指令就要花5个时钟了
redroof 发表于 2015-8-28 15:46
1微秒哪有72条指令，除开进出中断，能剩30条指令就烧高香了。
Flash是要分频的，实际只有24兆。不管它告 ...
好吧。最近在用GD32，零等待的。1us真能跑100来条指令…… xwkm 发表于 2015-8-28 17:52
好吧。最近在用GD32，零等待的。1us真能跑100来条指令……
运气好全是顺序执行的简单指令，当然可以跑满全部时钟。
你用个实际有意义的数据处理代码试试看，里面大量的判断跳转，读写内存，读写寄存器，还有读常量，
计算方法是数出这一段的指令数目除以示波器看到的间隔，看它平均每一行指令要几个周期{:lol:}
我相信平均能有1.5周期一条指令就不错了。
redroof 发表于 2015-8-28 17:57
运气好全是顺序执行的简单指令，当然可以跑满全部时钟。
你用个实际有意义的数据处理代码试试看，里面大 ...
看咯。BUSY处理放最前面。应该可以抢不少时间 分析51的功能， 直接换成stm32实现得了。
页:
[1]