The sub-$1 types aren't fast enough, and the ones fast enough cost too much. This LCD has a minimal 'E' strobe of 200 ns. What happens if his existing MCU can generate that? How do you sample it? How do you keep up with the bus handshake? Even an equally fast MCU can't sample the signals at the same rate.


There's no requirement to provide for displays other than the specific one he's using.

The monitoring of the busy flag is unnecessary at the remote end because he's using the LCD he's using. The logic-only approach ensures the correct signal timing. If the timing at the local system doesn't produce the correct result at the remote system, then something's broken and needs to be repaired/replaced. What you're suggesting implies a protocol be imposed on the comm system. After all, what does the remote MCU, if there is to be one, do if another character arrives before he gets a not-busy condition? I doubt the O/P had that in mind. If your LCD at the remote end is exactly like the one at the local end, the timing should be the same, i.e. meeting the spec's at the local MCU will meet the spec's at the remote LCD. If you consider WHY one needs to monitor the busy flag, it will become apparent why it's not necessary for the slave.

BTW, in well-managed companies, including or providing for features not specifically required in the current system will often get you fired. Though this sort of policy is probably traceable back to when people charged for code by the line, which some still do, it's certainly true that things not included because they're not absolutely necessary can't cause reliability issues.



I had guessed that there was some explanation like that ... nevertheless, it's important to be specific rather than introducing unfamiliar and potentially ambiguous nomenclature.

RE