80C188 expertice needed
Sauli Porttila
We have a LCD display connected to a 80C188. One peripheral chip select and
address lines A0 and A1 are used to access the display registers. The
problem with this design is that A0 and A1 do not meet the setup time
required by the display. I wonder if this could be fixed in firmware. Is
it possible to write code so (in assembly) that the two lowest address bits
output by the processor do not change when the LCD is accessed? I mean that
the previous bus cycle would use the same address bits.
Regards,
Sauli Porttila
Paul Mudditt
Sauli Porttila <sauli.p...@thermobio.com> wrote in message
news:Rhsm5.99$Z62....@read2.inet.fi...
We thought about this for a short time about ten years ago when we
interfaced 80188 to the HD44780 lcd controller - and then gave up and used
additional latches as port lines and toggled the control and address lines
in software - sorry
paul
Kenneth Porter
<Rhsm5.99$Z62....@read2.inet.fi>:
>We have a LCD display connected to a 80C188. One peripheral chip select
>and address lines A0 and A1 are used to access the display registers.
>The problem with this design is that A0 and A1 do not meet the setup
>time required by the display. I wonder if this could be fixed in
>firmware. Is it possible to write code so (in assembly) that the two
>lowest address bits output by the processor do not change when the LCD
>is accessed? I mean that the previous bus cycle would use the same
>address bits.
Wouldn't it be easier to add a wait state with the PCS control logic? How
much setup time do you need, and what speed are you running the CPU at?
Richard Erlacher
COuld you shed light on the nature of the display controller?
If your setup isn't met, you could easily detect the I/O address range
dedicated for the device and, since you've surely exhausted the
built-in wait-state generation logic, you could switch the processor
speed in the cycles in which you're having the setup-time shortfall
and pipeline them through a couple of flipflops clocked with the
oscillator. That will surely satisfy your setup and hold
requirements.
Dick
On Wed, 16 Aug 2000 08:29:37 GMT, "Sauli Porttila"
<sauli.p...@thermobio.com> wrote:
>Hi there,
>
>We have a LCD display connected to a 80C188. One peripheral chip select and
>address lines A0 and A1 are used to access the display registers. The
>problem with this design is that A0 and A1 do not meet the setup time
>required by the display. I wonder if this could be fixed in firmware. Is
>it possible to write code so (in assembly) that the two lowest address bits
>output by the processor do not change when the LCD is accessed? I mean that
>the previous bus cycle would use the same address bits.
>
>Regards,
>Sauli Porttila
>
>
>
Kenneth Porter
>The display controller requires that the RS and R/W_ (A0 and A1 of 188)
>signals are set up 50ns before activating the Enable (PCS of 188). The
>188 changes the address lines at the same time or even after it asserts
>PCS1. Adding wait states won't help.
/PCS (and all other memory selects) should be considered to be address
lines: They have the same timing characteristics. Use /RD or /WR to qualify
them. For example, generate your Enable signal as the AND of PCS and RD or
WR. A PAL or small FPGA could be used to get the signal relationships
correct.
I draw timing diagrams to show all the desired signal relationships, then
use shift registers in an FPGA to control which derived signals change
when. Feed some fundamental bus signal into the front of the shift register
and clock it with your system clock. Feed the taps into logic to gate
control signals on and off.
Sauli Porttila
possible to fix it in firmware and save the cost of hardware redesign. I
was hoping to find such a sequence of processor commands that the bus cycle
preceding the access to the HD44780 uses the same A0 and A1 bits as the
HD44780 access. With a processor like 8051 this should be not even
difficult, but since the 188 has a command pipeline, the actions of the Bus
Interface Unit are hard to predict. However, it should be possible if the
magic command sequence is placed to a proper program memory address.
Using the wait states or changing the processor speed won't help, since the
address lines change at the same time with the PCS line. What I need is
that the address lines settle display setup time before the chip select is
activated.
"Kenneth Porter" <sh...@well.com> wrote in message
news:8F93A9CC7s...@207.126.101.100...
Geoff Field
"Sauli Porttila" <sauli.p...@thermobio.com> wrote:
> I know this is a hardware design problem. I just thought that it
might be
> possible to fix it in firmware and save the cost of hardware
redesign. I
> was hoping to find such a sequence of processor commands that the bus
cycle
> preceding the access to the HD44780 uses the same A0 and A1 bits as
the
> HD44780 access. With a processor like 8051 this should be not even
> difficult, but since the 188 has a command pipeline, the actions of
the Bus
> Interface Unit are hard to predict. However, it should be possible
if the
> magic command sequence is placed to a proper program memory address.
Just a thought, but if you're using assembler and not doing any
optimisation, why not repeat the access sequence a few times? No
messing around with wait states and total control.
Alternatively, you could do a read or write to the same address (or an
address with the same A0 & A1 at least) in a way that doesn't touch the
PCS line (if possible). You may have to modify your memory management
(if used) to allow the use of an invalid address for this.
--
Geoff Field of XXXXia
Professional geek, amateur stage-levelling gauge
Sent via Deja.com http://www.deja.com/
Before you buy.
Sauli Porttila
"Geoff Field" <geoff...@my-deja.com> wrote in message
news:8nqfdn$c3a$1...@nnrp1.deja.com...
hate green eggs and spam"@yahoo.com Ken Stacey
and tie to a higher address line.
Now, using the following C code or assembler equivalent to access
it.(Assumes I/O Mapping. For Memory Mapping, simply substitute unsigned
short(16 Bit) Reads & Writes.)
void HD44780Write( unsigned short Address, unsigned char Data)
{
unsigned short DataOut = Data + ((unsigned short)Data)<<8; /* Echo in
upper & lower bytes */
_outpw( Address, DataOut ); /* This will cause 2 back to back
writes, consecutive cycles */
}
/* This will probably not work for reads of Status registers, etc. where the
read clears the data */
/* It will work for RAM like locations */
unsigned char HD44780Read( unsigned short Address)
{
unsigned short DataIn;
DataIn = _inpw( Address ); /* This will cause 2 back to back
Reads, consecutive cycles */
/* The Upper byte is read last on an Intel Processor */
return( (unsigned char)(DataIn>>8) );
}
"Sauli Porttila" <sauli.p...@thermobio.com> wrote in message
news:lo7o5.137$xG....@read2.inet.fi...
> Sounds fine, but the BIU executes code fetches between the accesses...
>
>
>
> "Geoff Field" <geoff...@my-deja.com> wrote in message
> news:8nqfdn$c3a$1...@nnrp1.deja.com...
dwight_...@my-deja.com
"Paul Mudditt" <pmud...@iee.org> wrote:
>
> Sauli Porttila <sauli.p...@thermobio.com> wrote in message
> > Hi there,
> >
> > We have a LCD display connected to a 80C188. One peripheral chip
select
> and
> > address lines A0 and A1 are used to access the display registers.
The
> > problem with this design is that A0 and A1 do not meet the setup
time
> > required by the display. I wonder if this could be fixed in
firmware. Is
> > it possible to write code so (in assembly) that the two lowest
address
> bits
> > output by the processor do not change when the LCD is accessed? I
mean
> that
> > the previous bus cycle would use the same address bits.
> >
> > Regards,
> > Sauli Porttila
> >
> >
> >
>
> interfaced 80188 to the HD44780 lcd controller - and then gave up and
used
> additional latches as port lines and toggled the control and address
lines
> in software - sorry
>
> paul
>
>
Hi
This is the way most people deal with this kind of
issue. I've done this my self.
Dwight
Sauli Porttila
writing display data, the HD44780 either autoincrements or autodecrements
the display data RAM address. Since the data write usually succeeds despite
the timing violation, we end up with doubled characters on the display. The
status read does not clear the status (just busy flag), so I could use a
word read there.
"Ken Stacey" <kenstacey"I hate green eggs and spam"@yahoo.com> wrote in
message news:8ns6u4$b...@news-central.tiac.net...
> Is the HD44780 an 8 bit device. If so, Cut the trace to A0 to the HD44780
> and tie to a higher address line.
> Now, using the following C code or assembler equivalent to access
> it.(Assumes I/O Mapping. For Memory Mapping, simply substitute unsigned
> short(16 Bit) Reads & Writes.)
>
> void HD44780Write( unsigned short Address, unsigned char Data)
> {
> unsigned short DataOut = Data + ((unsigned short)Data)<<8; /* Echo
in
> upper & lower bytes */
> _outpw( Address, DataOut ); /* This will cause 2 back to back
> writes, consecutive cycles */
> }
>
> /* This will probably not work for reads of Status registers, etc. where
the
> read clears the data */
> /* It will work for RAM like locations */
> unsigned char HD44780Read( unsigned short Address)
> {
> unsigned short DataIn;
> DataIn = _inpw( Address ); /* This will cause 2 back to back
> Reads, consecutive cycles */
> /* The Upper byte is read last on an Intel Processor */
> return( (unsigned char)(DataIn>>8) );
> }
>
> "Sauli Porttila" <sauli.p...@thermobio.com> wrote in message
> news:lo7o5.137$xG....@read2.inet.fi...
> > Sounds fine, but the BIU executes code fetches between the accesses...
> >
> >
> >
> > "Geoff Field" <geoff...@my-deja.com> wrote in message
> > news:8nqfdn$c3a$1...@nnrp1.deja.com...
hate green eggs and spam"@yahoo.com Ken Stacey
and tie to a higher address line.
Now, using the following C code or assembler equivalent to access
it.(Assumes I/O Mapping. For Memory Mapping, simply substitute unsigned
short(16 Bit) Reads & Writes.)
void HD44780Write( unsigned short Address, unsigned char Data)
{
unsigned short DataOut = Data + ((unsigned short)Data)<<8; /* Echo in
upper & lower bytes */
_outpw( Address, DataOut ); /* This will cause 2 back to back
writes, consecutive cycles */
}
/* This will probably not work for reads of Status registers, etc. where the
read clears the data */
/* It will work for RAM like locations */
unsigned char HD44780Read( unsigned short Address)
{
unsigned short DataIn;
DataIn = _inpw( Address ); /* This will cause 2 back to back
Reads, consecutive cycles */
/* The Upper byte is read last on an Intel Processor */
return( (unsigned char)(DataIn>>8) );
}
"Sauli Porttila" <sauli.p...@thermobio.com> wrote in message
news:lo7o5.137$xG....@read2.inet.fi...
> Sounds fine, but the BIU executes code fetches between the accesses...
>
>
>
> "Geoff Field" <geoff...@my-deja.com> wrote in message
> news:8nqfdn$c3a$1...@nnrp1.deja.com...
Thierry Leveque
Did you try a latch to acces this peripheral
and not a direct acces ??
Best Regards
Thierry
On Wed, 16 Aug 2000 08:29:37 GMT, "Sauli Porttila"
<sauli.p...@thermobio.com> wrote: