Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #30799

Re: Convert 16x2 chars display to big TFT display

Show all headers | View raw

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)

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Convert 16x2 chars display to big TFT display pozz <pozzugno@gmail.com> - 2021-09-21 12:31 +0200
  Re: Convert 16x2 chars display to big TFT display Reinhardt Behm <rbehm@hushmail.com> - 2021-09-21 13:44 +0000
    Re: Convert 16x2 chars display to big TFT display pozz <pozzugno@gmail.com> - 2021-09-21 16:01 +0200
      Re: Convert 16x2 chars display to big TFT display Reinhardt Behm <rbehm@hushmail.com> - 2021-09-21 15:07 +0000
      Re: Convert 16x2 chars display to big TFT display Stef <me@this.is.invalid> - 2021-09-21 17:09 +0200
        Re: Convert 16x2 chars display to big TFT display pozz <pozzugno@gmail.com> - 2021-09-21 18:48 +0200
  Re: Convert 16x2 chars display to big TFT display Don Y <blockedofcourse@foo.invalid> - 2021-09-21 19:34 -0700
    Re: Convert 16x2 chars display to big TFT display olaf <olaf@criseis.ruhr.de> - 2021-09-22 06:04 +0200
      Re: Convert 16x2 chars display to big TFT display Don Y <blockedofcourse@foo.invalid> - 2021-09-21 21:38 -0700
    Re: Convert 16x2 chars display to big TFT display pozz <pozzugno@gmail.com> - 2021-09-22 08:49 +0200
      Re: Convert 16x2 chars display to big TFT display Don Y <blockedofcourse@foo.invalid> - 2021-09-22 00:58 -0700
      Re: Convert 16x2 chars display to big TFT display Rick C <gnuarm.deletethisbit@gmail.com> - 2021-10-01 21:52 -0700
    Re: Convert 16x2 chars display to big TFT display Rick C <gnuarm.deletethisbit@gmail.com> - 2021-10-01 21:40 -0700
  Re: Convert 16x2 chars display to big TFT display Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-10-31 14:42 +0000

csiph-web