| ??? 04/29/09 23:38 Modified: 04/29/09 23:39 Read: times |
#164947 - I don't see a place for the 805x Responding to: ???'s previous message |
Jan Waclawek said:
While the reaction of the common 1602 module What's a "1602 module"? Who makes it? What sort of interface does it have? What's the controller IC? to commands is indeed in the tens-of-microseconds-and-slower range, the hardware interface (pulse lengths and mutial timing of the signals) is in the tens-of-nanoseconds range, which almost completely excludes a purely software solution.
I would use a latch or two ('574 + '74), simply latch the data plus the RS and RW at the falling edge of E, and feed the latched RW to an external interrupt set to edge sensitivity, inverted if needed, to have the interrupt triggered upon writes to the LCD. The ISR then would need to reset the RW latch, in case the original device does not perform reads from the LCD. Not a bad idea, this is. I could find quite a lot of uses of it. JW PS. Anybody fancy a common 8052.com project? A CPLD with 32 or 36 macrocells could handle this quite straightforwardly, including generating the appropriate timing at the "remote" end, transmitting the data serially over considerable distance, but this is true IF AND ONLY IF the module in question is HD44780 compatible. Registering those 11 signals and transmitting them over a synchronous link at a significant bit rate is not much of a challenge. It might even be possible to request retransmission if an error is detected. Just envision a '595 equivalent 11 bits long and a simple bit clock generator that works more or less like the Mode 0 805x serial port. Everything is purported to be stabile, as you say, at the falling edge of 'E' and no command will take much less than 40 microseconds. That's plenty of time for transmisison with parity, reception with acknowledge, and retransmission if necessary. An error signal can be provided so one can drive an indicator. I'd guess the CPLD and a crystal, if there's no adequate clock on the boards with which it "talks" would cost less than an MCU and the required registers, flipflops, etc. Most of the current CPLD's are JTAG programmable, hence would require no costly hardware to program them. A parity generator is just a 'T' flipflop clocked with the NRZ data. That thing could "talk" directly to the data lines, and the CPLD can talk directly to the display. The comm-channel could be no more than RS423 driver/receiver emulation in the CPLD. What do you think? RE |
