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
|