|
Over the past 20 years, I have completed a large number of 68HC811E2 based designs using the Optrex DMC series LCD displays. Previous design requirements have dictated a clock speed above 1MHz. Because of the timing limitations of the DMC series displays, I have used latches and buffers to interface to the DMC displays. This method has been very effective and reliable but it is extremely software intensive. My current project does not require a high clock speed so I chose to interface the DMC-16207 display directly to the 68HC11 bus (running in expanded multiplex mode). The delay in the address decode is 75nS. The software uses the same "soft reset" sequence as previous projects to initialize the display and uses the same sequence of commands to check BUSY and write to the display. I tested this at a 1MHz clock speed (4MHz crystal), cycle time of 1000nS, gives a DMC E time of 925nS (below their specified 1000nS E time) the display does not function correctly. I don't have a 3.5MHz crystal, so I can't try a slower E clock right now. Has anybody else put a DMC series display directly on the data bus? At what clock speed (or crystal frequency)? Thanks for any feedback. |
|
|
Optrex DMC displays
Started by ●June 26, 2004
Reply by ●June 27, 20042004-06-27
|
--- In , "Calamity Jane" <winnonad@y...> wrote: > Over the past 20 years, I have completed a large number of > 68HC811E2 based designs using the Optrex DMC series LCD displays. ... > Has anybody else put a DMC series display directly on the data > bus? At what clock speed (or crystal frequency)? Although my experience probably won't help you very much, I can state that I have had some initial success using a HD44700- controller-based character LCD module (not Optrex, but same chipset/specs) tied directly to the memory bus on a 'F1 running a 2 MHz E-clock. By 'initial success' I mean that I have been able to init the display and send characters to it in a debug environment (JBug) via the MM command. I have just completed the first debug pass on my (hand-built/wirewrap) hardware and have not even gotten to the point where I've written any code for my project yet. The reason I say that my experience is probably not relevant to your situation is that I am using the programmable chip-selects (CSIO1, to be precise) that the 'F1 offers. One of the features that can be set for the two CSIOx selects is a E-clock stretch (wait state) capability. I did my initial testing using a 3 E-clock stretch factor (the maximum allowed). I have not tried repeating my experiment using a lower clock-stretching factor. Considering your problem, the next time I sit down for another debug session on this project I will try doing a module init and test using fewer (or no) wait states. I presume that you have the module wired to the bus in 8-bit configuration, with the HC11's R/W connected to the module RW input, and your address decoder output connected to the module E input. Is your address decoder configured to generate an active select signal only when (HC11) E-output is active, or does it only 'look at' the address lines? FWIW, I configured the F1's CSIO1 to go active (high) only when E is valid (this is another config option offered by the F1 chip-select generation subsystem). I cannot say which method for generating chip selects (using discrete logic) would be better: If one looks at the address lines only (and ignores E), the address decoder will 'see' the appropriate address sooner, and perhaps generate a longer CS pulse, but it is possible that the contents of the data bus may be changing when a (non-E-conditioned) select pulse goes active since the data bus is guaranteed to be stable only when E is active. You *might* find that adding the E- clock output (active high) to your address decoding logic *may* fix your problem. Of course, conditioning your select signal on the E clock (as well as the desired address line(s)) will add to the prop delay of the decode logic. FWIW, I have always designed address decoding logic for the HC11 such that it respects the E-clock output. |
Reply by ●June 28, 20042004-06-28
|
Forum, I have used the HD4470 chipset LCDs and HC11F1 extensively, as Mark described previously, without problems. I have also driven the LCDs by bit-banging method. If you want to just write to the display and not read back from its registers the bit bang method is quite simple to implement. ----- Original Message ----- From: "Mark Schultz" <> To: <> Sent: Sunday, June 27, 2004 2:49 PM Subject: [m68HC11] Re: Optrex DMC displays > --- In , "Calamity Jane" <winnonad@y...> > wrote: > > Over the past 20 years, I have completed a large number of > > 68HC811E2 based designs using the Optrex DMC series LCD displays. > ... > > Has anybody else put a DMC series display directly on the data > > bus? At what clock speed (or crystal frequency)? > > Although my experience probably won't help you very much, I can > state that I have had some initial success using a HD44700- > controller-based character LCD module (not Optrex, but same > chipset/specs) tied directly to the memory bus on a 'F1 running a 2 > MHz E-clock. By 'initial success' I mean that I have been able to > init the display and send characters to it in a debug environment > (JBug) via the MM command. I have just completed the first debug > pass on my (hand-built/wirewrap) hardware and have not even gotten > to the point where I've written any code for my project yet. |
|
|
Reply by ●June 28, 20042004-06-28
|
Mark wrote "I presume that you have the module wired to the bus in 8-bit configuration, with the HC11's R/W connected to the module RW input, and your address decoder output connected to the module E input. Is your address decoder configured to generate an active select signal only when (HC11) E-output is active, or does it only 'look at' the address lines?" Yes on all counts and the address decode is included in the E signal ("chip select")to the display. There's no way to stretch the E-clock on the HC811E2 (that I know of). The Optrex specs call for a minimum E-time of 1,000nS and I have 75nS of address decode delay so I am 7.5% short. A color burst crystal would give me 1,100nS except that my P&E Debugger doesn't seem to like the slower clock - it gets really weird although the clock looks good on the scope. I suspect it is some kind of async problem that causes the software to have heart palpitations ;-) The Optrex manual doesn't say what chip set they use and I don't feel like tearing the prototype apart right now. Their manual does clearly state an E-time of 1,000nS MINIMUM. PFC wrote "If you want to just write to the display and not read back from its registers the bit bang method is quite simple to implement. "Bit bang"??? I'm almost afraid to ask! But I will anyway :-) What is "bit bang"??? The only thing I ever read from the display is the busy flag. Thanks for your input fellers! Dianne |
|
|
Reply by ●June 29, 20042004-06-29
|
> PFC wrote "If you want to just write to the display and not read
back > from its registers the bit bang method is quite simple to implement. > > "Bit bang"??? I'm almost afraid to ask! But I will anyway :-) What is > "bit bang"??? The only thing I ever read from the display is the busy > flag. > Bit banging is were you force input/output pins to act as control (R/W, CS, address) and data lines. The code determines the timing of the data transfer. Below is an example of bit banging an LCD using a PIC (sorry HC11). char read_lcd_register(char address) { char read_lcd_register_temp; // same as DDRB = 0x00 // make portb (8 bit i/o port) an input SET_TRIS_B(0xff); delay_us(2); // LCD_ADD is an output pin which can be set to 1 or 0 for address line LCD_ADD = address; // LCD_wr is an O/P pin used for W/R control lcd_wr = 1; delay_us(1); // LCD_EN is chip enable of LCD LCD_EN = 1; // the data stored in the LCD at selected address is now present at portb read_lcd_register_temp = portb; LCD_EN = 0; LCD_ADD = lcd_wr = 0; return(read_lcd_register_temp); } void write_lcd_register(char data,char address) { char write_lcd_register_temp; // set portb as output SET_TRIS_B(0x00); delay_us(1); // load data onto portb portb = data; // set address line LCD_ADD = address; // set to write lcd_wr = 0; delay_us(1); lcd_en = 1; delay_us(1); lcd_en = 0; LCD_WR = 1; LCD_ADD = 0; SET_TRIS_B(0xff); } ----- Original Message ----- From: "Calamity Jane" <> To: <> Sent: Tuesday, June 29, 2004 12:30 AM Subject: [m68HC11] Re: Optrex DMC displays > Mark wrote "I presume that you have the module wired to the bus in > 8-bit configuration, with the HC11's R/W connected to the module RW > input, and your address decoder output connected to the module E > input. Is your address decoder configured to generate an active select > signal only when (HC11) E-output is active, or does it only 'look at' > the address lines?" > > Yes on all counts and the address decode is included in the E signal > ("chip select")to the display. > > There's no way to stretch the E-clock on the HC811E2 (that I know of). > The Optrex specs call for a minimum E-time of 1,000nS and I have 75nS > of address decode delay so I am 7.5% short. A color burst crystal > would give me 1,100nS except that my P&E Debugger doesn't seem to like > the slower clock - it gets really weird although the clock looks good > on the scope. I suspect it is some kind of async problem that causes > the software to have heart palpitations ;-) > > The Optrex manual doesn't say what chip set they use and I don't feel > like tearing the prototype apart right now. Their manual does clearly > state an E-time of 1,000nS MINIMUM. > PFC wrote "If you want to just write to the display and not read back > from its registers the bit bang method is quite simple to implement. > > "Bit bang"??? I'm almost afraid to ask! But I will anyway :-) What is > "bit bang"??? The only thing I ever read from the display is the busy > flag. > > Thanks for your input fellers! > > Dianne > Yahoo! Groups Links |
Reply by ●June 29, 20042004-06-29
|
--- In , "Calamity Jane" <winnonad@y...> wrote: > Yes on all counts and the address decode is included in the E > signal ("chip select")to the display. > > There's no way to stretch the E-clock on the HC811E2 (that I know > of). Well, at least not by changing any HC11 control settings. I do have in mind a way that one could stretch a read/write cycle using a bit of external hardware. You would have to replace the crystal with a self-contained oscillator, and use a few flip flops. The module E ('chip select') signal would be used to trigger a circuit that would shut down the clock input to the HC11 for, say, 2 or 4 oscillator cycles. I have not fully thought through all the details of the circuit that would be needed, but I suspect it could be done with a few 74HC74's and maybe a NAND gate or two. However, based on what you said earlier, it sounds like your design is already built and installed, making this solution impractical or at least inconvenient. > The Optrex specs call for a minimum E-time of 1,000nS and I have > 75nS of address decode delay so I am 7.5% short. A color burst > crystal would give me 1,100nS except that my P&E Debugger doesn't > seem to like the slower clock - it gets really weird although the > clock looks good on the scope. I suspect it is some kind of async > problem that causes the software to have heart palpitations ;-) Your assumption is most likely correct. Since the HC11 SCI data transmission rate is directly affected by the clock source (xtal) you use, switching from 4.00 MHz to 3.56 MHz would be enough of a change to de-synchronize the host/target UARTs. I do not know if the latest versions of the P&E tools allow 'fine control' of the baud rate used to communicate with the target. If, for example, your P&E debugger was set to communicate with the target at 4800 BPS when your target is running w/a 4.00 MHz xtal, changing the xtal to 3.56 MHz would require the baud rate of the debugger tool to be changed to 4800 * (3.56/4.00) = 4272 (nominal), or any value within 2.5% on either side of nominal. > The Optrex manual doesn't say what chip set they use and I don't > feel like tearing the prototype apart right now. Their manual does > clearly state an E-time of 1,000nS MINIMUM. This requirement is typical of the ubiquitious Hitachi HD44700 series character mode LCD controllers, which I know for a fact Optrex has used in their character modules in the past. Almost all the character mode LCD modules that I have encountered use this controller, or encapsulated die controllers that are functionally identical to it. > PFC wrote "If you want to just write to the display and not read > back from its registers the bit bang method is quite simple to > implement. > > "Bit bang"??? I'm almost afraid to ask! But I will anyway :-) What > is "bit bang"??? The only thing I ever read from the display is > the busy flag. I saw PFC's reply, and in addition to his suggestion, two other alternatives come to mind. You could memory-map a 8-bit latch, such as a 74HC374/574 with your chip select signal wired to the latch- enable input (might need to be inverted, do not recall offhand what the active edge of the '374 LE input is) and -OE on the latch tied low. You would have to tie the module's RW input low (write mode only) and use a HC11 I/O line to toggle the module's E input. The write procedure to the module would look like this: (in init code): Module E = LOW Write data to latch (e.g. STAA LATCHADDR) Module E = HIGH \ do this with a Module E = LOW / HC11 port output pin Delay fixed time for module processing Repeat above as needed If full read/write capability is needed, you would need additional hardware (a HC374 and HC244, most likely) and two HC11 outputs. I won't go into the details now but will discuss it later if you are interested. The other possibility would be to use a serial-in/parallel-out shift register, such as the 'HC594 or 595, driven (serially) by the HC11 SPI. This approach was discussed (in a generic sense for I/O expansion) quite extensively in this group a few weeks ago. If this approach interests you, take a look at the message history on this group from a few weeks ago and if you still have any questions, feel free to ask. Regrettably, I cannot think of any solution (other than changing your xtal frequency) that will solve your problem that does not require SOME modification of your hardware. One last comment: You mention that your address decoder has a 75 nS propogation delay - this seems kinda slow to me. If, for example, you were using a HC138 as a address decoder, the specs I have for the '138 indicate that maximum prop delay is in the order of 30-35 nS. If you are using a PLD like a 16V8 or 22V10, it should be even faster, as most modern incarnations of such devices have prop delays <= 15nS. What sort of hardware are you using for address decoding? |
|
|
Reply by ●June 29, 20042004-06-29
|
--- In , "Mark Schultz" <n9xmj@y...> wrote: My "normal" method of interfacing to the DMC displays uses 2 latches (one for control lines and one for data writes) and 1 buffer (for data reads). I have standardized software packages for display control using this scheme. Since this project doesn't require high E-clock speed (usually required for high-speed "real world" control of external hardware) I thought I would save some time and money by simplifying the interface and the software. However, this is a 1-off unit and the display problem is now holding up the project, so I am simply going to add a piggyback "interface board" with the 2 latches and a buffer - minimal changes to the application board - and import the existing software. > You mention that your address decoder has a 75 nS > propogation delay - this seems kinda slow to me. I wont give away my "trade secrets" but my approach to small-run, fast turn-around, inexpensive uP systems leads to "cascading" address decoders, which normally isn't a problem. In this case, if the 1,000nS is absolute minimum, it wouldn't work even with a 10nS delay time anyway! |
Reply by ●June 30, 20042004-06-30
|
If you are using the latched 8 bit interface you could use a latched
version of the 74LS245 (bi-directional bus) and a 74LS123. The 123 uses an external RC to provide pulse stretching and will provide the clock stretch required. Another advantage of using the 123 is that there are two configurable outputs. I have used these to provide the clock stretch and the second (set to a much longer time) to turn on the LCD backlight. I triggered the second output on W/R line and had an 'on' delay of approx. 5 seconds. This allowed the backlight to come on when a new set of data was written to it and automatically turn off after 5 seconds if no new data was written, useful for battery powered applications. This project was some time ago so I cant remember all the details. PFC. ----- Original Message ----- From: "Mark Schultz" <> To: <> Sent: Tuesday, June 29, 2004 7:02 PM Subject: [m68HC11] Re: Optrex DMC displays > --- In , "Calamity Jane" <winnonad@y...> > wrote: > > > Yes on all counts and the address decode is included in the E > > signal ("chip select")to the display. > > > > There's no way to stretch the E-clock on the HC811E2 (that I know > > of). > > Well, at least not by changing any HC11 control settings. > > I do have in mind a way that one could stretch a read/write cycle > using a bit of external hardware. You would have to replace the > crystal with a self-contained oscillator, and use a few flip flops. > The module E ('chip select') signal would be used to trigger a > circuit that would shut down the clock input to the HC11 for, say, 2 > or 4 oscillator cycles. I have not fully thought through all the > details of the circuit that would be needed, but I suspect it could > be done with a few 74HC74's and maybe a NAND gate or two. > > However, based on what you said earlier, it sounds like your design > is already built and installed, making this solution impractical or > at least inconvenient. > > > The Optrex specs call for a minimum E-time of 1,000nS and I have > > 75nS of address decode delay so I am 7.5% short. A color burst > > crystal would give me 1,100nS except that my P&E Debugger doesn't > > seem to like the slower clock - it gets really weird although the > > clock looks good on the scope. I suspect it is some kind of async > > problem that causes the software to have heart palpitations ;-) > > Your assumption is most likely correct. Since the HC11 SCI data > transmission rate is directly affected by the clock source (xtal) > you use, switching from 4.00 MHz to 3.56 MHz would be enough of a > change to de-synchronize the host/target UARTs. I do not know if > the latest versions of the P&E tools allow 'fine control' of the > baud rate used to communicate with the target. If, for example, > your P&E debugger was set to communicate with the target at 4800 BPS > when your target is running w/a 4.00 MHz xtal, changing the xtal to > 3.56 MHz would require the baud rate of the debugger tool to be > changed to 4800 * (3.56/4.00) = 4272 (nominal), or any value within > 2.5% on either side of nominal. > > > The Optrex manual doesn't say what chip set they use and I don't > > feel like tearing the prototype apart right now. Their manual does > > clearly state an E-time of 1,000nS MINIMUM. > > This requirement is typical of the ubiquitious Hitachi HD44700 > series character mode LCD controllers, which I know for a fact > Optrex has used in their character modules in the past. Almost all > the character mode LCD modules that I have encountered use this > controller, or encapsulated die controllers that are functionally > identical to it. > > > PFC wrote "If you want to just write to the display and not read > > back from its registers the bit bang method is quite simple to > > implement. > > > > "Bit bang"??? I'm almost afraid to ask! But I will anyway :-) What > > is "bit bang"??? The only thing I ever read from the display is > > the busy flag. > > I saw PFC's reply, and in addition to his suggestion, two other > alternatives come to mind. You could memory-map a 8-bit latch, such > as a 74HC374/574 with your chip select signal wired to the latch- > enable input (might need to be inverted, do not recall offhand what > the active edge of the '374 LE input is) and -OE on the latch tied > low. You would have to tie the module's RW input low (write mode > only) and use a HC11 I/O line to toggle the module's E input. The > write procedure to the module would look like this: > > (in init code): Module E = LOW > > Write data to latch (e.g. STAA LATCHADDR) > Module E = HIGH \ do this with a > Module E = LOW / HC11 port output pin > Delay fixed time for module processing > Repeat above as needed > > If full read/write capability is needed, you would need additional > hardware (a HC374 and HC244, most likely) and two HC11 outputs. I > won't go into the details now but will discuss it later if you are > interested. > > The other possibility would be to use a serial-in/parallel-out shift > register, such as the 'HC594 or 595, driven (serially) by the HC11 > SPI. This approach was discussed (in a generic sense for I/O > expansion) quite extensively in this group a few weeks ago. If this > approach interests you, take a look at the message history on this > group from a few weeks ago and if you still have any questions, feel > free to ask. > > Regrettably, I cannot think of any solution (other than changing > your xtal frequency) that will solve your problem that does not > require SOME modification of your hardware. > > One last comment: You mention that your address decoder has a 75 nS > propogation delay - this seems kinda slow to me. If, for example, > you were using a HC138 as a address decoder, the specs I have for > the '138 indicate that maximum prop delay is in the order of 30-35 > nS. If you are using a PLD like a 16V8 or 22V10, it should be even > faster, as most modern incarnations of such devices have prop delays > <= 15nS. What sort of hardware are you using for address decoding? > > Yahoo! Groups Links > > |
Reply by ●June 30, 20042004-06-30
|
Sorry, in the section "...I triggered the second output on W/R line and
had an 'on' delay of approx. 5 seconds. " is should have stated the CS line not the W/R line. ----- Original Message ----- From: "PFC" <> To: <> Sent: Wednesday, June 30, 2004 5:23 AM Subject: Re: [m68HC11] Re: Optrex DMC displays > If you are using the latched 8 bit interface you could use a latched version > of the 74LS245 (bi-directional bus) and a 74LS123. The 123 uses an external > RC to provide pulse stretching and will provide the clock stretch required. > Another advantage of using the 123 is that there are two configurable > outputs. I have used these to provide the clock stretch and the second (set > to a much longer time) to turn on the LCD backlight. I triggered the second > output on W/R line and had an 'on' delay of approx. 5 seconds. This allowed > the backlight to come on when a new set of data was written to it and > automatically turn off after 5 seconds if no new data was written, useful > for battery powered applications. This project was some time ago so I cant > remember all the details. > > PFC. > > ----- Original Message ----- > From: "Mark Schultz" <> > To: <> > Sent: Tuesday, June 29, 2004 7:02 PM > Subject: [m68HC11] Re: Optrex DMC displays > > --- In , "Calamity Jane" <winnonad@y...> > > wrote: > > > > > Yes on all counts and the address decode is included in the E > > > signal ("chip select")to the display. > > > > > > There's no way to stretch the E-clock on the HC811E2 (that I know > > > of). > > > > Well, at least not by changing any HC11 control settings. > > > > I do have in mind a way that one could stretch a read/write cycle > > using a bit of external hardware. You would have to replace the > > crystal with a self-contained oscillator, and use a few flip flops. > > The module E ('chip select') signal would be used to trigger a > > circuit that would shut down the clock input to the HC11 for, say, 2 > > or 4 oscillator cycles. I have not fully thought through all the > > details of the circuit that would be needed, but I suspect it could > > be done with a few 74HC74's and maybe a NAND gate or two. > > > > However, based on what you said earlier, it sounds like your design > > is already built and installed, making this solution impractical or > > at least inconvenient. > > > > > The Optrex specs call for a minimum E-time of 1,000nS and I have > > > 75nS of address decode delay so I am 7.5% short. A color burst > > > crystal would give me 1,100nS except that my P&E Debugger doesn't > > > seem to like the slower clock - it gets really weird although the > > > clock looks good on the scope. I suspect it is some kind of async > > > problem that causes the software to have heart palpitations ;-) > > > > Your assumption is most likely correct. Since the HC11 SCI data > > transmission rate is directly affected by the clock source (xtal) > > you use, switching from 4.00 MHz to 3.56 MHz would be enough of a > > change to de-synchronize the host/target UARTs. I do not know if > > the latest versions of the P&E tools allow 'fine control' of the > > baud rate used to communicate with the target. If, for example, > > your P&E debugger was set to communicate with the target at 4800 BPS > > when your target is running w/a 4.00 MHz xtal, changing the xtal to > > 3.56 MHz would require the baud rate of the debugger tool to be > > changed to 4800 * (3.56/4.00) = 4272 (nominal), or any value within > > 2.5% on either side of nominal. > > > > > The Optrex manual doesn't say what chip set they use and I don't > > > feel like tearing the prototype apart right now. Their manual does > > > clearly state an E-time of 1,000nS MINIMUM. > > > > This requirement is typical of the ubiquitious Hitachi HD44700 > > series character mode LCD controllers, which I know for a fact > > Optrex has used in their character modules in the past. Almost all > > the character mode LCD modules that I have encountered use this > > controller, or encapsulated die controllers that are functionally > > identical to it. > > > > > PFC wrote "If you want to just write to the display and not read > > > back from its registers the bit bang method is quite simple to > > > implement. > > > > > > "Bit bang"??? I'm almost afraid to ask! But I will anyway :-) What > > > is "bit bang"??? The only thing I ever read from the display is > > > the busy flag. > > > > I saw PFC's reply, and in addition to his suggestion, two other > > alternatives come to mind. You could memory-map a 8-bit latch, such > > as a 74HC374/574 with your chip select signal wired to the latch- > > enable input (might need to be inverted, do not recall offhand what > > the active edge of the '374 LE input is) and -OE on the latch tied > > low. You would have to tie the module's RW input low (write mode > > only) and use a HC11 I/O line to toggle the module's E input. The > > write procedure to the module would look like this: > > > > (in init code): Module E = LOW > > > > Write data to latch (e.g. STAA LATCHADDR) > > Module E = HIGH \ do this with a > > Module E = LOW / HC11 port output pin > > Delay fixed time for module processing > > Repeat above as needed > > > > If full read/write capability is needed, you would need additional > > hardware (a HC374 and HC244, most likely) and two HC11 outputs. I > > won't go into the details now but will discuss it later if you are > > interested. > > > > The other possibility would be to use a serial-in/parallel-out shift > > register, such as the 'HC594 or 595, driven (serially) by the HC11 > > SPI. This approach was discussed (in a generic sense for I/O > > expansion) quite extensively in this group a few weeks ago. If this > > approach interests you, take a look at the message history on this > > group from a few weeks ago and if you still have any questions, feel > > free to ask. > > > > Regrettably, I cannot think of any solution (other than changing > > your xtal frequency) that will solve your problem that does not > > require SOME modification of your hardware. > > > > One last comment: You mention that your address decoder has a 75 nS > > propogation delay - this seems kinda slow to me. If, for example, > > you were using a HC138 as a address decoder, the specs I have for > > the '138 indicate that maximum prop delay is in the order of 30-35 > > nS. If you are using a PLD like a 16V8 or 22V10, it should be even > > faster, as most modern incarnations of such devices have prop delays > > <= 15nS. What sort of hardware are you using for address decoding? > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > Yahoo! Groups Links |
Reply by ●July 2, 20042004-07-02
|
Hi I'm using a DMC 20481 NY-LY-AGE on the bus of a MC68HC11E1 clocked with 2MHz (8MHz quartz). This runs fine, although it's out of spec. I used this for years with this product and had never reported a problem. It's always used at room temperature, so there may be a problem with high/low temperatures. It's an old product, and I probably would not do it the same way again. Edi Im Hof At 15:58 26.06.2004 +0000, you wrote: >Over the past 20 years, I have completed a large number of 68HC811E2 >based designs using the Optrex DMC series LCD displays. > >Previous design requirements have dictated a clock speed above 1MHz. >Because of the timing limitations of the DMC series displays, I have >used latches and buffers to interface to the DMC displays. This method >has been very effective and reliable but it is extremely software >intensive. > >My current project does not require a high clock speed so I chose to >interface the DMC-16207 display directly to the 68HC11 bus (running in >expanded multiplex mode). The delay in the address decode is 75nS. > >The software uses the same "soft reset" sequence as previous projects >to initialize the display and uses the same sequence of commands to >check BUSY and write to the display. > >I tested this at a 1MHz clock speed (4MHz crystal), cycle time of >1000nS, gives a DMC E time of 925nS (below their specified 1000nS E >time) the display does not function correctly. > >I don't have a 3.5MHz crystal, so I can't try a slower E clock right now. > >Has anybody else put a DMC series display directly on the data bus? At >what clock speed (or crystal frequency)? > >Thanks for any feedback. > >Yahoo! Groups Links > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + IH electronic + Phone: ++41 52 320 90 00 + + Edi Im Hof + Fax: ++41 52 320 90 04 + + Doernlerstrasse 1, Sulz + URL: http://www.ihe.ch + + CH-8544 Rickenbach-Attikon + E-Mail: + + Switzerland + + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
