I have a CPU board that interfaces to a standard 16x2 chars display,
based on HD44780 controller.
I'd like to replace this display with a full-color big TFT display,
maybe 10", but I can't change the firmware of the CPU (because I don't
have the source code and I can't rewrite it, because of cost and time).
The simple idea is to create an interface between the current CPU board
and the TFT display. This interface should be able to detect the signals
from the CPU and that was directed to HD44780, interpret the
instructions (write CGRAM/DDRAM and so on) and write the same things to
the big TFT display.
Of course, exactly the same texts will be written on TFT display (of
course with a bigger and visible font) and this is acceptable.
So the MCU on the interface should be able to read 8 data bits, RS and
R/W signals syncronous to signal E.
I'm thinking to configure E signal as an external interrupt on the
falling edge. In the interrupt, I read data bits, R/W and RS and decode
the instruction or data.
Any suggestions? Maybe a similar code is already online.
On Tue, 21 Sep 2021 12:31:54 +0200, pozz wrote:
I have a CPU board that interfaces to a standard 16x2 chars display,
based on HD44780 controller.
I'd like to replace this display with a full-color big TFT display,
maybe 10", but I can't change the firmware of the CPU (because I don't
have the source code and I can't rewrite it, because of cost and time).
The simple idea is to create an interface between the current CPU board
and the TFT display. This interface should be able to detect the signals
from the CPU and that was directed to HD44780, interpret the
instructions (write CGRAM/DDRAM and so on) and write the same things to
the big TFT display.
Of course, exactly the same texts will be written on TFT display (of
course with a bigger and visible font) and this is acceptable.
So the MCU on the interface should be able to read 8 data bits, RS and
R/W signals syncronous to signal E.
I'm thinking to configure E signal as an external interrupt on the
falling edge. In the interrupt, I read data bits, R/W and RS and decode
the instruction or data.
Any suggestions? Maybe a similar code is already online.
I guess you don't need an interrupt. The signals to the 44780 are quite
slow and well sequenced. So simple polling would do.
Beware that the E signal is high when data is valid. So I would look for
the rising edge.
Il 21/09/2021 15:44, Reinhardt Behm ha scritto:
On Tue, 21 Sep 2021 12:31:54 +0200, pozz wrote:
So the MCU on the interface should be able to read 8 data bits, RS and
R/W signals syncronous to signal E.
I'm thinking to configure E signal as an external interrupt on the
falling edge. In the interrupt, I read data bits, R/W and RS and decode
the instruction or data.
Any suggestions? Maybe a similar code is already online.
I guess you don't need an interrupt. The signals to the 44780 are quite
slow and well sequenced. So simple polling would do.
Are you sure? Enable cycle time could be 500ns at 5V, look at page 52 of datasheet[1].
Beware that the E signal is high when data is valid. So I would look for
the rising edge.
Are you sure? Look at Figure 25[1], data are valid at the falling edge
of E signal.
[1] https://www.sparkfun.com/datasheets/LCD/HD44780.pdf
Il 21/09/2021 15:44, Reinhardt Behm ha scritto:
On Tue, 21 Sep 2021 12:31:54 +0200, pozz wrote:
I have a CPU board that interfaces to a standard 16x2 chars display,
based on HD44780 controller.
I'd like to replace this display with a full-color big TFT display,
maybe 10", but I can't change the firmware of the CPU (because I don't
have the source code and I can't rewrite it, because of cost and
time).
The simple idea is to create an interface between the current CPU
board and the TFT display. This interface should be able to detect the
signals from the CPU and that was directed to HD44780, interpret the
instructions (write CGRAM/DDRAM and so on) and write the same things
to the big TFT display.
Of course, exactly the same texts will be written on TFT display (of
course with a bigger and visible font) and this is acceptable.
So the MCU on the interface should be able to read 8 data bits, RS and
R/W signals syncronous to signal E.
I'm thinking to configure E signal as an external interrupt on the
falling edge. In the interrupt, I read data bits, R/W and RS and
decode the instruction or data.
Any suggestions? Maybe a similar code is already online.
I guess you don't need an interrupt. The signals to the 44780 are quite
slow and well sequenced. So simple polling would do.
Are you sure? Enable cycle time could be 500ns at 5V, look at page 52 of datasheet[1].
Beware that the E signal is high when data is valid. So I would look
for the rising edge.
Are you sure? Look at Figure 25[1], data are valid at the falling edge
of E signal.
On 2021-09-21 pozz wrote in comp.arch.embedded:
Il 21/09/2021 15:44, Reinhardt Behm ha scritto:
On Tue, 21 Sep 2021 12:31:54 +0200, pozz wrote:
So the MCU on the interface should be able to read 8 data bits, RS and >>>> R/W signals syncronous to signal E.
I'm thinking to configure E signal as an external interrupt on the
falling edge. In the interrupt, I read data bits, R/W and RS and decode >>>> the instruction or data.
Any suggestions? Maybe a similar code is already online.
I guess you don't need an interrupt. The signals to the 44780 are quite
slow and well sequenced. So simple polling would do.
Are you sure? Enable cycle time could be 500ns at 5V, look at page 52 of
datasheet[1].
Datasheet indeed says 500ns minimum. It ofcourse depends on the mcu what
the actual timing is. 500ns is 'slow' for todays controllers, so I think
you could do polling as long as you don't do too much else (depending on
the speed of your mcu). But an interrupt may be a safer choice and makes other processing (outside irq) easier. But even with using an interrupt
you have to make sure latency is small enough, especially if there are
other interrupts.
Beware that the E signal is high when data is valid. So I would look for >>> the rising edge.
Are you sure? Look at Figure 25[1], data are valid at the falling edge
of E signal.
[1] https://www.sparkfun.com/datasheets/LCD/HD44780.pdf
Both is true: data is valid when E is high,
but with a small delay (Tddr
and Tdhr), so data is still valid on the falling edge.
But you must be
very fast in your response, minimum Tdhr is only 5 ns. This would
require an awfully fast interrupt response.
Setting an interrupt on the
rising edge gives you another challenge: Tddr is 160ns max, so you may
not actually read the data within 160ns of the rising edge of E. If you
have a fast interrupt response, you may need to wait a little before
reading.
Maybe an FPGA solution is easier for this problem. ;-)
have you already thought about the other end of the interface? How do
you plan to get data to the TFT panel? And don't forget about the part
in between, the frame buffer etc.
I have a CPU board that interfaces to a standard 16x2 chars display, based on HD44780 controller.
I'd like to replace this display with a full-color big TFT display, maybe 10",
but I can't change the firmware of the CPU (because I don't have the source code and I can't rewrite it, because of cost and time).
The simple idea is to create an interface between the current CPU board and the
TFT display. This interface should be able to detect the signals from the CPU and that was directed to HD44780, interpret the instructions (write CGRAM/DDRAM
and so on) and write the same things to the big TFT display.
Of course, exactly the same texts will be written on TFT display (of course with a bigger and visible font) and this is acceptable.
So the MCU on the interface should be able to read 8 data bits, RS and R/W signals syncronous to signal E.
I'm thinking to configure E signal as an external interrupt on the falling edge. In the interrupt, I read data bits, R/W and RS and decode the instruction
or data.
Any suggestions? Maybe a similar code is already online.
You will likely find there are issues that you've not even considered
that the original software relies on (directly or indirectly).
Don Y <blockedofcourse@foo.invalid> wrote:
>You will likely find there are issues that you've not even considered
>that the original software relies on (directly or indirectly).
Of course, but in these day much is possible.
https://hackaday.com/2021/09/02/pi-pico-emulates-rom-for-speedy-retro-hacking/
But it feels strange to do this. :-)
On 9/21/2021 3:31 AM, pozz wrote:
I have a CPU board that interfaces to a standard 16x2 chars display,
based on HD44780 controller.
I'd like to replace this display with a full-color big TFT display,
maybe 10", but I can't change the firmware of the CPU (because I don't
have the source code and I can't rewrite it, because of cost and time).
The simple idea is to create an interface between the current CPU
board and the TFT display. This interface should be able to detect the
signals from the CPU and that was directed to HD44780, interpret the
instructions (write CGRAM/DDRAM and so on) and write the same things
to the big TFT display.
Of course, exactly the same texts will be written on TFT display (of
course with a bigger and visible font) and this is acceptable.
So the MCU on the interface should be able to read 8 data bits, RS and
R/W signals syncronous to signal E.
I'm thinking to configure E signal as an external interrupt on the
falling edge. In the interrupt, I read data bits, R/W and RS and
decode the instruction or data.
Any suggestions? Maybe a similar code is already online.
You will likely find there are issues that you've not even considered
that the original software relies on (directly or indirectly).
Can your emulation handle a *steady* stream of reads/writes? Or,
are you expecting the host to be gentle with the display interface?
Keep in mind, that you have to run a fair bit of code to paint
pels onto the display from "character codes".
Does the host rely on the timing of the display's "busy" indication
in any way?
Are there any bug in the display controller that
the host code works around -- that you'd have to emulate (but
aren't disclosed in the datasheet because they *are* bugs)?
Are the visual characteristics of your display similar to those
of the original display? Cursor/character blink and other
attributes?
Put a pair of back-to-back latches on the data bus and some
steering logic and don't sweat the fine-grained timing issues.
Il 22/09/2021 04:34, Don Y ha scritto:
On 9/21/2021 3:31 AM, pozz wrote:
You will likely find there are issues that you've not even considered
that the original software relies on (directly or indirectly).
Yes, it could be possible.
Can your emulation handle a *steady* stream of reads/writes? Or,
are you expecting the host to be gentle with the display interface?
The host is a 16-bits MCU from Fujitsu. I will measure timings by an oscilloscope, but I don't think it writes so fast.
And I can implement a busy flag trick: after any instruction, I can simulate a
busy state... if the host really use busy flag check (I suspect yes, because I
saw R/W signal goes high and low often).
Keep in mind, that you have to run a fair bit of code to paint
pels onto the display from "character codes".
I will send sniffed character codes by a serial line to a "smart TFT".
Does the host rely on the timing of the display's "busy" indication
in any way?
Most probably the host polls for busy flag and I think I can replicate this.
Are there any bug in the display controller that
the host code works around -- that you'd have to emulate (but
aren't disclosed in the datasheet because they *are* bugs)?
I wrote some code for HD44780 in the past and I don't remember of any workaround. Of course it depends on how many features of controller the host uses.
Are the visual characteristics of your display similar to those
of the original display? Cursor/character blink and other
attributes?
If I can sniff these things, I think I can replicate on the TFT.
Put a pair of back-to-back latches on the data bus and some
steering logic and don't sweat the fine-grained timing issues.
Yes, it could be done in this way.
And I was thinking to leave the original display connected and put the interface as a passive sniffer. In this way I don't need to replicate the exact
behaviour of the controller, but only detect the stream of data and commands. Of course, in this case I have to be fast enough as the controller (I can't stop communication by busy flag).
Il 22/09/2021 04:34, Don Y ha scritto:
On 9/21/2021 3:31 AM, pozz wrote:
I have a CPU board that interfaces to a standard 16x2 chars display,
based on HD44780 controller.
I'd like to replace this display with a full-color big TFT display,
maybe 10", but I can't change the firmware of the CPU (because I don't
have the source code and I can't rewrite it, because of cost and time). >>
The simple idea is to create an interface between the current CPU
board and the TFT display. This interface should be able to detect the
signals from the CPU and that was directed to HD44780, interpret the
instructions (write CGRAM/DDRAM and so on) and write the same things
to the big TFT display.
Of course, exactly the same texts will be written on TFT display (of
course with a bigger and visible font) and this is acceptable.
So the MCU on the interface should be able to read 8 data bits, RS and
R/W signals syncronous to signal E.
I'm thinking to configure E signal as an external interrupt on the
falling edge. In the interrupt, I read data bits, R/W and RS and
decode the instruction or data.
Any suggestions? Maybe a similar code is already online.
You will likely find there are issues that you've not even consideredYes, it could be possible.
that the original software relies on (directly or indirectly).
Can your emulation handle a *steady* stream of reads/writes? Or,The host is a 16-bits MCU from Fujitsu. I will measure timings by an oscilloscope, but I don't think it writes so fast.
are you expecting the host to be gentle with the display interface?
And I can implement a busy flag trick: after any instruction, I can
simulate a busy state... if the host really use busy flag check (I
suspect yes, because I saw R/W signal goes high and low often).
Keep in mind, that you have to run a fair bit of code to paintI will send sniffed character codes by a serial line to a "smart TFT".
pels onto the display from "character codes".
Does the host rely on the timing of the display's "busy" indicationMost probably the host polls for busy flag and I think I can replicate this.
in any way?
Are there any bug in the display controller thatI wrote some code for HD44780 in the past and I don't remember of any workaround. Of course it depends on how many features of controller the
the host code works around -- that you'd have to emulate (but
aren't disclosed in the datasheet because they *are* bugs)?
host uses.
Are the visual characteristics of your display similar to thoseIf I can sniff these things, I think I can replicate on the TFT.
of the original display? Cursor/character blink and other
attributes?
Put a pair of back-to-back latches on the data bus and someYes, it could be done in this way.
steering logic and don't sweat the fine-grained timing issues.
And I was thinking to leave the original display connected and put the interface as a passive sniffer. In this way I don't need to replicate
the exact behaviour of the controller, but only detect the stream of
data and commands. Of course, in this case I have to be fast enough as
the controller (I can't stop communication by busy flag).
On 9/21/2021 3:31 AM, pozz wrote:
I have a CPU board that interfaces to a standard 16x2 chars display, based on
HD44780 controller.
I'd like to replace this display with a full-color big TFT display, maybe 10",
but I can't change the firmware of the CPU (because I don't have the source
code and I can't rewrite it, because of cost and time).
The simple idea is to create an interface between the current CPU board and the
TFT display. This interface should be able to detect the signals from the CPU
and that was directed to HD44780, interpret the instructions (write CGRAM/DDRAM
and so on) and write the same things to the big TFT display.
Of course, exactly the same texts will be written on TFT display (of course
with a bigger and visible font) and this is acceptable.
So the MCU on the interface should be able to read 8 data bits, RS and R/W signals syncronous to signal E.
I'm thinking to configure E signal as an external interrupt on the falling edge. In the interrupt, I read data bits, R/W and RS and decode the instruction
or data.
Any suggestions? Maybe a similar code is already online.You will likely find there are issues that you've not even considered
that the original software relies on (directly or indirectly).
Can your emulation handle a *steady* stream of reads/writes? Or,
are you expecting the host to be gentle with the display interface?
Keep in mind, that you have to run a fair bit of code to paint
pels onto the display from "character codes".
Does the host rely on the timing of the display's "busy" indication
in any way? Are there any bug in the display controller that
the host code works around -- that you'd have to emulate (but
aren't disclosed in the datasheet because they *are* bugs)?
Are the visual characteristics of your display similar to those
of the original display? Cursor/character blink and other
attributes?
Put a pair of back-to-back latches on the data bus and some
steering logic and don't sweat the fine-grained timing issues.
The simple idea is to create an interface between the current CPU board[...]
and the TFT display. This interface should be able to detect the signals
from the CPU and that was directed to HD44780, interpret the
instructions (write CGRAM/DDRAM and so on) and write the same things to
the big TFT display.
Any suggestions? Maybe a similar code is already online.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 491 |
Nodes: | 16 (2 / 14) |
Uptime: | 127:14:06 |
Calls: | 9,688 |
Calls today: | 4 |
Files: | 13,728 |
Messages: | 6,177,248 |