• Convert 16x2 chars display to big TFT display

    From pozz@21:1/5 to All on Tue Sep 21 12:31:54 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Reinhardt Behm@21:1/5 to pozz on Tue Sep 21 13:44:11 2021
    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.


    --
    Reinhardt

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pozz@21:1/5 to All on Tue Sep 21 16:01:42 2021
    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.

    [1] https://www.sparkfun.com/datasheets/LCD/HD44780.pdf

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stef@21:1/5 to All on Tue Sep 21 17:09:48 2021
    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.


    --
    Stef

    Yow! Those people look exactly like Donnie and Marie Osmond!!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Reinhardt Behm@21:1/5 to pozz on Tue Sep 21 15:07:24 2021
    On Tue, 21 Sep 2021 16:01:42 +0200, pozz wrote:

    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].

    An eternity.

    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.

    Data should be valid for the whole E time. Look for the rising edge and
    sample the other signals. Otherwise you rely on the z“unspecified hold
    time of your signal source.

    --
    Reinhardt

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pozz@21:1/5 to All on Tue Sep 21 18:48:32 2021
    Il 21/09/2021 17:09, Stef ha scritto:
    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,

    Immediately before the falling edge data must be valid, but they aren't
    valid immediately after the rising edge. So I don't think the sentence
    "data are valid when E is high" is correct.


    but with a small delay (Tddr
    and Tdhr), so data is still valid on the falling edge.

    So I think it's much more robust to read 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.

    I got the point and indeed is critical. Maybe rising edge is better,
    because most probably MCU set data bits and after make a pulse on E.


    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.

    Consider that the read operation for HD44780 will be a write operation
    for my interface. In other words, when a read operation is send from
    MCU, my interface should write on data bits.

    Howevere your point is valid: my interface should write on data bits
    before Tddr, 160ns maximum, and this could be difficult.

    Anyway read operations aren't usually used on this kind of applications.



    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 will send data to a serial port.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to pozz on Tue Sep 21 19:34:39 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From olaf@21:1/5 to Don Y on Wed Sep 22 06:04:46 2021
    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. :-)


    Olaf

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to olaf on Tue Sep 21 21:38:29 2021
    On 9/21/2021 9:04 PM, olaf wrote:
    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. :-)

    It used to feel strange to only partially decode address spaces for
    devices -- so, a single 8b latch would occupy 128KB of address space.

    <shrug> Times change.

    By comparison, a ROM is highly predictable. You don't, for example,
    expect a read of address X to take longer when it follows a read of
    address A vs. B. Or, when the datum returned is Q vs. R.

    A display controller, OTOH, is a serial machine and the time it
    takes to perform an action is typically related to the amount of
    "effort" that must be expended.

    It's likely that the original code took this into consideration
    (implicitly or explicitly). and, without delving into that code,
    it's hard to decide how you can reasonably expect to emulate it
    without unexpected consequences in the host.

    [E.g., the host may expect to have to wait when it does X.
    But, will expect X to have completed before some particular
    future time. If you fail to do so, there's no easy way
    of knowing what might "misfire".]

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pozz@21:1/5 to All on Wed Sep 22 08:49:46 2021
    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 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).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Don Y@21:1/5 to pozz on Wed Sep 22 00:58:32 2021
    On 9/21/2021 11:49 PM, pozz wrote:
    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.

    But you will only be able to observe the activities that *happen*
    while you are watching. Without access to the sources, you won't know
    if this is representative of every possible set of interactions with
    the display (and, thus, YOUR display).

    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).

    Again, you are assuming that the host software always checks for this
    and honors it. Are you sure the developer didn't "forget" in some
    cases? (in which case, you have to emulate the "forgotten" case)?
    Or, didn't implicitly rely on knowledge of how the (old) display
    device would react in a given situation? (e.g., "I know that if I
    issue an XYZ command, the display controller will finish processing
    it in 1.3 microseconds... and, the time it takes for my code to
    advance to the next display access happens to be 1.8 microseconds
    so no need to check the busy flag")

    I can't know that the code does this. Nor can you -- without
    a look at the source code.

    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.

    See above.

    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.

    Which you won't know without a look through the code...

    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).

    I'm not sure I see what that buys you. It certainly doesn't help
    the cost. And, the sniffed signals *should* be identical to your
    emulation of them. What will you do if there is a discrepancy,
    at run time, 3 months from now? Light a big "error" indicator?

    If I was tackling something like this, I'd try to build a model of
    the controller's internal state in the "emulator". Then, design
    a hardware interface that handled the fine-grained timing issues
    (to decouple the emulator as much as possible). Then, see how
    fast I could get the interface between that hardware and the
    *model* to run.

    Then, in the background, run a task that examines the state of
    the model and "paints" the new display, accordingly. Hopefully,
    the slippage won't cost you any features or result in display
    artifacts that aren't already part of the original design
    (e.g., updating the contents of the display asynchronously
    wrt it's being painted into the hardware)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rick C@21:1/5 to pozz on Fri Oct 1 21:52:16 2021
    On Wednesday, September 22, 2021 at 2:49:47 AM UTC-4, pozz wrote:
    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 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).

    The timing of the HD44780U and the various emulations is specified assuming a given internal clock speed set by an RC. If you look at the timing details of the instructions as the clock speed varies you can get timings that can let software work without
    reading the READY flag. The data sheet timings are based on the ideal timing of the internal clock and are not accurate for production variations as well as temperature and voltage. But since there is never any harm in the controller working faster
    than the given timings, you don't really need to worry with this as long as your MCU runs faster than the HD44780U with a 270 kHz clock. I can't think of a reason why your emulator device would not work much faster than the HD44780U.

    --

    Rick C.

    + Get 1,000 miles of free Supercharging
    + Tesla referral code - https://ts.la/richard11209

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rick C@21:1/5 to Don Y on Fri Oct 1 21:40:32 2021
    On Tuesday, September 21, 2021 at 10:34:52 PM UTC-4, Don Y wrote:
    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.

    No need for adding hardware. Read the data lines and the enable signal (and R/W, RS if you want) in a single read operation. Save the previous value in a memory location and watch the new value for E to drop from 1 to 0. Then read the previous sample
    where E was high. If your reads are fast enough it will contain valid write data. The tDSW is only 80 ns with 5V power, so the interface reads will need to be faster than 12.5 MHz to assure valid data. With a 3.3V unit the timing is 195 ns, so a bit
    faster than 5 MHz will do the job. If you are emulating a 4 bit data bus the entire set of signals fits in a single byte port.

    Otherwise a rather simple FPGA can do the job. If you want to emulate the full set of features of the HD44780 it might take a bit of work since it does some fancy cursor operations and has an internal buffer for user defined characters.

    The HD44780 has a few bugs that require software work arounds in the drivers. The big one is the reset issue that requires an arcane sequence to initialize the device. This does not need to be emulated since the work around sequence will work even if
    the chip doesn't have the bug. The operation of the cursor and character writing is a bit clumsy, but should not be hard to emulate. I don't recall any timing you will be obligated to emulate other than meeting the bus speeds which is obvious. The
    various delays in the chip are handled in the interface software either by reading a flag or simply by waiting some minimum time. If your emulation runs faster it won't matter. I'm pretty sure there is no "too fast", but it's been a year or so since I
    worked with it and don't recall every detail.

    --

    Rick C.

    - Get 1,000 miles of free Supercharging
    - Tesla referral code - https://ts.la/richard11209

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Schwingen@21:1/5 to pozz on Sun Oct 31 14:42:44 2021
    On 2021-09-21, pozz <pozzugno@gmail.com> wrote:
    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.

    It's not HD44780, but

    https://github.com/bigtreetech/BIGTREETECH-TFT35-V3.0

    does exactly that for a 12864 LCD (which has a parallel interface with
    similar timing requirements). Look for "Marlin Mode" in the source code.

    cu
    Michael

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)