Controlling LCD via MCP23017/I2C

Other Hardware Displays
21

Any delays between wire.write() calls are meaningless since no data leaves the microcontroller and goes on the i2c bus until endTransmission() is called. The write() calls simply buffer the data.
It pretty much has to work this way since the library cannot make the assumption that the user code will hand the bytes fast enough to ensure the required i2c bus timing.

The i2c bus is not packet based, it is byte based so the internal speed of the MCP230017 has no effect on how fast bytes will be presented to the output port.
Spend some more time looking at the MCP23017 datasheet for how the MCP part works.
Given an i2c clock speed, you can calculate how fast the bytes will be presented on the output port.

One thing that I would highly encourage is to actually do profiling on the code before you tweak/modify it.
As this will be the only way to know what you currently have. This is important to know since what you have might be "good enough" and it will be the only way to know if the modifications are having any effect.

LCDiSpeed is a good tool for profiling the byte transfer timing.

--- bill

22

Any delays between wire.write() calls are meaningless since no data leaves the microcontroller and goes on the i2c bus until endTransmission() is called. The write() calls simply buffer the data.

That's what I've been saying.

And you didn't answer my question. How will byte vs sequential mode change how data is sent to the mcp23017? I assume you're saying that the i2c bus is slow enough that the 1us delay is unnecessary and the two high/low nibbles can be sent in a single transmission right? If that's not what you are suggesting then what do you have in mind?

23

Kaisha:
That's what I've been saying.

And you didn't answer my question. How will byte vs sequential mode change how data is sent to the mcp23017? I assume you're saying that the i2c bus is slow enough that the 1us delay is unnecessary and the two high/low nibbles can be sent in a single transmission right? If that's not what you are suggesting then what do you have in mind?

I'm am leaving the rest of this for you.
Assumptions are never good. Math can be used to determine what is needed and what works.

There is a big difference in how byte vs sequential mode works.
They are two totally different ways to talk to the MCP chip.

The hd44780 datasheet specifies all required timing.
There is no specified nor required delay between nibbles in the hd44780 spec.

Using the MCP datasheet combined with the i2c bus timing based on the SCK clock speed and the number of bytes being transferred over the bus to control the output port, you have all the information needed to perform calculations for the output port update timing.

--- bill

24

I'm confused, you keep alternating between wanting to talk about how these things work, to pretending you're a 'teacher' and trying to 'coach' me through this.

I have a degree in Mathematics and Computer Science, the math and programming is trivial, I did harder stuff in grade 10. So please stop trying to talk down to me. I've been nice up till now because you do have information that I find useful, but your ego is getting on my nerves.

You're assertion that 'its all in the data sheet' is incorrect (an adage you seem to like repeating). For example I have right in front of me the HD44780U datasheet printed out, and on pg 24 it has execution timings. You know what the execution time for the Clear Function is??? Nothing. Its blank, left out, omitted. Heck, even in your very own code you had a 4-page tirade about the HD44780U documentation, how it has errors, how information is left out, and how you think it should work. If the documentation is so clear and accurate, then why did you write 4 pages to 'clear it up' for yourself? The documentation isn't clear, its poorly written, missing key information, and important numbers/facts are spread throughout in a haphazard manner. Its not 'difficult' its 'poor' documentation. Compare, for example the HD44780U documentation to say, the Vulkan spec. While Vulkan is FAR more complex, its also a far easier read, more complete, and more accurate. So the issue is not a matter of complexity, but of quality.

The fact that I am unsure about the wording of a poorly worded document does not mean I am a poor mathematician or coder, and your constant insinuations otherwise are really starting to grate on my nerves.

For example:

There is no specified nor required delay between nibbles in the hd44780 spec.

You are right, there is no specification, no mention anywhere at all in fact. Does that mean I can send it as fast as I can, or is it yet another piece of information omitted? Certainly there is some physical upper limit, so the only thing I can go on (knowing there is a limit but unsure as to what it is) is what others have done. Which is why I asked these questions, of course only to get patronizing answers like 'its all in the datasheet'. And really, why must I go out of my way to stroke some guys ego simply to get the answer "we don't know, the i2c bus is too slow for it to matter"?

There is a big difference in how byte vs sequential mode works.

No there isn't. In byte mode the address pointer is not updated, in sequential it is, nothing more. Had you read what I wrote in previous replies you would realize that I do in fact understand the difference. At this point I don't think you even bothered to read anything I've written. Which leaves me wondering why you are even bothering to reply at all? Is this some sort of 'ego' thing for you? Were you surprised someone could write a 'robust' lcd library in 6 hours and felt you needed to prove 'yours was better'? Its not a competition... leave the ego at the door.

For example, you repeatedly stated my code 'should be a in library format with proper layers'. I also stated repeatedly that it was a stripped down, bare minimum example so that people on the forums didn't have to scroll through pages of boilerplate code. But this seemed to be ignored by you. Every other programming forum people always ask you to strip it down to its simplest version. You post only the bare minimum that can still cause the error. That's just standard protocol.

Using the MCP datasheet combined with the i2c bus timing based on the SCK clock speed and the number of bytes being transferred over the bus to control the output port, you have all the information needed to perform calculations for the output port update timing.

No I don't, without some way to know if there is some upper limit (something not in the spec), all those calculations are for naught.

I don't care anymore. I'm not releasing the library. Its not like any arduino user would want to use compile time polymorphism anyways, just the words alone scare 99% of people away (even though its not actually very difficult to use).

You know, I was going to add the necessary functions to support the Print interface (since I used something different) to benchmark it simply because you asked. I don't care about shaving off a few microseconds, its more than fast enough for my uses. But I thought: 'he was nice enough to help me out, I'll do as he asks'... but not anymore. I really don't care anymore.

If you want people to actually stick around on these forums, actually bother to read what they wrote if you intend to reply. Your conduct was rude and unprofessional.

25

I did read everything you typed, very closely in fact.

There are two types of timings: byte transfer to the LCD and LCD instruction execution times.
The timings in table 6 starting on page 24 is irrelevant for transferring bytes to the LCD. Table 6 timings are for how long the instruction takes to complete which is the amount of time that must pass before you can send another command if not using BUSY. Just keep in mind that the timing is for a 270khz reference clock design.
The actual clock could be faster or slower.
From what people have seen in the field, most LCDs are running this or faster but every now and then some people run into an LCD that is slower.

The timings for the initialization sequence commands in figures 23 and 24 on pages 45 and 46 are for a 100khz clock.
If you do the math you will see the timing is based on a worst case instruction time from table 6 starting on page 24 (there is more detail about this in the hd44780 code). This must be taking into consideration if the initialization code is to be robust enough to recover from a host and LCD that are out of nibble sync.

The timings for transferring bytes to the LCD are in figures 25 and 26 on page 58.
Those are what matter when transferring bytes to the LCD.
In order to have the most robust interface with the LCD those timings should be honored.
I will say that practical experience shows that you can violate tAS and make it shorter (including zero) and not have issues as long as not changing between reads and writes since the actual write data is clocked on the falling edge of E.
tAS is mainly to allow time for the bus signals to settle when changing transfer directions so you don't get a potential bus collision if you raise E for a write operation while R/W was still high for a previous read operation.

To know if you are honoring the signal timing, you will have to do some calculations as how the host talks to the LCD can make a big difference.

And YES byte mode on the MCP can make a BIG difference in how fast the output port pins can be updated.
byte mode is a different way of talking to the MCP chip and updating the output port that can be much faster as it has much less overhead - but it depends on the code driving the chip and how it uses it.

So you will have to take into consideration the i2c clock speed you are using along with the mode you are using for the MCP chip along with how you are actually sending the data bytes over the i2c bus to control the MCP output port to know if the timing for the signals you are creating conforms with the timing in the figures on page 58.

How it is done can make more than a 20x difference at how those low level signals are wiggled during a nibble transfer so it is up to you to do the math based on how you are using the part and what i2c clock rate you are using to verify the timing.

--- bill

26

Kaisha:

The reason there is no specified nor required delay between nibbles in the hd44780 specification is not another example of poor editing or translation whereas the lack of a specified delay for the execution time for the Clear Function is.

The HD44780 controller does not do anything with the first nibble until the second one has been received and the two nibbles have been reassembled, hence there is no execution time involved between the nibbles.

When you look at other versions of the datasheet from other manufacturers you see that the delay time for the Clear function is specified and is the same as the time for the Return Home function. My 1990 Optrex catalog is a reputable example. In my opinion this is an editing problem.

Don